Mark Peeters
Read all my blogsIn most SAP CRM implementations, Action BAdI’s are used to trigger automatic processing of business logic. This can vary from a follow-up document or trigger output, to complete custom logic to check certain business rules. There are many articles written on the creation of your own actions and how to schedule these. There is however a problem I kept running into. If you use your action to set a status on the CRM document in the background, the system does not determine the new actions that should be scheduled for this new status.
Problem
Determining which action should be scheduled is done by FM CRM_ACTION_DETERMINE. Triggering this function module in your own action will most likely lead to the loss of context though. Let me explain this with an example. Lets say we have three actions, each scheduled to be triggered on their own document status.
The outcome of the business logic in action 1 can lead to system status 2 or 3. The problem is that the system is unable to perform the redetermination of the ‘to-be’ situation. This is because the redetermination will find that action 1 is no longer valid, and so it will remove this action. But this is the action that is processed, so loss of context and system will dump. SAP has figured this out, so redetermination of actions while executing another is not done.
Solutions
One of the most used solutions is scheduling actions in advance, and working with start conditions. As shown in this picture.
A negative side effect of working like this is that the actions are scheduled before they need to be started, and that the system needs to evaluate the start condition every time a document is touched. This might not be a big problem in your specific scenario, but if you have to process thousands of documents daily, you want to optimize the situation. Also if you have several of these sequential actions on a document, the scheduling can become a project in itself due to complexity.
Another solution would be to have your action exist in the ‘to-be’ situation as well.
In this case you would also have to call the FM CRM_ACTION_DETERMINE again for your document after each action call. This can also lead to complex scheduling and misunderstandings in maintenance.
In my current project I had work with the situation of large amount of calls a day, and a lot of sequential actions. This led me to further investigate the possibilities of solving this, without “misusing” the action scheduling.
In the end, the solution was unexpectedly simple, and therefore I wanted to share it with you. I simply created my own custom FM ZCRM_ACTION_DETERMINE, and in this FM I execute the standard FM CRM_ACTION_DETERMINE and CRM_ORDER_SAVE for the the given order GUID (Importing parameter). To prevent the loss of context I created a new context by calling this FM with the option “Starting new task” as follows (You have to enable your new FM for remote usage):
CALL FUNCTION ‘ZCRM_ACTION_DETERMINE’ STARTING NEW TASK ‘REDETERMINE’
EXPORTING
iv_header_guid = iv_ref_guid
Now the new context triggers the action redetermination and all actions are executed as planned in the original setup of the action customizing.
Receive our weekly blog by email?
Subscribe here:
