When working on Customer Incidents I regularly come across a setup with an extremely slow rule set execution. This is not only causing issues in the SAP Event Management system. But for example the outbound queues in a connected application system might keep growing, even until failure if the performance does not get improved.
However, at the core of the bad performance of the rule set execution often are Rule Conditions, in particular those created with the Condition Editor. While conditions like this are easily created, especially without any ABAP knowledge, they have to be parsed and evaluated by the system in a very generic way.
Furthermore, due to the design of the condition evaluation in the event processing all parameters (control, info, system and event message parameters) need to be assembled and provided to the condition evaluator. The system cannot recognize, for example, that your condition is only comparing the event code with a constant, not using anything of the assembled parameter data.
Now, would it not be nice to get rid of both - the slow assembling of parameter data as well as the slow parsing and evaluation of the condition - while keeping the function?
In general this is not possible. You can get rid of the parsing/evaluation part by using Rule Condition Functions. But the parameter assembly will still happen, as the condition might use any of those parameters. And you would need to code ABAP, implementing the Rule Condition Function.
However, for the most common use case of a condition there is a rather easy way to get rid of the condition while still maintaining its function in the rule set.
The most common use case is comparing the event code of the current event message with a constant. You can see this kind of setup in one of the older SAP delivered rule sets, LTL_RULES:
The idea behind replacing this type of rule condition is moving the condition as well as the activity into a Multitask Activity. The first task of the Multitask Activity would perform the check for the event code, the second task would perform the activity, but only if the first task has a true result (RC = 0).
As an example, let us try to replace the PLANTDEP condition in the rule set. The activity which should be executed in case the current event code equals "PLANTDEPT" is STATUS_SET.
So the new Multitask Activity would look like this:
To summarize: Using a rule with such a Multitask Activity instead of the rule consisting of condition and activity will
Please note that this kind of replacement also works if the activity you are moving into a Multitask Activity is itself a Multitask Activity. Multitask Activities can be nested.
Related SAP Notes:
2398982 - Slow rule set execution due to using many rule conditions
2306668 - Improving the stability of rule set processing
2217722 - Check function for rule sets
However, at the core of the bad performance of the rule set execution often are Rule Conditions, in particular those created with the Condition Editor. While conditions like this are easily created, especially without any ABAP knowledge, they have to be parsed and evaluated by the system in a very generic way.
Furthermore, due to the design of the condition evaluation in the event processing all parameters (control, info, system and event message parameters) need to be assembled and provided to the condition evaluator. The system cannot recognize, for example, that your condition is only comparing the event code with a constant, not using anything of the assembled parameter data.
Now, would it not be nice to get rid of both - the slow assembling of parameter data as well as the slow parsing and evaluation of the condition - while keeping the function?
In general this is not possible. You can get rid of the parsing/evaluation part by using Rule Condition Functions. But the parameter assembly will still happen, as the condition might use any of those parameters. And you would need to code ABAP, implementing the Rule Condition Function.
However, for the most common use case of a condition there is a rather easy way to get rid of the condition while still maintaining its function in the rule set.
The most common use case is comparing the event code of the current event message with a constant. You can see this kind of setup in one of the older SAP delivered rule sets, LTL_RULES:
The idea behind replacing this type of rule condition is moving the condition as well as the activity into a Multitask Activity. The first task of the Multitask Activity would perform the check for the event code, the second task would perform the activity, but only if the first task has a true result (RC = 0).
As an example, let us try to replace the PLANTDEP condition in the rule set. The activity which should be executed in case the current event code equals "PLANTDEPT" is STATUS_SET.
So the new Multitask Activity would look like this:
To summarize: Using a rule with such a Multitask Activity instead of the rule consisting of condition and activity will
- prevent the slow parameter assembly (since there is no longer any condition),
- avoid the slow parsing and evaluation of general Rule Conditions (replaced by a task) and
- still execute the activity only if the original condition is true.
Please note that this kind of replacement also works if the activity you are moving into a Multitask Activity is itself a Multitask Activity. Multitask Activities can be nested.
Related SAP Notes:
2398982 - Slow rule set execution due to using many rule conditions
2306668 - Improving the stability of rule set processing
2217722 - Check function for rule sets
- SAP Managed Tags:
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
