ALL SAP ABAP PROGRAMMING

DIFFERENCE BETWEEN BADI'S AND USER EXITS

2009-02-12T17:08:00.002+05:30

DIFFERENCE BETWEEN BADI'S AND USER EXITS:

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 in the 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:

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.

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.

The actual program code is enhanced using ABAP Objects. In order to better understand the programming techniques behind the Business Add-In enhancement concept, SAP recommends reading the section on ABAP Objects.

SAP R/3 ABAP/4 FAQ – User Exits

What is the gap bridging / Enhancement / Gap Development?

Customer changes to SAP repository objects without modifications.

Why do you need to use exits?

They do not affect standard SAP source code, do not affect software upgrade.

Various types of enhancement

Program, Menu, Screen, Field

How do you identify the user exits?

Use the transaction CMOD and for that respective development class exits available with + sign.

What do mean by SSCR & OSS.

“SAP Software Change Registration” & “Online Service System”.

How does the production system take the benefit from the user exit?

Development would be carried out in the Development system and the changes / user exits can be transported to the target system (quality or production)

ABAP ENHANCEMENTS

2009-02-12T17:08:00.001+05:30

ABAP ENHANCEMENTS:

SAP delivers a broad range of business functions within its R/3 application suite. You may find that the standard applications do not offer some of the functionality you need. The R/3 enchancement concept allows you to add your own functionality to SAP's standard business applications.

SAP creates customer 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.

Purpose of the Enhancement Concept

With the ABAP/4 Development Workbench, SAP's client-server development environment, you can create add-ons or entire applications. Before the enhancement concept existed, customers who wanted to add their own specific functions to SAP software had to modify the standard SAP programs.

Modifying SAP's software holds at least two dangers:

1.Modifying standard code can lead to errors

When a customer changes the source code of a standard program, these changes can have unwanted results within other parts of the application. Once a customer has begun 'reconstructing' a standard program, SAP can no longer guarantee that this customer's system will run without serious errors.

2.Modifications mean more work during software upgrades

Customers of standard software packages often want to take advantage of software upgrades or new releases. Customers who have modified the software of their current release must save these modifications and reenter them into the new software after each upgrade or release change. Depending on the number and scope of modifications, this reentry process may make it difficult or even impossible to take advantage of new software releases.

The enhancement concept offers a better alternative to the problem-ridden modification approach.

Reason for Using Exits

If you want to extend the functionality of your R/3 System, you should take advantage of the exits available within the standard R/3 applications. There are two main reasons why you should use exits rather than modifying SAP software. Add-ons that are attached to exits have the advantage that they:

1.Do not affect standard SAP source code When you add new functionality to your R/3 System using SAP's exits, you do not change the source code of standard SAP programs. The code and screens you create are encapsulated as separate objects. These customer objects are linked to standard applications, but they exist apart from SAP's standard software package.

2.Do not affect software upgrades When you add new functions using SAP's exits, the objects you develop are customer objects. Customer objects adhere to strict naming conventions. When the time comes to upgrade a software release, the special names of customer objects ensure that they will not be affected by either changes or additions within the standard software package. As a result, you do not need to save and then reenter add-ons attached to exits.

Customer exits are not available for all programs and screens within the R/3 standard applications. You can only use exits if they already exist within the SAP R/3 System. Locating Applications that Have Exits explains how to find applications with predefined exits.

If no user exit is available in an area where you want to add your own functionality, you can request that SAP develop an exit. You can make this request via the Online Service System (OSS).

Types of Exits

There are four basic types of customer exits. Each of these exits is a hook that you can hang your add-ons onto.

Menu exits Add items to the pulldown menus in standard R/3 applications. You can use these menu items, for example, 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 + (plus sign). You specify the menu item's text when activating the item within an add-on project.

Screen exits Add fields to the screens within R/3 applications. SAP creates screen exits by placing special subscreen areas within a standard R/3 screen and calling a customer subscreen from within the standard dynpro's flow logic.

Function module exits Add functionality 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 pulldown menu, for example, you can use a function module exits 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 the fields created within dynpro exits.

SAP application developers create function exits by preparing calls to customer functions within standard R/3 programs. These calls have the following syntax: CALL CUSTOMER-FUNCTION '001'.

Keyword exits Add documentation to the data elements of key words defined in the ABAP/4 Dictionary. The system displays this documentation whenever a user presses F1 to get online help for a screen field.

Unlike the other exits listed above, documentation exits do not require that SAP make any special preparations.

Creating an Add-on Project

To take advantage of the exits available within standard R/3 applications, you need to create an add-on project. This project lets you organize the enhancement packages and exits you want to use. The add-on project also allows you to hang add-on functionality onto the exit hooks contained with SAP enhancements.

Managing an Add-on Project

An add-on project contains a series of exits and the add-ons, such as menu entries or function modules, that you develop to hook onto these exits. To create an add-on project from within the ABAP/4 Development Workbench menu, choose Utilities ® Enhancements ® Project management.

Before you begin defining a project, you need to decide which application, application component, or specific standard transaction you would like to add your own functionality to. Give your project a name that indicates the type of functions it contains or shows which transactions are affected. It might be useful to agree upon a company-wide naming convention for enhancement projects.

There are two factors you need to keep in mind when you create an add-on project. First, you can include an SAP enhancement package and the customer exits it contains in one project only. The same SAP enhancement may not appear in two different customer projects.

Second, in order to make your add-ons, such as menu items or screen fields, appear in standard R/3 applications, you must activate your add-on project. When you activate a project, all of the add-ons created within this project are turned on. For this reason, you should ensure that the exits you include in your project contain functions that can be activated simultaneously. It is not possible to activate specific exits only.

After you have specified the name of your new project, proceed as follows:

1. Choose Create.
2. Describe the nature of the project by providing a short descriptive text.
3. Choose the SAVE icon.

The system prompts you to assign a change task. This assignment allows you to transport the project and its components into a productive system once you have completed it.

4. Specify which SAP enhancements packages you want to include in your project by choosing SAP enhancements.
5. Enter the names of all the SAP enhancements in the spaces provided.

You should choose enhancements packages which logically belong together. If you are planning to use several enhancements that deal with Materials Management modules, for example, you can include each of these enhancements in the same project. If you are working on enhancements that deal with different applications, or if the enhancements are not logically related, you should include these enhancements in separate projects.

Once you have identified the SAP enhancements to include in your project, you can begin adding your own functionality to the exits offered in the enhancements. To display the individual components of the SAP enhancements, return to the main screen of the Project Management transaction and choose Enhancement components. The system shows you all of the exits included in each of the enhancements assigned to your project.

To take advantage of the exits available within standard R/3 applications, you need to create an add-on project. This project lets you organize the enhancement packages and exits you want to use. The add-on project also allows you to hang add-on functionality onto the exit hooks contained with SAP enhancements.

Managing an Add-on Project

An add-on project contains a series of exits and the add-ons, such as menu entries or function modules, that you develop to hook onto these exits. To create an add-on project from within the ABAP/4 Development Workbench menu, choose Utilities ® Enhancements ® Project management.

Before you begin defining a project, you need to decide which application, application component, or specific standard transaction you would like to add your own functionality to. Give your project a name that indicates the type of functions it contains or shows which transactions are affected. It might be useful to agree upon a company-wide naming convention for enhancement projects.

There are two factors you need to keep in mind when you create an add-on project. First, you can include an SAP enhancement package and the customer exits it contains in one project only. The same SAP enhancement may not appear in two different customer projects.

Second, in order to make your add-ons, such as menu items or screen fields, appear in standard R/3 applications, you must activate your add-on project. When you activate a project, all of the add-ons created within this project are turned on. For this reason, you should ensure that the exits you include in your project contain functions that can be activated simultaneously. It is not possible to activate specific exits only.

After you have specified the name of your new project, proceed as follows:

1. Choose Create.
2. Describe the nature of the project by providing a short descriptive text.
3. Choose the SAVE icon.

The system prompts you to assign a change task. This assignment allows you to transport the project and its components into a productive system once you have completed it.

4. Specify which SAP enhancements packages you want to include in your project by choosing SAP enhancements.
5. Enter the names of all the SAP enhancements in the spaces provided.

You should choose enhancements packages which logically belong together. If you are planning to use several enhancements that deal with Materials Management modules, for example, you can include each of these enhancements in the same project. If you are working on enhancements that deal with different applications, or if the enhancements are not logically related, you should include these enhancements in separate projects.

Once you have identified the SAP enhancements to include in your project, you can begin adding your own functionality to the exits offered in the enhancements. To display the individual components of the SAP enhancements, return to the main screen of the Project Management transaction and choose Enhancement components. The system shows you all of the exits included in each of the enhancements assigned to your project.

Activating and Deactivating a Project

After you have attached all add-on functionality to the exits in your project, you need to activate the project. Activating a project turns on all your add-ons. You also need to activate your project after you have transported it from a development system into a productive system.

When you activate your project, the system turns on all the add-ons contained within the project. You cannot activate certain add-ons separately. The activate an add-on project, proceed as follows:

1. Enter the Project Management transaction.
2. Choose Activate project.

The system confirms that the project was activated.

You can now call up a standard SAP transaction that contains an exit you used in your add-on project. Your add-on functionally should appear.

If you need to make changes to any of your add-ons, you must first deactivate the project that contains that add-on. Deactivating a project turns off all of that project's add-ons. To deactivate an add-on project, proceed as follows:

1. Enter the Project Management transaction.
2. Choose Deactivate project.

The system confirms that the project was deactivated.

Once the project is turned off, you can make changes to the project's add-ons or build new functionality to hook on to the other exits in the project.

Transporting Add-on Projects
To take advantage of the exits in the R/3 System, you must create an add-on project. This project contains at least one SAP enhancement package and all the user exits assigned to this package. Your add-on project also holds the add-on functionality you create to hang onto the exit hooks.

When you first create an add-on project, you must assign the project to a change task. You also need to allocate a change task number for every add-on component you develop, such as include programs, subscreens, and menu texts. You can use the same change task number for all your project components. If your project is spread out over more than one change task, you should assign these tasks to the same transport request.

Once you have completed your project, release your change tasks. As a final step, release the transport request that contains all the change tasks for your project. The system will export your add-on project and coordinate its import into a consolidation or productive system. You must then ensure that your add-on project is active.

Using 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.

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.

To create your own logic for a particular data element, proceed as follows:

1. Enter the Project management transaction by choosing Utilities ® Enhancements ® Project management from the ABAP/4 Development Workbench menu.
2. Choose Text enhancements ® Field exits.
3. Choose Field exit ® Create.
4. Enter the name of data element.
5. Choose Continue.

The system takes you into the Function Library and suggests a name for your function module (FIELD_EXIT_BBBNR). You should use this name.

6. Create the source code and, if needed, global data for your function module.
7. Activate the function module.

After you have created the processing logic for your field exit, you must assign the exit to one or more programs and screens. This assignment tells the system which screens to trigger your function module on.

If your processing logic checks naming conventions for a certain field, for example, you might want to trigger the field exit module only on screens where new data can be written to the database. If another screen allows you to display data only, then you can leave out the special function module call. To assign your field exit module to one or more screens, proceed as follows:

1. Select the field exit.

2. Choose Assign prog./screen.

3. Enter the name of the program and the screen number.
4. Choose Save.

For some fields, you might want to trigger a different processing logic on different screens. You can trigger screen-specific logic by allocating a field exit identifier when you make your screen assignments. A field exit identifier can be any number or letter. The field exit identifier tells the system to trigger the function module that has this identifier in its name.

You create a field exit for the data element BBBNR. You make the following exit and screen assignments:

Field exit Program Screen
1 SAPMI0IA 2300
2 SAPMI0IA 3450

If a user makes an entry into the BBBNR-related field in screen 2300, the system triggers the function module called FIELD_EXIT_BBBNR_1. If the user makes the same entry in screen 3450, the system triggers the function FIELD_EXIT_BBBNR_2.

After you have created one or more function modules and assigned them to programs and screens, you need to activate the field exit. Choose Field exit ® Activate. The system will trigger the processing logic in your function modules according to the screen assignments you made.

CHANGING THE SAP STANDARD

2009-02-12T17:07:00.000+05:30

CHANGING THE SAP STANDARD:

You can adjust the R/3 System to meet your needs in the following ways:
Customizing: This means setting up specific business processes and functions for your system according to an implementation guide. The need for these changes has already been foreseen by SAP and an implementation procedure has been developed.
Personalization: This means making changes to certain fields' global display attributes (Setting default values or fading fields out altogether), as well as creating user-specific menu sequences.

Modifications:

These are changes to SAP Repository objects made at the customer site. If SAP delivers a changed version of the object, the customer's system must be adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

Enhancements:

This means creating Repository objects for individual customers that refer to Objects that already exist in the SAP Repository.

Customer Developments:

This means creating Repository objects unique to individual
Customers in a specific namespace reserved for new customer objects.
Customizing and most personalization are done using tools found in Accelerated SAP; customer developments, enhancements, and modifications are all made using the tools available in the ABAP Workbench.

If your requirements cannot be met by Customizing or personalization, you may either start a development project or try using a CSP solution (= Complementary Software Product).

A development project falls into the customer development category if the SAP standard does not already contain functions similar to the one you are trying to develop. If, however, a similar SAP function exists, try to assimilate it into your development project by either enhancing or modifying it, by using a user exit, or simply by making a copy the appropriate SAP program.

Modifications can create problems, as new versions of SAP objects must be adjusted after an upgrade to coincide with modified versions of SAP objects you have created. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

Thus, you should only make modifications if:
Customizing or personalizing cannot satisfy your requirements
Enhancements or user exits are not planned
It would not make sense to copy the SAP object to the customer namespace.

The Business Engineer is made up of all SAP implementation tools. These include:
The R/3 Reference Model contains all of the models used to describe R/3 (the process model, the data model, the organization model) The Implementation Guide (IMG)

A complete list of all Customizing changes

Personalization accelerates and simplifies how business cases are processed by the R/3 System. During personalization, individual application transactions are adjusted to meet the business needs of your company as a whole or even to the needs of specific user groups within your company. All unnecessary information and functions found in the transaction are switched off.

Global display attributes allow you to define default values for specific screen fields. You can also suppress individual fields or table control columns in a particular transaction, or even a whole screen.

Role-based menus, favorites, and shortcuts allow you to adjust menu sequences to reflect the needs of different user groups within your company.

Modifications are changes to SAP objects in customer systems. They are:
Executed with the help of user exits (these are subroutines reserved for customers that have been inserted in objects in the SAP namespace)
'hard-coded' at various points within SAP Repository objects.

Customer developments are programs developed by customers that can call SAP Repository objects.
Example: A customer creates a program that calls an SAP function module.

The enhancement concepts embody the reverse of this principle: SAP programs call Repository objects that you, as a customer, created or changed. Example: You use a function module exit called by an SAP program. You can enhance your system at the following levels:

in ABAP programs (function module exit)

on GUI interfaces (menu exit)

on screens by inserting a sub screen in an area specified by SAP (screen exit)
on screens by processing customer code that refers to a specific field on the screen (field exit)

in ABAP Dictionary tables or structures (table enhancement)

SAP provides two ways to enhance tables and structures with fields.

Structures

Customizing includes ("CI includes")

Both techniques 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. During activation, the system searches for all active append structures for that table and attach them to the table.

Append structures differ from include structures in how they refer to their tables. In order to include fields from an include structure in a table; you must add an '.INCLUDE...' line to the table. In this case, the table refers to the substructure. Append structures, on the other hand, refer to their tables. In this case, the tables themselves are not altered in any way by the reference.

Append structures allow you to attach fields to a table without actually having to modify the table itself. Table enhancements using append structures therefore do not have to be planned by SAP developers. An append structure can only belong to exactly one table.
In contrast, CI_includes allows you to use the same structure in multiple tables. The include statement must already exist in the SAP table or structure. Table enhancements using CI_includes do, however, have to be planned by SAP developers.

Field exits need not be prepared by the SAP application developer. You can create a field exit for any screen input field that has a Dictionary reference. The reference object is the data element.
The unit "Enhancements to Dictionary Elements" discusses how the field exits work.

The purpose of a program enhancement is always to call an object in the customer namespace. You can use the following techniques here:

A special exit function module is called by the SAP application program. The function module is part of a function group that is handled in a special manner by the system.

Business transaction events

The SAP application program dynamically calls a function module in the customer namespace.

Business add-ins

The application program calls a method of a class or instance of a class. This class lies in the customer namespace.

Program enhancements permit you to execute additional program logic in SAP application programs. SAP currently provides the techniques outlined above.

The advantages and restrictions of the particular enhancement techniques will be discussed in detail in later units.

Menu enhancements permit you to add additional menu entries to an SAP standard menu. The system provides two options here:

Customer exits

Business add-ins

The additional menu entries are merged into the GUI interface.

When the function code is implemented; you can change the text of the menu entry, and – provided the SAP developer specified this option - change the icons.

Screen exits belong to the customer exits. They allow you to display additional objects in an SAP application program screen. The SAP developer must:

Define the sub screen areas

Specify the corresponding calls in the flow logic

Provide the framework for the data transport

Include the screen exit in an enhancement

Maintain the documentation

You can implement screen exits by creating sub screens, possibly with flow logic. You also have to implement the data transport.

How you implement screen exits will be discussed in the "Enhancements using Customer Exits" unit.

Any change that you make your system to an object that has been delivered by SAP is known as a modification.

Modifications can lead to complications at upgrade. When SAP delivers a new version of the object, you must decide whether the new object should be used, or whether you want to continue using your old object.

Prior to Release 4.0B, modifications were only recorded at Repository object level (for example, an include program).

Since Release 4.5A, the granularity for recording modifications has been finer. This has been made possible by the Modification Assistant, as we will see in the "Modifications" unit.

The modification adjustment process has also been overhauled. How modifications are adjusted is also part of the "Modifications” unit.

The SAP System adjusts itself to the user's style of working: When the system is started, the users are only offered functions that are typical in their daily work.

There is no unnecessary navigating through functions that are not used. In the past, user menus could be called in the Session Manager or in the dynamic menu in R/3. With Release 4.6A, the role -based menu is output in the form of a tree for each user.

When you select a function, it is started in the same session. This function replaces the role –based menu. The role -based menu appears again automatically when you leave a transaction or when you start a new session.

In the maintenance screen for activity groups (Transaction PFCG), the administrator can combine the menu structure for an activity group consisting of transactions, reports, and Internet/Intranet links to a user menu. You can choose any structure and description for the functions contained.

The enterprise menu is no longer available with Release 4.6A.

Typical questions at a work center are:

What function should be performed at this work center?
Which menus are needed?
What authorizations do the users need?
Which users are involved here?

The goal of personalization is to answer these questions in the R/3 System.
The tools provided by R/3 for this purpose are area menus and activity groups.

We will now see how these tools can be used to adapt the work center to the user's needs as effectively as possible.

Area menus were also included prior to this release. They can contain:

Transactions

References to other area menus

Executable programs (new)

Lists created by programs (new)

From this release onwards, you can include programs in area menus that create lists directly.

You can assign users an area menu as their start menu. These users no longer see the complete SAP menu when they log onto R/3, but only the menu items that they require. By integrating the report trees, users obtain a complete view of their work environment.

Area menus can also be linked to activity groups.

In contrast to previous releases, area menus are displayed in tree form starting with Release 4.6. This gives the user a clearer overview of the available options.

The objects that can be included in the area menu are listed in the right part of the graphic.

Use Transaction SE43 to create an area menu. You can call this transaction with the given path.

Assign a name in the corresponding customer namespace and create the area menu.

You can include the area menus in your list of favorites in the GUI for faster editing at a later time.

You build area menus by creating entries in the tree structure. Position the cursor and choose the corresponding icon for insertion at the same level or one level down. In the popup window that now appears, choose a description and the corresponding transaction code.

You can also insert reports (objects that create lists, such as ABAP programs, querie s, and so on)

You can no longer store lists in report trees as of Release 4.6A. Report trees have been integrated in the new area menus.

With List--> Save --> Report tree you can store lists for the program. Since the lists are stored program-specifically, you can display them in the corresponding area menus.

During an upgrade, existing area menus are automatically migrated to the new structure. You can make further entries in these new area menus.

With Release 4.6, SAP has implemented user-oriented R/3 operations. When the R/3 application is started, a tree structure appears in the initial screen containing the entries the user needs for his daily work.

These role -based menus go beyond the scope of the area menus. Only the menu structure can be defined for area menus. You can define them as you like for role -based menus. They also use the functions of the Profile Generator.

By using specific role -based menus you can set the following individually:

Menu structure
Profiles
User assignments

The term "activity group" is synonymous in R/3 with "role -based menu." You can edit activity groups using the Profile Generator.

Before you create your own activity groups, you should evaluate the predefined workplace examples that SAP delivers in Release 4.6A. You can use these workplace examples just as they are delivered in the SAP System.

Delivered activity groups should not be changed. You can combine several activity groups to form a composite activity group. Which may also include activity groups delivered by SAP?

To create an activity group; choose the appropriate button on the initial R/3 screen.

Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP

Rest customer namespace

To create an activity group; choose the appropriate button on the initial R/3 screen.

Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP

Rest customer namespace

There are several ways to build the menu for your activity group. You can copy sub-trees and menu entries from

the SAP menu

another activity group

an area menu

You can also maintain single entries. These can be

a transaction code
a report in which a transaction code is automatically generated
a hyperlink (e.g. web address or a path on the local machine)
You cannot maintain single entries if it is a composite activity group.

The system determines the authorization objects used in the given transactions. The assignment of single authorization objects for a transaction using Transaction SU22 provides the basis for this determination.

Transaction SU22 also specifies for the particular authorizations whether or not:

there must be a check
there are default values

Using these default values makes maintaining authorizations much simpler. You only have to maintain authorizations marked with the yellow icon. If you do not do so, full authorization is automatically given.

In the last step, a profile is generated from your entries. The system proposes a name T-, which you can change here, but not later on. Enter a meaningful name.

Next assign the relevant users to the activity group.

Once you have assigned the users, you must adjust the user master profiles accordingly. The profile that was created is automatically assigned to the given users.

A user can be assigned to more than one activity group. Each time you change an activity group, you must also adjust the user masters again.

SAP delivers more than one hundred preconfigured activity groups. Choose the one ost suitable for the particular work center and assign the users. Adjust the user master records.
You can change activity groups delivered by SAP. However, these changes are lost during an upgrade. We therefore recommend that you copy the delivered activity groups and adjust the copy.
In the last section we introduced the user-specific appearance of the interface, which is implemented using activity groups. In addition, there are ways to set single transactions to the needs of your enterprise or of individual user groups. In this section we will see how a transaction can be simplified without being modified.

In this example you see two screens of an SAP transaction that should be redesigned using a transaction variant.

Screen 100 is changed as follows: Fields are hidden; field attributes are changed; buttons are hidden.

Screen 200 shows the following changes: buttons moved and screen inserted (with GuiXT). We will be discussing the use of GuiXT in more detail later.

A transaction variant is a reference to a set of screen variants.
You can create any number of screen variants for a screen. The transaction variant consists of these screen variants.

You can create different kinds of transaction variants for an SAP transaction:

a standard variant

any number of "normal" transaction variants
The standard variant is executed at runtime instead of the SAP delivered transaction. No new transaction code is required.

A normal transaction variant will be called with its own transaction code of type "variant
transaction".

To create transaction variants, choose the component Personalization from the entry Accelerated SAP in the SAP menu and then Transaction variant. You go to the transaction for maintaining transaction variants.

Enter the name of the transaction from which you want to create a variant. The name of the variant must be unique in the system and be in the customer namespace.

With the menu option Goto, choose whether you want to create a client-specific or a cross-client transaction variant.

To create the variant; choose the appropriate button in the application toolbar.

Pressing "Screen entries" starts the transaction in CALL mode.

Triggering a dialog also triggers PAI of the current screen. The system sends another screen in which you can evaluate the fields of the screen.

Also read the online documentation about transaction variants.

The screen that was evaluated is stored as a screen variant when you continue. This will be discussed next.

A screen variant is an independent Repository object, which has a unique name in the system. The name is constructed as follows:

Variant name

Client (only for client-specific transaction variants)

Screen number

Here you specify whether or not field contents should be copied to the screen variant. You can set various attributes for the individual fields: You can undo or hide the input status of a field. You can find a detailed list of options in the online documentation about transaction variants.

The GuiXT tool permits you to design the individual screens in a more flexible manner. GuiXT uses a script language to

Position objects on the screen,

Set attributes,

Include new objects.

If you press "GuiXT", an editor window appears where you can enter the script. You can also choose GuiXT files stored on your local machine.

You can also import scripts created on the local machine and export them there.

You can change the layout of a screen with the script language used by GuiXT. You can

Move objects

Insert screens

Insert pushbuttons

Insert value helps

Change the input attributes of fields

Delete screen elements

You are provided with a complete documentation of GuiXT with the installation. You You have the following options for starting a transaction variant:

Test environment
Transaction code of type "variant transaction"
User menu

You can test the transaction flow in the test environment of the transaction variant maintenance routine. This is intended primarily for developers creating transaction variants.

To insert a variant transaction in a user menu or activity group, you must create a transaction code of type "variant transaction".

To start a transaction variant from a menu, you must create a transaction code of type "variant transaction". You can navigate there directly from the maintenance screen for the transaction variants. Alternatively you can start the corresponding transaction from the ABAP Workbench.

You can insert the transaction in a menu by choosing one of the following two options: maintenance of

Activity group or

Area menu.

The user can immediately see the changes made in this way.

MODIFICATIONS OF SAP STANDARD OBJECTS

2009-02-12T17:06:00.000+05:30

MODIFICATIONS:

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.

Above is a list of the tools supported by the Modification Assistant.

In 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 pushbuttons. 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 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 programt. 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.

You can find a list of all user exits in the SAP Reference Implementation Guide.

There, you will also find documentation explaining why SAP developers have created a particular user exit.

Follow the steps described in the Implementation Guide.

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.

EPILOG:

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, pushbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases)

Without 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 (from Release 4.5A).

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 Re pository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions. OSS note 16466 gives you an overview of the current naming conventions for customer Repository objects (usually names that begin with either Y or Z).

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.

LESSON 51CHANGING THE SAP STANDARD

2009-02-12T17:04:00.002+05:30

You can adjust the R/3 System to meet your needs in the following ways:
Customizing: This means setting up specific business processes and functions for your system according to an implementation guide. The need for these changes has already been foreseen by SAP and an implementation procedure has been developed.
Personalization: This means making changes to certain fields' global display

attributes

(Setting default values or fading fields out altogether), as well as creating
user-specific menu sequences.

Modifications: These are changes to SAP Repository objects made at the customer site. If SAP delivers a changed version of the object, the customer's system must be adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

Enhancements: This means creating Repository objects for individual customers that refer to Objects that already exist in the SAP Repository.

Customer Developments: This means creating Repository objects unique to individual
Customers in a specific namespace reserved for new customer objects.

Customizing and most personalization are done using tools found in Accelerated SAP; customer developments, enhancements, and modifications are all made using the tools available in the ABAP Workbench.

If your requirements cannot be met by Customizing or personalization, you may either start a development project or try using a CSP solution (= Complementary Software Product).

A development project falls into the customer development category if the SAP standard does not already contain functions similar to the one you are trying to develop. If, however, a similar SAP function exists, try to assimilate it into your development project by either enhancing or modifying it, by using a user exit, or simply by making a copy the appropriate SAP program.

Modifications can create problems, as new versions of SAP objects must be adjusted after an upgrade to coincide with modified versions of SAP objects you have created. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

Thus, you should only make modifications if:
Customizing or personalizing cannot satisfy your requirements
Enhancements or user exits are not planned
It would not make sense to copy the SAP object to the customer namespace.

The Business Engineer is made up of all SAP implementation tools. These include:
The R/3 Reference Model contains all of the models used to describe R/3 (the process model, the data model, the organization model) The Implementation Guide (IMG)
A complete list of all Customizing changes
Personalization accelerates and simplifies how business cases are processed by the R/3 System. During personalization, individual application transactions are adjusted to meet the business needs of your company as a whole or even to the needs of specific user groups within your company. All unnecessary information and functions found in the transaction are switched off.

Global display attributes allow you to define default values for specific screen fields. You can also suppress individual fields or table control columns in a particular transaction, or even a whole screen.

Role-based menus, favorites, and shortcuts allow you to adjust menu sequences to reflect the needs of different user groups within your company.

Modifications are changes to SAP objects in customer systems. They are:
Executed with the help of user exits (these are subroutines reserved for customers that have been inserted in objects in the SAP namespace)
'hard-coded' at various points within SAP Repository objects.

Customer developments are programs developed by customers that can call SAP Repository objects.

Example: A customer creates a program that calls an SAP function module.

The enhancement concepts embody the reverse of this principle: SAP programs call Repository objects that you, as a customer, created or changed. Example: You use a function module exit called by an SAP program. You can enhance your system at the following levels:

in ABAP programs (function module exit)
on GUI interfaces (menu exit)

on screens by inserting a sub screen in an area specified by SAP (screen exit)

on screens by processing customer code that refers to a specific field on the screen (field exit)

in ABAP Dictionary tables or structures (table enhancement)

SAP provides two ways to enhance tables and structures with fields.

Structures

Customizing includes ("CI includes")

Both techniques 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. During activation, the system searches for all active append structures for that table and attach them to the table.

Append structures differ from include structures in how they refer to their tables. In order to include fields from an include structure in a table; you must add an '.INCLUDE...' line to the table. In this case, the table refers to the substructure. Append structures, on the other hand, refer to their tables. In this case, the tables themselves are not altered in any way by the reference.

Append structures allow you to attach fields to a table without actually having to modify the table itself. Table enhancements using append structures therefore do not have to be planned by SAP developers. An append structure can only belong to exactly one table.

In contrast, CI_includes allows you to use the same structure in multiple tables. The include statement must already exist in the SAP table or structure. Table enhancements using CI_includes do, however, have to be planned by SAP developers.

Field exits need not be prepared by the SAP application developer. You can create a field exit for any screen input field that has a Dictionary reference. The reference object is the data element.

The unit "Enhancements to Dictionary Elements" discusses how the field exits work.

The purpose of a program enhancement is always to call an object in the customer namespace. You can use the following techniques here:

A special exit function module is called by the SAP application program. The function module is part of a function group that is handled in a special manner by the system.

Business transaction events

The SAP application program dynamically calls a function module in the customer namespace.

Business add-ins
The application program calls a method of a class or instance of a class. This class lies in the customer namespace.

Program enhancements permit you to execute additional program logic in SAP application programs. SAP currently provides the techniques outlined above.

The advantages and restrictions of the particular enhancement techniques will be discussed in detail in later units.

Menu enhancements permit you to add additional menu entries to an SAP standard menu. The system provides two options here:

Customer exits

Business add-ins

The additional menu entries are merged into the GUI interface.

When the function code is implemented; you can change the text of the menu entry, and provided the SAP developer specified this option - change the icons.

Screen exits belong to the customer exits. They allow you to display additional objects in an SAP application program screen. The SAP developer must:

Define the sub screen areas

Specify the corresponding calls in the flow logic

Provide the framework for the data transport

Include the screen exit in an enhancement

Maintain the documentation

You can implement screen exits by creating sub screens, possibly with flow logic. You also have to implement the data transport.

How you implement screen exits will be discussed in the "Enhancements using Customer Exits" unit.

Any change that you make your system to an object that has been delivered by SAP is known as a modification.

Modifications can lead to complications at upgrade. When SAP delivers a new version of the object, you must decide whether the new object should be used, or whether you want to continue using your old object.

Prior to Release 4.0B, modifications were only recorded at Repository object level (for example, an include program).

Since Release 4.5A, the granularity for recording modifications has been finer. This has been made possible by the Modification Assistant, as we will see in the "Modifications" unit.

The modification adjustment process has also been overhauled. How modifications are adjusted is also part of the "Modifications” unit.

The SAP System adjusts itself to the user's style of working: When the system is started, the users are only offered functions that are typical in their daily work. There is no unnecessary navigating through functions that are not used. In the past, user menus could be called in the Session Manager or in the dynamic menu in R/3. With Release 4.6A, the role -based menu is output in the form of a tree for each user.

When you select a function, it is started in the same session. This function replaces the role –based menu. The role -based menu appears again automatically when you leave a transaction or when you start a new session.

In the maintenance screen for activity groups (Transaction PFCG), the administrator can combine the menu structure for an activity group consisting of transactions, reports, and Internet/Intranet links to a user menu. You can choose any structure and description for the functions contained.

The enterprise menu is no longer available with Release 4.6A.

Typical questions at a work center are:

What function should be performed at this work center?
Which menus are needed?
What authorizations do the users need?
Which users are involved here?

The goal of personalization is to answer these questions in the R/3 System.

The tools provided by R/3 for this purpose are area menus and activity groups.

We will now see how these tools can be used to adapt the work center to the user's needs as effectively as possible.

Area menus were also included prior to this release. They can contain:
Transactions
References to other area menus
Executable programs (new)
Lists created by programs (new)

From this release onwards, you can include programs in area menus that create lists directly.

You can assign users an area menu as their start menu. These users no longer see the complete SAP menu when they log onto R/3, but only the menu items that they require. By integrating the report trees, users obtain a complete view of their work environment.

Area menus can also be linked to activity groups.

In contrast to previous releases, area menus are displayed in tree form starting with Release 4.6. This gives the user a clearer overview of the available options.

The objects that can be included in the area menu are listed in the right part of the graphic.

Use Transaction SE43 to create an area menu. You can call this transaction with the given path.

Assign a name in the corresponding customer namespace and create the area menu.

You can include the area menus in your list of favorites in the GUI for faster editing at a later time.

You build area menus by creating entries in the tree structure. Position the cursor and choose the corresponding icon for insertion at the same level or one level down. In the popup window that now appears, choose a description and the corresponding transaction code.

You can also insert reports (objects that create lists, such as ABAP programs, querie s, and so on)

You can no longer store lists in report trees as of Release 4.6A. Report trees have been integrated in the new area menus.

With List--> Save --> Report tree you can store lists for the program. Since the lists are stored program-specifically, you can display them in the corresponding area menus.

During an upgrade, existing area menus are automatically migrated to the new structure. You can make further entries in these new area menus.

With Release 4.6, SAP has implemented user-oriented R/3 operations. When the R/3 application is started, a tree structure appears in the initial screen containing the entries the user needs for his daily work.

These role -based menus go beyond the scope of the area menus. Only the menu structure can be defined for area menus. You can define them as you like for role -based menus. They also use the functions of the Profile Generator.

By using specific role -based menus you can set the following individually:

Menu structure
Profiles
User assignments

The term "activity group" is synonymous in R/3 with "role -based menu." You can edit activity groups using the Profile Generator.

Before you create your own activity groups, you should evaluate the predefined workplace examples that SAP delivers in Release 4.6A. You can use these workplace examples just as they are delivered in the SAP System.

Delivered activity groups should not be changed. You can combine several activity groups to form a composite activity group. Which may also include activity groups delivered by SAP?

To create an activity group; choose the appropriate button on the initial R/3 screen.
Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP
Rest customer namespace

To create an activity group; choose the appropriate button on the initial R/3 screen.

Assign a name for the activity group in the customer namespace and press Create. The system displays the maintenance screen for activity groups.

The activity group naming conventions are defined as follows:

SAP* delivered by SAP
Rest customer namespace

There are several ways to build the menu for your activity group. You can copy sub-trees and menu entries from
the SAP menu
another activity group
an area menu
You can also maintain single entries. These can be

a transaction code
a report in which a transaction code is automatically generated
a hyperlink (e.g. web address or a path on the local machine)
You cannot maintain single entries if it is a composite activity group.

The system determines the authorization objects used in the given transactions. The assignment of single authorization objects for a transaction using Transaction SU22 provides the basis for this determination.

Transaction SU22 also specifies for the particular authorizations whether or not:
there must be a check
there are default values
Using these default values makes maintaining authorizations much simpler. You only have to maintain authorizations marked with the yellow icon. If you do not do so, full authorization is automatically given.

In the last step, a profile is generated from your entries. The system proposes a name T-, which you can change here, but not later on. Enter a meaningful name.
Next assign the relevant users to the activity group.

Once you have assigned the users, you must adjust the user master profiles accordingly. The profile that was created is automatically assigned to the given users.

A user can be assigned to more than one activity group. Each time you change an activity group, you must also adjust the user masters again.

SAP delivers more than one hundred preconfigured activity groups. Choose the one most suitable for the particular work center and assign the users. Adjust the user master records.

You can change activity groups delivered by SAP. However, these changes are lost during an upgrade. We therefore recommend that you copy the delivered activity groups and adjust the copy.

In the last section we introduced the user-specific appearance of the interface, which is implemented using activity groups. In addition, there are ways to set single transactions to the needs of your enterprise or of individual user groups. In this section we will see how a transaction can be simplified without being modified.
In this example you see two screens of an SAP transaction that should be redesigned using a transaction variant.

Screen 100 is changed as follows: Fields are hidden; field attributes are changed; buttons are hidden.
Screen 200 shows the following changes: buttons moved and screen inserted (with GuiXT). We will be discussing the use of GuiXT in more detail later.
A transaction variant is a reference to a set of screen variants.
You can create any number of screen variants for a screen. The transaction variant consists of these screen variants.

You can create different kinds of transaction variants for an SAP transaction:
a standard variant
any number of "normal" transaction variants

The standard variant is executed at runtime instead of the SAP delivered transaction. No new transaction code is required.

A normal transaction variant will be called with its own transaction code of type "variant transaction".

To create transaction variants, choose the component Personalization from the entry Accelerated SAP in the SAP menu and then Transaction variant. You go to the transaction for maintaining transaction variants.

Enter the name of the transaction from which you want to create a variant. The name of the variant must be unique in the system and be in the customer namespace.

With the menu option Goto, choose whether you want to create a client-specific or a cross-client transaction variant.

To create the variant; choose the appropriate button in the application toolbar.

Pressing "Screen entries" starts the transaction in CALL mode.
Triggering a dialog also triggers PAI of the current screen. The system sends another screen in which you can evaluate the fields of the screen.
Also read the online documentation about transaction variants.
The screen that was evaluated is stored as a screen variant when you continue. This will be discussed next.

A screen variant is an independent Repository object, which has a unique name in the system. The name is constructed as follows:

Variant name
Client (only for client-specific transaction variants)
Screen number

Here you specify whether or not field contents should be copied to the screen variant. You can set various attributes for the individual fields: You can undo or hide the input status of a field. You can find a detailed list of options in the online documentation about transaction variants.

The GuiXT tool permits you to design the individual screens in a more flexible manner. GuiXT uses a script language to
Position objects on the screen,
Set attributes,
Include new objects.

If you press "GuiXT", an editor window appears where you can enter the script. You can also choose GuiXT files stored on your local machine.

You can also import scripts created on the local machine and export them there.
You can change the layout of a screen with the script language used by GuiXT. You can

Move objects
Insert screens
Insert pushbuttons
Insert value helps
Change the input attributes of fields
Delete screen elements

You are provided with a complete documentation of GuiXT with the installation.

You have the following options for starting a transaction variant:

Test environment
Transaction code of type "variant transaction"
User menu

You can test the transaction flow in the test environment of the transaction variant maintenance routine. This is intended primarily for developers creating transaction variants.

To insert a variant transaction in a user menu or activity group, you must create a transaction code of type "variant transaction".

To start a transaction variant from a menu, you must create a transaction code of type "variant transaction". You can navigate there directly from the maintenance screen for the transaction variants. Alternatively you can start the corresponding transaction from the ABAP Workbench.

You can insert the transaction in a menu by choosing one of the following two options: maintenance of

Activity group or
Area menu.

The user can immediately see the changes made in this way.

LESSON 52 ENHANCEMENTS TO DICTIONERY ELEMENTS

2009-02-12T17:04:00.001+05:30

ENHANCEMENTS TO DICTIONERY ELEMENTS

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.

Note: 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.

LESSON 54 ENHANCEMENTS USING COSTMER EXITS

2009-02-12T17:03:00.000+05:30

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 _{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.}

LESSON 56 SAP MODIDICAITONS

2009-02-12T17:02:00.002+05:30

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.
Above is a list of the tools supported by the Modification Assistant.

n 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 pushbuttons. 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 programt. 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.

You can find a list of all user exits in the SAP Reference Implementation Guide.
There, you will also find documentation explaining why SAP developers have created a particular user exit.
Follow the steps described in the Implementation Guide.

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.

hanges 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.

LESSON 57 MODIFICAITONS EXITEDED

2009-02-12T17:02:00.001+05:30

MODIFICAITONS EXITEDED:

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, pushbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases)

Without 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 (from Release 4.5A).
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 Re pository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions. OSS note 16466 gives you an overview of the current naming conventions for customer Repository objects (usually names that begin with either Y or Z).

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.

USER EXITS IN DETAIL

2009-02-12T17:01:00.000+05:30

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.

Overview

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.

In Details

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 subscreen 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 userexit routine.

Steps:-

• Goto transaction VL01 to pick a Sales Order for delivery (you don't have to save the data)
• In the initial screen, click System -> Status -> Double click on Program (Screen)
• In the dialog program SAPMV50A, click Edit -> Search/replace
• Type userexit in the Find field, then click the In program radio button and hit Enter
• A number of userexit routines will be displayed. You'll have to roughly decide which is the correct userexit 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.
* Check delivery quantity not zero
if xlips-pikmg < pgmid =" 'R3TR'" object =" 'PROG'" obj_name =" tstc-pgmna." name =" tstc-pgmna." pname =" tstc-pgmna." funcname =" tfdir-funcname." pgmid =" 'R3TR'" object =" 'FUGR'" pgmid =" 'R3TR'" object =" 'SMOD'" devclass =" v_devclass." sprsl =" sy-langu" name =" jtab-obj_name." zzzz =" up">Bus.transactions->Base parameters->Validation
/NORFB->Bus.transactions->Base parameters->Substitution
Example
=ULTE "FI_DOCU 001 "Parked SA,FY,SI=>long text CORRESP. "

=U&VALID_WBS_IN_ZUONR "FI_ITEM 011 Spon.Res: Check WBS valid in ZUONR"

* changed in 4.5B (* Form UFIA -- formerly U&VALID_WBS_IN_ZUONR)
User exits are form routines that the user programs. There are two types of

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.
Note
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.
SAP exits
SAP exits are form rountines programmed by SAP. The name of the form pool is SAPFGBEB.
Syntax:
=Szzzz (zzzz = up to four characters)
FORM Szzzz using B_result. "'T' or 'F'
Example
=S01 "SAP exit S01"
Display description of T80D configuration
Return ->
Change Validation: FI_ITEM (Message view)

SAP USER EXITS

2009-02-12T16:59:00.000+05:30

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.

LESSON 35 BASICS OF INTERACTIVE REPORTS

2009-02-12T16:58:00.000+05:30

BASICS OF INTERACTIVE REPORTS:

When the user starts an executable (type 1) program, the program context and memory space for data objects (variables and structures) are made available on the application server. The subsequent program flow is controlled by the ABAP runtime system.

If the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the start of the program.

Once the user has finished entering data on the selection screen, he or she chooses 'Execute' to tell the system to start processing the rest of the program. The data entered on the selection screen is automatically placed in the corresponding data objects. The ABAP runtime system takes over control of the program.

In this simple example, there is only one ABAP processing block to be processed by the runtime system.

This processing block contains a read access to the database. The program sends information to the database about the records that should be read.

The database returns the required database records and the runtime system ensures that the data is placed in the relevant data objects.

The list output is also programmed in the processing block. After the processing block finishes, the runtime system sends the list as a screen to the presentation server.

Selection screens allow users to enter ranges of values. They are normally used to define the set of data that needs to be read from the database.

As well as the normal graphical elements (group boxes, checkboxes, radio buttons, and so on) that you use in screens, selection screens also have input/output fields (PARAMETERS) and special groups of input/output fields (SELECT-OPTIONS).

You place a single input/output field on the selection screen using the PARAMETERS statement.

You can use the SELECT-OPTIONS statement to place a group of fields on the screen that allows users to enter complex selections. The selection may be a single value, or any form of interval (discrete or continuous). You can also use patterns. (See following slides).

You can create variants for selection screens.

If you declare an input field with reference to an ABAP Dictionary field, any search helps defined for the Dictionary field will be available on the selection screen.

Selection texts can be translated into other languages. They are then displayed in the user's logon language.

Selection ranges are stored in programs using an internal table.

The ABAP statement SELECT-OPTIONS FOR declares an internal table called , containing four fields - SIGN, OPTION, LOW, and HIGH. The fields LOW and HIGH have the same type as the field .

The SIGN field can take the value 'I' (for inclusive) or 'E' (for exclusive).

The OPTION field can contain relational operators, pattern operators, and operators that allow you to enter intervals.

For more information about selection ranges, choose Goto -> Selection screen help from any selection screen.

To define a selection screen, include the required PARAMETERS and SELECT-OPTIONS statements in your data declarations. If you define more selection screens than just the standard selection screen, you must enclose the additional definitions in the statements SELECTIONSCREEN BEGIN OF SCREEN and SELECTION-SCREEN END OF SCREEN where is the number of the selection screen.

For information about other graphical elements that you can place on a sele ction screen, such as group boxes, checkboxes, radio buttons, references to input fields on other selection screens and so on, see the keyword documentation for the SELECTION-SCREEN statement

The standard selection screen is displayed by the ABAP runtime system when the program starts.

User-defined selection screens are displayed when you use the statement CALL SELECTIONSCREEN . This statement sets the return code sy-subrc to zero if the user chooses 'Execute', and to 4 if the user chooses 'Cancel'.

You can also call a selection screen as a modal dialog box. To do this, use the syntax CALL SELECTION-SCREEN STARTING AT ENDING AT where and are the coordinates of the top left-hand corner of the screen. and are the coordinates of the bottom right-hand corner.

Selection screen processing is event-driven. Events are ABAP processing blocks that are called by the runtime system in a particular order and processed sequentially. In the program, each event is introduced by an event keyword. The processing block ends when the next event block starts, or the definition of a subroutine or dialog module occurs.

AT SELECTION-SCREEN OUTPUT is processed before the selection screen is displayed. You can use this event to modify the selection screen dynamically.

AT SELECTION-SCREEN ON HELP-REQUEST FOR and
AT SELECTION-SCREEN ON VALUE-REQUEST FOR allow you to define your own F1 and F4 help.

AT SELECTION-SCREEN is processed when the user presses ENTER or chooses another function on the selection screen. You can use this event to check the values the user entered on the screen. The addition ON... allows you to control which fields or groups of fields should accept input again in the event of an error.

An ABAP program consists of a sequence of processing blocks (events) that are processed by the runtime system in a particular order.

LOAD-OF-PROGRAM is triggered directly after the system has loaded a program with type 1, M, F, or S into an internal session. The processing block is executed once only for each program in each internal session.

INITIALIZATION is processed in executable (type 1) programs, directly before the selection screen is displayed. You can use the corresponding processing block to preassign values to the parameters and selection options on the selection screen.

START-OF-SELECTION is processed after the selection screen has been processed. If you are working with a logical database, the corresponding GET events are triggered after START-OFSELECTION.

END-OF-SELECTION is processed after all of the data has been read, and before the list is displayed.

TOP-OF-PAGE is an event in list-processing. The processing block is always executed when you start a new page in the list.

Once the basic list has been displayed, you can react to possible user actions. Detail lists allow you to distribute the information you want to display across several lists.

This makes the lists easier for the user to understand, and improves performance, since you can delay reading extra information from the database until the user actually requests it.

You can also use additional selection screens to allow the user to enter further restrictions.

For each basic list you can use up to 20 detail lists. Each list is stored in its own list buffer. When the user chooses 'Back' (green arrow) or 'Cancel' (red cross), he or she returns to the previous list.
This action initializes the list buffer of the list level the user just le ft.

When the user chooses 'Exit' (yellow arrow), the system terminates the list processing and returns to the standard selection screen.

The events START-OF-SELECTION, GET, END-OF-SELECTION, TOP-OF-PAGE and END-OFPAGE can be used only to create basic lists.

To create detail lists, use the events AT LINE-SELECTION or AT USER-COMMAND.

Use TOP-OF-PAGE DURING LINE-SELECTION for page headers on detail lists.

Each detail list event exists only once in the program and is shared by all detail lists. You must therefore ensure yourself, within the processing block, that the correct list is created. To do this, use a CASE structure that uses the system field sy-lsind. This system field contains the list index of the list that you are currently generating.

Use the statement HIDE global_field to store the contents of the global data field
global_field for the current line.

If the user selects the line, the data field is automatically filled with the value that you retained for the line.

You do not have to display the field on the list in order to retain its value using HIDE.

The field can be a structure. However, deep structures (structures containing internal tables as components) are not supported.

When the user selects a line on an interactive list, all of the global data fields whose values you stored using the HIDE statement while you were creating the basic list are filled with those values.

The line selection is based on the cursor position when the AT LINE-SELECTION and AT USERCOMMAND events occur. (system field sy-lilli).

If you choose a line using the READ LINE... statement, the values are placed back in the original fields according to the line numbers.

To check whether the user selected a valid line, you can use the fact that the hide area only contains data for valid lines. When you have finished creating the list, initialize a suitable test field. This allows you to check before you create the detail list whether a value from the hide area has been placed in the test field.

Once you have created the detail list, re-initialize the test field to ensure that the user cannot choose an invalid line once he or she returns from the detail list and attempts to select another line for a new detail list.

LESSON 37 Interactive List Techniques

2009-02-12T16:57:00.000+05:30

INTERACTIVE LIST TECHNIQUES:

When a user chooses a function from a list, it triggers that function's function code. This function code, in turn, triggers a corresponding event.

Some function codes are reserved for use by the system and therefore do not trigger an interactive event when the user chooses them (that is, the system does not return to the program). Instead these codes trigger a corresponding system function.

All function codes with the exception of "PICK" as well as all codes reserved for system use trigger the event AT USER-COMMAND. For more information, refer to the Program Interface unit.

The statement MODIFY LINE modifies the first line of the list. The values stored in the hide area for this line are placed in the corresponding fields, and are thus available in the program.

The statement MODIFY CURRENT LINE changes the last line to have been chosen by line selection or the READ LINE statement (even if it was in a different list level).

If you use the LINE FORMAT addition, the selected line is formatted according to the
specifications , , ...

The addition FIELD VALUE replaces the field contents of , , ... in the list line with the current values of , , ... (all values are converted to type C).
The contents of , , ... themselves are not replaced.

If a field from the line being modified is displayed more than once, that line will only be modified the first time it is displayed.

The LINE VALUE FROM addition allows you to replace the entire line being modified with the current contents of field .

The FIELD statement, allows you to find out the name of the field in which the cursor is positioned. The name of the variable from which the value comes is placed in the field . However, for the sort criterion, you only use the name of the field as it appears in the table definition. You therefore need to use an offset specification to find out the field name. The offset is the length of the structure name plus one character for the hyphen.

The name of the output field is provided in the field specified in the FIELD parameter. The output value is contained in the field specified in the VALUE parameter.

The operation sets the return code sy-subrc.

sy- subrc = 0: The cursor was positioned on a field.
sy- subrc = 4: The cursor was not positioned on a field.

Caution: Do not use the value from the VALUE parameter as a selection criterion in a SELECT statement. If it is not a character field, the system will convert its type, which could lead to undesired results. It is better to use the hide technique instead.

Before you find out the sort field, check that the user placed the cursor on a valid line. If this is not the case, you should display an appropriate message.

Decreasing the list level (changing the value of sy-lsind) should always be the last action before you display the list buffer. This system field determines the list level at which the new list is displayed. The hide area and list buffer of any higher list levels are automatically initialized.

You can use system field sy-lsind to determine the list level at which the list is displayed. In the example above, list level 2 where the list is sorted according to the number of unoccupied seats is being displayed. The statement sy-lsind = 1 causes the list to be displayed at list level 1, thus replacing the list sorted according to date, which would normally be displayed first.

You cannot assign a value to sy-lsind that is greater than the current value of the field assigned by the system. This means you cannot bypass list levels in ascending direction.

You should only change sy-lsind in the last statement before the list is displayed, since changing the value does not always lead to an immediate change of list level. The new list level is assigned to the list at the very end, after the entire list buffer has been displayed. If you are not acquainted with this behavior, you could program your lists incorrectly.

Message types have the following effects on list processing:

Type E messages discard the current detail lists and return to the list level previously displayed.

Type W messages are always displayed as error messages (type E).

While the basic list is being created, type W and type E messages always lead to program termination (corresponds to type A).

ABAP Project Overview XI

2009-02-10T08:50:00.001+05:30

MANAGING ABAP PROJECT OBJECT-ABAP PROJECT OVERVIEW:

TeamSAP is the coordinated network of people, processes & products from SAP & partners that delivers fast, integrated and assured solutions over time.

There are three key components: People, Processes, and Products.

The people component represents SAP and its partners. Any R/3 implementation team is usually composed of multiple organizations which bring different skills to the table.

Our objective with TeamSAP is to ensure that the right vendor skills are coordinated, at the right time, with appropriate quantities and management.

The product, SAP’s Business Framework, is a vital piece of TeamSAP because it’s the platform on which SAP and non-SAP applications work together. It also provides the flexibility to change over time and includes R/3 business components, integration technologies, and open interfaces that allow R/3 and complementary partner software to operate together.

Third party software and hardware products are certified by SAP within this infrastructure. Certification programs for TeamSAP partners that are part of the Business Framework include Joint Development Partners, Certified Interface Partners, and Technology Partners.

The processes represent SAP an its partners working together to synthesize the knowledge gained in over 11,000 completed R/3 installations. Three key areas that reflect this experience: the ASAP Roadmap and accelerators, Business Engineer, and Services, Support and Training.

AcceleratedSAP (ASAP) is SAP’s total process-oriented solution for accelerated implementation and continuous optimization of R/3. ASAP was developed and enhanced with the knowledge of a team of international consultants. It consists of the ASAP Roadmap, tools, service & support and training.

The ASAP Roadmap is an implementation plan that includes detailed descriptions of why, when, how, and by whom certain jobs should be completed. The ASAP Implementation Assistant is the ASAP Roadmap browser. The ASAP Roadmap contains technical information and numerous accelerators (questionnaires, project forms, and check lists), with which you can start your implementation project.

The Business Engineer makes up the backbone of ASAP within the R/3 system.
Additional ASAP tools include the Project Estimator, with which project costs and time can be analyzed in cooperation with your consultant, and the Q&A database for creating a business blueprint.

ABAP Workbench Tools are implemented in the following project phases:

Phase 1: Project Preparation

no ABAP Workbench tools

Phase 2: Business Blueprint

process design template, technical design template, Data Modeler, Screen Painter (Early Prototype Screens), Menu Painter

Phase 3: Realization

all ABAP Workbench tools

Phase 4: Final Preparation

Test Workbench, tuning tools, LSM Workbench (Legacy System Migration)

Phase 5: Go Live and Support

tuning tools (in particular workload analysis)

Large reengineering projects are initiated at either phase 1 or phase 2.
Depending on the scope and complexity of your project the roles described below could fall to one and the same person.

The steering committee consists of those people from the board of directors initiating and sponsoring the project and the committee has ultimate authority over which direction the project takes.

Project management is responsible for the R/3 implementation project as a whole. Project management plans the proje ct (budgets, deadlines, personnel, functions), resolves conflicts and delivers status reports to the steering committee.

Project coordination is responsible for standardization and marketing the project within the company.

In addition, the responsibility for project logistics belongs to the project coordinators.

Development creates process and technical designs for the project in cooperation with the other areas and is responsible for actual implementation.

Planning, carrying out and reviewing testing all falls into the area of quality assurance.

Technical support is responsible for clearing away all technical obstacles to implementation (server downtime, transport problems, database problems, etc.).

Process managers come from the department affected and are responsible for logistics within a subproject. They support development by creating process designs, drawing up integration plans together with quality assurance, and are responsible for CATT (Computer Aided Test Tool) test case input.

Marketing representatives coordinate all internal (company) activities in the areas of project marketing, training, and consulting. They are responsible for rollout of the subproject and report to project management (status reports).

Standards coordinators deal with more than one subproject and are responsible for establishing standards for project documentation and communication company wide. They are also responsible for customizing and development activities documentation (templates for process and technical design, naming conventions, programming guides, graphical user interface style guides).

Development managers coordinate development activities within a subproject. His or her responsibilities include creating development standards for the subproject as a whole, determining the feasibility of process and technical designs, and writing status reports.

Concept developers analyze both process designs and technical designs using the templates created by standards coordinators.

Data modelers support the creation of data models within the project’s technical design using SERM (Structured Entity Relationship Method) and the Data Modeler. Dictionary developers reproduce these data models in the ABAP Dictionary (tables, data elements, domains, foreign key dependencies, search help, etc.).

ABAP developers implement the process model described in the technical design using the tools provided by the ABAP Workbench. They also create the user interfaces and print lists foreseen in both the process and technical designs.
Interface developers implement necessary online and offline interfaces (outside of ABAP if necessary).

SAPscript developers use SAPscript to create the forms foreseen in both the process
and technical designs.

Information developers write the documentation for what the other developers have created.

Quality coordinators coordinate all quality assurance activities. This includes writing reviews of quality assurance activities and generating status reports for project management.

Test coordinators create test catalogs for subprojects documenting the individual test case. They coordinate test case input and work together with process managers during test case creation and user test organization.

The actual testers come from the user departments where these new functions are going to be used. They complete function tests by manually going through test cases and CATT procedures.

Quality assurance consultants deliver technical support for all of these quality assurance activities. Their responsibilities include writ ing reviews and measuring performance using Workload Analysis, SQL Trace, ABAP Trace and other tools.

Transport coordinators are responsible for setting up and maintaining correction and transport mechanisms. They determine in conjunction with the subproject management when and how transports should take place and are responsible for conducting them. Transport coordinators solve transport problems using CTS (Change and Transport System).

System administrators guarantee the availability of the system landscape for development and quality assurance. This includes administering operating systems, database systems, networks and R/3 systems. In addition, system administrators are responsible for regularly backing up data and for creating a recovery strategy.
Authorization administrators provide individual employees with authorizations for various R/3 systems depending on the roll they play (for database management systems and operating systems too, if necessary).

An R/3 system landscape is made up of all of a customer‘s R/3 systems taken as a whole. Each individual role (development, testing, test systems, quality assurance, training, production) must be mapped onto a client within the R/3 system.
Repository objects are client independent. Thus all changes to Repository objects are immediately visible in all clients. For example: if M1 and M2 are clients in an R/3 system and a program is saved in M1, any changes made to the program will immediately influence M2’s runtime environment.

SAP recommends defining Customizing and application table structures as client specific (see Realization unit).

SAP recommends conducting development, quality assurance, and production in three different clients in three different R/3 systems . For greater needs (for example, system landscapes where central development is conducted in one country and additional development in other countries) complex system landscapes with more than three systems can be planned.

Many customers with fewer needs work with a two system landscape with one central maintenance site for development and Customizing. Other clients for sand-box, training or master data may be deployed over the systems.

System landscapes can be constructed using the tools client copy, transport client and copy database. After landscape construction, the maintenance phase begins. From here on out changes to Customizing settings and Repository objects can only be copied or transported using requests .For the setup of the system landscape, Customizing is copied and transported using client copy (within R/3) and client transport (cross-system).

Repository Objects are not transported by client copy or client transport but instead are transported by releasing and importing Workbench requests.

Once in production, the system landscape is in the state of maintenance
All changes to Customizing or Repository Objects are recorded in change requests and are transported using the transport system and the function copy request
The Change & Transport Organizer consists of the tools Workbench Organizer and Customizing Organizer.

In the Workbench Organizer you can only see Workbench requests. In the Customizing Organizer, Customizing and Workbench requests are visible.

Changes to customizing and Repository objects are recorded in change requests. There are two types of change requests :

Client dependent customizing is recorded in Customizing requests.
Client independent customizing and Repository Objects are recorded in Workbench requests.

Repository objects are:

Assigned to development classes.

Have versions Locked for access of non-team members as long as the Workbench request is not rele ased. This system landscape combines central international development with national development in subsidiaries.

The Workbench Organizer allows the user to develop software in an organized manner.
The transport system provides for transport execution and registration.
Repository objects are connected to the transport system by their development class and change request assignments. After a request has been released in a development system, it is then transported along pre-determined routes into a quality assurance system or a production system.

You can tailor the R/3 system to your needs in the following ways:

Customizing: Setting business processes and functions according to an implementation guide. Possible changes are anticipated and thus organized in advance.

Personalization: Changes to the global display characteristics of fields (pre-determing some input values, removing other input fields from certain screens), user specific menu sequences.

Modification: Customer changes to SAP Repository objects. When such changes are made by SAP, customer versions must be adjusted to conform to the new SAP version. Up to Release 4.0B these technical adjustments are made manually using upgrade utilities. From Release 4.5A the Modification Assistant will greatly automate this process.

Enhancement: Creation of customer-defined Repository objects that are referentially included in SAP Repository objects.

Customer Development: Creation of customer-defined Repository objects using customer name spaces.

Customer development, enhancement, and modification are undertaken using ABAP Workbench tools, Customizing and most Personalization are done with Business Engineer tools. Thus the course MBC40 deals mainly with managing projects that are, from a technical standpoint, based on the ABAP Workbench (development projects ).

The Business Engineer contains all of SAP’s implementation tools, specifically:

Reference Models

All Remodels that describe R/3 (process models, data models, organization models)

Implementation Guide

A list of all Customizing activities

The goal of Personalization is to speed up and simplify the business transactions that are going to be processed within the R/3 System. Each individual application’s transactions are adjusted to the business needs of the company as a whole or of various user groups. All unnecessary information and functions are disabled.
The input values of fields on certain screens can be predetermined using global display characteristics. Within transactions, individual fields and individual columns of table controls or even complete screens can be hidden.

Using area menus, the Session Manager (installed on a front end or transaction SESS) enables customized shortcuts, reporting trees and menu sequences to meet specific needs of different user groups within the company.

ABAP Workbench includes all tools necessary for developing client/server applications. Using highly developed tools, ABAP Workbench supports productive program development on the basis of early prototyping. All development objects created using the ABAP Workbench are called Repository objects and are stored in a special part of the SAP system’s central database called the R/3 Repository.

The ABAP Workbench tools listed below allow you to edit the following Repository objects:

Data Modeler enterprise data models according to SAP-SERM

ABAP Dictionary data descriptions and their relationships to one another
ABAP Editor ABAP source code
ABAP Query Reports (no knowledge of the ABAP language necessary)

Function Builder Function modules (centrally stored program modules)
Class Builder Centrally stored OO objects (classes, methods)
Menu Painter Title settings, menu bar settings, standard toolbar and application
toolbar settings Screen Painter Screens

Workbench Organizer Change requests (ensure organized object development
and transport in conjunction with the transport system)

ABAP stands for Advanced Business Application Programming and is the programming language developed by SAP for use in application development.

ABAP is designed to support the application development of business tasks (mass data processing, currency specific display, multilingual capability, etc.).

ABAP is also designed for developing user dialogs in a distributed R/3 system. Developers need not concern themselves with communication and distribution aspects of the system.

ABAP programs in conjunction with the SAP Basis are platform independent.
ABAP contains a special set of commands for database access called ABAP Open SQL.

ABAP application development can be done in project teams which is organized by using the Workbench Organizer.

SAP Repository objects can be called from within a customer’s own program. For example, a customer can develop his or her own program that calls an SAP function module.

With enhancements this works the other way around: here SAP programs call Repository objects that the customer has either created or alter himself. For example, a customer can create a program exit that an SAP program calls. Enhancements can take place in the following places:

in an ABAP program (program exits)
in the graphical user interface (menu exits )
on screens by inserting a subscreen in an area pre-determined by SAP (screen exits )
by executing code written by a customer related to a particular screen field (field exits )

in ABAP Dictionary tables or Dictionary structures (table appends )
as text enhancements (replacing SAP field or keyword documentation).
Modifications are changes to SAP objects made within the customer system. They are:
driven by user exits (subroutines reserved for customers in objects in the SAP namespace) assisted or hard at any point desired in SAP Repository objects.

Customizing Customizing Development/Purchase Development/Purchase

If your requirements cannot be met using Customizing or Personalization either start a development project or use a CSP solution (Complementary Software Product).

A development project allows for customer development if no similar function is available within the SAP standard. Otherwise, you can try to meet the customer’s needs by adding enhancements, user exits, modifications, or copies of SAP programs to SAP standard objects.

Modifications can be problematic because all new SAP versions must be adjusted and reconciled with the customer’s modified version after each upgrade. Up to Release 4.0B these technical adjustments are made manually using upgrade utilities. From Release 4.5A the Modification Assistant will largely automate this process.

You should only make modifications if

Customizing and Personalization cannot fulf ill your requirements

enhancements and user exits are not foreseen

copying an SAP object into the customer namespace is not useful (see following slide).

Modifying has the advantage that your active Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustments must be made to active Repository objects after an upgrade.
Choose copying instead of modifying if you have to change numerous parts of the SAP program your requirements are not going to be met by future R/3 release standards.

Pay attention to the dependent objects when copying. For example, the choice between modifying and copying must also be made for all of the includes attached to your base program. The same applies within function groups respectively function modules.
ABAP development projects can be evaluated according to the following criteria:
How costly is implementation, measured in man hours (creating, implementing, and testing the concept)?

How does the ABAP development project affect performance
the amount of work at upgrade?

By calling SAP objects in your Repository object, you can greatly reduce the amount of work required to implement it. Repository object changes made by SAP can also make for additional work during an upgrade. For example, SAP might change the interface of a screen for which you have written a batch input program.

The following Repository objects are normally only changed by SAP in an upwardly compatible manner and therefore, can be regarded safe for use in customer programs:

function modules that have been released
objects that are public in the ABAP Class Builder
BAPIs (Business Application Programming Interface)
user exit includes
customer exits

SAP guarantees BAPI stability for two functional rele ases.

Customer developed programs that call SAP objects, as well as all objects displayed in the upgrade utility SPAU, must be tested for functionality and performance after an upgrade. The same holds true for those Repository objects automatically upgraded by the Modification Assistant (from Release 4.5A).

For the adjustment of programs you need knowledge of the process logic of your individual application.

Modifications are especially critical when they influence numerous other Repository objects (Dictionary objects, function modules) adjustments are difficult (menu, pushbuttons, graphical user interfaces (GUIs) before 4.5A) or not supported by tools (transaction codes, messages, logical databases).

Without the help of the Modification Assistant (before 4.5A) modifying GUI statuses and GUI titles and assigning customer function modules to SAP function groups are considered critical.

In the general project environment, project planning, implementation, communication, notification management, project documentation, quality assurance procedures, teamwork building, and other areas are standardized.

The following areas are standardized specifically in ABAP development projects :

Evaluation of development projects (see Change Levels)
Process design (see Process Design and Technical Design)
Technical design (see Process Design and Technical Design)

Naming conventions for Repository objects

Naming conflicts between customer Repository objects and Repository objects from SAP and SAP partners can be avoided by using standard naming conventions.
Interface Style Guide
SAP delivers a Style Guide that standardizes your interface according to ergonomic principles.

Program documentation

Repository objects can be documented in various different ways.

Modification Handling

Installation rules and logbook of all modifications made to a customer’s system
central central decentralized decentralized

By instituting naming conventions, you avoid naming conflicts and give your Repository objects meaningful names.

The following naming conflicts can occur:

The names of an SAP Repository object and a customer Repository object conflict
Naming conventions delineate between SAP Repository objects and customer Repository objects. Tip 16466 delivers an overview of all of the current naming convention for Repository objects (normally a Y or Z at the beginning of the name).
The names of two or more customer Repository objects conflict

In decentralized development scenarios with more than one development system, naming conflicts between customer Repository objects can occur. Customers can prevent this situation from occurring by reserving namespaces for development areas within the customer namespace. The Workbench Organizer uses the entries in view V_TRESN to ensure that namespaces remain intact.

The names of Complementary Software and a customer Repository object conflict
Naming conflicts that occur when loading Complementary Software from SAP partners can only be solved by reserving namespaces in SAP OSS. To do this, the SAP partner can from Release 4.0 apply for a name prefix in SAP OSS that is then added to all of that partner’s Repository objects (OSS notes 84282 and 91032, White Paper Development Namespaces in R/3, purchase order number E:50021723 or D:50021751).

The application hierarchy and development classes serve to group Repository objects in a logical manner. The SAP application hierarchy subdivides the Repository according to applications and their functional parts. Each node in the SAP application hierarchy can be assigned to a development class.
Each Repository object must be assigned to a development class, which in turn must be assigned to an application hierarchy node.

Often Repository objects are made up of subobjects that are also Repository objects.
The Repository Information System allows you to search for Repository objects according to various criteria.

SAP delivers a Style Guide that standardizes your interface according to ergonomic principles .

Ergonomics examples can be found in the Repository Browser under Environment
Ergonomics examples.

SAP recommends to store documentation as follows:

Project documentation

internally in a SAPoffice folder structure
externally (e.g. on a document server).

End user documentation

Documentation at the repository object data element (appears when you hit F1 on a screen field) program (appears when you select Help Extended help on a selection screen)

Independent SAPScript text called by an application

Technical documentation of a single repository object
documentation at a repository object (e.g. function modules, ...)

Inline documentation (comments in source code)

Select a central storage for your project documentation that is available and known to all project members.

ABAP source code (in programs, screen flow logic, function modules, methods) can be documented at the following levels:

object heads modularization unit heads

functional methods for stretches of code Customer generated source code should be encapsulated in modularization units instead of distributed throughout SAP source code (for example when calling customer function modules in program source code or calling customer subscreens for additional screen fields).

Keep the interfaces with those parts of the program written by the customer (encapsules) compact.

Define a company-wide standard for online documentation (see the following slides).

Keep a list of all modifications (a modification logbook, see the following slides).

All repairs and all requests that contain repairs must be confirmed and released before an upgrade is run.

SAP recommends labeling hard modifications to source code as described above:
Preliminary Correction OSS notes, repair numbers, changed by, change date, note valid until Customer Functionality Insertions areas, repair numbers, changed by, change date, INSERTION Customer Functionality Replacements areas, repair numbers, changed by, change date, REPLACEMENT Unnecessary SAP functionality is not deleted, but excluded using asterisks.

Areas are specified within the process design (for example area SD_001 = pricing).
SAP recommends keeping a list of all modifications (of all changes made to Repository objects in the SAP namespace).

Such a list normally contains the following columns:

object type (programs, screens, GUI status, ...)
object name routine (if necessary)
area according to process design or technical design
repair number change date
changed by preliminary correction (yes/no)
OSS note number, valid until Release x.y
estimated expense to reinstall the modification during adjustment (measured in hours).

Implementing a SAP Project

2009-02-10T08:49:00.003+05:30

Successfully Implementing SAP

Implementing a package can be a traumatic affair for both the customer and the vendor. Get it wrong and the vendor may get paid late or have to resort to lawyers to get paid and tarnish their reputation. For the company the new package may not work the way they expected, be late or cost a more than budgeted for and take management will take their eye off running their business.

Recently a client asked me what I would consider to be the five most important things one should consider before embarking on an implementation.

top five factors to consider would be:

1. Set up a Project Board,
2. Secure the resources,
3. Complete the GAP Analysis,
4. Have detailed Cut Over Plans,
5. Train the users.

Taking each one in turn:

The Project Board

The correct set up and operation of the Project Board in my view is major factor in the success failure of the project. The Project Board will consist of the stakeholders, key users and the vendor. The Project Board is part of the governance of the project. The Project Board will meet regularly to ensure that the project plans are created and being executed as planned, moves from stage to stage with all the deliverables being signed off is resourced properly.

The Resources

Three types of resources are absolutely necessary -- end users, change team and technicians.

Early involvement by the end users is absolutely necessary, as they will be the ones living with the system for hopefully many years to come. They will want to feel involved in its implementation. Buy in from the end users of the system is absolutely essential if the system is to have a long and stable life in any organisation.

The Change Team will identify the gaps between the package and the business requirements, re-engineer some of the businesses process to cope with the package, train the users to ensure implementation is smooth as possible into the business.

The Technical Team will prepare the systems environment for the package, apply any software fixes from the vendor, implement the software in the best way possible for the organisation set up and tune the software for the particular technical environment.

GAP Analysis

A through gap analysis will identify the gaps between how the business operates ad its needs against what the package can can't do. For each gap there will be one of three outcomes which must be recorded and actioned, GAP must be closed and customised software can be developed close the gap, GAP must be closed but software cannot be written therefore a workaround is required, GAP does not need to be closed.

In simple terms:

Gap means small cracks. In SAP world. In information technology, gap analysis is the study of the differences between two different information systems or applications( ex; existing system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as "the space between where we are and where we want to be." Gap analysis is undertaken as a means of bridging that space.
Actual gap analysis is time consuming and it plays vital role in blue print stage.

Cut Over Plans

Detailed plans need to be developed for cutting over from the old system(s) to the new. Parallel runs of what will happen over the conversion period using test data, convert and watch for a period after wards to ensure nothing unexpected happens.

Train Users

Well trained users will support and defend the system on site. Unsupportive users will continually undermine the system and eventually it will be replaced. Therefore the more effort you put into helping the users master the system early the better.

Difference between the User Exit & Gap analysis.

Both are quiet a different and has a small relation.

User exits are standard gate ways provided by SAP to exit the standard code and we can write our own code with the help of ABAP workbench. its not new functionality which we are trying to build in sap but its slight enhancement within the same code.

Gap analysis is start point of Realization and once blue print is finished we have to find the realization of sap system for client requirment and there will be certain gaps when compared to system fit. Those gaps can be closed either by re-engineering of business process to fit with SAP or we have to use USER exits in case of small deviations or complete enhancements with the help of ABAP to fit with the SAP system.

EDI and International Standards for SAP

2009-02-10T08:49:00.001+05:30

Electronic Data Interchange (EDI) as a tool for paperless inter-company communication and basic instrument for e-commerce is heavily regulated by several international standards.

Unfortunately, it is true for many areas in the industry that an international standard does not mean that everybody uses the same conventions.

Too many organizations play their own game and define standards more or less
compatible with those set by competing organizations.

The main contenders are the national standards organizations and private companies
versus the big international organizations ISO and ANSI.

The private companies being backed up by their country organizations usually fight
for maintaining conventions, which have been often established for many years with
satisfaction.

The American National Standards Organisation ANSI and the international
partner International Standards Organization ISO will usually fight for a solid open
standard to cover the requirements of everybody.

This generally leads to a more or less foul trade-off between pragmatism and
completeness. Tragically the big organizations put themselves in question. Their
publications are not free of charge. The standards are publications which cost a lot
of money. So they mostly remain unread.

Nowadays computing standards have mostly been published and established by
private organizations who made their knowledge accessible free of charge to
everybody. Examples are manifold like PostScript by Adobe, HTML and JavaScript
by Netscape, Java by SUN, SCSI by APPLE, ZIP by PK Systems or MP3 by – who
cares, XML by W3C and EDIFACT by the United Nations Organization UNESCO.

The well-known standards EDIFACT, X.12 and XML have similar characteristics and are
designed like a document description language. Other standards and R/3 IDocs are based on segmented files.

ANSI X.12 is the US standard for EDI and e-commerce. Why is it still the
standard? There are chances that X.12 will be soon replaced by the more flexible
XML, especially with the upcoming boost of e-commerce. ANSI X.12 is a
document description language.

An ANSI X.12 message is made up of segments with fields. The segments have a
segment identifier and the fields are separated by a special separator character, e.g. an asterisk.

BEG*00*NE*123456789**991125**AC~

EDIFACT was originally a European standard. It became popular when chosen by
the UNO for their EDI transactions. EDIFACT is a document description language.
EDIFACT is very similar to ANSI X.12 and differs merely in syntactical details and
the meaning of tags.

XML and the internet page description language HTML are both subsets derived
from the super standard SGML...

The patent and trademark holder of XML describes the
advantages of XML very precisely as follows.

1. XML is a method for putting structured data in a text file.

2. XML looks a bit like HTML but isn't HTML.

3. XML is text, but isn't meant to be read.

4. XML is verbose, but that is not a problem.

5. XML is license-free and platform-independent.

And XML is fully integrated in the world wide web. It can be said briefly: XML
sends the form just as the customer entered the data.

XML

This is an excerpt of an XML EDI message. The difference from all other EDI standards is that the message information is tagged in a way that it can be displayed in human readable form by a browser.

XML differs from the other standards. It is a document markup language like its
sister and subset HTML.

XML defines additional tags to HTML, which are specially designed to mark up
formatted data information.

The advantage is that the XML message has the same information as an EDIFACT
or X.12 message. In addition, it can be displayed in an XML capable web browser .

EDI Converter for SAP

2009-02-10T08:48:00.002+05:30

R/3 does not provide any tool to convert IDocs into international EDI format like ANSI X.12, EDIFACT or XML. This conversion needs to be done by an external add-on product which is Provided by a variety of companies who specialize in general EDI and e-commerce solutions.

R/3 does not provide conversion to EDI standard formats like X.12, EDIFACT or XML.Converters exist on UNIX and PC platforms.

Many converters are simple PC programs.

R/3 certification only guarantees that the converter complies to RFC technology and works fine with standard IDoc scenarios.

Real life situations require a flexible and easily adaptable converter program.

SAP R/3 has foregone implementing routines to convert IDocs into international EDI standard formats and forwards those requests to the numerous third party companies who specialize in commercial EDI and e-commerce solutions..

Nearly every standard organization defined an own EDI standard for their members. So there is X.12 by ANSI for the US, EDIFACT/UN adopted by the United Nations Organization UNO or XML as proposed by the internet research gurus of W3C.

But there is still more about it. All major industry companies define an additional file format standard for their EDI partners. Even if they adhere officially to one of the big standards, they yet issue interpretation guidelines with their own modifications according to their needs.

If a company does not play in the premier league of industry or banking companies, it will have to comply with the demands of the large corporations.

As this leads to the insight that there are as many different EDI formats as companies, it is evident that an EDI converter needs to have at least one major feature, which is flexibility in the sense of openness towards modification of the conversion rules.

There are hundreds of converter solutions on the market not counting the individual in-house programming solutions done by many companies.

EDI is a market on its own. Numerous companies specialize in providing EDI solutions and services. The majority of those companies also provide converters. Many of the converters are certified by SAP to be used with R/3. However, this does not tell anything about the usability or suitability to task of the products.

SAP EDI introduction

2009-02-10T08:48:00.001+05:30

EDI is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network. EDI is also called paperless exchange.

Why do we need EDI ?

Business scenario :

A customer who wants to purchase an item creates a purchase order and then faxes or mails it to the vendor.
The vendor receives the purchase order and manually keys in a sales order.
The vendor's system generates a confirmation date that is sent back to the customer via fax or mail.
The vendor then ships the goods via a carrier. The carrier delivers the products to the customer.
When the goods are shipped, the vendor invoices the customer.
The customer makes the payment by check, and the vendor deposits the check in the bank.
Finally, funds are transferred from the customer's account to the vendor's account.

This simple scenario requires the exchange of various documents between several business partners at different times.

A business process is a series of actions or functions that bring about a business result, and as such there are some inherent problems with this scenario. They are

Is highly inefficient and laborious ·
Cannot be tracked easily ·
Gives no visibility into the process ·
Has a very long lead time ·
Includes redundant data entry at various points.

The electronic exchange of business documents in a standard format gave birth to what is now known as EDI.

Benefits of the EDI Process :

1.Reduced data entry errors: EDI does not involve data entry at multiple points. In the traditional process, a sender creates a purchase order on the system, prints the order, and then faxes or mails it to a trading partner. The receiver then rekeys the same information on his or her computer. The process is prone to data entry errors. This procedure is repeated when invoicing takes place. With EDI, data goes directly from one computer to another without involving a human being.

2· Reduced processing cycle time : The biggest advantage is the reduced processing time of the complete cycle. As soon as orders are entered into the system, they can be processed on the receiving side in seconds. There is a considerable savings in the processing time of document transfer.

3. Availability of data in electronic form : Data from EDI is in electronic form, which makes it easy to share across the organization.

4· Reduced paperwork : The entire EDI process can be handled without using a single piece of paper.

5· Reduced cost : Time is money. Any savings in time is directly linked to savings in money. The initial cost of an EDI setup is certainly higher compared to the paper process, but over a long period it is very cost−effective.

6·Reduced inventories and better planning : Companies do not have to keep a safety stock for the time taken with order processing. Changes to planning schedules can be communicated instantaneously. MRP (Material Requirements Planning) can take into account a shipment in transit as soon as an Advance ship notice (EDI 856) transaction is received.

7·Standard means of communication : Because EDI enforces standards on the contents of data,uniform naming standards and field sizes have emerged. Such consistency leads to clearer communication and less ambiguity.

8·Better business processes : Compared to traditional methods of exchanging business documents, EDI is certainly a better way of communicating with your trading partners. Companies are willing to share information and participate in inter−organizational issues. This environment enhances supply−chain management.

9·Competitive advantage: In many cases, companies that have implemented EDI have an advantage over their competitors, especially when dealing with government agencies or large corporations. (15.1)

SAP Business Process using EDI

2009-02-10T08:47:00.001+05:30

In the process of buying and selling goods, partners exchange business documents at various times. These documents record the process of creating and executing a contract for sales of goods or services.

While many of these documents help to meet legal requirements, they are also all significant factors in the efficiency of processing a particular sales transaction. Well−run businesses pay a lot of attention to optimizing these business processes, and EDI frequently plays a major role in efforts to improve speed and efficiency.

Many modern business process designs are feasible only because of the existence of EDI technology.

Documents Exchanged with Customers :

Between a customer and a supplier, it is the customer who typically drives the EDI requirements. The following are key business documents exchanged between a customer and supplier.

The customer requests price catalogs.
The customer requests quotes.
The customer places blanket purchase orders.
The customer authorizes delivery against its blanket orders.
The customer places an order.
The customer expects an order acknowledgment.
The customer expects a delivery schedule.
The customer wants to know the status of the order.
The customer might cancel an order.
The customer might change an order.
The customer expects an order.
The customer requires a shipment notification.
The customer receives goods.
The customer notifies the supplier that goods have been received.
The customer wants authorization to return goods.
The customer wants to return goods damaged in transit.
The customer is an international customer.
The customer receives an invoice.

Documents Exchanged with Carriers :

A carrier is a party who undertakes the transportation of goods. The following documents are exchanged during the transportation process.

The shipper requests a carrier pickup.
The carrier responds with a pickup date.
The carrier prints a bill of lading.
The carrier informs the receiving party of the shipment.
The receiver tells the carrier where to unload the goods.
The shipper requests tracking for a particular shipment.
The carrier informs the shipper of the status of the shipment.
The carrier bills the shipper through an invoice.
The carrier receives payment.(17.2)

SAP EDI Process Components

2009-02-10T08:45:00.000+05:30

An EDI process is a transfer of one or a sequence of electronic messages.It involves senders, receivers, language, content, and a medium. In EDI, the senders and receivers are called trading partners, and the X12 or EDIFACT standards supply a common language for formatting the information content of common messages.

Software tools called translators enable trading partners to converse in a standard language, and application programs (such as SAP R/3), coupled with networking facilities such as the Internet or a commercial VAN (Value−Added Network), supply the messaging medium.

Trading Partners Parties involved in a business transaction are called trading partners. The trading partners can be any combination of organizations or business types. For example, customers and vendors are trading partners.

Business Documents A business document is a legal document that defines the transaction conducted between trading partners. The legal boundaries for these transactions are defined by trade agencies, trading partners, and the ISO (International Standards Organization). The trading partners are bound by the terms and conditions of these documents. Numerous business documents are in existence today. Examples of some typical business documents follow.

Requests for quotes
Purchase orders
Purchase order changes
Purchase order acknowledgments
Invoices

EDI Messages

The formation of common standards has many advantages.
Standardization allows representation that can be easily processed by a computer system.
Standardization allows companies to exchange information that is independent from the application software.
Third−party applications can provide EDI translation and thus relieve the application of having to keep up with evolving standards.(19.2)

SAP EDI Process Components II

2009-02-10T08:44:00.002+05:30

This post is in continuation with EDI Process components part one .
Transaction : A transaction is the electronic equivalent of a business document. A transaction is usually divided into three areas: header area, detail area, and summary area. The header area consists of segments that apply to the entire document, and is usually mandatory.

For example, in a purchase order, vendor number and vendor address are part of the header segments. The detail area contains document details. The items being ordered and their quantities are considered detail segments. The summary area consists of data that summarizes the entire document, and the total amount and taxes are part of the summary segments.

Segment : A segment is equivalent to a record in a document. A data segment has the following attributes: a unique ID, a name, a flag indicating whether it is optional or mandatory, and a number of occurrences. A group of segments can be combined to form a loop, which can also be mandatory or optional, and can be nested as well.
Segments are contained in a segment directory .

A segment consists of a sequence of logically related data elements. Data elements are separated by a data element separator and can be mandatory or optional. Some data elements are conditional, or mandatory, in certain situations.

Data Elements : Data elements are the smallest unit of information in a transaction and are defined in the data element dictionary (X12.3). A data element is identified by a data element reference number, a data type, and a minimum and maximum length.

UN/EDIFACT (United Nations EDI for Administration, Commerce, and Transport) was formed in 1985, using the ANSIX12 and UNTDI (United Nations Trade Data Interchange) as the base standards. The purpose of the standard was to develop an international standard to meet the needs of a global economy.

Most companies are moving toward adopting EDIFACT because of its international recognition. EDIFACT is quite similar to ANSI X12, with some minor differences in terminology and layout.

EDIFACT calls business documents messages and represents them by a name such as ORDERS for a purchase order, whereas ANSI X12 calls them transactions and represents them by a number such as 850 for a purchase order.

EDIFACT uses different terminology for fields. Conditional fields of EDIFACT are the same as optional fields in ANSI X12.

EDIFACT uses the same segment in multiple places, whereas ANSI has a specific use for each segment.

EDIFACT has additional segments that apply to international trade.

Application Programs

Application programs are responsible for generating and processing data in business documents. These application programs are part of the application suite commonly referred to as ERP (Enterprise Resource Planning). ERP systems meet a broad range of a company's business needsSAP R/3 is an example. Most ERP vendors recognize the business needs for EDI and thus enable their software to support EDI processes. An ERP system must do the following:

Support standard EDI transactions in the business area of interest. For example, if the focus of a company is shipping and distribution, the software must support basic shipping transactions.

Make the data necessary for EDI messages readily available.
Document the EDI processes and functionality.
Be flexible enough to incorporate business requirements within the existing process.
Provide support for enhancing existing transactions.
Contain easily configurable and manageable systems.
Contain a sufficient number of control points to meet business needs.
Exhibit a disciplined approach for controlling the flow of documents within the organization, from error handling to the approval process.
Be integrated with EDI translation software vendors.
Provide system limits and performance measures if a company expects a large volume of EDI.
transactions.(22)

SAP EDI Standards

2009-02-10T08:43:00.000+05:30

SAP provides the application logic, application data, and format for the data contents for EDI. Third−party software vendors supply the other pieces. EDI−enabled applications in SAP are capable of generating IDoc (Intermediate Document) data from an SAP document or reading IDoc data and creating application documents.

The application must understand the syntax and semantics of the data in the IDoc format. In the case of outbound processes, a separate selection program reads application data and creates an IDoc, as shown in Figure below. Similarly, for inbound processes, a posting program reads IDoc data to create an application document.

In the standard SAP system, several EDI−enabled applications in various modules are capable of generating and processing IDoc data, but all EDI documents are not supported. It is very likely that SAP supports the business process but not the creation or processing of IDocs. However, with every release of SAP, the list of supported IDocs grows considerably.

Note An application that is not EDIenabled can be enabled by developing the selection and posting programs and IDoc structures. SAP provides a comprehensive set of tools for developing IDocs and programs.(24.3)

EDI Outbound Process

2009-02-10T08:42:00.000+05:30

Here i am going to present the overview of EDI process in SAP. The SAP EDI process comprises two distinct processes. The outbound process sends documents from the SAP system to a business partner (vendor, customer, bank). Figure below shows the outbound process at a very high level. The outbound process consists of six steps.

1.The application document is created: The first step in the outbound process involves creating an application document such as a purchase order or sales order and saving it in the database tables. This step is no different from the way in which these documents are normally created. It is the following steps that have relevance to EDI. The document is created and leaves some hooks for the EDI process to begin.

2.The IDoc is generated : The application document just created is now formatted to an IDoc format. At this point you can think of IDoc as yet another format in which the application document has been represented. For example, think of how a date can be stored in different formatsimagine a date as a document with three components: day, month, and year.

In one case, you represent it as MM/DD/YYYY, a standard American way of representing a date. To make it meaningful for a German partner, you have to represent it as DD.MM.YY. IDocs follow a similar concept of representing information in different ways. The data in the application document format is suitable for the application modules, screens, and internal programs.

3.The IDoc is transferred from SAP to the operating system layer : The IDoc created in Step 2 resides in the SAP database repository. This IDoc document must be passed down to the operating system layer for processing by the EDI subsystem. In Step 3, the IDoc is transferred to the operating system as a text file. The document is still in an IDoc format. The only difference is the medium of storage.

4.The IDoc is converted to EDI standards : The IDoc format is an SAP proprietary format. For EDI purposes, the document in IDoc format has to be converted into an EDI standard format. Third−party software called a translator carries out the transformation process and reports status back to the SAP system.

SAP refers to these translators as EDI subsystems, and has certified several subsystems for connectivity to SAP. SAP takes no responsibility for translation. Thus, from SAP's perspective, after the IDoc is delivered to the subsystem, SAP does not have control over the process, but it maintains the status reported by the EDI subsystem.

5.The EDI document is transmitted to the business partner : After the document is converted to an EDI standard format, it is transmitted to a trading partner based on the partner's EDI settings. This step is not part of the SAP EDI architecture, but is mentioned here to describe the complete process from a business perspective.

6.The EDI subsystem reports status to SAP : When an IDoc is under the control of the EDI subsystem, the subsystem can optionally report the state of processing at various milestones back to the SAP system. This mechanism is always recommended because it provides complete visibility of the process from within SAP, and the user does not have to be involved with the intricacies of the EDI subsystem.(26.2)

What is inbound EDI Process

2009-02-04T13:21:00.001+05:30

The inbound process simply reverses the steps of the outbound process. The inbound process receives an EDI document (such as a purchase order response, sales order, or payment information) from a business partner (such as a vendor, a customer, or a bank) and creates SAP documents from it. Figure at the bottom of the post shows the inbound process at a very high level.

The inbound process consists of five steps.

1.The EDI transmission is received : EDI documents are received from a business partner via the VAN. These documents are in one of the EDI standard formats. The documents are deposited in a common repository for the subsystem. This part of the process is not part of the SAP EDI architecture.

2 .The EDI document is converted into an IDoc:The EDI−specific headers and trailers are stripped off, and the document is converted into an IDoc format suitable for SAP applications. The process is carried out at the EDI subsystem level.

3. The IDoc is transferred to the SAP layer : The IDoc created in Step 2 is stored in a text file at the operating system layer. The subsystem starts an inbound program in the SAP layer. This program reads the IDoc file and creates an IDoc in the SAP repository for further processing.

4. The application document is created : The IDoc received from the subsystem is passed to a posting program. This program creates an application document such as a sales order, purchase order acknowledgment, invoice, or shipment notice.

5. The application document can be viewed: The application document created via EDI is the same as any document created manually in the system: The document can be viewed using standard application transactions. For example, if an incoming sales order was created via EDI, you could view the sales order document via transaction VA03.

Exception Handling via Work flow :

Exceptions can occur at any point during either the outbound or inbound process. They are caused by technical problems (such as network connectivity failures or file system problems), data−related problems (such as data that is formatted incorrectly or missing), or a combination of both.

Workflow provides a very sophisticated method for managing the exception−handling process. Based on the type of error, workflow can be configured to identify the persons responsible for handling the problem, notify them in a timely manner, and provide a mechanism for making the necessary correction. After the problem is fixed, the process can be restarted from the point of failure.(27.2)

SAP Out bound EDI Process Over view

2009-02-04T13:20:00.003+05:30

The outbound process uses IDoc types, Message control, partner profiles, port definitions, selection programs, service programs, and tables to generate an IDoc.

The IDoc Structure

The EDI document to be generated has an equivalent message type defined in the SAP system. The message type is based on an IDoc structure. For example, if you are going to generate EDI transaction 850, which is a purchase order, the message type ORDERS is assigned in SAP to purchase orders. This message is based on IDoc type ORDERS01 and ORDERS02.

Selection Programs

Selection programs, which are typically implemented as function modules, are designed to extract application data and create an IDoc. A selection program exists for each message type. The programs are generally named with the following naming convention:

IDOC_OUTPUT_message type

The naming convention mentioned here is not a rule, but it is a common practice for naming the outbound programs.

These function modules have a standard interface for input and output parameters. A process code is assigned to each selection program that executes under Message control. Because process codes are flexible, you can assign any processing option to a process code. A process code can point to a function module or a workflow. In the standard system, process codes always point to a function module.

Message Control

Message control is a cross−application technology. It is used in pricing, account determination, material determination, and output determination. The message control component enables you to encapsulate business rules without having to write ABAP/4 programs. In the EDI process, Message control determines and processes the various outputs associated with an application document (for example, EDI, printed output, fax, confirmation, and mail).

The Port Definition

Port is used in the outbound process to determine the name of the EDI subsystem program ,the directory path where the IDoc file will be created at the operating system level, the IDoc file names, and the RFC destination.

The RFC Destination

RFC (Remote Function Call) destination is the term used to define the characteristics of communication links to a remote system on which a function needs to be executed. In EDI, it is used to specify information required to gain access to the system on which the EDI subsystem is installed.

The Partner Profile

A partner profile specifies the various components used in an outbound process (partner number, IDoc type, message type, port, process code), the mode in which it communicates with the subsystem (batch versus immediate), and the person to be notified in case of errors. A partner profile is created for each business partner, and a record exists for each outbound message sent to a business partner.

For example, if two outbound messages (purchase order and purchase order change) are being sent to vendor number VEN001, a partner profile must exist for VEN001, and two outbound records (one for each message type) must exist in the partner profile. The partner profile is an important and frequently referenced component.

Service Programs and Configuration Tables

The asynchronous outbound process can be seen as a sequence of several processes that work together. SAP provides service programs and configuration tables to link the various components and provide customizing options for an outbound process. The process flow for the outbound process describes the role played by each service program and configuration table.(35.1)

SAP EDI Outbound Process with Message Control

2009-02-04T13:18:00.000+05:30

Processing in the Application Layer

An application document is entered via a transaction.Before an application document is saved, the Message control component is invoked. An application passes several key elements of the application data to the Message control component via communication structures.

Processing in the Message Control Layer

The Message control component checks various business rules defined in the Message control configuration. Based on the business rules, Message control proposes the output type ,medium and language of the message. Multiple outputs are possible from Message control. Each output is processed independently.

The output proposed by the Message control component can be edited. The user can delete, add, or modify any outputs proposed on the output control screen.

When the application document is saved, the outputs proposed on the output control screen are saved as a record in the NAST table. An entry in the NAST table stores the key of the application document, output type, timing, processing status, and language.

If the timing for an output is set to 4 (Immediate), the system immediately starts the processing of the output type by executing the RSNAST00 program. If the timing is set to 1 (Batch Mode), the entries are processed when the RSNAST00 program is executed explicitly.

The RSNAST00 program is usually scheduled to run on a regular basis. It selects entries that can be processed based on their status and calls the appropriate program for the selected medium. Each output medium (EDI, ALE, fax, printed output, and so on) has a corresponding program to generate the output in the required medium. SAP provides standard processing programs for each output medium.

In the case of EDI, the processing program is a form routine: EDI_PROCESSING in the RSNASTED program. This program is a generic program for all EDI outputs and reads the partner profile configuration to determine the selection program for a particular message.

In ALE, the processing program is also a form routine: ALE_PROCESSING in the RSNASTED program. This program is a generic program for all ALE outputs and reads the partner profile configuration to determine the selection program for a particular message.

Processing in the Selection Program

The selection program is specified in the partner profile with a process code. The RSNASTED program calls the appropriate selection program.

One of the parameters for these function modules is the NAST entry, which contains the key of the application document. These programs extract application data, format it into an IDoc format in an internal table, and then pass control to the ALE/EDI layer.

Processing in the ALE/EDI Layer

The ALE/EDI layer is responsible for creating the IDoc in the SAP database. By now, a tangible IDoc that can be viewed using the various monitoring tools has been created in the system. The IDoc gets a status record with a status code of 01 (IDoc Created).

The IDoc, before being saved in the database, goes through a syntax check and other validations. If there are no errors, the IDoc gets a status of 30 (IDoc Ready for Dispatch to ALE Service).

Dispatching the IDoc

The settings of the Output Mode fields in the partner profile are read to determine the timing of dispatching idoc,and the port definition is read to determine the directory location in which the file will be created. If the mode is set to Do Not Collect IDocs, the IDoc isimmediately passed to the operating system layer automatically, using program RSEOUT00.

The subsystem takes the IDoc file as input and translates it into an EDI standard format. At various milestones, the subsystem reports the status of the process to SAP, thus providing complete visibility into the process from within SAP. The status reported by the subsystem is attached as a status record to the IDoc in the SAP database.

To report status back to the SAP system, the subsystem creates a status file at the OS level and calls the function module EDI_STATUS_INCOMING in SAP, passing the status file name as an input parameter. For this, SAP provides a standard program named startrfc at the OS level to execute any RFC−enabled function module in SAP.

SAP EDI outbound process

2009-02-04T13:17:00.001+05:30

Here we are going to discuss regarding EDI outbound process with out message control.This is in continuation with the previous discussion of EDI outbound process with message control.

The following are the problems in EDI outbound with message control.

1 . Message control might not be available for your application document. Here we have no choice. Applications are programmed to make use of the Message control service, and it is not automatically available for every application. The FI applications, for example, do not use Message control. The REMADV message is generated by the Payment Run program, which does not use Message control. Most ALE processes do not use Message control.

2 · The Message control component is intricate because of its generic technology of building business rules without coding ABAP/4 programs. Here client may not want to maintain Message control because of its complexity and decided to bypass it completely. This is not a configuration option. The client had developed custom programs to select IDoc data and pass it directly to the ALE/EDI layer.

Here are the following steps in this process.

Processing in the Application Layer :

The application document is entered by way of a transaction.
The business rules for selecting objects for EDI output are established through a selection screen or a dialog box.
The data−extraction logic, which is built into the application, is implemented as a separate function module but is still a part of the application logic. This concept is different compared to the outbound process with Message control, in which the data−extraction logic is not part of theapplication logic.
The application builds the IDoc and passes control to the ALE layer. The interface to the ALE layer is through the function module MASTER_IDOC_DISTRIBUTE.

Processing in the ALE/EDI Layer

The ALE/EDI layer checks for the sender and receiver fields. If they are not supplied, the ALE distribution model is consulted to determine the recipients. The ALE distribution model is used to model the messages exchanged between the systems. A message can have multiple recipients.
After the set of receivers is determined, the IDocs are processed for filtering, data conversion, and version change. An IDoc is generated for each partner identified in the distribution model. These IDocs, called communication IDocs, are then saved in the SAP database. That IDoc gets a status record with a status code of 01 (IDoc Created).
The IDoc goes through a syntax check and other validations. If there are no errors, the IDoc gets a status of 30 (IDoc Ready for Dispatch to ALE Service).(40.2)

SAP EDI inbound process overview

2009-02-04T13:15:00.000+05:30

The inbound process uses IDoc type, port definition, posting programs, service programs, and configuration tables. The inbound process components are specified in the partner profile and configuration tables.

IDoc Types

The EDI document to be posted has an equivalent message type defined in the SAP system. The message type is based on an IDoc structure.

Posting Programs

Posting programs are implemented in the system as function modules. A posting program exists for each message type. The programs are named with the following naming convention:

IDOC_INPUT_message type

These function modules have a standard interface for their input and output parameters. The function modules can handle one IDoc or multiple IDocs of the same type simultaneously.

A process code is assigned to each posting program. Because process codes are flexible, you can assign any processing type to a process code. A process code can point to a function module or a workflow. In the standard system, process codes always use the Processing by Function module processing type with the Processing with ALE service option.

The Port Definition

In the inbound process, the port definition specifies the name of the input IDoc file and the directory path where the file is located.

The SAP Business Workflow

SAP business workflow represents a sequence of customized steps (dialog and background) that are to be carried out for a process. The workflow management system is used to model the sequence, the information required to carry out the various steps, and the person responsible for the dialog steps.
In workflow terminology, if there is only one step in a flow, it can be implemented using a single−step task. A single−step task is technically defined as a task described by an object method.

If there are multiple steps, they are implemented as a workflow that contains multiple single−step tasks.

The Partner Profile

A partner profile specifies the various components used in an inbound process (partner number, message type, or process code), the mode in which it communicates with the posting program (batch or immediate), and the person to be notified in case of errors.

A partner profile is created for each business partner, and a record exists for each inbound message received from a business partner.

Service Programs and Configuration Tables

The inbound process is asynchronous and can be regarded as a sequence of several processes that work together. To link the components and provide customizing options for an inbound process, SAP provides service programs and configuration tables. The process flow for the inbound process describes the role played by each service program.(43.2)

SAP EDI Inbound Process via Function Module

2009-02-04T13:14:00.003+05:30

We had a overview of EDI inbound process in the previous post.Now we are going to have a discussion of EDI Inbound process through function module.

In this process, the IDocs are transferred from the EDI subsystem to SAP, and then they are passed to the posting function module to post an application document.

Processing in the EDI Subsystem Layer

The inbound SAP EDI process begins at the subsystem layer with an EDI document converted to an IDoc format. The IDoc is stored in a text file at the operating system (OS) layer. The IDoc file can be passed to the ALE/EDI interface layer immediately via the file port using the startrfc program, or can be processed at a later time through execution of program RSEINB00.

The startrfc program is a standard SAP program at the OS level to call any RFC−enabled function module in SAP. To trigger the inbound process, the startrfc program calls the function module EDI_DATA_INCOMING, which acts as the entry point for inbound processes. The name of the IDoc file is passed as an input parameter to this function module.

Processing in the ALE/EDI Layer

The EDI_DATA_INCOMING function module reads the IDoc file into an internal table. The IDoc is first checked for integrity by doing a syntax check. Then the standard ALE services such as version change,filtering, and conversion are applied, if necessary.

The ALE/EDI layer creates an application IDoc in the database. At this point IDoc, which can be monitored via one of the monitoring transactions, is created in the system. The IDoc gets a status code of 50 (IDoc added). If the IDoc passed the syntax check process earlier, it gets a status code of 64 (IDoc ready to be passed to application), signifying that the process can continue.

The processing flag and process code are read from the partner profile table. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program using the RBDAPP01 program.

If the field is set to Background Processing, the IDocs are buffered in the system until the RBDAPP01 program is executed explicitly. RBDAPP01 is usually scheduled to run on a regular basis, or it can be started as a result of an event raised by the subsystem after the IDoc file has been loaded into the SAP system.

Processing in the Application Layer

The posting function module either calls a standard SAP transaction, using the call transaction command for posting the document, or invokes a direct input function module.

The results of the execution are passed back via the function module's output parameters. If posting is successful, an application document is created. The IDoc gets a status code of 53 (Application document posted). If errors occur, the IDoc gets a status code of 51 (Application document not posted).

SAP EDI Inbound Process via Workflow

2009-02-04T13:14:00.001+05:30

The inbound process via workflow is similar to the inbound process via function module, except for the difference in the processing that occurs in the application layer.

The IDoc, instead of being processed by a posting program, is processed by a single−step task or a multi−step workflow. Pointing the process code to processing by task or process, instead of processing by function module, configures this option.

Workflow allows human intervention in the process, which is sometimes necessary. A typical example is the sales order change transaction coming in via EDI. Someone might need to review any change from a customer before the change can be accepted; if you have already begun production, you might not be able to accept a change in quantity or delivery date. This process gives you the option of reviewing the changes and taking appropriate action.

In the standard system, the inbound processes use function modules for posting the document. Although no process uses workflow by default, you can customize the interface to start workflow.

The inbound process via workflow differs from processing via function module mainly in the processing that occurs in the application layer. The processing that occurs in the EDI subsystem layer and the ALE/EDI layer is the same in the two approaches as shown in the figure.

Processing in the Application Layer

The posting module in this case is a workflow task. The workflow task can be designed to accommodate any customized processing, such as reviewing an incoming order change transaction followed by posting, or posting an incoming order change document followed by review.

If a complex business process is associated with an incoming document, you can use a multi−step workflow to map that process.

Workflow is a useful method for processing inbound EDI transactions, but it adds additional load to the system, especially when you have high−volume EDI transactions. It also blocks the process unless someone processes the work item, which can cause unnecessary delays.

Exception Handling in the Inbound Process

The inbound process described in this chapter shows the success path from the IDoc's creation through the final creation of the application document, but the system can experience problems at any stage during the process. Compared to the outbound process, the inbound process has more opportunity for error because data originates outside the SAP system. SAP validates the data using the same business rules as if the document were entered online.

The workflow system uses the Post Processing: Permitted Agent fields in the partner profile to send the error notification. For example, an error might occur before an IDoc is created or because the partner profile cannot be read; in any case, the EDI administrator is notified.(47)

EDI Subsystem I

2009-02-04T13:12:00.000+05:30

The EDI subsystem carries out the task of converting an EDI document in a standard EDI format to an IDoc file, and vice versa. SAP does not supply the EDI subsystem because several EDI standards are in existence and each standard has multiple versions. To further complicate the process, these standards are still evolving. Hence, this task is best carried out by EDI vendors, who stay current with the standards.

EDI vendors have developed translators to help with the conversion of application−specific messages IDocs, in the case of SAPto standard EDI format. Any translator software product is completely independent of the SAP software and resides outside the SAP system.

The translator can be installed on the same hardware as the SAP system, or it can stand alone on another computer. The operating system environment of the EDI subsystem can be different than the SAP operating system environment. If the SAP system is installed on a UNIX platform, the subsystem can reside on a separate platform that operates on, for example, Windows NT.

SAP certifies several EDI subsystems for compatibility with the EDI interface. The IDoc interface has changed with every release . For this reason, the certification is applicable only for a specific release of SAP.

The subsystem has several responsibilities in the EDI process chain.

Data Mapping

Within the framework of SAP EDI, the conversion of a business document in IDoc format to an EDI standard format (and vice versa) is the most important task performed by a subsystem. This process is resource intensive and, hence, is better done at the subsystem level than within SAP.

The following conversions and translations are carried out by the subsystem.

Creating a control record for each inbound IDoc. An inbound IDoc must have a control record.The EDI subsystem builds the control record using the information stored in its local repository or from the SAP repository.
Removing the control record during the outbound process. The control record in the IDoc file is used by the subsystem for housekeeping functions, such as locating the trading partner profile. The data on the control record is not needed for translating the content of the EDI documents.
Translating data from IDoc format to EDI format. For an outbound transaction, the EDIsubsystem converts data in the IDoc format to a suitable EDI format.
Translating data from EDI format to IDoc format. For an inbound transaction, the EDI subsystem converts data in the standard EDI format to IDoc format.
Bundling and unbundling IDocs. If several IDocs are passed to the EDI subsystem in one file, thesubsystem separates them into individual documents. Similarly, on the inbound process the subsystem can bundle multiple IDocs into a single file to improve performance.

Maintaining the Partner Profile

A partner is defined as the business partner with whom you conduct business and exchange EDI documents. These partners are not necessarily the same as the partners in the partner profile of SAP.
In SAP, the partner profile maintains parameters specific to the IDoc process, and in the subsystem the partner profile maintains parameters specific to the EDI process.

Some attributes in a partner profile are

A unique partner number
The partner type (Customer, Vendor)
The standard used (EDIFACT, ANSI X12, and so on)
The version of the EDI standard
The EDI message exchanged (850, 860, ORDERS, ORDCHG)
A functional acknowledgment flag

Triggering the Inbound Process

After receiving an inbound EDI transmission and creating an IDoc file, the subsystem is often responsible for triggering the inbound process. SAP provides a program named startrfc to start any RFC−enabled function module from the operating system level. For the EDI process, the subsystem uses the start rfc program to trigger the function module EDI_DATA_INCOMING.

Reporting Process Status to SAP

In an outbound process, after an IDoc has been transferred from SAP to the subsystem, SAP loses control over the process. However, SAP maintains visibility into the process by requiring the subsystem to report on the status of the process. SAP provides a file interface for the subsystem to send a status report at every milestone.

When the subsystem has status information to send to SAP, it creates a status file and uses the startrfc program to trigger the SAP system. The status file contains the IDoc number, which is used to identify the IDoc to which the status record is to be attached. The startrfc program calls the EDI_STATUS_INCOMING function module to start the processing of the status file in SAP.

Status Code Description

04 Error within control information of EDI subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check
08 Syntax check OK
09 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgment positive
15 Interchange Acknowledgment negative
16 Functional Acknowledgment positive
17 Functional Acknowledgment negative
22 Dispatch OK, Acknowledgment still due
23 Error during retransmission
24 Control information of EDI subsystem OK
36 Electronic signature not performed (timeout)

EDI Sub System II

2009-02-04T13:10:00.002+05:30

This part of EDI sub system is in continuation with the previous post about EDI subsystem.

Handling Functional and Interchange Acknowledgments

An interchange acknowledgment is the message that the VAN sends to the subsystem to inform it about the transmission results. A functional acknowledgment (ANSI X12 transaction 997) acknowledges the receipt of data by the receiving system. This transaction verifies the successful receipt of an EDI document but does not guarantee successful data processing. The subsystems are responsible for generating this document on receipt of an EDI transmission.

For an outbound process, the status codes that the subsystem reports to SAP depend on the results of the acknowledgment. Status codes 14, 15, 16, 17, and 22 are returned to SAP.

Performing a Syntax Check

The EDI standards have a rigid structure. The segments and fields have the following characteristics.

Optional or mandatory
Conditional or non−conditional
Data format
Data length
Loop counts
ID codes (similar to SAP IDoc qualifiers)

These characteristics form the basis for a syntax check. If any rules are violated, the document processing can fail. To avoid wasteful transmissions, the subsystem checks the documents for conformance to the standards defined by the standards committee. The results of the syntax check are sent back to SAP using status code 07 or 08.

Handling Partner−Specific Processing

The subsystem also handles partner−specific processing.Several data elements in the EDI transactions have not been assigned a definitive meaning. The subsystem can handle this partner−specific processing.

Handling Errors

In the outbound process, the subsystem is responsible for reporting to SAP any errors, including translation errors, syntax errors, transmission errors, and connectivity issues. In the inbound process, until an IDoc is created, the subsystem is responsible for reporting and managing the errors. The subsystem provides the necessary monitoring and recovery tools. Once an IDoc is inside SAP, SAP has full responsibility for handling errors.

Communicating with Business Partners

Business partners can provide a direct connection to their network or subscribe to a VAN. The subsystem is responsible for establishing and terminating connections with the business partner's network or VAN to send and receive EDI transmissions. The subsystem is also responsible for processing acknowledgments from the VAN and communicating those to SAP.

Attaching EDI Headers and Controls

EDI transmissions have several header and trailer segments that act as control information The subsystem is responsible for attaching these segments to the document.

Archiving

All important documents, such as payment stubs or remittance advice transmitted to the trading partners, might have to be archived for auditing purposes and liability issues. The subsystems provide data archiving and management options.(51.8)

SAP EDI Subsystem Architecture and Mapping

2009-02-04T13:08:00.000+05:30

The Definition Component

The definition component is where mapping definitions between EDI and IDoc formats are created. This component can run without any connection to the SAP system or its server module. The maps are platform independent. The definition component carries out the following functions.

Defines the source structure and destination structure.
Maps fields in the source structure to fields in the destination structure.
Compiles maps for other platforms.
Tests maps.
Provides utilities to download and upload IDoc structures, document structures, and maps.

The structure of standard EDI documents for commonly−used standards (ANSI X12 and EDIFACT) is shipped with most EDI subsystems.

The Execution Component
Maps created in the definition component step are executed on the server, which is known as the execution component. The execution component is where the complete environment for executing the maps, trading partner relationships, and other server−related functions are performed. The list of common tasks performed on the server and features commonly found in EDI subsystems is given below.

Execution of maps
Maintenance of trading partner agreements
Configuration of the environment
Maintenance of log information
Archiving
Tools for monitoring the process
Tools for restart and recovery of failed transactions
Scripts for connectivity with VAN

Mapping Concepts for IDocs and EDI Document Formats

A map is created for every message exchanged with a business partner. Mapping an IDoc to an EDI format requires the following steps.

1.Download the SAP IDoc structure :The IDoc structure is downloaded into the definition component. SAP provides a program named RSEIDOC3 that generates a structured report of the IDoc structure. The report is downloaded to a file and can then be copied to the PC on which the definition component is installed.

2.Define the IDoc structure: The output file can be imported into the definition component to make the IDoc format known to the system. To create the IDoc structure, the software vendors provide a utility program to import the file automatically. The IDoc structure has a control record structure and several data record structures.

3.Define the EDI document structure: Software vendors usually provide the structure of the standard EDI documents.

4.Define the maps:Mapping is the process of linking source fields to destination fields. In complex mapping, values from several fields of the source structure are manipulated in different ways to generate an output value for a field in the destination structure. The systems usually allow manipulation using functions, external program calls, and so on. You must check with your software vendor about the sophistication of the mapping process.

5.Compile the maps: Maps need to be compiled before they can be executed. The compilation process is simple. The system checks the syntax of the map, the consistency of business rules used in the map, and the source and destination data elements in the map. If compilation is successful, the map is ready to be executed.

6.Test the compiled maps: The maps can be tested on the definition system using some test data. An input file is processed through a map to generate the output. The output should be verified manually the data should be in the correct location and in the correct format.

7.Transport the maps: The definition component can usually compile maps for use on other platforms. Thus, if the execution engine resides on UNIX and the definition component is on a PC, the system can generate a compile map for the UNIX system. The compiled map can then be transported to the EDI server system via any file transfer techniques.

8.Execute the maps: The maps can then be executed on the server. During production, the system executes maps on the server.(53.2)

EDI Basic Components Configuration I

2009-02-04T13:06:00.000+05:30

You must set up the various components before you can get an IDoc out of or into the system. Two types of components build and support the SAP EDI process.

1.Components specifically designed for the ALE/EDI process (for example, the port definition, partner profiles, and process codes)·

2.Flexible cross−application technologies that are deployed in the EDI process and can be adapted
across multiple applications (for example, Message control and workflow).

The Configuration Settings

The various configuration settings for the EDI process are done in the IMG and in the area menu of the EDI system.

Implementation Guide: The various EDI customization settings (see Figure 6.1) are available under the following path in the IMG: Basis Components, Basis Services, IDoc Interface/Electronic Data Interchange.

Number Ranges for IDocs :

Transaction: OYSN

Path: EDI settings in the IMG, Create number ranges Every IDoc created in the system, inbound or outbound, is assigned a 16−digit number that uniquely identifies it in the system. The IDoc number range is already defined. You normally do not have to maintain this number range, but theoretically you could exhaust the number range and then have to reset it.

Be careful when resetting the number range. Make sure that old IDocs with the number range to
which you are resetting have been archived and deleted from the system. Otherwise, the system will not be able to create IDocs in the number range that has been initialized.

Global IDoc Interface Parameters

Transaction: WE46

Path: From the Area menu of EDI, choose Control, Partner profile, IDoc administration In transaction WE46, you assign values to the global variables used in the EDI process.

The settings you need to make for the global IDoc interface parameters are explained in the following list.

IDoc Administrator : This parameter group specifies the administrator for the IDoc interface at run time. The IDoc Administrator group consists of two parameters, named Recipient Type and Identification, which identify the individual(s) who will be responsible for the integrity of the overall IDoc interface.

You must enter the recipient type (for example, US for user ID, S for position, or O for organizational unit), along with the identification value.

For example, if the position with position number 12345678 is assigned as the administrator, the value of the parameter in the Recipient Type field will be S, and the value for the Identification field will be 12345678. If a user with user ID AN000001 is the administrator, the value of the parameter in the Recipient Type field will be US, and the Identification field will be AN000001. This parameter is used by the workflow system in either of the following situations.

1.A technical error occurs in the EDI interface layer, for example, an error in deleting an IDoc file after successfully creating an IDoc.

2. An application error occurs in processing an IDoc. In this case, workflow first attempts to send a notification to the ID specified in the partner profile. If the error is such that the partner profile cannot be read, notification is sent to the IDoc administrator.

Normally, these situations should not occur because the IDoc administrator has overall responsibility for the interface and cannot handle application−specific errors.

It's better to avoid a user ID as the IDoc Administrator. You should use more abstract object types, such as position, job, or organizational unit. This approach saves you the headache of changing the entry when the user leaves the company or changes jobs. Compared to users, organizational objects such as positions, jobs, and organizational units tend to be more stable.(59.1)

EDI Basic Components Configuration II

2009-02-04T13:03:00.002+05:30

This portion of EDI basic components configuration is in continuation with previous post.

1· IDoc sys. environment:These parameters should always be checked.

2.General IDoc Interface, Max. Number of Syntax Errors: This parameter sets the maximum limit on the number of status records created for syntax errorsa good recommendation is five. If your IDoc gets more than five syntax errors in a production environment, something is terribly wrong. Setting this number higher usually does not help you debug the problem; at that point, you need to investigate the process more deeply at the source of data.

3· IDoc inbound from file, Synchronous Processing: The standard IDoc processing method is asynchronous, which usually provides higher throughput and allows decoupled parallel processing of individual IDocs. At times, such as when IDocs must be processed in sequence to prevent record−locking problems, synchronous processing can offer a possible solution.

Be careful with the Synchronous Processing parameter. It affects all inbound IDocs and can profoundly slow the throughput of IDoc processing.

4.Test tab, Parameter Setting, TestPort: You use this setting for testing purposes only. It defines the port name that will be used for assigning default parameters during inbound testing. The naming convention used for this port is SAP, where is a three−character ID assigned to your SAP instance. For example, if the System ID (SID) of your development instance is DV1, the port name will be SAPDV1. This port must be defined in the port definition.

5·The instance ID is the three−character name in the status bar that appears at the bottom portion of any SAP screen. However, if the status bar is turned off, you can also determine the instance ID by executing transaction SM51. The three characters following the first underscore under the server name are the instance ID .

Coupling IDoc Creation to IDoc Processing

Path: EDI settings in the IMG, Activate event receiver linkage for IDoc inbound

The process of creating IDocs from the input file was disconnected from the processing of the IDocs for posting for two reasons.

1· To improve the efficiency of the process of creating IDocs from a file.
2.To separate logically the process of posting an IDoc from the process of creating an IDoc, because they are two independent processes.

Anyway , the two processes have to be coupled for EDI process flow. The workflow concept of publish and subscribe, shown in Figure , accomplishes the coupling. The link is maintained via an event−linkage table.

When an IDoc is created, it raises an event, which is the publishing piece, to inform the system about the creation. The subscriber is the process that processes the IDoc. The subscriber starts automatically when the corresponding event is published. To establish the linkage, you execute the customizing step (Activate Event Receiver Linkage) in the EDI settings of the IMG or run program RSEINBEV.

For inbound IDoc processing, the event triggered is PROCESSSTATEREACHED, and the subscriber is the workflow standard task TS30200090.

LOGICAL DATA BASES

2009-01-18T14:33:00.000+05:30

In general, the system reads data that will appear in a list from the database.

You can use OPEN SQL or NATIVE SQL statements to read data from the database.

The use of a logical database provides you with an alternative to having to program database accesses individually. Logical databases retrieve data records and make them available to ABAP programs.

The same logical database can be the data source for several Quick Views, queries, and programs. In the Quick View, the LDB can be specified directly as a data source. A query works with the logical database when the functional area that generated the query is defined with a logical database. In the case of type 1 programs, the LDB is entered in the attributes or called using function module LDB_PROCESS. See appendix for information on how to use the function module.

Logical databases offer several advantages:

The system generates a selection screen. The use of selection screen versions or variants provides the required flexibility.

The user does not have to know the exact structure of the tables involved (especially the foreign key dependencies); the data is made available in the correct order at GET events.

Performance improvements within logical databases directly affect all programs linked to the logical database, without having to change the programs themselves.

Maintenance can be performed at a central location.

Authorization checks can also be performed centrally.

A logical database is an ABAP program that reads predefined data from the database and makes it available to other programs.

A hierarchical structure determines the order in which the data is supplied to the programs. A logical database also provides a selection screen that checks user entries and conducts error dialogs. These can be extended in programs.

SAP provides some 200 logical databases in Release 4.6. The names of logical databases have been extended to 20 places in Release 4.0 (namespace prefix max. 10 characters).

In the case of executable programs, you can enter a logical database in the attributes.

Use the NODES statement to specify the nodes of the logical database that You want to use in the program. NODES allocates the appropriate storage space for the node - that is, a work area or a table area depending on the node type.

The logical database makes the data records available for the corresponding GET events.
The sequence in which these events are processed is determined by the structure of the logical database.

Logical databases are made up of several sub-objects. The structure determines the hierarchy, and thus the read sequence of the data records.

Node names can contain up to 14 characters. There are four different node types.

Table (type T): The node name is the name of a transparent table (this type corresponds to the concept prior to Release 4.0A). The table name must be identical to the node name. Deep types (complex) are not allowed.

DDIC type (type S): Any node name is possible. It is assigned a structure or a table type from the Dictionary. The node name can differ from the type name. Deep structures are possible.

Type groups (type C): The node type is defined in a type group. The name of the type group must be maintained in the "Type group" field. You should generally prefer DDIC types, as the other applications that use the logical database (such as SAP Query) can access them (short texts, and so on).

Dynamic nodes (type A): These nodes do not have a fixed type; they are not classified until the program runtime. Which types are generally allowed is determined when the structure is created.

Nodes are declared using language element NODES.

Processing blocks are always allocated to an event. A processing block is closed by the next event key word, the start of form routines, or by the end of the program.

The START-OF-SELECTION event is triggered before control is given to the read routine of the logical database. The END-OF-SELECTION event is triggered after all GET events have been processed - that is, all data records have been read and processed.

The GET event is triggered whenever the logical database supplies data for this node. This means that GET events are processed several times, and that data has already been read from the database for these events. The sequence in which the GET events are processed is determined by the structure of the logical database.

The GET LATE event is triggered when all subordinate nodes of node have been processed, before the data is read for the next ; that is, whenever a hierarchy level has been completed.

At the start of the event, the system automatically adds a line feed and configures the default formats (for example, INTENSIFIED ON).

CHECK statements end the current processing block.

STOP statements end program processing. However, in contrast to the EXIT statement, the processing block END-OF-SELECTION is processed first (if it exists).

If there is a STOP statement within the END-OF-SELECTION processing block, program processing ends immediately and a list is displayed.

The EXIT statement exits the program and displays the list.

You can also use the REJECT statement. The data record is not processed further. Processing continues on the same hierarchy level when the next data record is read. REJECT, unlike the CHECK statement, can also be used within a subroutine.

Use the selection include dbsel to define selection screens for logical databases. The addition FOR NODE assigns selections to individual logical nodes. The appearance of a selection screen thus directly depends on the NODES statement contained within your program.

A field selection can be defined for the individual nodes. To do this, you have to specify the addition FIELD SELECTION FOR NODE in the SELECTION-SCREEN statement. You can then use GET FIELDS to restrict the amount of data returned.

You can designate individual nodes for dynamic selection using the addition DYNAMIC SELECTIONS FOR NODE. The Dynamic selection pushbutton then appears on your selection screen. You can determine which selection fields can be set by choosing a particular selection view yourself (type: CUS) or by using the selection view delivered by SAP (type: SAP).

With large logical databases you can define several selection screen versions. Each selection screen version contains a subset of your selection criteria (language element: EXCLUDE). Specify the name of a selection screen version in the program attributes.

When you enter a logical database in the attributes of your type 1 program, the system processes the selection screen of the logical database. The concrete characteristics of the selection screen depend upon the node specified in the NODES statement. If you specify a node of type T (table), you can also declare the table work area with the TABLES statement.

If you address only subordinate nodes (in the hierarchy) of the logical database in the program (for example sflight), the selection screen criteria for the superior node in the hierarchy (spfli) also appear. You can thus restrict the dataset to be read so that it meets your specific requirements.

Note: A logical database always reads in accordance with its structure. This means that if you only need data from a node deep in the hierarchy, you will achieve better performance by programming the access yourself. This avoids unnecessary reading of the database.

If the logical database supports dynamic selections, the pushbutton for Dynamic selections appears on the selection screen. When the user presses this button, a second selection screen is displayed.
This screen allows the user to select additional database fields. The system transfers the selections directly to the logical database program and therefore to the database (dynamic selections).

he selection view determines which fields are displayed on the selection screen. Create your own view with type CUS, and have it override the view with type SAP.

Database program sapdb for logical database is a collection of subroutines, each of which is performed for specific events. For example, subroutine is processed once at the start of the database program. This program can be used to define default values for the selection screen of the LDB.

Other subroutines also exist that are processed during events PBO (Process Before Output) and PAI (Process After Input) of the selection screen. Checks, such as authorization checks (AUTHORITY-CHECK), are usually performed during event PAI.

The database accesses (SELECT statements) are programmed in the put_ subroutines. These subroutines may be processed several times, depending on which selection criteria the user specifies. The sequence in which these subroutines are processed is determined by the structure of the logical database.

Database access (SELECT statements) should be programmed with optimal performance in mind. When creating a logical database you generate the corresponding database program after first having determined its structure and selection attributes. You can find performance tips in the comment lines.

When a program that has been assigned a logical database is started, control is initially passed to the database program of the logical database. Each event has a corresponding subroutine in the database program - for example, subroutine init for event INITIALIZATION. During the interaction between the LDB and the associated program, the subroutine is always processed first, followed by the event (if there is one in the report).

Logical database programs read data from a database according to the structure declared for the logical database. They begin with the root node and then process the individual "branches" consecutively from top to bottom.

The logical database reads the data in the put_ subroutines. During event PUT, control is passed from the database program to the GET event of the associated report.

The data is made available in the corresponding work areas in the report. The processing block defined for the GET event is performed. Control then returns to the logical database.
PUT activates the next form subroutine found in the structure. This flow is continued until the report has collected all the available data.

The depth of data read in the structure depends upon a program's GET events. A logical database reads to the lowest GET event contained within the structure attributes. Only those GET events for which processing is supposed to take place are written into the report program. Logical databases read all data records found on the direct access path.

If you specify a logical database and declare additional selections in the program attributes that refer to the fields of a node not designated for dynamic selection, you must use the CHECK statement to see if the current data record fulfills the selection criteria.

If the data record does not fulfill these selection criteria, current event block processing ends.

PROGRAMMING DATA RETRIVAL

2009-01-18T14:32:00.000+05:30

Whenever a logical database cannot supply your program with all necessary data, you must program database access directly into the program itself. This can be done using either Open SQL or Native SQL statements.

Open SQL statements offer several advantages. These include being able to program independent of your underlying database, access to a syntax check, and the use of a local SAP buffer.

Native SQL statements are bound into a program using
EXEC SQL [PERFORMING form.
.
ENDEXEC

Pay attention to the following when programming Native SQL:
Try not to use update operations (INSERT, DELETE, UPDATE)
Group EXEC SQL statements together (in an include) in order to be able to alter them centrally for different database systems
Restrict yourself to Standard SQL 

In order to optimize performance, choose your SQL statements carefully when accessing several (dependent) tables at a time.
To insure optimal database performance:

Follow these general rules:
Keep the amount of selected data as small as possible (use WHERE conditions, for
example)

Keep data transfer between the application server and the database to a minimum (use field lists, for example)

Reduce the number of database inquiries if possible (use table joins instead of nested SELECT statements, for example)

Reduce search size (this optimizes your database index)

Minimize database server load (use SAP buffers, for example).

Always subject programs containing SQL statements to an SQL trace. Which processing sequence is chosen by the Optimizer? Are indices used? If so, are the right ones used?

Is a FULL TABLE SCAN performed? Based on the results of this analysis, you should reprogram your SQL statements (WHERE) conditions, create a database index, or buffer the tables better. To start the SQL trace, use menu path GDA-1.

You can create database views in the ABAP Dictionary. Views (aggregate objects) are application specific and allow you to work with multiple database tables. The link is mapped in an INNER JOIN LOGIC (see slide on INNER JOIN).

From Release 4.0 you can buffer database views. You can then read from views using the SAP buffer on the relevant application server. The same rules apply when buffering views as when buffering tables.

Database view advantages:

Central maintenance
Accessible to all users
Only one SELECT statement is required in the program
One disadvantage of the view is its low flexibility.

In a join, the tables (base tables) are combined to form one results table. The join conditions are applied to this results table. The resulting composite for an inner join logic contains only those records for which matching records exist in each base table.

Join conditions are not limited to key fields.

If columns from two tables have the same name, then you have to ensure that the field labels are unique by prefixing the table name or a table alias.

A table join is generally the most efficient way to read from the database. The database is responsible for deciding which table is read first and which index is used (DB Optimizer).

At LEFT OUTER JOIN, results tables can also contain entries from the designated left hand table without the presence of corresponding data records (join conditions) from the table on the right. These table fields are filled by the database with null values and are then initialized according to ABAP type.

It makes sense to use a LEFT OUTER JOIN when data from the table on the left is needed for which there are no corresponding entries in the table on the right.

The following limitations apply for the Left Outer Join:

you can only have a table or a view to the right of the JOIN operator, you cannot have another join statement
Only AND can be used as a logical operator in an ON condition.
every comparison in the ON condition must contain a field from the table on the right.
if the FROM clause contains an Outer Join, then all ON conditions must contain at least one 'true' JOIN condition (a condition that contains a field from tab1 and a field from tab2).

FOR ALL ENTRIES works with a database in a quantity-oriented manner. Initially all data is collected in an internal table. Make sure that this table contains at least one entry (query sy-subrc or DESCRIBE), otherwise the subsequent transaction will be carried out without any restrictions).

SELECT...FOR ALL ENTRIES IN is treated like a SELECT statement with an external OR condition. The system only selects those table entries that meet the logical condition .
Using FOR ALL ENTRIES is recommended when data is not being read from the database, that is, it is already available in the program, for example, if the user has input the data. Otherwise a join is recommended.

The easiest technical option for reading from multiple (dependent) tables is to use nested SELECT statements. The biggest disadvantage of this method is that for every data record contained in the external loop a SELECT statement is run using the database. This leads to a considerably worse performance in client/server systems.

SAP ABAP DATA FORMATTING AND CONTROL LEVEL PROCESSING

2009-01-18T14:24:00.001+05:30

You can use control level processing to create structured lists. Control levels are determined by the contents of the fields that are to be displayed. there is a control level change whenever the content of a field changes. This means that there is no point in creating control levels unless the data are sorted.

The data to be displayed must be saved temporarily if you want to use control level processing. You can also use internal tables and intermediate datasets.

You can use an array fetch in a SELECT statement to fill an internal table in one go.

You can use the APPEND statement to insert table entries at the end of an internal table. The variant of the APPEND statement on the slide is permitted only for standard or sorted tables. After an APPEND statement, system field SY-TABIX contains the index value of the newly inserted table entry.

You use the COLLECT statement to generate unique or compressed datasets. The contents of the work area of the internal table are recorded as a new entry at the end of the table or are added to an existing entry. The latter occurs when the internal table already contains an entry with the same key field values as those currently in the work area. The numeric fields that do not belong to the key are added to the corresponding fields of the existing entry.

When the COLLECT statement is used, all the fields that are not part of the key must be numeric.

The SORT statement sorts the entries in internal table in ascending order. If the addition BY ..., is missing, then the key assigned when the table was defined is used.

If addition BY ... is used, then fields , , ... are used as sort keys. The fields can be of any type.

You can use the additions ASCENDING and DESCENDING with the SORT statement to determine whether the fields are sorted in ascending (default) or descending order.

For more information about the SORT statement, please refer to appendix documentation DAP-3.

You can use the loop statement LOOP AT ... ENDLOOP to process an internal table. The data records in the internal table are processed sequentially.

The CONTINUE statement can be used to prematurely exit the current loop pass and skip to the next pass.

The EXIT statement can be used to exit loop processing.

At the end of loop processing (after ENDLOOP), return value sy-subrc indicates whether the loop was passed or not.

SY-SUBRC = 0: The loop was passed at least once
SY-SUBRC = 4: The loop was not passed because no entry was available.

You can use special control structures for control level processing. All the structures begin with AT and end with ENDAT. These control structures can only be used within a LOOP.

The statement blocks AT FIRST and AT LAST are run exactly once: at the first AT FIRST and at the last AT LAST loop.

The statements within AT NEW ... ENDAT are executed when the value of field changes within the current LOOP (start of a control level) or the value of one of the fields in the table definition (further to the left).

The statements within AT END OF ... ENDAT are executed when the value of field changes during the next LOOP (end of a control level) or the value of one of the fields in the table definition (further to the left).

At entry of the control level (directly after AT), - all fields with the same character types after (to the right of) the current control level key are filled with "*" - all other fields after (to the right of) the current control level key are set to default values.

When a control structure is exited (at ENDAT), all fields of the query area are filled with the data from the current loop pass.

The SUM statement supplies the respective group totals in the query area of the LOOP in all fields of TYPE I, F and P.

The control level structure in internal tables is static. It corresponds exactly to the sequence of columns in the internal table (from left to right). In particular, the control level structure for internal tables is independent of the criteria used to sort the internal table. The table must be sorted according to the internal table fields.

When you implement control level processing, you must follow the sequence of individual control levels within the LOOP as illustrated in the slide. The sequence follows the sequence of fields in the internal table and is therefore also the sort sequence.

The processing block between AT FIRST and ENDAT is executed before processing of the single lines begins. The processing block AT LAST and ENDAT is executed after all single lines have been processed.

ABAP DATA BASE ACCESS FROM UNIX FILE

2009-01-18T14:23:00.001+05:30

PROGRAM TO LOAD A DATABASE TABLE FROM A UNIX FILE

report zmjud001 no standard page heading.

tables: z_mver.

parameters: test(60) lower case default '/dir/judit.txt'.
data: begin of unix_intab occurs 100,
field(53),
end of unix_intab.
data: msg(60).

***open the unix file

open dataset test for input in text mode message msg.
if sy-subrc <> 0.
write: / msg.
exit.
endif.

***load the unix file into an internal table

do.
read dataset test into unix_intab.
if sy-subrc ne 0.
exit.
else.
append unix_intab.
endif.
enddo.

close dataset test.

***to process the data. load the database table

loop at unix_intab.
z_mver-mandt = sy-mandt.
z_mver-matnr = unix_intab-field(10).
translate z_mver-matnr to upper case.
z_mver-werks = unix_intab-field+10(4).
translate z_mver-werks to upper case.
z_mver-gjahr = sy-datum(4).
z_mver-perkz = 'M'.

z_mver-mgv01 = unix_intab-field+14(13).
z_mver-mgv02 = unix_intab-field+27(13).
z_mver-mgv03 = unix_intab-field+40(13).
* to check the data on the screen (this is just for checking purpose)
write: / z_mver-mandt, z_mver-matnr, z_mver-werks, z_mver-gjahr,
z_mver-perkz, z_mver-mgv01,
z_mver-mgv02, z_mver-mgv03.

insert z_mver client specified.

*if the data already had been in table z_mver then sy-subrc will not be
*equal with zero. (this can be *interesting for you - (this list is
*not necessary but it maybe useful for you)
if sy-subrc ne 0.
write:/ z_mver-matnr, z_mver-werks.
endif.
endloop.

NOTES:

1. This solution is recommended only if the database table is NOT a standard SAP database table .
2. In the above mentioned unix file record's size is 53 bytes.
Every record in the unix file as the same size:

10 bytes for material
04 bytes for plant
13 bytes for corrected consumption for January
13 bytes for corrected consumption for February
13 bytes for corrected consumption for March
3. Table Z_MVER

This table was created to store the consumption values for first quarter of the year.
Fields Data Element
mandt mandt
matnr matnr
werks werks
gjahr gjahr
perkz perkz
mgv01 mgvbr
mgv02 mgvbr
mgv03 mgvbr