In your daily work as an SAP Transport Administrator working with ABAP systems, you might already have experienced one of the following situations during or after the import of transports into your production system:
- Important business processes were disrupted due to import errors because transported or dependent objects could not be activated correctly (return codes 8).
- Technical or functional errors occurred which were not detected immediately due to sequence errors (downgrades) of the transported objects.
- When imports happen during the uptime of the production system, the import process was disturbed by end user activities, background jobs or other day-to-day activities.
If you have encountered these issues in the past, we strongly recommend you to utilize the
proactive transport checks and integrate them into your software development/deployment process. They are included in the ST-PI software component for several years now, are free of charge, must not be configured and are ready to be used out of the box.
What checks are there?
In total there are 5 proactive transport checks available which will be explained in the upcoming paragraphs.
Cross Reference Check
The Cross Reference Check can predict return codes 8. For all objects in the selected transports the dependent objects are identified by a where-used-index. If the dependent objects are not included in the checked transports and do not exist in the target system, an error is displayed. However, if the dependent objects do exist in the target system but only in a different version, then just a warning is displayed. In addition, the last transports for the missing object versions are shown. The Cross Reference Check works for ABAP repository, data dictionary, customizing, SAP notes and BW objects. For performance reasons SAP standard objects are excluded from the analysis.
The check runs between the import target system and the closest system before (e.g., QAS<>PRD). For this check the closest system before the target system should be used as source system, because the check always compares the active object version in the system and not the historic object version in particular transport requests. In the development system there might already be newer object versions which are not relevant for the planned import.
Sequence Check
The Sequence Check identifies sequence dependencies between transports containing the same object, sub-object or customizing keys. An error is displayed when two transports with identical objects are planned to be imported in a wrong sequence or a transport is planned to be imported, but a newer transport request with identical objects has already been imported in the past. A warning is displayed when a transport is planned to be imported, but an older transport request with identical objects is not yet imported. This can cause a downgrade situation in the future, when the older transport request shall be imported. By default all transport requests that have been exported from the development system in the past 90 days are considered in the sequence check. The number of days to be considered can be extended by the parameter PERIOD in the customizing table /SDF/CMO_TR_CONF. It must be done in the system in which the report is executed.
If a correction transport is part of the import queue, then no error or warning is shown. For example, transport 1 and 2 are in the wrong sequence. But finally transport 3 is supposed to be imported with the final object version, the conflict between transport 1 and 2 is not shown.
The check runs between the development system and import target system (e.g., DEV <> PRD).
Cross Release Check
For all transported SAP standard objects in the selected transports the Cross Release Check identifies the corresponding software component and the release and support package level in the source and target system. For SAP standard objects an error is displayed when a release or support package level is different between the source and target system. For customizing entries an error is displayed when the underlying table structure is different between the source and target system. It can be used when customers are performing a release or support package upgrade and the development system is already upgraded but the production system is still on the old release or support package level.
The check runs between the development system and import target system (e.g., DEV <> PRD).
Import Time Check
The Import Time Check analyzes how long the import of the selected transports took in the reference system by summing up the import durations based on the logfiles and estimates the time it will take to import them into the target system. As a prerequisite the selected transports must already be imported into the reference system. Often transports are imported individually into the test systems and shall be imported via Import All into the production system. In that case the import time in production can be expected to be smaller than in the test system.
The check runs between the import target system and the closest system before (e.g., QAS<>PRD).
Online Import Check
The Online Import Check analyzes the transported objects and estimates whether they can be safely imported into the production system during uptime when end users are working, background jobs are running and the remaining day-to-day activities are still ongoing. Then the Online Import Check identifies the dependent objects of the transported objects and checks the usage profile of all objects. For tables the number of table accesses per hour, table changes per hour and the table size in KB is shown. For reports the number of report execution steps per hour is shown. In addition, you can maintain a list of critical objects with regard to online import in table /SDF/OI_CRITOBJ in production system. In the end, suitable timeframes are displayed with low activity in which the transported objects can be imported. This way, the import process is less likely not be disturbed by uptime activities.
As a prerequisite you should collect the table call statistics and the report execution statistics in the production system for one week as described in the attachment of note 2475591. Without this information you will only get limited results.
The check runs between the development system and production system (DEV <> PRD).
How can the checks be executed?
The proactive transport checks can be executed in the Solution Manager or in the managed systems directly by using transaction /SDF/TRCHECK or report /SDF/CMO_TR_CHECK. As a prerequisite it must be ensured that the note(s) mentioned in SAP Note 2475591 are implemented in the system in which the check should run in and the two systems which are declared as the source and target system. If the checks are executed in SAP Solution Manager, the TMW or READ standard roles should be up to date according to SAP Note 2257213.
The screen to execute the proactive transport checks looks like the following:
System Information
Depending in which system the checks are executed there is a difference which RFC connection should be used. When the checks are run in the Solution Manager, all required RFC connections to the managed systems are already in place. In a managed system on the contrary, new RFC connections must be created first or the TMSSUP RFC connection can be used. TRUSTED RFC connections can be used to avoid unnecessary logons.
Transport Details
One or more transports can then be entered. The list of transports can also be retrieved from the import queue of the target system or any system in the transport domain, including a virtual system. It is important to also specify the client and the RFC connection used must also point to this client.
Transport Checks
Finally, the transport checks themselves must be selected, meaning you must specify which checks should be performed.
Save Check Results
Optionally, you can save the check results and later access them by pressing the “History” button at the top right corner of the screen.
Example output
An example output of the Cross Reference Check looks like the following:
After executing the Cross Reference Check, a result list is displayed for the selected transports and included objects. It contains yellow (warning) and red (error) ratings depending on whether the referenced objects are not included in the selected transports or completely missing in the target system or exist in a different version in the target system. For example, the second transport Y59K903869 contains object FUGR ZONLINEIMPORT which references object TABD ZPROGRAME which is not included in the selected transports and missing in the target system. That’s why it is rated red. The solution to prevent the incoming return code 8 is to include the missing transport Y59K903745 into the transport bundle to be imported which contains object TABD ZPROGRAME.
Integration in the software deployment process
The following picture provides a good overview of how the proactive transport checks should be integrated into the transport landscape:
The proactive transport checks can also be executed with the Guided Self Service
Transport Execution Analysis for Projects (TEAP).
Conclusion
To summarize, the proactive transport checks are described again in a brief manner:
- Cross Reference Check: Predicts return codes 8 by checking if all referenced transported objects are present in the target system or in the transport bundle to be imported.
- Sequence Check: Prevents downgrades by analyzing if identical objects in the selected transports will be imported in the correct sequence.
- Cross Release Check: Indicates problematic cross release transports by comparing the release and support package level of the source and target system for SAP standard objects and customizing.
- Import Time Check: Displays the estimated import time into the target system by summing up the import time of the individual transports in the reference system.
- Online Import Check: Analyzes the transported objects and estimates whether they can be safely imported into the production system during uptime.
If you have any questions or need assistance, you can contact us.
Additional Links