Introduction
In SAP system landscape of automotive components Supplier Company where there are many Roll-out projects running across, it is required to plan development work and customizing activities in structured projects and changes can be structured independently of each other in different projects, and then import them independently into target systems. SAP recommends do this if, for example, you want to go live with different projects at different times, or if you want to link development work in a single area. In this blog, have an attempt to explain the advantage of defining and setting up Attribute of Transport request in sensitive SAP environment of an Automotive component Supplier Company.
The CTS is the central tool for managing changes to Customizing and Repository data that is incurred during project realization phase made in the IMG or ABAP Workbench. The changes in change requests can be linked together logically, or can be completely independent of each other. The activity including the configuration is purely managed by Basis folks. The change request is then used to copy the changes from this client to other clients or systems, thus to allows us develop in one environment, test development work in a test environment, and then, if the tests are successful, use it to productive system. This makes sure that productive operations are not placed at risk by faulty settings or program errors.
Editing Attributes of Transport Request
This requires the administration authorization (Basis Team) in the CTS to edit attributes.
Procedure (To edit attributes, proceed as follows)
1. Call Transaction SE03, or choose Goto → Transport Organizer tools in the Transport Organizer.
2. Choose Administration → Display/Change Request Attributes.
New attributes as per Client requirement which is intended to be created and maintained needs to begin with the letters Z or Y. If the attribute is required to be obligatory for all change requests, select Attribute obligatory for requests. This means that change requests that do not have this attribute cannot be released. If it is essential that a value is specified for the attribute, select Attribute value obligatory and this kind of requirement is very Client specific. In short this prevents unnecessary Transport request release and each transport request gets assigned to meaningful attribute i.e. Z_Change_Approval and Z_Change_Reason for Project. This exhibits better transparency and control for transport request generated due to stringent Project development objects as a part of multiple Roll-Out Projects in system Landscape.
Releasing Change Requests
Once all the task in a change request are released, then the change request itself can be released. At this point, the object list of the change request contains all objects that have been changed by the users involved. To release the change request, position the cursor on the request and choose Release Directly.
The following occurs when the change request is released:
● The current version of all objects entered in the request is stored in the version database. This means that the sequence of the change requests under which an object is edited corresponds to the various object versions archived in the database.
● If the change request contains repairs, the repair flag for these objects is reset when you release the request, as long as no sub-objects are locked in another change request. If this is the case, the object’s repair flag will be reset only when the last change request is released. After the repair flag has been reset, the objects are no longer protected from being overwritten by imports into the system.
● When you release a transportable change request, its objects are exported out of the SAP System and copied to an operating system file. The request is also marked for import into the target system.
● The objects entered in the request are unlocked. They can now be changed again.
For the system administrator:
For the export, the transport dispatcher program RDDIMPDP must be scheduled in the background in client 000. You only need to perform this scheduling once. To do this, log on as a user with administration authorization (S_CTS_ADMIN) and execute the report RDDNEWPP in the initial screen of the ABAP Editor (transaction SE38). If you export more objects at a later time, you do not need to reschedule the program unless the scheduling information was deleted manually. For more information, refer to the program documentation of the transport dispatcher program RDDIMPDP.
Once testing of the Development object is completed and approved at Quality system, run the transaction code STMS_QA where the approval for the Transport Request is updated so that it will be finally deployed to PRD system. Select the Transport request as per the sequence which needs to be moved to Production system; from the menu bar select the approval step since this is the first formal step of releasing the Transport request to Production system.
A transportable request is not automatically imported into the target system, since this could disrupt work significantly, particularly if the target system is an SAP System used for production operation. Approval Step can be updated as per the process established in the project by Basis and often; first option is preferred where the system owners do finally review before release. The import must be started by the system administrator at an appropriate point in time. The system administrator can decide whether only particular requests or all requests waiting for import should be imported into the target system. Moreover, rejection option is also available here which helps in rejecting the transport request so that it is not moved further to Production system and all the information related to attribute of Transport request, it is available in SAP table - WBOATTR.
Reference Link :-
http://wiki.scn.sap.com/wiki/display/ABAP/Transport+Dependency+Utilities
- SAP Managed Tags:
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
