Optimize the performance of your Cloud for Service implementation – Part 2
This is the second part of a blog post on how administrators can optimize the performance of SAP Hybris Cloud for Service. You can find Part 1 here.
So far we have reviewed how to optimize the Ticket UI, which is a basic first step towards achieving good performance. Let’s now have a look at a few other ways to further minimize the waste of resources.
As you probably already know, scoping questions are the mechanism through which an admin can decide which features should be active in a tenant. These questions are usually answered during the initial implementation project, but can be changed at any time (via Business Configuration -> Implementation Projects). A few of these questions can make quite a difference in terms of performance.
- If your scenarios do not require Tags, Sentiment Analysis, or Product Recognition, consider disabling the automatic Text Analysis.
- SAP Hybris Cloud for Service comes out-of-the-box with quite sophisticated text analysis capabilities. These capabilities allow the system to automatically recognize the sentiment of a social media message, the keywords within an email, and even a product name mentioned by the customer.
- However, basic customer service scenarios often do not require such complex analysis, in particular when they do not involve the high volumes of social media engagement. Since text analysis is enabled by default, turning it off can be a good way to save precious resources.
- There are three scoping questions connected to text analysis, as you can see in the pictures below. Check all of them in order to completely disable text analysis.
- If your agents do not need access to a knowledge base repository, consider disabling Knowledge Base integration.
- The Ticket UI includes a standard section, the Solution Finder, which makes it really easy to access an external knowledge repository, consult articles, and share links with customers. Any repository supporting Open Search can be connected in just a few minutes of configuration.
- However, many companies do not have or do not need a knowledge base repository, for example because most of the questions can be answered by accessing some other external system, such as SAP ECC.
- In such cases, disabling the KB integration via scoping is even more effective than simply hiding the Solution Finder section from the UI. You can disable it by checking the question in the picture below.
The workflow engine of Cloud for Customer provides an extra layer of flexibility readily available to the administrator. The system can be configured to automatically send emails, notifications, SMS, or to update objects and execute logic. The following best practices will allow you to get the best out of the workflow engine without impacting your system performance.
- Avoid using workflow rules for tasks that can be covered by more specialized engines.
- A common mistake is using workflow Field Update rules for ticket routing, rather than using the Ticket Routing Rules available under Administrator -> Service and Social.
- Both approaches will achieve the objective of updating the agent or team of a ticket, but the Ticket Routing Rules will do it much more efficiently. The routing rules are configured as a decision table that the system can evaluate as a whole, rather than as independent rules. Moreover, when using Ticket Routing Rules the system will stop at the first match, while all workflow rules need to be evaluated each time.
- The only situation in which it may makes sense to use Field Updates is when you need to re-route a ticket as a consequence of a specific event.
- Every workflow rule has an incremental impact on performance. If you can achieve the same objective with a more efficient engine, avoid creating workflow rules.
- Avoid defining workflow rules with timing “On Every Save” when “On Create Only” or “Scheduled” would work as well.
- Minimize the number of times a rule needs to be evaluated by making sure you define the timing correctly. Many rules can be evaluated “On Create Only”, for example those triggered by the channel or customer of the ticket.
- Rules “On Every Save” are evaluated and executed synchronously every time the ticket is changed. If you define them as “Scheduled” the rule will be evaluated immediately but executed later, and the scheduling engine will balance the load according to the available resources. Most rules that trigger communications to customers can usually be “Scheduled”.
- Every workflow rule “On Every Save” has an incremental impact on the Save time of the ticket. Minimize these rules by leveraging the other available options.
- Leverage condition operators to minimize the total number of rules.
- When different conditions need to trigger the same result, they can be combined with an OR operator (by using Add Group).
- Many fields allow you to define conditions based on patterns, rather than on specific values. This way a single condition can cover multiple scenarios. For example, if your ticket categories IDs follow a specific pattern, this feature would allow you to match multiple categories with one condition.
- The best practice of minimizing the number of rules is of course valid also for all other engines within Cloud for Customer: Ticket Routing, SLA Determination, Activity Plan Routing, etc. Always take advantage of condition operators to keep the rule definition as compact as possible.
Finally, a few general recommendations, not specifically related to Cloud for Service but very important if you are looking to optimize your performance. You can find a more complete overview here: SAP Hybris Cloud for Customer: Performance Landing Page.
The browser is often neglected, but it is a critical component between the user and any web application. Here are a few things to keep in mind:
- We have noticed that, compared to other browsers, Chrome tends to perform better and provide a better experience. Consider using it if possible.
- All screens within Cloud for Customer are rendered as a combination of metadata, which describes the screen structure, and actual data. The actual data is loaded every time from the server, but the metadata can be cached on the client. If your caching policy clears the cache too often, this will force the browser to download the metadata every time, impacting the end-user’s experience. For more information, see also this article.
- Browsers also provide important tools to inspect potential performance issues. By using HttpWatch or the Developer Tools you can analyze the performance impact of every change and customization.
SAP Cloud Applications Studio is a great tool to shape Cloud for Customer based on your specific needs. However, it is important to keep track of the performance impact of each customization, as they can easily add up.
- Embedded components add to the total number of http calls required to load a screen. If possible, avoid adding embedded components to the Header or Overview facet of the Ticket UI. The Ticket UI includes, in both the Overview and Service and Repair facets, standard anchors that can be used to group fields into new sections, reducing the need for custom components.
- Synchronous logic can easily add to the time required to save a ticket. Rather than adding logic “before save”, consider using a custom batch job, or encapsulating the logic within a custom action to be called asynchronously by a scheduled workflow rule.
- While you implement any customization, keep a close eye on HttpWatch or the browser Developer Tools in order to track the impact of your changes on the number of http calls and on the end-to-end response time.
Working through all these best practices will allow you to keep the performance of your tenant close to the ideal baseline. Your agents will be able to focus on handling tickets promptly, and your customers will be grateful for that. Run better, with SAP Hybris Cloud for Service.
Have you found other interesting ways to improve performance? Don’t forget to share them in the comments!
All the best,
Great post, thank you.
I have found the workflows work quite well for routing tickets when there are more complex scenarios, but I agree that ticket routing rules should rather be used where possible. Busy exploring this to see if this can be used rather than workflows with our complex scenario.
Two questions, not related to one another -
1. Does ticket routing rules run on every save like workflow can or only on create?
2. With your knowledge of the Service Environment, is it in SAP's roadmap to bring more ERMS functionality into C4C? Specifically, will there ever be text analysis of the email body (inbound email from the customer) to determine the team the ticket should be routed to? Can you comment on that?
Look forward to hearing from you
Thank you. Here are some comments to your questions:
1. Standard routing rules are only triggered on create. If you need to re-route automatically after a change, that's when you may want to use a Field Update rule. We plan to eventually expose the ability to re-trigger Routing (to avoid the need for a field update even in this scenario), but we don't have a timeline for it yet.
2. Yes, that's on our roadmap. Our ERMS capabilities are improving with every release (I should write a series of posts on it), and the fact that the Ticket Description (which is inherited from the body of the first email) cannot be used for Workflow or Routing is a known gap. We plan to fix it in one of our future releases.
2 years since this reply but no improvement on ticket routing rules execution - they are not called on ticket changes or ticket save. I noticed that the routing rules are executed on status change which is good but not enough though - as mostly the service categorization decides which team the ticket should go to & sadly the routing rules aren't executed on categorization change so a large number of workflows are still need to be created and maintained 🙁