Currently Being Moderated

"The R/3 enhancement concept allows you to add your own functionality to SAP's standard business applications without having to modify the original applications." (Introduction to the Enhancement Concept).

This blog is about a specific type of exit, namely Function Module Exits. Assuming that you are familiar with transactions CMOD and SMOD I will show you how User-Exits can be organized in order to achieve four major goals:

  1. Easy Maintenance
  2. High Transparency
  3. Process-Independent Testing
  4. Avoidance of Dangerous Liaisons 

The Problem

User-Exits are normally implemented "On-Demand". Having found out that a specific behaviour of a standard application cannot be realized by means of customizing the next step is to look for appropriate User-Exits. An enhancement project (CMOD) is created and the required enhancements assigned. Now it is time to create the implementation of the User-Exit which occurs in a ZX-include predefined by SAP.


These ZX-includes have to be assigned to customer packages. Depending on who implements the ZX-includes and for which purposes they are implemented these User-Exit includes are likely to be scattered around many packages.

On one of our ERP systems the situation looks like this:

  • 98 implemented ZX-includes are assigned to 15 different packages

The ZX-includes of User-Exit XLTO (User Exits for TO Processing) have been assigned to four(!) different packages demonstrating the historical evolution of this User-Exit.

Considering the fact that these User-Exits are shared by three different companies residing on three different clients this is already a bad situation regarding maintenance and transparency of the User-Exits.


From Bad to Worse

Being responsible for SAP-XI & EDI support at our company I sooner or later had to modify existing User-Exits for Billing-Doc-Output (XEDF). However, I almost got a heart attack when I saw the implementation of include ZXEDFU02 (EXIT_SAPLVEDF_002) for the first time (see below). 



While it is easy to spot the two companies (Spain & Switzerland) that have used this User-Exits it is less obvious to identify and understand the manifold requirements that have been implemented.


Step 1 - Organizing the Mess

In order to organize the existing and new User-Exits in a more meaningful way I created a new package ZCMOD. This package is intended to contain all User-Exit related repository objects.

The next step was to clearly separate the company specific coding. This was achieved by a generic Five-Step approach:

  1. Create a Z-exit function group (if not already existing)
  2. Copy the Exit-Function Module to a Z-Exit Function Module
  3. Create company specific Z-Exit Function Modules
  4. Replace coding in ZX-include with function module call
  5. Reassign ZX-includes to the new package ZCMOD


The result of the first three steps is shown below:

A new function group ZXEDF was created and assigned to the package ZCMOD. The Exit-Function module EXIT_SAPLVEDF_002 was copied to ZEXIT_SAPLVEDF_002 in function group ZXEDF. This function module was again copied twice to yield ZEXIT_SAPLVEDF_002_CH and ZEXIT_SAPLVEDF_002_ES. The main point is that all Z-exit function modules have the same interface like the SAP Standard Function Module-Exit.


Implementing User-Exits: Once and for All

If we need to touch SAP standard objects we should always try to do it once and for all. In case of Function Module-Exits this can be done quite easily:

The ZX-include contains nothing but a call to the frame Z-exit function module (see below).

Using this approach we obviously never ever have to touch this ZX-include again.


The Frame Z-Exit Function Module

The frame function module ZEXIT_SAPLVEDF_002 has the function to separate the coding logic at the highest hierarchical level which in our case are the companies:


The company specific function modules contain the company specific coding:



Step 2 - Complete Structural Separation of Concerns

Even though we have now separated the company specific coding the function modules are still linked together into a single function group. Thus, if developers need to change the User-Exit for different companies at the same time they might interfere with each others. Therefore the next level of organizing User-Exits is required: the complete structural separation of concerns.

For each company a specific Z-Exit function group is created:

  • ZXMGV - Frame Z-Exit function group
  • ZXMGV_CH - specific for Lindt Switzerland
  • ZXMGV_ES - specific for Lindt Spain
  • ZXMGV_ES - specific for Lindt Poland


Within the frame function module ZEXIT_SAPMV01_002 we determine the name of the company specific function module and dynamically call it.


There are two obvious advantages of this structural organization of User-Exits:

  1. Errors accidentially introduced into a User-Exit will not affect any other company.
  2. Different companies can modify the same User-Exit at the same time without interfering with each other.



In this weblog I presented a possible strategy how to organize User-Exits (CMOD / SMOD). The major steps of this approach are:

  • Create a specific package (e.g. ZCMOD) containing all User-Exit related repository objects
  • Copy the Exit-Function module to a Z-Exit function module having the very same interface. Only the frame function module is called in the ZX-include.
  • Implement the ZX-include once and for all.
  • Create Z-Exit function groups for the highest hierarchical level that employs the User-Exit


An example for a hierarchy of Z-Exit function modules is given below:

  1. Frame: ZEXIT_SAPLVEDA_001
  2. Country specific: ZEXIT_SAPLVEDA_001_CH
  3. Country & Customer specific: ZEXIT_SAPLVEDA_001_CH_SHOP


If I need to change the User-Exit for inbound ORDERS IDocs intended for our Lindt Shops I immediately know that I have to change function module  ZEXIT_SAPLVEDA_001_CH_SHOP. Thus, based on the requirements (SD-EDI User-Exit & Lindt Shops) I can deduce the affected Z-Exit function module.


Is there another advantage of replacing the coding in the ZX-includes with the call to the frame Z-Exit function module? 

Yes, there is.

The Z-Exit function modules enable you to test the User-Exit independent of the entire process / transaction !!!

If you are already working on SAP releases >= 6.20 you can define ABAP Unit Tests for each Z-Exit function module. Having assigned all User-Exit related repository objects (ZX-includes and Z-Exit function groups) into a single package you can then use the Code Inspector (transaction SCI) to easily test all your User-Exits at once:

  • Define an object set containing this package
  • Define a check variant executing all dynamic tests (ABAP Unit)
  • Run an inspection with object set and check variant created before


Finally, if you intend to get rid of obsolete User-Exits and revert back to the SAP standard processes a package like ZCMOD will give you a headstart for your project.



Function Module-Exits (CMOD / SMOD) can be organized by simple means into a useful structure thereby achieving major goals like

  • Easy Maintenance
  • High Transparency
  • Process-Independent Testing

and at the same time avoiding dangerous liaisons by separating concerns into completely independent structural components.



The topic of this blog has been continued in:

Dangerous Liaisons in User-Exits - Revisited



Filter Blog

By date:
By tag: