Showing posts with label MODIFICATIONS USER EIXTS CUSTOMER EIXTS. Show all posts
Showing posts with label MODIFICATIONS USER EIXTS CUSTOMER EIXTS. Show all posts

BADI and Customer exits in SAP ABAP

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included inthe standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software.

As with customer exits two different views are available:

1·In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.

2· In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.

In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.

SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces. You do not have to register Business Add-Ins in SSCR.

The Business Add-In enhancement technique differentiates between enhancements that can only
 be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).

All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.

Related Posts:

SAP USER EXITS

Locating User Exits

Before you can add functionality to a SAP system, you need to be able to locate the appropriate user exits. SAP has provided around 2000 user exits.

Searching from transaction CMOD

Searching from the Application Hierarchy

Making your own customized search

Keep in mind that you must first search for an enhancement. Once you find an enhancement, you can display its components -- the actual user exits. Then you need to include the enhancement containing the required user exit as a component in your own project.

Method #1: Using Transaction CMOD

- Transaction CMOD contains search functionality to help locate enhancements.
- Selecting the "Utilities -> SAP enhancements" menu path in transaction CMOD will take you to an enhancement selection screen .

- You can limit the search for enhancements based on:

Enhancement name
Development class

- After clicking on the ‘Execute’ pushbutton (or ‘F8’) on the selection screen, the system will display a listing of the development classes that contain enhancements (see graphic above).

- From this listing, you can double-click a development class to display its enhancements.

- If you have clicked on the ‘Display components’ pushbutton on the selection screen (see graphic on previous page), the components of each enhancement will automatically be displayed.

Remark: To use this search method one must either know the part of the enhancement name or the development class. But if one looks at SAP’s naming convention for user exits (see note below), the screen numbers/program names/ function codes/etc are contained in the components name and there is no scope for that in selection options. Also one cannot restrict the search to only one type of exit.

Method #2: Using SAP Application Hierarchy

- Selecting the "Overview -> Applic. hierarchy -> SAP" menu path in the ABAP/4 Development Workbench will take you to a listing of all standard SAP applications and components .

- To locate a user exit for a particular application, follow these steps
from the SAP Application Hierarchy:

- Select the appropriate application by single clicking on it.
- Choose the "Edit Sel./desel. subtree" menu path.
- Click on the ‘Repository Infosys.’ pushbutton.
- This will take you to the ABAP/4 Repository Information System.
- Double click on the ‘Environment’ branch.
- Double click on the ‘Customer enhancement’ branch.
- Double-click on the ‘Customer exit’ branch.
- This will take you to the customer exit (or enhancement) selection screen with the appropriate development class for the application selecting on the Application Hierarchy.

- Click on the ‘Execute’ pushbutton.
- This will take you to a listing of all enhancements that meet the selection criteria.

From this listing, you can display the components of each enhancement and the documentation. You will be taken automatically to transaction SMOD from the ABAP/4 Repository Information System.

Remark: To use this one must have knowledge about the application hierarchy to which that particular enhancement belongs. Also one has to explode individual enhancements to identify weather the component is contained in that enhancement.

Like previous method, there is no scope for selection option on the components name.


Method #3:
Writing a small report program
The details about projects, enhancements and components are contained in two SAP tables:

MODSAP: containing enhancement name, type of exit and component
MODACT: containing project name and enhancements
Thus by writing a report program to retrieve data from these two tables, you can customize your search requirements. Code for one such sample program is attached in annexure A and the corresponding transaction code to execute this program is YSMD .

Using this you can list all components that match a particular string like the program name or the function code as well as search for only one type of exit.

NOTE: SAP’s naming convention for user exits-

· Program/Function exits : EXIT_AAAAAAAA_nnn where
AAAAAAAA stands for the program name which contains the exit and
nnn is a SAP assigned number starting from 001

· Menu exits : AAAAAAAA+XXX where
AAAAAAAA stands for the program name which contains the exit and
+XXX is the name of the function code contained in the menu item

· Screen Exits : AAAAAAAA_nnnn_BBBBBBBB_CCCCCCCC_mmmm where
AAAAAAAA : calling program name
nnnn : calling screen number
BBBBBBBB : area
CCCCCCCC : called program name
mmmm : called screen number

Source Code to find User Exits 1
************************************************************************
* REPORT YSMOD2
*
* SELECTION TEXTS : INPUT1 ----> Enter search term for Trxn.
* INPUT2 ----> Enter type of exit
************************************************************************
REPORT YSMOD2 .

TABLES: MODSAP, MODACT, TSTC.

PARAMETERS: INPUT1 LIKE TSTC-TCODE DEFAULT ' ',
INPUT2 LIKE MODSAP-TYP DEFAULT ' '.

DATA: SEARCH1(6),
SEARCH2(3),
SEARCH3 LIKE MODSAP-MEMBER.
DATA : FIRST_ROW VALUE 'Y'.

CONCATENATE: '%' INPUT1 '%' INTO SEARCH1,
'%' INPUT2 INTO SEARCH2.

SELECT * FROM TSTC WHERE TCODE LIKE SEARCH1.
FIRST_ROW = 'Y'.
CHECK TSTC-PGMNA NE SPACE.
CONCATENATE '%' TSTC-PGMNA '%' INTO SEARCH3.
SELECT * FROM MODSAP WHERE TYP LIKE SEARCH2
AND MEMBER LIKE SEARCH3.
SELECT SINGLE * FROM MODACT WHERE MEMBER = MODSAP-NAME.
IF FIRST_ROW EQ 'Y'.
WRITE: /0 TSTC-TCODE, 6 TSTC-PGMNA, 16 MODSAP-NAME, 32 MODSAP-TYP,
45 MODSAP-MEMBER, 70 MODACT-NAME.
FIRST_ROW = 'N'.
ELSE.
WRITE: /16 MODSAP-NAME, 32 MODSAP-TYP, 45 MODSAP-MEMBER, 70 MODACT-NAME.
ENDIF.
CLEAR : MODSAP, MODACT.
ENDSELECT.
IF SY-SUBRC NE 0.
WRITE : /0 TSTC-TCODE, 6 TSTC-PGMNA, 30 'No exits found'.
ENDIF.
CLEAR TSTC.
ENDSELECT.

END-OF-SELECTION.
CLEAR: SEARCH1, SEARCH2, SEARCH3.

Source Code to Locate User Exits
************************************************************************
* REPORT YSMOD
*
* SELECTION TEXTS : INPUT1 ----> Enter search term for Enhancmn
* INPUT2 ----> Enter type of exit
* INPUT3 ----> Enter search term for componen
************************************************************************
REPORT YSMOD .

TABLES: MODSAP, MODACT.

PARAMETERS: INPUT1 LIKE MODSAP-NAME DEFAULT ' ',
INPUT2 LIKE MODSAP-TYP DEFAULT ' ',
INPUT3 LIKE MODSAP-MEMBER DEFAULT ' '.

DATA: SEARCH1 LIKE MODSAP-NAME,
SEARCH2(3), " like modsap-typ,
SEARCH3 LIKE MODSAP-MEMBER.

CONCATENATE: '%' INPUT1 '%' INTO SEARCH1,
'%' INPUT2 INTO SEARCH2,
'%' INPUT3 '%' INTO SEARCH3.

SELECT * FROM MODSAP WHERE NAME LIKE SEARCH1
AND TYP LIKE SEARCH2
AND MEMBER LIKE SEARCH3.
SELECT SINGLE * FROM MODACT WHERE MEMBER = MODSAP-NAME.
WRITE: /10 MODSAP-NAME, 30 MODSAP-TYP, 45 MODSAP-MEMBER, 70 MODACT-NAME.
CLEAR : MODSAP, MODACT.
ENDSELECT.

IF SY-SUBRC NE 0.
WRITE : /'Not found'.
ENDIF.

END-OF-SELECTION.
CLEAR: SEARCH1, SEARCH2, SEARCH3.

Step by step procedure for creating Field Exits

There are eight steps to creating a field exit:

Step 1: Determine Data Element
Step 2: Go To Field Exit Transaction
Step 3: Create Field Exit
Step 4: Create Function Module
Step 5: Code Function Module
Step 6: Activate Function Module
Step 7: Assign Program/Screen
Step 8: Activate Field Exit

Step 1: Determine Data Element

- Before you can begin adding the functionality for a field exit, you must know the corresponding data element.

- An easy way to determine the data element associated to a particular screen field is to:
Go the appropriate screen.
Position the cursor in the appropriate field.
Press ‘F1’ for field-level help.
Click on the ‘Technical info’ pushbutton (or press ‘F9’) on the help dialog box.

On this Technical Information dialog box, the data element will be specified if the field is 'painted' from the ABAP/4 Dictionary.


Step 2: Go To Field Exit Transaction

- The transaction to create field exits is CMOD.
- You can use the menu path Tools -> ABAP/4 Workbench -> Utilities -> Enhancements -> Project management.

- From the initial screen of transaction CMOD, choose the Text enhancements -> Field exits menu path.

- After choosing this menu path, you will be taken to the field exits screen. From here, you can create a field exit.

NOTE : Even though you use transaction CMOD to maintain field exits, you do not need to create a project to activate field exits.


Step 3: Create Field Exit

- From the field exit screen of transaction CMOD, choose the Field exit -> Create menu path.

- After choosing this menu path, a dialog box will prompt you for the appropriate data element .

- Enter the data element name and click the ‘Continue’ pushbutton.
- Now, you will be able to create the function module associated to the data element’s field exit.

Step 4: Create Function Module

- You will automatically be taken to the Function Library (SE37) after entering a data element name and clicking the ‘Continue’ pushbutton.

- In the ‘Function module’ field, a function module name will be defaulted by the system based on the data element specified. This name will have the following convention:
FIELD_EXIT_

- You can add an identifier (an underscore followed by a single character ).
- The first function module for a data element’s field exit must be created without an identifier.

- To create the function module, click on the ‘Create’ pushbutton, choose menu path Function module -> Create, or press ‘F5’.

- After choosing to create the function module, you will get the warning: "Function module name is reserved for SAP". This message is just a warning so a developer does not accidentally create a function module in the field exit name range. By pressing ‘Enter’, you will be able to go ahead and create the function module.

- Before coding the function module, you will have to specify the function modules attributes -- function group, application, and short text.


Step 5: Code Function Module


- From the function module’s attributes screen, click on the ‘Source code’ pushbutton or choose the Goto -> Function module menu path to the code of the function module.

- Here you will add your desired functionality for the field exit.
- Remember that field exit’s function module will have two parameters -- one importing parameter called "INPUT" and one exporting parameter called "OUTPUT". These parameters will be set up automatically by the system.

- You must remember to assign a value to the OUTPUT field. Even if the value does not change, it must be moved from the INPUT field to the OUTPUT field.

Step 6: Activate Function Module

- After coding the function module, you must remember to activate it.
- Use the Function module -> Activate menu path to activate the function module.
- At this point, you can return to the field exit transaction.
- You should be able to 'green arrow' back to this transaction.
- When you return to the field exit transaction, you will see an entry for the newly created field exit.

- At this point, the field exit is global. That is, it applies to all screens that use a particular data element. On any screen that uses the data element, the corresponding field exit function module will be triggered, once it is active.
- Also, the field exit will not be triggered yet because it is inactive.


Step 7: Assign Program/Screen

- This step is only needed if you want to make a field exit local.
- To make a field exit local, select the field exit and click on the ‘Assign prog./screen’ pushbutton.

- In the dialog box , indicate the appropriate program name and screen number.
This information indicates that the field exit is local to the specified screen in the specified program.

- In the dialog box, you determine which function module gets executed for the field exit by specifying the identifier in the ‘Fld. Exit’ field.
- If this field is left blank, the function module triggered will be 'FIELD_EXIT_'.

- If a single-character identifier is entered into the field, the function module triggered will be 'FIELD_EXIT__'.

Step 8: Activate Field Exit

- The field exit must be active for it to be triggered by the system.
- Activate the field exit by choosing the Field exit -> Activate menu path.
- After assigning the field exit to a change request, its status will change to ‘Active’ and it will be triggered automatically on the appropriate screen(s).

NOTE : In order to activate the field exit the profile parameter abap/fieldexit = YES must be set on all application servers

Step by step procdure for creating Menu Exits

PART A: Search for the menu exit.

1. A menu exit is a way to add a menu item and corresponding functionality to the menu bar of an SAP transaction. The first step is to navigate to the screen where you want to attach menu exit.

2. Go to the menu painter of that screen through system -> status and look for function codes in the menu bar that start with a plus sign. These are the menu's which can be enhanced.


PART B: Attaching your own menu.


3. Run transaction YSMD (available in 3.1G) to identify the Enhancement and the Component which contains that exit or search it through transaction SMOD.

Note : All menu exits will have the function code name with the plus sign as the last four characters of the component.

4. Include the Enhancement in your own project through transaction CMOD.

5. Go to Enhancement Components a
And double click on the component name to give your own text to the menu item.
6. Activate the project.

At this point the menu item will appear, but it will have no functionality.

PART C: Adding functionality to the menu item.

The new menu item can have functionality in four ways:
predefined functionality by SAP programmer
transaction code
program exit
area menu'

7. You do not have control over the first method of functionality to a menu exit. In some cases, SAP programmers will have predefined code that is executed once you activate the menu exit.

8. If the menu exit function code is a type “T” function code, you will need to create a transaction code to add functionality to the new menu item. (To find the type of the function code, just double click on the function code in the GUI screen) The transaction code should have the same name as the function code (remember: it will start with a plus sign). The transaction code you create can either call an online (module pool) program or a report. You can create a transaction code from the object browser.

9. If the functionality for a menu exit is to be placed in a program exit, the menu exit and corresponding program exit will belong to the same enhancement.

Examining the enhancement that contains the menu exit can give you an initial indication that a program exit is needed to add functionality. You can code the program exit by double clicking on the component in your project or examining the SAP code to find the corresponding check of the function code triggered. For the appropriate function code, you will see a “CALL CUSTOMER-FUNCTION” statement.

10. The last way of adding functionality is through area menu’s. An area menu is a transaction that serves as a collection point for several other transactions. Unlike other dialog transactions, area menus do not have underlying programs, hence, you cannot append your own functions to them.

No screens accompany an area menu. An area menu has only one title and status, both of which are assigned by the system. Area menus allow you to create menus containing functions that are customized for a particular function in your company. Creating an area menu is similar to creating a standard menu. However, instead of specifying functions for menu options you specify transaction codes.

To navigate to area menu’s choose Development -> Other tools -> Area menus. The name of the area menu should be same as that of the function code of the menu exit.


Step by step procedure for creating Screen Exits


PART A: Search for the screen exit.

1. A screen exit is a way to add a sub-screen and corresponding functionality to an SAP transaction. The first step is to navigate to the screen where you want to attach menu exit.

2. Go to the field list of that screen through system -> status or F1 -> Technical details and look for fields that have subscreen as the field type for that particular screen. These are the area's on the main screen which can be enhanced.

PART B: Creating your own subscreen.

3. Identify the enhancement and its component that has the provision for creating the screen exit for that particular screen.

Note A: To know more about how to identify the enhancement, refer to the document on Locating User Exits.

Note B: All SAP provided subscreen’s may not have the scope for enhancement. There are a limited number of transactions which has scope for screen exit. Refer to Annexure A for details.

4. Include the Enhancement in your own project through transaction CMOD.
5. Go to Enhancement Components and double click on the component name.
6. It will take you to the screen attributes for that particular subscreen.
· The screen type should be subscreen.
· Maintain the size of the subscreen through Lines/Columns attribute. This should correspond to the size of the subscreen mentioned in the main SAP screen.

· The development class for the subscreen should be the development class for the project.

7. Create the subscreen using the fullscreen editor.
8. You can add your own modules in the subscreen’s flow logic. However, one has to be careful regarding data transfer between the main screen and the subscreen. For more details refer to R/3 On-line Help.
9. Generate the screen.

PART C: Activating the project

10. Use the back button to navigate back to the project enhancement main screen.
11. Activate the project.

RELATED POST

USER EXITS IN SAP COMPLETE

EnjoySAP introduction and Business Process of SAP XML with ALE,IDOC and BAPI

USER EXITS in SAP ABAP in Detail

In computer software, a user exit is a place in a software program where a customer can arrange for their own tailor-made program to be called.In the R/3 system from SAP, a user exit is contrasted with a customer exit and allows a customer's developer to access program components and data objects within the R/3 system. In R/3, some user exits use Include statements to include customer program enhancements that are called from the program.Other user exits use tables that are accessed through customization.


Extension of SAP functionality

SAP makes different possibilities available to extend SAP functionality in the R/3 without modifying the delivered R/3-Standard. Thus these extensions are further present also after a R/3-Release-Wechsel.

• User exit
• Field exit
• Text extensions
• Customer exit
• Table extensions

1. User exit

User exits are original one in the selling module (SD) developed expandability.They consist of empty subroutines (FORM) in special Includes, which can be filled by a ABAP Use developer.In special places in the SA P-CODE such subroutine references were inserted by SAP. An extension is thus only possible, where SAP planned it.They usually offer a rather rudimentary expandability, since purely technically objects in the SAP name area are modified.


2. Field exit

Field exits are bypasses of a Dynprofield with data element purchase into a functional module. These will go through when leaving the Dynpros. There are global and local field exits.

Global field exits

are not limited to a Dynpro. If a data element is used on several Dynpros, after activation of the field exit with all this Dynpros to a functional module one branches out.

Local one field exit

work only on a Dynpro limited. There is the possibility of putting on bus to 36 local field exits to a data element.

3. Text extensions

With text extensions it acts around user keywords and user documentation (F1-Hilfe) to data elements. The new keywords can refer to SAP documentation and to user documentation. Thus one has also the possibility of overwriting the keywords delivered by SAP.With text extensions the changes are global effective for all SAP applications concerned contrary to application extensions after activation.

4. Customer exit

An application function can be extended by application extensions by the customer. Customer exits must be intended by SAP. They consist generally of several components. The interface SAP/Kunde is clearly defined.With a R/3-Release-Wechsel and/or. Upgrade remain the customer extensions without effort.

• Function exit
• Menu exit
• Dynpro exit

A) Function exit
By functional module exits the customer can implement additional logic in an application function.
SAP built such exits in different places into many application functions. Thus are the interfaces are already given, and/or which data handed over.These functional modules can be filled now by the customer. It can insert also user Dynpros with associated processing logic and GUI surface and put on user text elements.

B) Menu exit

Menu exits make it for the customer possible to build and occupy with a function code in an SAP application new menu entries.SAP determined, where in the program additional function codes are queried and like to it is being reacted, either by a functional module exit or by an already firmly given functionality.

C) Dynpro exit

Dynpro exits permit the customer to arrange ranges of a dynpros reserved by SAP. Within these ranges large information can be indicated or data be seized. Those for this force fields by the customer on a user Dynpro are arranged.



What is User Exits?

The following document is about exits in SAP: -
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.SAP creates user exits for specific programs, screens, and menus within standard R/3 applications.These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.

Types of Exits

There are several different types of user exits. Each of these exits acts as hooks where you can attach or "hang" your own add-ons.

Menu Exits

Menu exits add items to the pulldown menus in standard SAP applications. You can use these menu items to call up your own screens or to trigger entire add-on applications.SAP creates menu exits by defining special menu items in the Menu Painter. These special entries have function codes that begin with "+" (a plus sign). You specify the menu item’s text when activating the item in an add-on project.

Screen Exits

Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing special sub screen areas on a standard R/3 screen and calling a customer subscreen from the standard screen’s flow logic.

Function Module Exits

Function module exits add functions to R/3 applications. Function module exits play a role in both menu and screen exits.When you add a new menu item to a standard pull down menu, you use a function module exit to define the actions that should take place once your menu is activated.Function module exits also control the data flow between standard programs and screen exit fields.SAP application developers create function module exits by writing calls to customer functions into the source code of standard R/3 programs.

These calls have the following syntax:

CALL CUSTOMER-FUNCTION ‘001’.

Field Exits

Field exits allow you to create your own programming logic for any data element in the Dictionary.You can use this logic to carry out checks, conversions, or business-related processing for any screen field. Example: The data element BBBNR identifies a company’s international location number. You might want to set up your R/3 System so that all international location numbers are larger than 100.

The field exit concept lets you create a special function module that contains this logic.You assign the special function module to the data element BBBNR. You then assign the module to any programs and screens in which users can add new international location numbers. When you activate your field exit, the system automatically triggers your special routine whenever a user enters a company location number.

In 4.6c, you can use "RSMODPRF" program to create field exits.
An example of a user exits :-
MODULE user_exit_0001 INPUT
CASE okcode.
WHEN 'BACK OR EXIT'.
CASE sy-dynnr.
WHEN '100'.
SET SCREEN 0.
LEAVE SCREEN.
WHEN '200'.
******************************************************************************
**** Note that you can write any code that satisfy your needs. ****
**** But in this case, this was wrote as a sample code for reference sake. ****
**** And you can test it. ****
******************************************************************************
SET SCREEN 100.
LEAVE SCREEN.
ENDCASE.
ENDCASE.


SAP User Exits Routine

User exits are routine which SAP allows you to add in additional customized programs process without affecting the standard SAP programs.
SAP user exit are usually declare as a form routine :-
form userexit_xxxxx
........................
endform

In VL01 - Create Delivery Order, standard program SAPMV50A, the standard program did not check for storage location equal to space, and delivery quantity less than one when the user click the save button. Therefore I have to insert the additional checking into the user exit routine.

Steps:-

  1. • Go to transaction VL01 to pick a Sales Order for delivery (you don't have to save the data)
  2. • In the initial screen, click System -> Status -> Double click on Program (Screen)
  3. • In the dialog program SAPMV50A, click Edit -> Search/replace
  4. • Type user exit in the Find field, then click the In program radio button and hit Enter
  5. • A number of user exit routines will be displayed. You'll have to roughly decide which is the correct user exit routine to used.
Another way of determining the list of user exits could be bus executing the Tcode SE80.
For example if U need to search for the user exits for the above mentioned program, execute the Tcode SE80 and enter the above program name,

The highlighted row denotes a user exit, which is used in this program form userexit_save_document_prepare.
case xlips-pstyv.
when 'TAX' or 'REX'.
* Accept this two Delivery item category
when 'REN'.
if xlips-lgort = space.
* Reject this Delivery item category
message e001.
endif.
when others.
if xlips-matnr <> space.
* Check storage location not space
if xlips-lgort = space.
message e002.
endif.

user-exits:

1. Validation exits are used in the prerequisites and checks. They have either the value 'T' for true or 'F' for false. They are interpreted as a part of the logical statement, like a constant or field comparison. For this type of user exit, you must fill a parameter with the results of your check ('T' for true; 'F' for false).

Example

FORM Uzzzz USING B_RESULT. "'T' or 'F'
from program ZGGBR000 (ZGGBRI03)
2. Substitution exits are used to change one or more fields. However, you can only change those fields that are permitted in the Boolean class for the substitution. You can display these fields by selecting the following menu options in substitution maintenance: Fields for substitutions> 

Example 

FORM Uzzzz USING COST_CENTER.
from program ZGGBS000 (ZGGBSI02)
Substitution Fields can be found from this window

/NORFB->Bus.transactions->Base parameters->Substitution->Call Pnt 2->Substitution step 3->Extras->Substitution flds
The name of the form pool (e.g., ZGGBR000 & ZGGBS000) that contains your user exit must be stored in table T80D.

1. Data declaration 

Tables and field stings cannot be declared in form routines, so that the contents can be used along with the calling transaction. 

2. Parameter definition 

It is important that you make declare the code generation program for your user exit; how many and what type of parameters you are using for the user exit. You do this by entering your newly defined user exits in the form routine GET_EXIT_TITLES.
found in program ZGGBR000 (ZGGBRTIT)
found in program ZGGBS000 (ZGGBSTIT)

One exception is the parameter for the results of a validation exit. You must not declare this, it is automatically generated be the system. What types of parameters are available and how you use them is described in the online documentation. When creating your user exits, you can use the example form pools delivered by SAP (RGGBR000 for validations; RGBBS000 for substitutions) as a reference. We recommend that you copy the example form pools delivered by SAP when creating your own user exits. In these example form pools, entries already exist in the form routine GET_EXIT_TITLES for the examples delivered. The GET_EXIT_TITLES must absolutely exist in your form pool. 

You can find additional information on the creation of user exits in the online documentation on validations and substitutions.

RELATED POSTS

TABLE CONTROL IN BDC
ERP advantages and erp project launch


SAP Modifications Extended Lesson Fifty Seven

Modifications can be categorized as 'critical' if:They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult (as with menus, pushbbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases).Withbout the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:

Function modules that have been released
BAPIs
Includes for user exits
Screen, program, menu, and field exits

After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant .You must be familiar with the processing logic of your application in order to be able to adjust programs properly.Modification adjustment is not necessary if you avoid making changes to SAP objects.Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.From Release 3.0, you can use Online Correction Services to import and cancel Support packages and patches automatically (instead of having to insert preliminary corrections manually).

Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.

Choose copying instead of modifying if:

You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.

ABAP development projects can be evaluated according to the following criteria:

What will implementation cost, measured in manpower (creating the concept, implementation, testing)?
How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?
By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.

Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).
The following naming conflicts can occur:
An SAP Repository object and a customer Repository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions.

Two customer Repository objects conflict

Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.

RELATED POSTS

LESSON 1 SAP NAVIGATION

SAP Modifications Lesson Fifty Six

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type Development/Correction.This request ensures that the objects are transported from the development system into the subsequent systems.Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately.However, you cannot do this with SAP objects, because they are not original in any of your systems.

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

A registered developer must register registers changes to SAP objects. Exceptions to this registration are match codes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example , in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

How do you benefit from SSCR (SAP Software Change Registration)?

Quick error resolution and high availability of modified systems
All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

Dependable operation
Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

Simplification of upgrades
Upgrades and release upgrades become considerably easier due to the smaller number of
modifications.

If you want to change an SAP Repository object, you must provide the Workbench Organizer with the following information:

SSCR key
Change Request

We saw above how you get an SSCR key. If you now continue to change the object, you must confirm the following warning dialogs: At this point, you can still cancel the action without repairing the object.The Workbench Organizer asks you to enter a change request, as it would for your own objects. The object is automatically added to a repair task. The change request has the following functions:

Change lock
After the task has been assigned, only its owner can change the object.

Import lock
The object cannot be overwritten by an import (upgrade or support package).

Versions
The system generates a new version of the object (see below).

After development is finished, the programmer releases the task. At this point, the programmer must document the changes made. The objects and object locks valid in the task are transferred to the change request. If the developer confirms the repair, the import lock passes to the change request. If the developer does not confirm the repair when releasing the task, the import lock remains in place.
Only the developer can release this lock.Once the project is completed, you release the change request. This removes all of the change request's object locks. This applies both to the change locks and the import locks.

When the change request is released, the objects are copied from the R/3 database and stored in a directory at operating system level. They can then be imported into subsequent systems by the system administrator.After the modifications have been imported into the quality system, the developer must test them and check the import log of the request.When you release a change request, a complete version of all objects contained in the change request is written to the versions database.

If you transport the Repository object again later, the current object becomes a Complete copy and the differences between the old and the new object are stored in the versions database as a backwards delta.Whenever you assign a Repository object to a task, the system checks whether the current version agrees with the complete copy in the versions database. If not, a complete copy is created. This process is also initiated the first time you change an object, since SAP does not deliver versions of Repository objects.

The versions of a Repository object provide the basis for modification adjustment. To support adjustment, information on whether the version was created by SAP or by the customer is also stored.Encapsulate customer source code in modularization units instead of inserting it directly into SAP source code (with, for example, customer function module calls in program source code, or customer sunscreen calls for additional screen fields).When encapsulating the customer portions of a program, be sure to use narrow interfaces.You should define a standard for all of your company's modification documentation (see the following slides).You should also maintain a list of all modifications to your system (a modification log - see the following slides).

All requests that contain repairs must be released before an upgrade so that all relevant customer versions can be written to the versions database (the system compares versions during adjustment).Repairs must also be confirmed prior to upgrade, otherwise the object being repaired is locked and cannot be imported.

Any modifications that you make to ABAP Dictionary objects that belong to Basis components are lost at upgrade--- these objects revert to their earlier form and no adjustment help is offered. This can lead to the contents of certain tables being lost.The aim of the Modification Assistant is to make modification adjustments easier. In the past, the granularity of modifications was only at including program level. Today, a finer granularity is available. Now, modifications can be recorded at subroutine or module level.

This is because (among other reasons) the modifications are registered in a different layer. As well as providing finer granularity, this means that you can reset modifications, since the original version is not changed.If, in the past, you modified an include for which SAP provided a new version in an upgrade, a modification adjustment was necessary. The modification adjustment had to be performed line by line. The system provided little support.

The Modification Assistant has changed this situation considerably. Modifications are now recorded with finer granularity. For example, if you modify a subroutine, the rest of the include remains unchanged. If SAP delivers a new version of the include, the system looks to see if there is also a new version of that subroutine. If this is not the case, your changes can be incorporated into the new version automatically.

The original version of each software layer comprises the originals from the previous layer plus current modifications.the ABAP Editor, you can use modification mode to change source code. Only a restricted range of functions is available in this mode. You can add, replace, or comment out source code, all under the control of the Modification Assistant.Changes to layout and flow logic in the Screen Painter are also recorded.

The Modification Assistant also records changes in the Menu Painter and to text elements, as well as the addition of new function modules to an existing function group.To avoid conflicts in the upgrade, table appends are also logged by the Modification Assistant.If you want to change an SAP object, you must provide the following information:

SSCR key

Change request
The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.You can switch the Modification Assistant on or off for the entire system changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate push buttons. For example, in the ABAP Editor, you can:
Insert

The system generates a framework of comment lines between which you can enter your source code.

Replace
Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

Delete
Select a line or a block and choose Delete . The lines are commented out.

Undo modifications
This undoes all of the modifications you have made to this object.

Display modification overview
Choose this function to display an overview of all modifications belonging to this object.

The graphic shows the result of changes made with Modification Assistant.The Modification Assistant automatically generates a framework of comment lines describing the action. The comment also contains the number of the change request to which the change is assigned, and a number used for internal administration.The "modification overview" icon provides you with an overview of the modifications you have made in the current program.The display is divided up according to the various modularization units. This corresponds to the structure used by the Modification Assistant to record the modifications.You can reset all of the modifications that you have made to the current object using the Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.The Modification Browser provides an overview of all of the modified objects in the system. The Modification Browser differentiates between modifications made with the Modification Browser and those made without.

On the initial screen of the Modification Browser, you can restrict the selection according to various criteria. This allows you to find modifications in a particular area.The Modification Assistant displays the hit list in tree form. Objects are arranged by:

Modification type (with/without the Assistant)

Object type (PROG, DOMA, DTEL, TABL,)

SAP recommends that you use Modification Assistant to make changes to R/3 objects. Changes without the use of the Modification Assistant should be avoided. However, should this be necessary, you should document your modifications in the source code as follows?

Preliminary corrections SAP note, repair number, changed by, changed on, valid until

Customer functions that have been inserted subject area, repair number, changed by, changed on, INSERTION

Customer functions that have replaced SAP functions subject area, repair number, changed by, changed on, REPLACEMENT The SAP functions that you do not need should not be deleted, but commented out instead

Subject areas are specified in the relevant process design blueprint (for example, subject area SD_001 = pricing).

SAP recommends that you keep a record of all modifications that have been made to your system (that is, of any changes you have made to Repository objects in the SAP namespace).

The following information should be logged for each modification:

Object type (program, screen, GUI status,)

Object name

Routine (if applicable)

Subject area (according to process design blueprint or technical design)

Repair number
Changed on
Changed by
Preliminary correction? (Yes/no)
OSS note number, valid until Release x.y

Amount of time necessary to recreate modification during adjustment (measured in hours).
A module pool is organized as a collection of include programs. This is particularly useful for making the program easier to understand. The organization is similar to that of function groups. In particular, the naming convention, by which the last three letters of the name of the include program identify its contents, is identical.The main program, as a rule, contains the include statements for all of the include programs that belong to the module pool.The includes described as "special" includes in the program are themselves only include programs - technically, they are not different. These programs are only delivered once.User exits are a type of system enhancement that were originally developed for the R/3 Sales and Distribution Module (SD). The original purpose of user exits was to allow the user to avoid modification adjustment.

A user exit is considered a modification, since technically objects in the SAP namespace are being modified.The SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention userexit_. The calls for these subroutines have already been implemented in the R/3 program. Usually global variables are used.After delivering them, SAP never alters includes created in this manner; if new user exits must be delivered in a new release, they are placed in a new include program.User exits are actually empty subroutines that SAP developers provide for you. You can fill them with your own source code.

The purpose behind this type of system is to keep all changes well away from program source code and store them in include programs instead. To this end, SAP developers create various includes that fulfill the naming conventions for programs and function groups. The last two letters in the name of the include refer to the include that the customer should use: "Z" is usually found here.Example: Program SAPM45A Include M45AFZB

This naming convention guarantees that SAP developers will not touch this include in the future. For this reason, includes of this nature are not adjusted during modification upgrade.The subroutine call is already implemented in the program. The interface is already defined. Normally, subroutines of this type only work with global data.If any new user exits are delivered by SAP with a new release, then they are bundled into new includes that adhere to the same naming convention.There, you will also find documentation explaining why SAP developers have created a particular user exit.

The set of objects for adjustment is derived from the set of new objects delivered by SAP in a new release. This is compared with the set of objects you have modified on your R/3 system.The intersection of these two sets is the set of objects that must be adjusted when you import an upgrade or support package.During modification adjustment, old and new versions of ABAP Repository objects are compared using transactions SPDD and SPAU.You do not have to call transaction SPDD to adjust Dictionary objects if:

No changes have been made to SAP standard objects in the Dictionary
You have only added customer objects to your system. Only SAP objects that have been
Changed must be adjusted using this transaction.

All other ABAP Repository objects are adjusted using transaction SPAU. Upgrade program R3up tells you to start the transaction after upgrade has finished. You have 30 days to use transaction SPAU after an upgrade. After 30 days, you must apply for a SSCR key for each object that you want to adjust.

Transaction SPAU first determines which objects have been modified. Then it determines which of these objects have a new version in the current upgrade. Modification adjustment allows you to transfer the modifications you have made in your system to your new R/3 Release.Use transaction SPDD to adjust the following ABAP Dictionary objects during the modification adjustment process:

Domains
Data elements
Tables (structures, transparent tables, pool, and cluster table, together with their technical settings)
These three object types are adjusted directly after the Dictionary object import (before the main import). At this point in time, no ABAP Dictionary objects have yet been generated. To ensure that no data is lost, it is important that any customer modifications to domains, data elements, or tables are undertaken prior their generation.

Changes to other ABAP Dictionary objects, such as lock objects, match codes, or views, cannot result in loss of data. Therefore, these ABAP Dictionary objects are adjusted using transaction SPAU after both main import and object generation have been completed. You can use transaction SPAU to adjust the following object types:

ABAP programs, interfaces (menus), screens, match code objects, views, and lock objects.During modification adjustment, you should use two different change requests to implement the changes you have made: one for SPDD adjustments and another for SPAU adjustments. These change requests are then transported into other R/3 systems you want to adjust. This guarantees that all actual adjustment work takes place solely in your development system.

When upgrading additional R/3 systems, all adjustments exported from the first system upgrade are displayed during the ADJUSTCHK phase. You decide which adjustments you want to accept into your additional systems and these are then integrated into the current upgrade. Afterwards, the system checks to see if all modifications in the current R/3 system are covered by the change requests created during the first system upgrade. If this is the case, no adjustments are made during the current upgrade.

Note: For this process to be effective, it is important that all systems involved have identical system landscapes. This can be guaranteed by first making modifications in your development system and then transporting them to later systems before you upgrade the development system. You can also guarantee that all of your systems have an identical system landscape by creating your development system before upgrade as a copy of your production system and then refraining from modifying the production system again until after upgrade.Version compare is also used during or after an upgrade for modification adjustment.

During modification adjustment, version compare determines the number of SAP objects that you a) changed in the system and that b) were then overwritten by SAP at upgrade.Version compare allows you to find where changes were made and transfer them to your new SAP version if you want.The icons in front of the individual objects that need adjustment show how they can be adjusted.The possible methods are:

Automatically
The system could not find any conflicts. The changes can be adopted automatically

Semi-automatically
The individual tools support you in adjusting the objects.

Manually You must process your modifications with no special support from the system. In this case, the modification adjustment does allow you to jump directly into the relevant tool. Adjusted objects are identified by a green tick. If you want to use the new SAP standard version, use Restore original. If you do this, you will have no further adjustment work in future.

RELATED POSTS

LESSON 57 MODIFICATIONS EXTENDED


Check Deposit Customization

Enhancement using Customer Exists Lesson Fifty Four


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 push button 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 run time.The R/3 System determines which screen will be displayed in a SUB SCREEN area at PBO. 

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.


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.


RELATED POSTS

LESSON 55 BUSINESS ADD IN'S
SAP project introduction in the best ERPSAP project migration

Enhancements to Dictioanry Elements in ABAP Lesson Fifty Two


Tables and structures can be expanded in one of two different ways:

Append structures allow you to enhance tables by adding fields to them that are not part of the standard. With append structures; customers can add their own fields to any table or structure they want.Append structures are created for use with a specific table. However, a table can have multiple append structures assigned to it.If it is known in advance that one of the tables or structures delivered by SAP needs to have customer-specific fields added to it, the SAP application developer includes these fields in the table using a Customizing include statement.The same Customizing include can be used in multiple tables or structures. This ensures consistency in these tables and structures whenever the include is extended.

Nonexistent Customizing includes do not lead to errors.Append structures allow you to attach fields to a table without actually having to modify the table itself.Append structures may only be assigned to a single table. A table may, however, have several append structures attached to it. Whenever a table is activated, the system searches for all active append structures for that table and attach them to the table. If an append structure is created or changed and then activated, the table it is assigned to is also activated, and all of the changes made to the append structure take effect in the table as well.

You can use the fields in append structures in ABAP programs just as you would any other field in the table.If you copy a table that has an append structure attached to it, the fields in the append structure become normal fields in the target table.You create append structures in the customer namespace. This protects them from being overwritten at upgrade or during release upgrade. New versions of standard tables are loaded during upgrades.

The fields contained in active append structures are then appended to the new standard tables when these new standard tables are activated for the first time.From Release 3.0, the field sequence in the ABAP Dictionary can differ from the field sequence in the database. Therefore, no conversion of the database table is necessary when adding an append structure or inserting fields into an existing one. All necessary structure adjustment is taken care of automatically when you adjust the database catalog (ALTER TABLE). The table's definition is changed when it is activated in the ABAP Dictionary and the new field is appended to the database table.

Pay attention to the following points when using append structures:

You cannot create append structures for pool and cluster tables.If a table contains a long field (either of data type LCHR or LRAW), then it is not possible to expand the table with an append structure. This is because long fields of this kind must always be the last field in their respective tables. No fields from an append structure may be added after them.

If you use an append structure to expand an SAP table, the field names in your append structure must be in the customer namespace, that is, they must begin with either YY or ZZ. This prevents naming conflicts from occurring with any new fields that SAP may insert in the future.

Some of the tables and structures delivered with the R/3 standard contain special include statements:

Customizing includes. These are often inserted in those standard tables that need to have customer specific fields added to them.

In contrast to append structures, Customizing includes can be inserted into more than one table. This provides for data consistency throughout the tables and structures affected whenever the include is altered.

Customizing include programs is part of the customer namespace: all of their names begin with 'CI_'. This naming convention guarantees that nonexistent Customizing includes do not lead to errors. No code for Customizing includes is delivered with the R/3 standard.

You create Customizing includes using special Customizing transactions. Some are already part of SAP enhancements and can be created by using project management (see the unit on 'Enhancements using Customer Exits').

The Customizing include field names must lie in the customer namespace just like field names in append structures. These names must all begin with either 'YY' or 'ZZ'.

When adding the fields of a Customizing include to your database, adhere to same rules you would with append structures.

Every time they define a data element, the SAP application programmers define keywords in different lengths and a short description for each data element.

You create field exits in Project management. Field exits are processed when the user leaves a screen that contains a field which refers to a data element containing a field exit.

SAP lets you create a field exit for every input-ready screen field that has been created with reference to the ABAP Dictionary. The additional program logic is stored in a function module and is executed at a specific point in the PAI logic.

The slide shows the order in which processing takes place. Before the PAI logic of the screen is executed, the system performs the following checks: First the system checks if all the required fields have been filled in. If a required field is empty, the screen is shown again.

The system then checks that data has been entered in the correct format.

Any defined field exits are executed next. For example, by sending an error message you can have the screen sent again.

Once all the field exits have been checked, the screen is processed as normal.

Field transport
Foreign key check
Processing the PAI module

Field exits take you from a screen field with a data element reference to a function module. Field exits can be either global or local:

Global field exits are not limited to a particular screen: If a global exit's data element is used on several screens, the system goes to the function module for all these screens after activating the field exit. Here you can, for example, edit the contents, force a new entry to be made by outputting an error message, or prohibit certain users from proceeding further.

Local field exits are valid for one screen only. If you assign a screen from a specific program to a field exit, then the system will go to the appropriate function module from this screen once the exit has been activated.

You can either create a global field exit or up to 36 local field exits for a data element, but not both.Each exit number refers to a different function module. Field exit function modules adhere to the following naming convention:

Prefix: FIELD_EXIT_
Name:
Suffix (for local field exit): _0 to _9, _A to _Z
To create field exits; choose Utilities in the ABAP Workbench. Choose Enhancements and then Project management to edit field exits and to implement customer exits. Do not create field exits directly from the Function Builder.

Choose Goto -> Global enhancements -> Field exits to start the transaction for maintaining field exits. To create a new enhancement, use the menu path Text Enhancements -> Create.Enter the name of the data element to which your screen field refers in the modal dialog box. The Function Builder is started with a special naming convention and interface options. The system specifies the name of the field exit. Do not change this name. Create the function module in a customer function group.The function module must be assigned to an existing customer function group.

The function module interface is fixed and cannot be changed. The function module has an import parameter INPUT and export parameter OUTPUT. The contents of the screen field are stored in parameter INPUT. The contents of OUTPUT are returned in the screen field when you leave the function module.

Field exits are not transported automatically. Therefore, you must assign the value of INPUT to OUTPUT in your source code. Otherwise the screen field would be blank after executing the field exit.The following ABAP statements are not allowed in field exit function modules:

CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT
COMMIT WORK, ROLLBACK WORK
COMMUNICATION RECEIVE
EXIT FROM STEP-LOOP
MESSAGE I, MESSAGE W
STOP, REJECT

When you debug a screen that is referenced by a field exit, the field exit code is ignored by the debugger. As with any normal function module, you can, however, debug the field exit code in the Function Builder's test environment.You can create local field exits that relate to a specific screen. A global field exit must already exist.Edit the local field exit based on the global field exit.You can create up to 36 local field exits, each of which carries a unique suffix. The system proposes a name for the function module; you should use this name.

Defining local field exits means that the function module of the global field exits initially created is no longer used. However, you must not delete it, for technical reasons. The field exits in the system would be deleted if you deleted the global function module of the field exit from the list.You must activate the field exit as well as the function module. Also note that field exits are only taken into account during screen execution if the R/3 profile parameter abap/field exit = YES has been set for all application servers. (This profile parameter is set to 'NO' by default).

If you declare field exits for multiple screen fields, you have no control over the order in which they are processed. In particular, you cannot access the contents of other screen fields in a field exit.


RELATED POSTS

LESSON 53 BUSINESS TRANSACTION EVENTS
MySAP environment security solutions
SAP security authentication and authorization