Skip to end of metadata
Go to start of metadata


This page provides the best practices that can be used for SAP CRM Web UI Customization and development. It also outlines the advantages of using these practices during an Upgrade.
Members of development, solution management and quality management teams may use this document as guidelines or checklists for SAP CRM Web UI Development.

One Client approach

It is recommended to have a single client for an SAP CRM system unless the business justifies use of multiple clients in situations like 'Multiple CRM Scenario'.

(More Informartion: SAP Note 1084315).

SAP CRM system downloads, exchanges customizing and business data from the ECC system using CRM Middleware.A single CRM client instance will not only reduce the overhead involved in downloading the data across systems but also eliminates the functional issues that arise out of the multiple clients like conflicts in Organizational data, Partner data etc.,

(thumbs up) All the Web UI Component Enhancements need to be assigned to an Enhancement Set. The Enhancement Sets are assigned to a client in view 'BSPWDV_EHSET_ASG'.
If a client with same number is used across QA and Regression systems etc.,there is no need to manually assign Enhancement Set entries in each client in view 'BSPWDV_EHSET_ASG'.
(More Informartion: SAP Note 1122248)

Run Time Repository changes

Runtime Repository Editor Tool TCODE: BSP_WD_CMPWB, helps in visualizing the underlying XML code used for view navigation or a view hierarchy etc.,

(thumbs up) Any Runtime Repository changes should be done using Runtime Repository Editor instead of manually changing the XML code.
This will ensure that the XML tags used are uniform across the system as the XML code is auto generated by the system.

(lightbulb) All the changes to Run Time Repository are Repairs. So during an Upgrade, any new additions or deletions in new SAP version will not be cascaded to this file. These changes have to be manually incorporated after making a comparison with the new SAP version using report 'BSP_WD_RT_REP_COMPARE'.

If the Runtime Repository changes are well documented, upgrade corrections can be completed quite easily. Version comparison can be of little help as there can be changes in the way XML tags are written in the newer version as in case of CRM 6.0 and CRM 7.0.
So, Runtime Repository Editor should always be used for any XML changes and should be documented.
(More Informartion: SAP Note 1122248)

Custom attribute, Component Usage and I/O plug additions

To meet business requirements,custom context nodes and attributes may have to be created using TCODE BSP_WD_CMPWB.
Similarly there may be a need to create new I/O plugs to define navigation between components and component usages have to be created to use in F4 helps.

(lightbulb) When these changes are added to Run Time Repository, they cannot be distinguished from SAP provided ones and will create many issues during upgrade. As discussed in earlier step, version comparison may be of little help.
\(y) So, a name space like 'Y' or 'Z' if adapted for all the custom attributes, context nodes, component usages, I/O plugs, Navigation Links, views, windows, components and methods helps in easy identification.

HTML changes and Button manipulations

HTML pages are used for the Web UI Layout and UI element definitions. Changes to HTML pages are accounted under Repairs.

(thumbs up) So during an Upgrade,any new additions or deletions in new SAP version will not be cascaded to the HTML page. Hence, better documentation and comments in HTML page changes will help during an upgrade.

Method Redefinitions

SAP delivered Methods in a class can be redefined from Class Builder SE24 or Component Workbench BSP_WD_CMPWB. \(on) Due to the business requirement, sometimes the inherited code is overwritten.(No call to super class is made; rather part of code is copied and pasted).

SAP may incorporate new logic or change the code in these methods as part of a newer version or in an SAP Note. (thumbs up) Such overwritten methods if documented, can be incorporated with the new changes easily.

UI Configuration changes

UI configuration tool allows 'role based customization' like adjusting position, add or remove fields from a field set, set fields to mandatory/display only and define load option for blocks of CRM standard views as well as custom ones.

(thumbs up) All the Custom UI configurations including custom object types should use a naming convention for better tracking.

Although the system allows changing the 'Default' SAP configurations, it should never be changed.

Message Statements

Messages are displayed on Web UI by adding them to the Message Log using classes like 'CL_BSP_WD_MESSAGE_SERVICE', 'CL_CRM_GENIL_GLOBAL_MESS_CONT' etc.,.

To add a message, the Message ID and number are passed to the 'ADD_MESSAGE' method of these classes in quotes ''.These messages cannot be tracked using Where Used List option in SE91.

(thumbs up) So, if a classic ABAP Message Statement with the Message Number is placed inside a 'Never If block' like IF 1 = 2, messages can be tracked using the Where Used List option in SE91.

OTR Changes

The Online Text Repository (OTR) is a central storage location for texts.

(thumbs up) Though the system allows changing standard SAP texts, it is a good practice to create Aliases in Custom Packages and use them. This will allow better Localization.

If you really need to change standard SAP texts you should use a custom context (cf. this document).

Custom field additions

(thumbs up) New fields may have to be added to the Web UI to meet business requirements. This should be done always using SAP delivered tools like Easy Enhancement Workbench EEWB,Application Enhancement Tool AET(available from CRM 7.0). Append Structures should be used only in a case above options are not available for a Business Object.


In any programming language 'Modularization' is one of the key features of writing efficient and easily maintainable code.

(thumbs up) As SAP CRM Web UI is completely based on ABAP Objects, methods should be created in Controller Classes, BADI Implementations etc., where and when necessary to ensure readability, low maintenance, abstraction and reusability.

  • No labels