Copyright 2022 - BV TallVision IT

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.