Actions in SAP CRM Part 2: Action conditions and execution
In the previous blog I’ve discussed how action profiles can be set up and how it is possible to reuse actions and be more flexible in determining profiles through common profiles and action profile determination.
Now, let’s turn to action conditions. Especially if you plan to use a lot of actions in your processes, setting up conditions the right way will prevent performance problems and allow for future reuse.
So, actions have been created and correctly linked (or determined) via the profile. Time to focus when to execute them. This is done with action conditions. You can base them on attributes from the transaction or item at hand. Probably most often used are attributes like user or system status, priority, or a milestone.
There’s a few tips and tricks here that I’d like to share, but let’s start with the difference between the two types of conditions that are available in SAP CRM.
Schedule vs start conditions
Schedule conditions define when an action is put on the list of executable actions within the object. Once it is put there, it will be executed as soon as the start condition is met.
- By not assigning a schedule condition, the action will be added to the list of executable actions automatically or manually.
- By not assigning a start condition, it is possible to execute the action automatically or manually.
This seems quite straightforward, but there’s more to it:
- Once an action is scheduled, it will be considered during a (background) run of the action selection report. This impacts performance of the jobs you plan to use.
- If you want to tirgger actions based on a milestone (e.g., contract end date has passed), you should use a Start Condition: schedule conditions are only checked if there is a change in the transaction and this means that the contract end date has long passed before the transaction is ‘touched’ again and the action is finally executed.
- You can assign both a schedule and a start condition to one action. In such cases, the start condition is only considered if the action’s schedule condition was fulfilled.
As these points show, there is a conflict here: using too many schedule conditions may impact performance, but only using start conditions disallows you to plan actions based on milestones. Later, we will look into the solution that SAP provides for this, and milestone-based actions in general. Let’s first discuss setting up conditions in general, and running a background job.
Setting up action conditions
When you click on Define Conditions in the customizing, you will see the following screen:
Action Condition Maintenance
I won’t go into all the details of this screen, but I would like to highlight a few elements:
- with the Technical Names-button you can switch between the description of the action and action profile to the technical names. This can be very handy if you have non-unique descriptions
- setting up conditions is done with an editor in which you link attributes to values with help of expressions.
- you can reuse conditions after you created them (you can get an overview of all conditions by cllicking on the Schedule Conditions or Start Conditions-buttons).
- Reusing conditions is particularly useful if you are using common profiles. As highlighted in my blog on action profiles, common profiles can be used to reuse actions in various action profiles without having to configure them again and again. These embedded actions’ conditions need to be set up per action profile that uses them. By reusing these conditions, you can easily do this.
- Please note that reusing conditions is only possible within:
- the same type of condition (schedule / start)
- the same item category
- As a general rule of thumb you should consider a naming convention for your conditions (e.g.: [item category] [description of condition]). Too often you see condition names that tell more about the action that they are linked to, than what they actually check. Reusing them will then be quite hard!
- If you want to setup an action without any conditions, you should still add it in this screen (right top corner). If you forget this, the action will not work.
Now that the action profiles, its actions and conditions are set up, it is time to see how actions are executed. As you recall, there are three moments on which actions are executed:
- Immediate processing:as soon as the action should be executed (either by an automatic or a manual trigger), it will be executed. Typically, an end user is working in the transaction when this occurs.
- This option will lead to wait time for the end user. Therefore, I would only advise it if user feedback is required or if the action is highly time critical.
- Processing when saving the document:when the user or a background process saves the order, the action is executed.
- This option may also impact the end user’s experience.
- Processing using selection report: during order processing, the action(s) will only be scheduled. Execution will be done by running the action processing program (transaction code: CRMC_ACTION_JOB).
- Within action customizing you can allow end users to execute the action directly, so they don’t need to wait for the program to run.
- Let’s look into the action selection report with some more detail.
- ‘Processing without dialog’: if set, the selected actions are executed directly. This should be set in case of a background job.
- ‘Restricted Log’: will prevent a spool to be created. The action processing logs (that can also be found in SLG1) will still be filled.
Setting up an action that should be executed after a period of time can seem quite tricky at first. This is because a number of elements should be correctly setup before the action is actually scheduled at the right moment. These are the things you should get straight:
- Set up a date profile to calculate your milestone
- Hint: give different names to the date types and date rules, even though this is not required
- Be sure to include the standard date rule TODAYTIME in your profile (this will always give the current date+time when executed; we will need it in the next step)
- In action condition maintenance, create a start condition that checks whether TODAYTIME is greater than or equal to the date type
Now let’s assume we want to run a hourly background job that executes actions. This would have to check all start conditions with milestones again and again, even if the milestone will not be reached within another 6 months! That’s why optimization rules were introduced.
With help of optimization rules, you can have the background job calculate when the start condition will be met. In the example above, in six months time. The system will write this in a table and, the next time the job is executed, simply skip the start condition because it already found that this condition is not yet met. This functionality improves performance and requires two configuration activities:
- In the action condition maintenance, select the date type that you want to use as an Optimization Rule. If you look at the previous picture, you can already see that an Optimization Rule was linked.
- In the action job, be sure to flag the Use Optimization Rules option.
- Note: typically you run this report in a background job. Make sure to set up the variant attributes like in the picture below. it ensures that each time the job is run, the current date and time are considered.
I tried this with a different case:
-Created my action profile(say:ZOPP_HDR) for Object type: BUS2000111 (CRM Opportunity)
-Defined a action in the profile, where processing time is when saving the document, partner dependant on partner function: 00000014 (Employee responsible)
-Defined processing type: Method Call and implemented the BADI.
-Set Schedule condition:
-Created a custom transaction type for Trans. Category: Opportunity
-assigned the action profile (ZOPP_HDR) to this transaction type.
-Created a new document of the new transaction type and set the status to <userstatus>(E0004) and save.
-I can see correct status in table CRM_JEST as active.
-Transaction 'SPPFP' has no records for my action definition.
What could have gone wrong?
Is there any other way to check if action was executed at all?
In your testing I miss the step where you added a partner in role 00000014. Guess you did include that too?
You can also check in the order itself by going to the assignment block Scheduled Actions. The action should be scheduled directly after you updated the status in the order and thereby become visible in that block.
This was the problem. I could see SPPFP entry after I removed 'Partner-Dependant' flag. Could you please explain the purpose of this? Also, What should happen if I specify partner function but no partner ID?
If you make an action partner-dependent, it will only be scheduled if a partner is added with the specified function. This is be used, for instance, if you want to send mails only to the contact person in a transaction: if none has been entered (yet), the mail will not be sent. If you would not make such an action partner-dependent, the logic would not know who to send the mail to.
Your document is very helpful, I have created a post in SAP SCN to trigger service order's based on service contract validity periods
Could you please help me how do I resolve the same I am using action profiles using start conditions. My condition given in the below e.x. is wrong however I am unable to find the correct condition.
I have an issue with a action that its not trigered eventhough the initial condition is validated.
The Start condition is based on the status, we have succesfully tested the action if we check that the User status is Z..Open/Pending/... but we need it to check the one Zfinish that is linked to the transaction FINI.
The condition keeps correct, but the action is not trigered SAP CRM 7 EHP 2?
Thanks for your reply. It is hard to come up with a suggestion based on this description alone. Can you create a discussion on SCN? You can include screenshots to make it a bit more clear.
Nice post, but i have a question on how to schedule an action every 15mins ?
I have created a post here.
Appreciate your input.
SOLMAN 7.1 PPF Action - Send email notification for a status every 15mins, fixed duration
Thanks in advance
I just replied to that question. Most importantly: you need to schedule a new action every time the prequisites are met, even if such an action was already executed before. Then, with the RSPPFPROCESS report, you execute the new action. Once executed, the system will automatically schedule a new action again (as long as the schedule condition is met).
I have a query regarding the actions. Can the item data be used for creating an action at the header level.
I am not able to find any conditions for that in the condition editor.
No, this is not possible. What I used to do in such cases is the following:
- Add an action on item level which sets another user status on header level (this requires some development but is rather straightforward)
- Set a schedule condition on this header status in a new header action.
I have a question.
On the existing Action Definition I changed schedule and start condition. Now I have a problem with the old events that have been scheduled with the initial conditions.
Is there a standard way to update existing events, and thus update according to the new conditions.
thanks for the post,
I would like to ask you something about rescheduled.
I would ike to planify an action automatically when it fails. Ie, If I run the action and if it fails, i want to scheduled another one automatically.
In customizing I have filled the field Action Merging with the value: Max. 1Unprocessed Action for each action definition. So, I can reprocesed the erroneous action until it gets correct, but it does not planify another action. Is it possible?.
I need to run in batch the report RSPPFPROCESS with filter in field Action status, and I would like to insert in the filter Not processed. It is why I need what I have explained.
Thanks and regards
Thank you Joost , a great document.
I have an scenario here, Just wondering is it possible to do something without any badi implementation.
I want to cancel all my open contracts if sy-datum > Contract Expiry date.
In the system if i have 10 documents which needs to be cancelled, if the second document is having errors, then job sets to cancelled and other 8 documents are not being processed.
Is there something settings which i can proceed with processing of other documents even though system faces any error documents in between.