Page tree
Skip to end of metadata
Go to start of metadata

A common situation when customers are using SAP CRM is that the standard fields in UI could not fulfill their specific business requirement and they would like to add their own fields to the standard UI. When partners are implementing the project, sometimes the new fields are added via the custom development way. However, the suggestion is the possibility of using Application Extension Tool (AET) for new fields creation must always be evaluated first before the decision to use custom development is made.

The table below lists the comparison between using AET and Custom development to create the new fields:



Custom Development

Create new fields in UI( including search view, search result view and detail page)

Feasible, if the UI is designed by SAP as AET extensible

Technically feasible in any UI

Skills required

Completely UI-driven, require no technical background.

•Only developers can do it
•Requires solid understanding on SAP standard function


Effort required

Minor, can be almost done instantly

Normally huge, depends on the application complexity

Enhancement robustness

High, since no coding from developer

Low, if the quality of the coding by the developer is poor

Enhancement performance

High – ensured by AET framework

Low, if the design of the new fields Read & Write access is poor

Upgrade Survival



  1. approach scope
    The AET can only work, if the standard UI is "marked" as AET extensible by SAP. There is not an explicit flag or checkbox in UI page which indicates whether current page is AET extensible. Instead, you have to figure it out yourself in the system. For technical details you can refer to blog why the create field button is invisible for my ui and step by step to enable your genil component with AET. The easiest way is to enter the configuration mode and try to create a field. If you could not see "create field" in configuration mode or the button is disabled, it means the respective UI is not extensible. 
  2. Skill required
    The AET solution requires no technical background: you do not have to know the technical detail how the UI component is developed, what the underlying Genil model is, etc. The way to create fields via AET is completely UI driven and thus very intuitive. 
    On the other hand, the custom development, could only be accomplished by a developer with solid knowledge on the SAP standard solution. For example, if you need to create new fields on Sales Order UI via custom development and enable their read & write access, you need to enhance the Genil implementation of model BT. Without good knowledge of that model, your development would be very rough.
  3. Effort required
    Using AET very little effort has to be paid. No programming is necessary, just step by step configuration in UI. The custom development could lead to normally great development effort. Still use the example in point 2 for demonstration, it means you have to:

    a. enhance the database table to include the new fields
    b. enhance the Genil implementation for new fields read-write access
    c. enhance the Sales Order UI to make the new fields visible in UI 
    Even if you choose not to strictly follow Webclient UI and bypass the BOL/Genil layer and directly control the new fields read&write access in UI layer, the efforts for a and c are still unavoidable.
  4. Enhancement robustness
    The UI enhanced by AET is very robust since all of the artifacts for new fields are generated by AET framework. The robustness of custom development depends on the skill of the developer. In general the more coding done for the custom development, the higher potential bug rate it has.
  5. Enhancement performance 
    If you choose AET, you need not to take care about performance since the performance of new field read&write access is improved and guaranteed by AET framework. For the custom development, you have to consider read & write access optimization by yourself. 
  6. Upgrade Survival
    The new fields created by AET can survive the system upgrade. On the other hand, in the custom development if you do not leverage SAP enhancement strategy and tool like Genil component enhancement, the BAdI definition and implementation, but make direct modifications on the standard code, then all your modifications will be lost after system upgrade.
  • No labels