A blue-print solution that allows mixed use of user exits, this article describes a setup where the "module(s)" to be called is(are) determined at runtime allowing activation of user exits per country. The user exit is where SAP allows the customer system to interfere (in a good way of course) with the system, which does not really take into account the country split - unless the developer defines it (in ABAP coding). A centralized solution for this would:

• Avoid having (several) developers build coding to isolate their changes
• Avoid having (several) developers work on the same coding (locking each other out)
• Limit the impact of country-specific errors on user-exits, as country specific coding will only be called for the respective countries
• Overall overview of what is "out there" on all user exits (cross application)

Please do note that this approach is to be rendered "old and replaced" where BADI implementations are concerned. When implementing BADI's a filter can be set up which would house the same functionality as the geo-key in this example.

Blue print on user exit control

(bottom up)

• A transparent table Z_EXIT_CONTROL is set up

  with as customizing mapping table, effectively mapping user exits (usually a function module) to the country specific version of this exit. Fields:

  Fieldname	Key	Type	Description	Comments
  MANDT	Yes	c3	Client	The table is client dependant, so functionality can be active per client
  Z_UE_OBJECT	Yes	c30	User exit object	A (meaningful) code that identifies the user exit that is being handled
  Z_GEO_KEY	Yes	c40	Variabele key to identify (geographic) location	This can be a concatenation of key fields like Plant or actual Country code - separated by a ":". It can however also be used for a non-geographic seperation...
  Z_ACTIVE		c1	User exit is active	This field can be edited via a report, functionality can thus be activated or deactivated
  Z_LOG_CALLS		c1	Calls to this user exit are logged	Logging functionality can be put in place and logging can be activated or deactivated per entry. Logging will also be done if the entry is inactive
  Z_CALL		c30	Development object to be called	The development object to be called would typically be a function module, with the same interface as the original user-exit function module (E.g. EXIT_SAPMM06E_012)
  Z_COMMENT		c40	Description of the user exit	Can e.g. also hold a reference to a responsible used-ID

• A function module Z_EXIT_CONTROLLER is set up

  that should be implemented in every user exit to be used. The following parameter settings apply:

  Name	Type	Description	Comments
  IMPORTING
  UE_OBJECT	like Z_EXIT_CONTROL-Z_UE_OBJECT	User exit object	This code is normally supplied in the function module call as hardcoded string (to make the where-used list useful)
  TABLES
  GEO_KEY_PARTS	c15	Key fields needed for the Z_GEO_KEY key buildup	With the list of fields supplied here, all relevant Z_EXIT_CONTROL entries are selected and their call-priority is determined.
  CALL_REQUEST	like Z_EXIT_CONTROL-Z_CALL	Development object to be called	The list of (typically) function modules that should be called is returned, in the sequence they should be called in

  
  The function module will determine which call requests need to be handled (if any!) and it also places a log entry somewhere if the settings on Z_EXIT_CONTROL dictate. Inactive Z_EXIT_CONTROL entry calls are logged but not returned as (valid) call requests.
  
  

• The user exits that are used should be set up to call Z_EXIT_CONTROLLER

  for every user exit we are using. Even if it is currently only used locally by just one group. This coding can be the same for many user exits, and should perform the following steps:
  1. Gather information to build the GEO-key with (effectively build up the GEO_KEY_PARTS table for the function module)
  2. Call the function module Z_EXIT_CONTROLLER to determine which CALL_REQUEST entries should be executed
  3. Loop over the call request table and call the relevant function modules therein

• Implementation of actual user-exit contents

  Where this approach is implemented, the actual module that responds to the user exit should be set up, much like a copy of the user exit function module itself. The module filled in on table Z_EXIT_CONTROL (field Z_CALL) should have the same parameters as the actual user exit function module it is tagging on to, e.g. EXIT_SAPMM06E_012.
  
  

• Interactive report on the Z_EXIT_CONTROL table

  which allows the end user change Active-settings and Logging-settings, but this report will also clarify the overall setup and make the implemenation of user exits by different countries something that can easily be overseen.

• Prev
• Next