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.
SAP ABAP Programming,Reports,Bdc,Scripts,erp,crm,Smart Forms,ALV,ALE,IDOC,EDI,User,Customer Exits,BADI,BAPI, FAQ'S.
Showing posts with label MODIFICATIONS USER EIXTS CUSTOMER EIXTS. Show all posts
Showing posts with label MODIFICATIONS USER EIXTS CUSTOMER EIXTS. Show all posts
Thursday, October 15, 2009
CHANGING THE SAP STANDARD
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.
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-
MODIFICATIONS OF SAP STANDARD OBJECTS
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.
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_
Wednesday, October 14, 2009
DIFFERENCE BETWEEN BADI'S AND USER EXITS
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)
Subscribe to:
Posts (Atom)