In system landscapes in which several releases are processed at the same time, similar changes can be made in different development systems. For example, new developments can be made in the new implementation development system, and errors to be corrected or improvements to be made in a maintenance system for the production system landscape at the same time. The system release levels must be adjusted regularly to ensure that changes are synchronized in parallel across different system landscapes. This synchronization is called retrofitting.
A Phased System Landscape as an Example of System Relationships
For information on what you have to do before you can use the retrofit functions, see Prerequisites for Using the Retrofit Function.
The following retrofit processes are available:
Process | Object Types Supported | Can Be Used For |
---|---|---|
Automatic import | All object types Note BW objects are partially supported. End of the note. |
|
Using the correction workbench and Business Configuration sets as postprocessing tools |
|
|
Manual retrofit | Objects that cannot be imported automatically and that are not supported by the postprocessing tools | All other objects |
Note
In Customizing, you can define object types for specific scenarios (retrofit scenario for Business Warehouse objects, retrofit scenario for manual processing). Objects of these object types are always retrofitted manually.
You can perform retrofits for systems that are on different support package, enhancement package, or release levels (cross-release retrofit). The system performs the following checks to ensure that no downgrade occurs:
Check for Customizing objects: If table structures, views, or view structures have changed, the object is set to “manual retrofit”.
Check for Workbench objects: SAP objects are set to manual retrofit.
Check for SAP Notes. They can not be retrofitted.
You can use the following functions to prepare the retrofit:
Retrofit status display for transport requests and objects
Object list of the transport request
Shows the objects included in the transport request that you want to retrofit, including the object types
Information on the sequence dependency
Indicates whether a transport request is dependent on another transport request.
Example
Transport request A contains object X, which is already in transport request B. This means there is a sequence dependency between transport requests A and B.
The sequence dependency implies the following:
A transport request can have a sequence dependency to more than one other transport request, that is, different objects are in different transport requests.
There is just one sequence dependency for an object X between transport request A and transport request B if transport request B is the only request with object X or is the request that was last released. There can also be a sequence dependency between transport request B and a third transport request.
The sequence dependency is based on the objects in the object list for the entire retrofit queue. It is updated or deleted as soon as the retrofit for a transport request is completed.
If there is no sequence dependency, and some requests have not yet been processed, the system displays a message. You can specify in the Customizing settings whether the message is to be displayed as a warning or as an error.
Consistency check
The system checks whether the retrofit was prepared correctly:
Have transport requests been created in the retrofit system into which you want to import the changes from the maintenance system?
Has the execution sequence of the transport requests to be imported been observed?
Does the transport request contain objects from SAP Notes that could cause conflicts during the import?
Display of various logs with messages for the transport requests
Display and processing of BC Sets for transport requests that contain Customizing objects
Navigation to the TMS Alert Viewer
For more information, see Displaying the TMS Alert Viewer.
You can use the retrofit functions without using the Change Control Management scenarios (Change Request Management or Quality Gate Management). This approach includes all standard retrofit functions as described above, however, you handle the retrofit functions via the task list. You can use this approach and start using Change Control Management later on.
You start the retrofit from your change document.
You check the status of each transport request and the objects in the requests.
You perform the retrofit for your transport requests.
Note
This process is relevant for Change Request Management only.
Register all transport requests you want to use in the SAP Solution Manager system for the implementation landscape by performing the Prepare Implementation Landscape for Retrofit
activity in SAP Solution Manager Configuration (transaction SOLMAN_SETUP) .
Register all objects from these transport requests in the central cross-system object lock tables (for customizing and workbench objects) by performing the Prepare Implementation Landscape for Retrofit
activity in SAP Solution Manager Configuration (transaction SOLMAN_SETUP) .
Register all transport requests you want to use in the central SAP Solution Manager system for the maintenance landscape by performing the Prepare Maintenance Landscape for Retrofit
activity in SAP Solution Manager Configuration (transaction SOLMAN_SETUP) .
Create and release transport requests in the task list in the Administration Cockpit.
Create the target transport request directly in the relevant system, for example, in the implementation system.
The system creates the data for the retrofit process.
Start the retrofit by executing the relevant task in the cycle that was created for the maintenance landscape.