LESSON 54 ENHANCEMENTS USING COSTMER EXITS

ENHANCEMENTS USING COSTMER EXITS



Application enhancements allow customers to enhance their application functions. Customer exits are preplanned by SAP and generally consist of several components.

Application enhancements are inactive when delivered and can be completed and activated by customers as they are needed.

Application enhancement characteristics:

Each enhancement provides you with a set of preplanned, precisely defined functions.

Each interface between SAP and customer functions is clearly defined.

As a customer, you do not need in-depth knowledge of how to implement SAP applications.

You do not need to adjust enhancements at upgrade because of new functions that SAP has developed.

The SAP application programmer creates SAP enhancements from function module exits, menu exits and screen exits. A management function is provided for this purpose (transaction code SMOD).

Customers are given a catalog containing an overview of existing SAP enhancements. They can then combine the SAP enhancements they want into an enhancement project using transaction CMOD.

SAP enhancements are made up of component parts. These components include function module exits, menu exits, and screen exits. A specific component may be used only once in a single SAP enhancement (this guarantees the uniqueness of SAP enhancements).

Customer enhancement projects consist of SAP enhancements. Each individual SAP enhancement may be used only once in a single customer enhancement program (this guarantees the uniqueness of a customer project).

The SAP application programmer plans possible application enhancements in an application and defines the necessary components. These components are combined in SAP enhancements.

The programmers document their enhancements as best they can, so that customers can implement the enhancements without having to analyze program source code or screen source code.

First, create an enhancement project and then choose the SAP enhancements that you want to use.

Next, edit your individual components using the project management function and document the entire enhancement project.

Finally, activate the enhancement project. This activates all of the project's component parts.

Transaction CMOD starts the project management function. You must give your enhancement project a name. SAP recommends that you think up a naming convention for all of your projects.

You can, for example, include the project's transaction or module pool in its name. All enhancement project names must be unique.

Next, go to the project's attributes and enter a short text describing the enhancement project. The system inserts the entire project's other attributes (such as created by, created on, or status).

Use the project management function to assign SAP enhancements to customer enhancement projects. Enter the names of the SAP enhancements you want to use on the appropriate screen.

The search function gives you a catalog-like overview of existing SAP enhancements. From there you can select those enhancements that are of interest to you.

Use the product management function to edit the components of your enhancement project.

Depending on whether the component you are editing is a function module, a menu entry, or a SUB SCREEN, you branch to either the Function Builder, a dialog box for entering menu entries, or to the Screen Painter.

Activation of an enhancement project affects all of its components. After it has been activated successfully, the project has the status active.

During activation, all programs, screens, and menus containing components that belong to the project are regenerated (programs at the time they are executed). After activation, you can see the effect of the enhancements in your application functions.

The Deactivate function allows you to reset an active enhancement project's status to inactive.

When the enhancement project was created; you should have assigned it to a change request. Each of the component pieces (include programs, SUB Screens, menu exits, and so on) should be assigned to the same change request. Using the same change request allows you to transport the entire enhancement at the same time.

Function module exits allow customers to implement additional logic in application functions. SAP application programmers define where function module exits are inserted and what kind of data they transfer. SAP programmers also create an exit's corresponding function modules complete with short text, interface, and documentation, as well as describing each function module exit's intended purpose in the SAP documentation.

You write the source code for the function modules yourself. If need be, you can also create your own screens, text elements, and includes for the function group.

The system processes your ABAP code when the enhancement project (of which your function module is a component) is activated. Function module exits have no effect prior to enhancement project activation.

This graphic shows the flow of a program providing an enhancement in the form of a function module exit.

The exit function module is called in the PAI logic of a screen at a position determined by the SAP application developer. Within the function module, the user can add functions in the customer namespace using an include.

SAP application programmers use the ABAP statement CALL CUSTOMER-FUNCTION 'nnn' to call function modules, where nnn is a three-digit number. (Where 'nnn' is a three-digit number). The application programmer must also create the function module he wants to call and its related function group.

These function modules belong to function groups whose names begin with X (X function groups).

The following naming convention applies to these function modules:
Prefix: EXIT
Name: name of the program that calls the function module
Suffix: three-digit number
The three parts of the name are separated by two underscores.

The CALL CUSTOMER-FUNCTION statement is only executed if the enhancement project has been activated. Multiple calls of the same function module are all activated at the same time.

The most frequently asked question concerning enhancements is: how can you see if an application program offers a function module exit? There are a number of ways to find the answer to this question.

To see quickly if an application program offers a function module exit, you can follow the path on the left-hand side of the graphic: (The menu path System Status always displays the name of the current application program). In our example a suitable character string would be "CALL CUSTOMER". Use the Find icon and search globally in the program. If your search does not provide any results, you can define a larger search area. Determine the environment for the corresponding program and look for the specific character string in the program environment.

The right side of the graphic shows you how to find the name of the required enhancement using search tools. You can restrict the search in the R/3 Repository Information System using different criteria: These are:

Development class (also try generic entries)

Technical name of the enhancement

Use the project management (transaction: CMOD) function to edit function modules for function module exits.

Use the button for editing components to go directly to the function module editor (display mode).

DO NOT change the function module itself. It is especially important that you do not alter the interface in any way. The function module, however, contains an INCLUDE statement for an include program that you have to create in the customer namespace.

Double-click on the include name beginning with ZX. This automatically takes you to the editor of the include program, where you can enter your code.

To understand how an X function group works, you need to understand how a normal function group works:

A function group consists of includes. The system assigns unique names to the includes for different objects. Some of the include names are simply proposals and some cannot be changed.

Global data is stored in the TOP include. This include is generated automatically when a function group is created.

Function modules are stored in includes with sequential numbering, and they in turn are all stored in an include ending with UXX.

You can freely choose the names of the includes for all other objects (subroutines, modules, events, etc.). However, we advise you to accept the proposed names.

Exit function groups created by SAP application programmers for enhancement exits contain include programs that begin with either 'LX' or 'ZX'. You can only edit includes beginning with a 'Z', since they are stored in the customer namespace.

No further function modules may be added to the function group.

The include program ZxaaaUnn contains the source code for the function modules of a function module exit.

SAP application programmers can declare global data in include program LXaaaTAP.

You can declare your global data in include ZXaaaTOP.

Include program LXaaaTOP also contains the FUNCTION-POOL statement, which may not e changed. Therefore, you must always include the message class in parentheses when outputting messages - for example, MESSAGE E500 (EU).

The INCLUDE statement for program ZXaaaUnn is in a FUNCTION - ENDFUNCTION block.
Because of this, neither events, nor subroutines (FORM), nor modules (MODULE) are allowed here.

They can, however, be created in separate includes, which is explained later. Data declarations made here with DATA are valid locally in this function module.

The SAP application programmer can also make a proposal for the source text. In this case, an INCLUDE LXaaFnn is created (where nn is the internal number for the function module in the include LXaaaUXX). Documentation is also provided within the SAP enhancement. You can copy the source code from this include into your own customer include program ZXaaaUnn using the project management transaction.

You can create your own text elements for the function group.
SAP applications programmers can supply you with default subroutines in include LXaaaF01.

There could be further includes containing specific sub-objects.

LX...F01 contains subroutines delivered by SAP.

LX...E01 contains the events belonging to the X function group.

LX...O01 contains PBO modules for screens to be delivered.

LX...I01 contains the corresponding PAI modules.

Subroutines, modules, and interactive events (AT…) are created as include programs and included enhancements using include program ZXaaaZZZ.

Additional includes must adhere to the following naming convention:

ZXaaaFnn for subroutines,

ZXaaaOnn for PBO modules,

ZXaaaInn for PAI modules,

ZXaaaEnn for events.

You can use CALL SCREEN to call your own screens. Create the related include programs for the PBO and PAI modules in include program ZXaaaZZZ.

Use forward navigation (select an object and then double -click on it) to create your own screens and modules.

Screens created in this manner are automatically given the name of the function module's main program (SAPLXaaa). The PBO modules for these screens can be found in include
ZXaaaO01, the PAI modules in include ZXaaaI01.

You can enhance SAP applications by adding your own processing logic at predefined points.

Such enhancements can include your own screens with their corresponding processing logic and graphical user interface, as well as text elements created by customers.

Menu exits allow you to attach your own functions to menu options in SAP menus. SAP application programmers reserve certain menu entries in your GUI interface for this. This allows you to define a text for the reserved menu entry and add your own logic, often in the form of a related function module exit. Once you activate menu exits, they become visible in the SAP menu. Whenever this menu option is chosen, the system processes either a function provided by SAP application programmers or your own function that you have implemented in a function module exit.

In order for you to be able to implement menu exits, SAP application programmers must equip the GUI interface with function codes that begin with a plus sign ('+').

These function codes are inactive at first and do not appear in the GUI until you have activated them. They do not appear on the screen.

Menu exits are edited with the project management transaction (CMOD).

The pushbutton for editing components calls a dialog box where you can enter short descriptions and choose a language for each additional menu entry.

You may not make any changes to the GUI interface.
SAP application programmers determine where a program reads additional function codes and how it reacts--- either with a function module exit or with a predefined function.

You can implement menu exits based on reserved function codes. The SA P application programmer defines the relevant function codes, assigns them to menus, and often provides a function module exit.

Menu exits and function module exits are both part of the same SAP enhancement.

No pushbuttons may be assigned to additional function codes.

You can, however, make changes to the various menu entries and activate their function codes.

Screen exits allow you to make use of reserved sections of a main screen (SUB SCREEN areas). You can either display additional information in these areas or input data. You define the necessary input and output fields on a customer screen (SUB SCREEN).

SUB SCREENs are rectangular areas on your screen that are reserved for displaying additional screens at runtime. Each SUB SCREEN area can be filled with a different screen (of type SUB SCREEN) at runtime.

The R/3 System determines which screen will be displayed in a SUB SCREEN area at PBO. The general syntax is as follows:
CALL SUB SCREEN <sub>INCLUDING .
For each SUB SCREEN, PAI and PBO events are processed just as if the SUB SCREEN were a normal screen.

The sequence of "CALL SUB SCREEN" statements in your main screen's flow logic directly determines in what order the flow logic of individual SUB SCREENs is processed.

Caution:
Function codes are only processed in the main screen's flow logic
You are not allowed enter a name for a SUB Screen’s command field
You are not allowed to define GUI statuses for SUB Screens
No value for next screen may be entered in a SUB Screen’s flow control

The SAP application programmer can reserve multiple SUB SCREEN areas for a screen.
The SUB SCREEN is called during flow control of the main screen with the CALL CUSTOMERSUB SCREEN statement. The name of the SUB SCREEN area must be defined without apostrophes. The function group to which the SUB SCREEN belongs is defined statically in apostrophes, but the screen number can be kept variable by using fields; it must always have four places.

Screen exit calls are inactive at first, and are skipped when a screen is processed.

Only after a corresponding SUB SCREEN has been created in an enhancement project, and this project has been activated, will the system process the screen exit.

You create SUB Screens in X function groups. Normally, these function groups also contain function module exits.

Whenever the statement CALL CUSTOMER-SUB SCREEN INCLUDING occurs at PBO in the flow control of a screen, a SUB SCREEN is included in the SUB SCREEN area defined by SAP application programmers. At this point, all modules called during the PBO event of the SUB SCREEN are also processed.

The PAI event of a SUB SCREEN is processed when the calling screen calls the SUB SCREEN during its PAI event using the statement CALL CUSTOMER-SUB SCREEN .

The global data of the calling program is not known to the X function group that contains your SUB SCREEN; SAP application programmers use function module exits to explicitly provide this data to SUB Screens.

In order to facilitate data transport, modules is called in the flow control of the calling program that contains function module exits for transferring data via interface parameters.

Function modules belonging to these kinds of function module exits can be found in the same function groups as their corresponding SUB Screens.

Data must be transported in the other direction as well, since global data from the X function group that contains your SUB SCREEN is not known to the calling program either. For this reason, SAP application programmers use function module exits to return any data to the calling program that was changed in the SUB SCREEN.

This is done by calling a module during the main screen's PAI event that contains a function module exit for returning customer data via interface parameters.

SUB Screens are edited with the project management transaction (CMOD).
The technical names of screen exits consist of the name of the calling program, a four-digit screen number, and the name of the SUB SCREEN area, followed by the name of the X function group's program and the number of the SUB SCREEN.

You must create the SUB SCREEN as well as the corresponding PBO and PAI modules. The SAP development environment supports creation with forward navigation.

Make sure that your SUB Screens are of screen type SUB SCREEN the first time you create them.

You are not allowed to change any of the interfaces in the X function group that the SUB SCREEN and the function module exits belong to, nor are you allowed to add any of your own function modules.

See also the restrictions listed on the slide entitled 'Calling SUB Screens'.

Screen exits allow you to determine the layout of certain portions of a screen yourself. You can use these areas to display additional information, or to collect and process data.

Screen exits must be predefined (planned) by an SAP application programmer. Use the statement CALL CUSTOMER-SUB SCREEN to integrate these preplanned SUB SCREEN areas into the flow control of the calling screen at PBO and PAI events.

As soon as you activate an enhancement project that contains a SUB SCREEN as a component, the calling screen is regenerated and the SUB SCREEN is displayed the next time the application function is called.</sub>