I'm creating and updating my PM notifications via BAPI_ALM_NOTIF_CREATE and BAPI_ALM_NOTIF_DATA_MODIFY respectively.
BAPI_ALM_NOTIF_CREATE triggers user-exit EXIT_SAPLIQS0_017 (QQMA0025), but BAPI_ALM_NOTIF_DATA_MODIFY does not trigger user-exit EXIT_SAPMIWO0_020 (QQMA0014).
I was wondering if there is another BAPI or FM that triggers the user-exit for saving the notification and triggering the user-exit.
If not, what are my other options? Would an explicit enhancement be the next best thing?
This is what Enhancement Spot ES_SAPLIWOPM looks like. Does this mean only BAPI_ALM_NOTIF_DATA_DELETE is supported?
you could use the enhancement spot ES_SAPLIWOPM, it offers three enhancement points within BAPI_ALM_NOTIF_DATA_MODIFY. The enhancement spot doesn't seem to be limited to SAP internal use, so you could use it to implement your requirements. It also offers enhancement points for BAPI BAPI_ALM_NOTIF_CREATE, which would allow you to implement your requirements for create and update scenarios in the same technology.
Regarding the user exit from extension QQMA0014, the function module is contained in module pool SAPMIWO0 and seems to be called by a few function modules and from dynpro logic, but I'm not sure they are meant to be called from outside their regular dynpro scope. Often those function modules need quite a bit of preparation to work correctly. I would stick with the BAPIs, as they are clearly meant for this purpose and have extension points to implement additional requirements, which is always a big bonus in terms of extension maintenance.
edit: the enhancement spot is present in ECC 6.0 EHP8, I'm not sure about previous releases.
Can you check if any BAdi is getting triggered as well.
I think badi NOTIF_EVENT_POST is triggered after exit QQMA0014.
Regards
Related
In the scala and scalajs library Diode, I have used but not entirely understood the PotAction class and only recently discovered the AsyncAction class, both of which seem to be favored in situations involving, well, asynchronous requests. While I understand that, I don't entirely understand the design decisions and the naming choices, which seem to suggest a more narrow use case.
Specifically, both AsyncAction and PotAction require an initialModel and a next, as though both are modeling an asynchronous request for some kind of refreshable, updateable content rather than a command in the sense of CQRS. I have a somewhat-related question open regarding synchronous actions on form inputs by the way.
I have a few specific use cases in mind. I'd like to know a sketch (not asking for implementation, just the concept) of how you use something like PotAction in conjunction with any of:
Username/password authentication in a conventional flow
OpenAuth-style authentication with a third-party involved and a redirect
Token or cookie authentication behind the scenes
Server-side validation of form inputs
Submission of a command for a remote shell
All of these seem to be a bit different in nature to what I've seen using PotAction but I really want to use it because it has already been helpful when I am, say, rendering something based on the current state of the Pot.
Historically speaking, PotAction came first and then at a later time AsyncAction was generalized out of it (to support PotMap and PotVector), which may explain their relationship a bit. Both provide abstraction and state handling for processing async actions that retrieve remote data. So they were created for a very specific (and common) use case.
I wouldn't, however, use them for authentication as that is typically something you do even before your application is loaded, or any data requested from the server.
Form validation is usually a synchronous thing, you don't do it in the background while user is doing something else, so again Async/PotAction are not a very good match nor provide much added value.
Finally for the remote command use case PotAction might be a good fit, assuming you want to show the results of the command to the user when they are ready. Perhaps PotStream would be even better, depending on whether the command is producing a steady stream of data or just a single message.
In most cases you should use the various Pot structures for what they were meant for, that is, fetching and updating remote data, and maybe apply some of the ideas or internal models (such as the retry mechanism) to other request types.
All the Pot stuff was separated from Diode core into its own module to emphasize that they are just convenient helpers for working with Diode. Developers should feel free to create their own helpers (and contribute back to Diode!) for new use cases.
We are interested in using Odoo but we would need to modify it slightly for our use case, for instance modifying partner by adding fields, and integrating with an external system.
Is it best to fork it or to make a module with the changes in? The changes would be quite specific to our use case and existing system so it's unlikely it would be useful to anyone else as a module/app.
My thinking is that by forking it would be easier to stay up to date with Odoo - we just have to pull in changes from upstream occasionally. It seems like with a module you would end up with lots of stale code that's difficult to update because you've moved it outside the source tree.
It also seems like it would be easier to deploy because you have all the code in one place rather than two.
As from my POV and according to many years of ERP - experience, it is the best advice to implement those kind of changes always in an own module (inheriting all the required standard components) and leave the standard untouched. This applies also for very specific customizations as well as for general improvements.
This procedure provides you with the best flexibility in installing, updating, distributing and maintaining your code while not being touched when updates to the standard modules are carried out on the target systems.
You will also be able to share and move your code between dev/test/prod systems and applying a version control on it.
Please always make sure to be in line with valid license obligations applying to your code (especially when inheriting standard modules).
Hope this helps ;-)
I'm not very familiar with working with SAP but my current task is to utilize Rfc calls for creating purchase orders in SAP via a c# project I'm working on.
Is there any advantage to using direct Rfc calls instead of the BAPI? I asked my supervisor this and his reason was "to avoid the unknown/unneeded mess".
Our old program used the BAPI. I find with this task I'm now chasing my tail as I dive into metadata and resolve issues with using/getting the structures I need.
Things are working and coming along, but I just don't understand the insistence on using Rfc instead of BAPI.
Edit to clarify my poor terminology: We currently use a wrapper that then calls the BAPI for us. My task is to not use the wrapper but utilize the same Rfc calls the BAPI would.
Example:
IRfcFunction poCreateFunction = _dest.Repository.CreateFunction("BAPI_PO_CREATE1");
IRfcStructure poHeader = poCreateFunction.GetStructure("POHEADER");
poCreateFunction.SetValue("POHEADER", poHeader);
...
poCreateFunction.Invoke(_dest);
A technically correct, but somewhat unhelpful answer would be ?SYNTAX ERROR, followed by a huge blue blinking cursor.
BAPIs are RFC-enabled function modules, so there is no technical difference between calling a BAPI and any other RFC-enabled function module. The difference is that BAPIs are officially released for customer and partner use. They are supported, maintained and for the most part well documented - as opposed to some internal function module that for some technical reasons has to be RFC-enabled. There is a strict set of rules that any developer who wants to provide a BAPI has to obey in order to maintain a certain set of standards throughout the programming interface. It is true that BAPIs have rather lengthy parameter names and huge data structures to cover all kinds of special applications, but calling this a "mess" does not leave a positive impression...
Your supervisor gave you a very half-assed answer, and it makes you wonder if he understands what he is trying to achieve by forcing you to use custom (I assume) RFC's.
In .NET integrated projects I (as the ABAP programmer) will often provide wrapper RFC modules to hide some of the BAPI's complexity, or because the .NET side may not have all the information needed by the BAPI. This often results in a simpler interface, but with limited functionality. But in the end that just moves the BAPI call from .NET to within the ABAP stack.
If you are having issues with the supplied RFC function modules that does not occur when you are using the BAPI, there is probably something wrong with the function module. Or at the very least it does not serve the purpose of hiding SAP's complexity from the .NET program and does not provide you any benefit over using the standard BAPI's, which at least is well documented and supported.
I have almost 4 months learning/working in SAP. I've done several reports and enhancements all along this time but recently I began to work in a requirement which is related to Mobile Data Entry or RF and it basically consists to add the EAN and some other data to the dynpro 2502.
I made a copy of the dynpro 2502 in program SAPLLMOB into SAPLXLRF 9502, related the user exit MWMRF502 and programmed the basic functionality of it but it is not working as I expected because this exit is very limited and it only lets me import and export a small group of data and is difficult to perform exactly as the standard.
I've been searching all over internet and a lot of people make their own implementations and other just simply change the standard. I don't know how to make my own implementation cause I don't understand all the process within and the alternative of changing the standard code would be better for performance and time spent in development but as I quoted I would have to change the standard code and that's something I would like to do only if there's no other option.
But the question is ¿Is it OK to change the standard? ¿How often is the the standard code changed in SAP implementations? ¿What would be the better alternative?
Thanks in advance.
You are asking the right sort of questions and it is good that you are not just plowing ahead without thinking about the consequences of what you are doing. Keep researching!
As far as changing the SAP standard goes, you generally do not want to copy an object to change it. For screens SAP quite often creates a user-exit with a sub-screen that can be modified by the customer. For Web-Dynpro you can use enhancement points and/or bADI's to extend the functionality.
Try to look for one of the following:
A SAP BAdI in the area that you want to change (transaction SE18),
a user-exit allowing you to change the necessary screen(s) (transaction SMOD),
explicit enhancement points within the functionality,
one of the implicit enhancement points in functionality
There are a lot of documentation on sdn.sap.com as well as within the SAP help regarding the topics above.
If none of are available, you may have no other choice but to modify (repair) the SAP standard objects. In order to be able to change the SAP standard you need to register the object(s) that you have to change on SAP OSS and get a repair key that the system needs to allow you to make changes. Always ensure that the SAP Modification Assistant is switched on when making changes, this will make your life a lot easier when you patch or upgrade your system.
If at all possible try to find an experienced ABAP programmer to help you with this.
Also see this question regarding changing SAP standard code:
Edit: Thomas Weiss on SDN has a helpful blog series on the enhancement and switch framework.
Always make sure that there's absolutely no other way to implement the functionality you need. If you're sure about that, then either write your own implementation from scratch, or simply change SAP's code. Just don't copy SAP's programs to the customer namespace, because I can guarantee you that that'll turn into a maintenance nightmare. You'll have to decide yourself whether the size of the change is worth the time building your own implementation, or changing SAP's.
If you decide to change SAP's code, keep in mind that all changes will pop up for review when the system is upgraded, which will take time to evaluate and adjust to the new SAP code.
Your options are, from most to least desirable:
Check the documentation of the application on help.sap.com for possible extensibility scenarios. There are many ways how SAP intends for you to customize their applications through various kinds of event architectures. Unfortunately any attempts by the various departments at SAP to agree on one event architecture and then stick to it failed. So you have user exits, BTEs, FQEVENTS, BAdIs, explicit enhancement spots and many more. If you want to know what's used by the application you need to change, RTM.
Use an implicit enhancement spot. Enhancements are a great way to modify standard software in ways SAP did not anticipate, because they are easy to disable and usually pretty stable during upgrades (use the transaction SPAU_ENH after an upgrade to confirm that your enhancements still make sense in the new version of the program). You will find implicit enhancement spots at the beginning and end of every include and every kind of subroutine, which allows you to inject arbitrary ABAP code in these locations.
But sometimes there just is no implicit enhancement spot where you need it to be. In that case you can copy the whole program into the customer-namespace and modify it. This gives you the freedom to do whatever you want with the program while still retaining the original program as a possible fall-back. It is usually a good idea to use as many components from the original program as possible, by including its includes or calling FORMs from the original program via PERFORM formname IN PROGRAM originalprogram. The main problem with this method is that after a new release, your program might no longer behave as expected. You will have to look at the new version of the program and see if there are any changes you need to port to your version. And there is nothing in the SAP standard that assists you with this maintenance task. So you are responsible to keep a list of all your copies of standard programs.
Just modify the program directly. But this is really a last-resort option for programs that are too complex to copy into the customer-namespace. The problem with this is that it means SAP will no longer offer you support for that program. If you post a ticket about that program on launchpad.support.sap.com, and they find out you modified the program, they will assume it's your own fault and close the ticket. But fortunately, when you upgrade your system, you have the transaction SPAU that will help you to merge your changes with the new versions of the modified SAP programs.
AOP is an interesting programming paradigm in my opinion. However, there haven't been discussions about it yet here on stackoverflow (at least I couldn't find them). What do you think about it in general? Do you use AOP in your projects? Or do you think it's rather a niche technology that won't be around for a long time or won't make it into the mainstream (like OOP did, at least in theory ;))?
If you do use AOP then please let us know which tools you use as well. Thanks!
Python supports AOP by letting you dynamically modify its classes at runtime (which in Python is typically called monkeypatching rather than AOP). Here are some of my AOP use cases:
I have a website in which every page is generated by a Python function. I'd like to take a class and make all of the webpages generated by that class password-protected. AOP comes to the rescue; before each function is called, I do the appropriate session checking and redirect if necessary.
I'd like to do some logging and profiling on a bunch of functions in my program during its actual usage. AOP lets me calculate timing and print data to log files without actually modifying any of these functions.
I have a module or class full of non-thread-safe functions and I find myself using it in some multi-threaded code. Some AOP adds locking around these function calls without having to go into the library and change anything.
This kind of thing doesn't come up very often, but whenever it does, monkeypatching is VERY useful. Python also has decorators which implement the Decorator design pattern (http://en.wikipedia.org/wiki/Decorator_pattern) to accomplish similar things.
Note that dynamically modifying classes can also let you work around bugs or add features to a third-party library without actually having to modify that library. I almost never need to do this, but the few times it's come up it's been incredibly useful.
Yes.
Orthogonal concerns, like security, are best done with AOP-style interception. Whether that is done automatically (through something like a dependency injection container) or manually is unimportant to the end goal.
One example: the "before/after" attributes in xUnit.net (an open source project I run) are a form of AOP-style method interception. You decorate your test methods with these attributes, and just before and after that test method runs, your code is called. It can be used for things like setting up a database and rolling back the results, changing the security context in which the test runs, etc.
Another example: the filter attributes in ASP.NET MVC also act like specialized AOP-style method interceptors. One, for instance, allows you to say how unhandled errors should be treated, if they happen in your action method.
Many dependency injection containers, including Castle Windsor and Unity, support this behavior either "in the box" or through the use of extensions.
I don't understand how one can handle cross-cutting concerns like logging, security, transaction management, exception-handling in a clean fashion without using AOP.
Anyone using the Spring framework (probably about 50% of Java enterprise developers) is using AOP whether they know it or not.
At Terracotta we use AOP and bytecode instrumentation pretty extensively to integrate with and instrument third-party software. For example, our Spring intergration is accomplished in large part by using aspectwerkz. In a nutshell, we need to intercept calls to Spring beans and bean factories at various points in order to cluster them.
So AOP can be useful for integrating with third party code that can't otherwise be modified. However, we've found there is a huge pitfall - if possible, only use the third party public API in your join points, otherwise you risk having your code broken by a change to some private method in the next minor release, and it becomes a maintenance nightmare.
AOP and transaction demarcation is a match made in heaven. We use Spring AOP #Transaction annotations, it makes for easier and more intuitive tx-demarcation than I've ever seen anywhere else.
We used aspectJ in one of my big projects for quite some time. The project was made up of several web services, each with several functions, which was the front end for a complicated document processing/querying system. Somewhere around 75k lines of code. We used aspects for two relatively minor pieces of functionality.
First was tracing application flow. We created an aspect that ran before and after each function call to print out "entered 'function'" and "exited 'function'". With the function selector thing (pointcut maybe? I don't remember the right name) we were able to use this as a debugging tool, selecting only functions that we wanted to trace at a given time. This was a really nice use for aspects in our project.
The second thing we did was application specific metrics. We put aspects around our web service methods to capture timing, object information, etc. and dump the results in a database. This was nice because we could capture this information, but still keep all of that capture code separate from the "real" code that did the work.
I've read about some nice solutions that aspects can bring to the table, but I'm still not convinced that they can really do anything that you couldn't do (maybe better) with "normal" technology. For example, I couldn't think of any major feature or functionality that any of our projects needed that couldn't be done just as easily without aspects - where I've found aspects useful are the kind of minor things that I've mentioned.
I use AOP heavily in my C# applications. I'm not a huge fan of having to use Attributes, so I used Castle DynamicProxy and Boo to apply aspects at runtime without polluting my code
We use AOP in our session facade to provide a consistent framework for our customers to customize our application. This allows us to expose a single point of customization without having to add manual hook support in for each method.
Additionally, AOP provides a single point of configuration for additional transaction setup and teardown, and the usual logging things. All told, much more maintainable than doing all of this by hand.
The main application I work on includes a script host. AOP allows the host to examine the properties of a script before deciding whether or not to load the script into the Application Domain. Since some of the scripts are quite cumbersome, this makes for much faster loading at run-time.
We also use and plan to use a significant number of attributes for things like compiler control, flow control and in-IDE debugging, which do not need to be part of the final distributed application.
We use PostSharp for our AOP solution. We have caching, error handling, and database retry aspects that we currently use and are in the process of making our security checks an Aspect.
Works great for us. Developers really do like the separation of concerns. The Architects really like having the platform level logic consolidated in one location.
The PostSharp library is a post compiler that does the injection of the code. It has a library of pre-defined intercepts that are brain dead easy to implement. It feels like wiring in event handlers.
Yes, we do use AOP in application programming . I preferably use AspectJ for integrating aop in my Spring applications. Have a look at this article for getting a broader prospective for the same.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html