Business Rules of SAP Field Service Management allow to automate business processes with high flexibility.
The challenge when utilizing their possibilities and advantages often is, to define them in an efficient and high-performing way without putting high load to the system and having impact on system performance.
Therefore in this blog are summarized some points which are worth to consider.
A high number of skipped executions puts an additional load to the system, because variables of the Business Rule need to be determined before conditions, which decide whether the rule will be executed or skipped, are evaluated.
How could you avoid skipped executions? Dependent on usage and needs of the rule, one of the possibilities outlined below might help:
Sometimes a possibility might be to define a scheduled rule with a selective CoreSQL WHERE Clause in the trigger instead of an event triggered rule like in the following example:
Inefficient rule with many skipped executions:
Analogous rule via scheduled trigger without skipped executions:
Another possibility to reduce skipped executions might be to combine several rules with same or similar trigger into one rule.
In case you have rules, which are triggered on the same event, such as ‘On Object Update’ for Object Type ‘ServiceCall’ but they have different conditions, you might consider making use of the action ‘Execute Conditional Operation’. Via this action you can define conditions which are related to specific actions.
Example:
Sometimes there are scheduled rules which have repeated skipped executions.
This often can be avoided by considering the timeframe within the CoreSQL WHERE Clause in dependency of the frequency.
Example:
Sometimes there are scheduled rules with a condition which relates to the object type in the trigger. Such conditions should be avoided but instead the CoreSQL WHERE Clause of the trigger should be enhanced accordingly.
If possible make use of predefined variables like ${old} or ${fsmEvent} in the conditions. These variables do not have to be read from the DB during the execution and it can be quickly decided if a rule should be executed.
Example: If there is a rule, which reacts on “Object Update” and which updates a specific field with some value, check first if the value is not already as desired. This will avoid updating the object with the same values and will avoid triggering additional events.
Please use delays cautiously. Managing delayed executions puts additional load on the system, which has an impact on system performance.
Therefore, please check whether a delay really is needed. Sometimes the better approach is
If you define variables of type Array, make sure that you select only data which are really required.
Therefore, select only the required fields instead of selecting the whole object with all its fields.
If possible, make use of further SQL clauses or functions when defining variables, such as defining a limit or using count().
The risk of defining recursive executions (or endless loops) may occur for example if you use API-Calls within action ‘Webhook’ or ‘FSM Webhook’ and via these API-Calls another rule execution is triggered.
Another source of recursive rule executions might be synchronization scenarios, for example if the action ‘Update Object’ triggers a synchronization with an ERP and the ERP on his part reacts with another update of this object, which then is sent to FSM.
Often you can avoid such endless loops by defining very precise conditions to ensure the rule only is executed if really needed.
Via automated health checks we regularly send notifications via email to the technical contact, in case it looks like there might be room for improvement, for example
Perhaps the one or the other point mentioned above is helpful for you when defining Business Rules.
If you have any related feedback or thoughts, please feel encouraged to share it in the comment section.
The challenge when utilizing their possibilities and advantages often is, to define them in an efficient and high-performing way without putting high load to the system and having impact on system performance.
Therefore in this blog are summarized some points which are worth to consider.
How to define efficient high-performance Business Rules
1 Avoid rules with many skipped executions
A high number of skipped executions puts an additional load to the system, because variables of the Business Rule need to be determined before conditions, which decide whether the rule will be executed or skipped, are evaluated.
How could you avoid skipped executions? Dependent on usage and needs of the rule, one of the possibilities outlined below might help:
1.1 Turn event triggered rule into a scheduled rule
Sometimes a possibility might be to define a scheduled rule with a selective CoreSQL WHERE Clause in the trigger instead of an event triggered rule like in the following example:
Inefficient rule with many skipped executions:
Analogous rule via scheduled trigger without skipped executions:
1.2 Combine several rules into one rule
Another possibility to reduce skipped executions might be to combine several rules with same or similar trigger into one rule.
In case you have rules, which are triggered on the same event, such as ‘On Object Update’ for Object Type ‘ServiceCall’ but they have different conditions, you might consider making use of the action ‘Execute Conditional Operation’. Via this action you can define conditions which are related to specific actions.
Example:
1.3 Avoid repeated skipped executions in scheduled rules
Sometimes there are scheduled rules which have repeated skipped executions.
This often can be avoided by considering the timeframe within the CoreSQL WHERE Clause in dependency of the frequency.
Example:
1.4 Make CoreSQL WHERE Clause as selective as possible
Sometimes there are scheduled rules with a condition which relates to the object type in the trigger. Such conditions should be avoided but instead the CoreSQL WHERE Clause of the trigger should be enhanced accordingly.
2 Use smart conditions
2.1 Use the predefined variables for conditions
If possible make use of predefined variables like ${old} or ${fsmEvent} in the conditions. These variables do not have to be read from the DB during the execution and it can be quickly decided if a rule should be executed.
2.1 Add checks for fields and values, which you plan to update
Example: If there is a rule, which reacts on “Object Update” and which updates a specific field with some value, check first if the value is not already as desired. This will avoid updating the object with the same values and will avoid triggering additional events.
3 Avoid rules which have defined a delay
Please use delays cautiously. Managing delayed executions puts additional load on the system, which has an impact on system performance.
Therefore, please check whether a delay really is needed. Sometimes the better approach is
- Make use of the field ‘order’ when defining rules
- Trigger the rule based on a convenient FSM event
- Define a scheduled rule instead of an event triggered rule with delay
- Use variables like ${old} or ${fsmEvent} for conditions checks (see point 2.1)
4 Define variables as small as possible
If you define variables of type Array, make sure that you select only data which are really required.
Therefore, select only the required fields instead of selecting the whole object with all its fields.
If possible, make use of further SQL clauses or functions when defining variables, such as defining a limit or using count().
5 Avoid defining recursive rule executions
The risk of defining recursive executions (or endless loops) may occur for example if you use API-Calls within action ‘Webhook’ or ‘FSM Webhook’ and via these API-Calls another rule execution is triggered.
Another source of recursive rule executions might be synchronization scenarios, for example if the action ‘Update Object’ triggers a synchronization with an ERP and the ERP on his part reacts with another update of this object, which then is sent to FSM.
Often you can avoid such endless loops by defining very precise conditions to ensure the rule only is executed if really needed.
6 Ensure a valid technical contact is assigned to your rules
Via automated health checks we regularly send notifications via email to the technical contact, in case it looks like there might be room for improvement, for example
- In case there is a high percentage of failed executions or
- In case there is a huge percentage of skipped executions or
- In case it looks like there might be an endless loop.
Thank you for Reading!
Perhaps the one or the other point mentioned above is helpful for you when defining Business Rules.
If you have any related feedback or thoughts, please feel encouraged to share it in the comment section.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 11 | |
| 8 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
