C4C Performance Update – What’s new in 1702
Performance is an integral part of SAP Hybris Cloud for Customer development process. In 1702 (February 2017) release, we have included many performance improvements which are summarized below.
| Area | Description | |
| 1. | Improved Server Time | Improved server logic in 8 (eight) objects for Quick Create - Save & Open |
| 2. | Improved Time to Interact (TTI)1 | Faster TTI due to decoupled server logic. Example “Check and Determine3” process in Thing Inspector is performed asynchronously and separately from the main object’s core logic |
| 3. | Reduction in Cold Starts2 | - Optimistic Pre-fetch of static floorplan metadata asynchronously - Increased MAX-AGE of static assets that are cached on browser to 365 days thereby reducing need to download static objects every 14 days |
| 4. | Mobile Offline | Enhancements in local device storage and access mechanisms improved performance across more than 130 |
Note: The performance improvements mentioned above can vary from customer to customer
depending on customizations, network conditions, location of the user and other factors.
Now let’s dive into the details of each one of the updates
listed above.
1. Improved server logic in 8 (eight) objects for Quick Create - Save & Open:
Server logic has been optimized for the mentioned objects below. Based on our internal tests, we can expect server performance improvements between 500ms to 1 second.
Screenshot
of QC/ Save and Open for Account
The following are the list of objects with optimized server logic in Quick Create-Save & Open.
- Account
- Quote
- Appointment
- Phone Call
- Task
- Visit
- Opportunity
- Service Request
2. 2. Faster Time to Interact (TTI1) due to decoupled server logic
Due to asynchronous request handling, many UI artifacts in Open Thing Inspector (ex. Open Account, Open Quote) has a faster TTI. For example, starting 1702, the “Check and Determine” process has been decoupled from the main object’s server logic. Also, Check and Determine
itself is handled by an asynchronous request allowing users to interact with the screen before other components/panels such as Analytical Reports, Embedded Component and Notification Messages are loaded and rendered on the screen.
1 Note: Time to Interaction (TTI)
TTI can be described by the following illustration below:
Time
to Interact Explanation
Let’s take an example of Service Ticket Thing Inspector (TI).
When a service ticket is opened (clicked), the screen consists of a main section and several embedded components. With the help of the above diagram we can describe the flow of screen rendering:
a. In this phase (#1) when a user opens a ticket, the screen has a global block were the user is not able to interact until the main section with business data is rendered
b. After the main section, has been loaded, the embedded component for example with customer interaction information is loaded asynchronously. In this phase (#2) the screen is ready for interaction for the user (while the ECs are being loaded in the background). Example the user can edit the main section in this phase. The time taken to render the main section (while other components are being loaded) is called Time to Interact (TTI). During this phase where components are being loaded in the background, there is a local block in the section of the screen only
c. Meanwhile after all the embedded components (and other UI artifacts) have been loaded asynchronously the entire screen is displayed. This, entire time to display all the data including the main section and the embedded components including Check and Determine, Reports is called End to End time (E2E)
2 Note: Check and Determine
Check and Determine is the process whereby messages related to the data for an object are retrieved. For example, in the screenshot below we can see some error messages highlighted in green for an opportunity.
Example: Notification messages (highlighted in green) for Opportunity object in the Opportunity Thing Inspector screen
Previously, for Open Thing Inspectors, the “Check and Determine” process would occur as part of an object’s main application logic. Therefore, if the checks were complex with quite a few line
items, then the main retrieval request would also get blocked until all the notification messages were determined and retrieved for display.
As of 1702, the object’s main object logic runs separately from the retrieval of the Check & Determine messages. As part of the execution process - firstly, data from the object is retrieved and rendered on to the screen. Then, this is followed by an asynchronous call for “Check and
Determine” which retrieves all the messages, which are then subsequently displayed in the notifications bar (highlighted in green). As this request is asynchronous, the user is not blocked from interacting with the screen during the check and determine process.
This leads to an improvement between 200ms to 2 seconds depending the screen and number of line items for the object.
<
Pre-fetch process for floorplan metadata
In the first step, the interaction flow performed by John is stored on the browsers’ cache. Please note – No business data is stored and only the properties of the screens visited by the user are stored. For example, in the above flow diagram, John performs a login to C4C followed by
opening an Account and an Opportunity. This is followed by creating of a Quote and then John logs off.
Now let’s assume a key user makes a change to the account thing inspector (TI) by adding a panel using copy and paste. This is referred in the above diagram as step #2.
After the key user activates these changes for the account
TI, all user’s floorplan metadata for Account TI are invalidated.
When John logs back in as in step#3 and during the login process, the client logic checks against the inventory of each of screens John has visited earlier. When it detects then Account TI has changed, it then downloads (pre-fetches) the floorplan metadata. Therefore, this download no longer happens when John opens an Account but rather is done asynchronously during the login process. Since this pre-fetch process happens asynchronously behind the scene, it does not block the user nor does the user experience the busy indicator that blocks further interactions.
With the pre-fetch optimization, we can expect an improvement between 20-50% based on the UI screen.
<
Introspect HTTP Cache Control header max-age using Chrome Developer Tool for
Login Page.
max-age = 31536000 (seconds) divide 60 (minutes) divide 60 (hours) divide 24 (days) = 365 days
Please note previously the max-age used to be set at 14days.
<
