In this blog we will discuss performance best practices for workflows. For more information on workflows itself please follow this link
Workflow time is the amount of time spent while executing the defined events for that business object. It is represented by the value in the “Workflow Time” column in the in-tenant performance report. In the screenshots I have used the report “(Beta) End to End Response Time” under either the business analytics (HTML5 client) or under analysis (Fiori client). In case you are not able to see the fields please make sure you have added the fields to the report. The workflow time is sub component of the server time. Therefore the report will always show total server time.
Fig 1: Adding fields to the End to End performance report.
In the below screenshots I have workflow rules attached to the Ticket object. Currently all the rules are active as shown below.
Based on the above rules when a ticket is created or updated these workflow rules are run and it takes a certain amount of time on the server side. As shown below, during ticket create it takes 0.48seconds or 480ms to run all the rules. Please note this is the time just to run the rules and does not include the server time to run rest of the logic. Here for the same row the total server time takes 1.68seconds.
Now just to show the impact of these rules on the server time we will disable these workflow rules.
After disabling these rules and when we create a similar ticket we can see that now it takes only 0.03seconds or 30ms. The total server time in this case is 1.42seconds.
As we can see that we need to be judicious and plan in advance with the number or the types of the event of these rules, otherwise we may impact the total server time resulting in longer end to end times or poor front end response times.
Therefore while configuring workflow rules please note the following best practices:
- Workflow rules that are set to with “Timing”, “On Every Create/ On Every Save” is run synchronously. If you have too many of these rules then you would affect performance. Therefore see if you can consolidate these rules
- In many cases the use of “Scheduled” option may be possible. In this case the rules run asynchronously. They can also be monitored and are reliable. Therefore if your use case allows the use of “Scheduled” then please do so
- Workflow times will affect all users using the business object within a process
- Use service routing capabilities instead of workflow for ticket routing
- Combine conditions for workflow in a single rule rather than having multiple rules
- Do not assign more than 100 rules per business object
- In case of complex field update conditions with 50 or more checks, it is better to use Cloud SDK/PDI
- Avoid the use of custom BO actions which execute synchronous web service call within a workflow. If required use scheduling
- Creation of email activity as part of workflow rules will result in longer save times
- Use Schedule (5min) instead of “On Every Create/Save”