Skip to Content
Author's profile photo Guru Shetti

C4C Performance Update – Whats new in 1702

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.

of QC/ Save and Open for Account

The following are the list of objects with optimized server logic in Quick Create-Save & Open.

  1. Account
  2. Quote
  3. Appointment
  4. Phone Call
  5. Task
  6. Visit
  7. Opportunity
  8. 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:

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.

<![3.   (a) Reduction in Cold Starts: Optimistic Pre-fetch of static floorplan metadata:

An exciting performance optimization feature incorporated in 1702 is the Pre-Fetching of a screens Floorplan static metadata.

Whenever a change is made to a screen either by key user tool (KUT) or SDK, the floorplan metadata associated with that screen that is cached on the browser side is invalidated and must be retrieved from the server by every user’s browser for the changed screenThis can also occur after Hot Fix Deployments or during Upgrades. Therefore, a user may suddenly experience some sluggishness when accessing the impacted screen.

 Typically, once this metadata is cached on the browser, it’s only invalidated after a year or for the said reasons mentioned above.

 To make the user experience smoother the floorplan metadata is now pre-fetched during the login process.

 The pre-fetching process of floorplan metadata is described with the help of the diagram below:

     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.

<![3.  (b) Reduced Cold Starts by Increasing MAX-AGE of static assets that are cached on browser to 365 days:

Typically, most web applications cache static data like images, JavaScript & HTML on the local disk in the browser’s cache. Therefore, a browser can retrieve this static asset from the cache instead of from the server. Retrieving from the server can be very expensive and it’s based on the number of static objects and the network condition. From time to time this static data is invalidated and downloaded again from the server. This is controlled based on HTTP header control flags or with an explicit “cache-burst”. Cache buster events can invalidate cache for example after an upgrade.

On the other hand, HTTP header cache-control allows the browser to know how long to keep an object in its cache. This feature is controlled by parameters in the HTTP headers called the Cache-Control. The flag that controls the amount of time is called cache control “max-age”.

Cache-Control: max-age=<seconds>

As we can note from above, its specified in seconds.

 To see the static objects max-age please open the developer tool for the browser and check the header properties.

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.

<![4.    Mobile Offline – Improved offline performance due to enhancements in device database along with meta cache optimizations:

Enhancements in local device storage and access mechanisms resulted in improvements in offline response
times. These improvements are across more than 130 interaction scenarios including Open TI, Search and QC. The performance improvements range from 200ms to 3.5 seconds. Some of the examples are listed below:

  1. Search Sales Quote
  2. Select from OVS Sales Units For Sales Quote
  3. New Related Appointment TI Phone Calls
  4. Save and Open QC Tasks
  5. Select from OVS Account For Sales Quote
  6. Action Summary Visits
  7. Open WoC View Contacts
  8. Open OVS Account For Visits
  9. Save and Open QC Opportunities
  10. Click add Appointment to Tasks

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.