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_
0 comments:
Post a Comment