Transport Checks

Prerequisites for Import Checks

• You've installed at least ST-PI 740 SP 27 and implemented the latest versions of SAP Notes 3497169 and 3497168 .

• You've set up transport checks on your managed system. See Setting up Transport Checks for Import Checks on how to do the setup.

• Depending on your ST-PI level, you have to implement specific SAP Notes. See SAP Note 2475591 for the required SAP Notes.

• Your source system and target system reside on different physical systems.

• In the production system for client 000, you've activated use case task Transports: Check. For more information, see Activating the Use Case Transports.

• At least one CTS-managed transport is assigned to your feature.

• Your transports are in the import queue of your production system, or are already deployed to production.

Import Checks

Import checks include Downgrade Protection and a Cross-Reference Check. You can choose to perform an individual check or both. When you perform import checks, all production systems of all CTS-managed transports of your feature are checked.

Both checks identify conflicts with other transport requests by using the RFC connection you created in the production system that targets your development system. As a result, this checks all transports that are in the production system import buffer. This means that unassigned transports or transports assigned to another feature can also be conflicting entities.

You can start import checks in the detail view of your feature in the Features app. After a check has been successful and shows a warning or error, you can select a check result to navigate to the Transport Checks app. The Transport Checks app provides more details about the checks and shows you what to do in case of critical results.

For more information about transport checks, see also SAP Note 2475591 and 2964512 .

Downgrade Protection

The Downgrade Protection check helps you to deploy transport requests in correct sequence. The check shows your checked transports of the feature and if there are any conflicting transports.

This check identifies conflicts with other transport requests by using the RFC connection you created in the production system that targets your development system. Conflicts can happen between the transports of the planned import bundle, if they are arranged in a wrong sequence. Or objects, which have been imported into the target system before, can be downgraded to an older version.

By default, only transports which have been released in the last 180 days are considered as potential conflicts, due to performance reasons. However, in table /SDF/CMO_TR_CONF you can set the parameter "Number of days in analysis period" to a higher value. This parameter must be set in the production system for client 000 where the check is performed.

Conflicting transports can cause the following downgrades:

Potential Downgrade

This animation illustrates what a Potential Downgrade is:

You have a released transport with an older version and a released transport with a newer version. If you deploy the released transport with the newer version first, a potential downgrade occurs. This means that when you later deploy the transport with the older version, it overwrites the newer version.

To avoid this, always deploy the feature of the released transport with the older version first.

Imminent Downgrade

This animation illustrates what an Imminent Downgrade is:

You have a released transport with an older version and a released transport with a newer version. If you’ve already deployed the transport with the newer version and then deploy the transport with the older version on top, an imminent downgrade occurs.

To avoid this, always deploy the feature of the released transport with the older version first.

Intrinsic Downgrade

This animation illustrates what an Intrinsic Downgrade is:

You have a released transport with an older version and a released transport with a newer version. If you deploy both transports together, but deploy the transport with the newer version into the production system first, it creates an incorrect sequence. This causes an intrinsic downgrade.

To avoid this, check the content of the transport with the older version and decide if you can omit it.

If you can omit it, unassign the transport with the older version from the feature.

If you can’t omit it, create a new transport request containing the latest version of all objects in both transport requests.

This video shows you how to use the Downgrade Protection for customizing requests:

Open this video in a new window

Prerequisites for Export Checks

• You've installed ST-PI 740 SP 31 or ST-PI 740 SP 30 with SAP Note 3569187 and 3569295 . For ST-PI 740 SP 31 you've also installed SAP Note 3621761 .

• Your SAP_BASIS version is at least 740 SP13.

• You've configured the ABAP Test Cockpit (ATC). For more information, see Quality Checking with the ABAP Test Cockpit (ATC).

• In your development system, you've activated use case task Transports: Export Checks (client-specific) on all clients on which you want to perform an export check. For more information, see Activating the Use Case Transports.

• You've set the Behavior on Release of the Code Inspector to Disable "Code Inspector" as test driver. To change the setting, run transaction ATC, then select Basic Settings. In the Code Inspector section, you see the current setting.

• In the Basic Settings of ATC, Block for Findings and Inform for Findings aren't set to Never.

• In the Basis Settings of ATC, Restrict Findings to Objects on Transports isn't activated.

• Currently, you also have to select Workbench Request for object checks at release of Task. You can set this in the Global Customizing with transaction SE03.

• At least one CTS-managed workbench transport in status Modifiable is assigned to your feature. Customizing transports aren't supported.

• You have the Project Admin, Project Lead, Project Member, or Developer role.

Export Checks

The export checks are the ABAP Test Cockpit (ATC) check. As a developer, you can use the ATC check to check your CTS transports in status Modifiable before releasing them from source systems. This ensures that there are no critical errors in your code and that you comply with the standards of the testing process.

The ATC check scope is based on the Global Check Variant of the Code Inspector. By default, the check variant is set to DEFAULT. You can change the check variant in the Basic Settings with transaction ATC:

In Global Customizing, you can set whether the ATC check should be performed at Task or Workbench Request release.

To change the Global Customizing, run transaction SE03 and select Global Customizing (Transport Organizer):

We recommend to set the object checks at release of Task. With this, developers already know in the managed system if the ATC check detected an error.

You can also set the object checks at release of Workbench Request. With this, the ATC check is triggered through transport release from the Features app. Then, check results aren't directly send to the Features app. This means, if the ATC check detects an error which is blocking the release, the transport shows release failed in the Features app. In this case, you have to perform the ATC check directly in the Features app to get more details on how to solve the error.

In the Features app you start an ATC check in the detail view of your feature:

When you perform an ATC check, all workbench transports in status Modifiable are considered and grouped by source system.

After a check has been successful and shows a warning or error, you can select a check result to navigate to the Transport Checks app. The Transport Checks app provides more details about the check and shows you what to do in case of critical results.

For more information about ATC Checks in general, see ATC Concepts.