Skip to end of metadata
Go to start of metadata


The CRM framework is using a mechanism to optimize frontend performance which is called automatic delta handling (ADH).

There are certain situations that can not be handled in ADH. You can switch off a view for ADH in that case. Or you can try to change the views content to be ADH compatible. This page gives you information how to analyze if your view has issues related to delta handling and what you can do to make it compatible.

In few words, how ADH works?

When the page is being prepared for the rendering, ADH detects which areas (e.g. views) of the page have changed. Only such changed areas are then redrawn in the browser.

How can I see if my view was loaded with ADH

Use an http viewer, such as HttpWatch? for IE, to see the sent and received http headers. If the roundtrip

  • uses POST method, and
  • has a sent header x-requested-with equal to XMLHttpRequest, and
  • has a received header sap-ajax-targets equal to a list of changed areas (e.g. C1_W1_V2_C1_W1_V2_V3_$subHeader,C1_W1_V2_C1_W1_V2_V3_$workCenterContent,), and
  • doesn't have a received header sap-ajax_http_redirect equal to X.

then the page is loaded using ADH.

Remark. There could be a situation when the roundtrip uses POST method and has a sent header x-requested-with equal to XMLHttpRequest, but no received header sap-ajax-targets. This correspond to one of the following cases:

  • ADH is active, but it didn't detect any change to the page, so no list of changed area is received;
  • Nothing can be said about the status of ADH because the roundtrip is the result of custom Ajax request generated by an individual view on the page.

How can I temporarily switch off ADH to see if the problem happens without ADH

You can set the following user parameter with transaction SU3:

How to switch off ADH on user basis You can - TCode: SU3 - Select "Parameters" TAB - Add the following user parameter "CRM_TAJAX_DH_MODE" and set it to "OFF" - Save 

Make sure you close the browser and open a new one after the change.

How can I permanently switch off my view for ADH

Once you know that your view is not compatible you can enter it to the "switch off" table and ship that entry (cross client customizing. Requires workbench request)

  • TCode: SM31
  • Enter "BSPWDV_ADH_DSBL" in Table/View input box
  • Click Maintain
  • Create New Entry
  • Enter the component name (as in BSP_WD_CMPWB) in field APPLICATION 
  • Enter the view name without any extension (as in BSP_WD_CMPWB) in field PAGE 
  • Save   

How can I permanently switch off ADH for my Business Role

  1. Find the technical profile for the business role.
  3. Select technical profile.
  4. Select "Disable Automatic Delta Handling" check box.

What releases supports ADH

ADH is supported with CRMUIF 5.2 SP00. Which is used for SAP CRM 2006s/2 SP00.

What can not be handled by ADH

This section lists the situations not supported by the ADH. The views that are in a not-supported situation should have ADH turn off, if a workaround is not possible or not desirable.

Use of document.write() function inside a view

A view cannot use document.write() javascript function.

Unified rendering popups

Any view using THTMLB_SUPPORT_UR tag cannot rely on the features defined in UR library /sap/public/bc/ur/Design2002/js/popup*.js files, such as non CRM UI pop-up windows.

Reload of external javascript libraries

The external js libraries of applications are loaded only once, at the first time. This means that the application could not assume that after a roundtrip the state of js inside those libraries is initial.

Use of onLoad attribute

If a view needs "on load" execution of a js code, it should register such a code using thtmlbRegisterOnLoad(handlerFunction) javascript function rather than attaching it to onLoad event of the body. For example, if a view contains the script block



then the function viewSpecificJSFunction() will be called at each roundtrip, even if the view was not modified (so not reloaded) during the roundtrip.

If you call thtmlbRegisterOnLoad more than once for the same function, make sure to call thtmlbUnregisterOnLoad in the same roundtrip that thtmlbRegisterOnLoad, unless an additional string parameter is used - see the next paragraph below.

In CRMUIF 2007 SP02 (see Note 1110203) it is possible to unregister a function in a later roundtrip, not necessarily in the one where the registration happened. For that, the registration and unregistering must be done using an additional string parameter, e.g.

thtmlbRegisterOnLoad(viewSpecificJSFunction, null, "viewSpecificJSFunction");



thtmlbUnregisterOnLoad(viewSpecificJSFunction, null, "viewSpecificJSFunction");


DOM changes outside Delta block

In ADH-enabled mode, the DOM is not entirely rebuilt after each round trip. If a view does some changes to DOM such as e.g. document.body.appendChild(newNode) then it should take into account that its changes could be still there after a roundtrip.

HTML Comments to disable javascript

ADH only searches for tags and the content of them. Example



alert('do not execute this');


should be done as

alert('do not execute this');



There have been reported incidents where the "Sophos" antivirus was causing ADH some issues via its "Browser Helper Object" (BHO).

When Timeout Error scenarios are expected, i.e. for those views expecting long RoundTrips

When DH is enabled, if a timeout occurs on any node before the backend and an error message is sent to the front end from that node… the error message would not be accessible to the JavaScript engine… and the area to replace for DH will be empty so… DH will replace the entire page with empty string.

NOTE: Considering the applications where minutes of delays are expected from the backend to be able to send the response back to the frontend. It is RECOMMENDED to disable Delta Handling for those specific views. Delta Handling was designed to save some milliseconds and get the performance of fast roundtrips even faster. So in such cases Delta Handling is not really doing its job. Also with such a long delay for roundtrips, there is a big possibility that a timeout might occur on one of the communication nodes in the landscape before the backend is ready to send the response back. when this node timeout it will send an error message to the front end. since ADH uses AJAX and since AJAX is using JavaScript. the error message content will not be reachable since it is coming from different domain, "Cross Site Scripting", this would result with DH engine receiving an empty response with no areas specified as well. so the DH engine would replace the entire body with an empty string and a White Screen would show up.