Show TOC

Function documentationDowngrade Protection Locate this document in the navigation structure

 

The downgrade protection function tracks objects in transport requests, and reports conflicts in five scenarios when an object that is saved in two or more transport requests, is released, reassigned, or imported. This applies to all managed development systems and clients for which the cross-system object lock is active, and the Change and Transport System plug-in is installed.

Note Note

Downgrade protection is available only for ABAP systems.

End of the note.

Prerequisites

  • You have configured downgrade protection and the cross-system object lock, in Customizing, under   SAP Solution Manager   Capabilities   Change Control Management   Extended Configuration   Cross-System Object Lock and Downgrade Protection  .

    Note Note

    In Customizing, you can, for example, configure the conflict criticality for each check type, and the systems that bypass downgrade protection.

    End of the note.

  • If you want to use the predecessor and the imminent checks, you have installed and configured the central Change and Transport System plug-in on the managed systems (including development, quality assurance, and production systems). For more information, see SAP Note 1688276.

  • To be able to explicitly ignore conflicts, the authorization object SM_CM_DGP has been assigned to your role.

    Note Note

    In the SAP standard delivery, the following roles contain this authorization object:

    • SAP_CM_SMAN_CHANGE_MANAGER (Change Manager)

    • SAP_CM_SMAN_OPERATOR (IT Operator)

    • SAP_CM_SMAN_ADMINISTRATOR (Administrator)

    End of the note.

    If you do not have one of these roles, the authorization object needs to be assigned to your user.

Features

  • The Downgrade Protection assignment block in the WebClient UI is available for project and maintenance cycles and for change documents. Whenever the system detects a conflict, it is displayed in the assignment block. For more information, see Using the Downgrade Protection Assignment Block.

  • There are two ways to trigger downgrade checks:

    • Manually

      You can trigger downgrade checks from the Downgrade Protection assignment block. The system analyzes potential release check conflicts for all open transport requests in the development system, and import check conflicts for all released transport requests in all systems into which they can be imported. This helps you to handle the conflicts before triggering the transport.

    • Automatically

      Downgrade checks are triggered automatically when releasing transport requests, importing, decoupling, assigning transport requests or when reassigning a change document from the WebClient UI. In case of a conflict, the operation (release/import) is canceled, unless you have ignored the conflict. You can set the system to automatically ignore conflicts in specific project and/or in logical systems. To do so, refer to the downgrade protection Customizing for more information.

  • You can also trigger a downgrade check from a task list. In case of a conflict, the system displays a dialog box notifying the user about the conflict and the cancelation of the operation. A link to the change cycle document in the WebClient UI, where the conflicts can be checked and handled, is provided.

Note Note

The manual check checks all open transport requests (release check) and all importable transport requests (import check), including all corresponding target systems. The automatic check checks only the transport requests to be released or imported, and only the relevant target systems, so the automatic check checks a smaller number of transport requests.

End of the note.
Downgrade Check Types

The following downgrade checks can be performed by the system:

  • Cross-system object lock

    The cross-system object lock (CSOL) ensures that when an object is changed in a managed system, it is locked in the central SAP Solution Manager system. Depending on the conflict scenario, this prevents changes being made to this object in any other transport request. For more information, see Cross-System Object Lock.

  • Release check

    When you release a transport request, downgrade protection can detect conflicts for objects in transport requests. The conflicts are the same as those displayed by the cross-system object lock when saving the objects to the transport requests.

    Reason: If the transport request released first is imported second, the conflict object is downgraded.

    When the system finds conflicts, the release is canceled and they are logged. The conflict check results are displayed in the Downgrade Protection assignment block. If you want to ignore the conflicts, check the results on the assignment block and ignore them. You can then start the release again.

    Example Example

    1. You modify a function module, Z_TEST_FUNC1, and save it in transport request DEVK000001 in normal change NC1.

    2. You release DEVK000001 without noticing any conflicts.

    3. You modify the function module again and save it to another transport request DEVK000002 in normal change NC2, bypassing the CSOL warning in the managed system.

    4. When you try to release DEVK000002, a conflict message is shown and the release is canceled. The Downgrade Protection assignment block displays the conflicts.

    5. To continue to release, the change manager must ignore those conflicts. Alternatively, you can import DEVK000001 into the production system by importing it into the quality assurance system through a project import, and then import it into the production system through a project import. DEVK000002 can then be released without conflicts.

    End of the example.

  • Reassign check

    The system performs this check when you reassign a change document or assign or decouple transport requests in a change document. It displays potential conflicts of the transport requests involved. You can choose to cancel or continue. If you continue, the operation continues and the ignoring of the conflicts is logged.

    Reason: A reassignment might change the order of release and import, as the transport requests would belong to a different project. This kind of conflict may lead to a downgrade. You can reconsider whether the reassignment, decoupling or assignment is appropriate.

    Example Example

    1. You modify a function module, Z_TEST_FUNC1, and save it to a transport request DEVK000001. You release the transport request.

    2. You modify the function module again and save it to transport request DEVK000002, bypassing the CSOL warning. DEVK000001 belongs to normal change NC1, while DEVK000002 belongs to normal change NC2. When you try to reassign the normal change NC2 to another project, potential conflicts with NC1 are detected and displayed in simulation mode in a dialog window. The system shows what would actually happen during reassignment. If you ignore the conflicts, NC2 will be reassigned.

    End of the example.

    Example Example

    You already have two conflicting transport requests, DEVK000001 and DEVK000002, in normal changes NC1 and NC2. When you decouple DEVK000002 from NC2, a conflict popup shows the existing conflicts on DEVK000002, and you can continue only if you ignore the conflicts.

    End of the example.

    Example Example

    DEVK000002 was previously decoupled, and has conflicts with DEVK000001 in normal change NC1. When you try to assign DEVK000002 to normal change NC2, conflicts are detected and displayed in simulation mode in a dialog window. The system shows what would actually happen if DEVK000002 were assigned to the normal change.

    End of the example.

  • Predecessor check

    The system can detect conflicting predecessors, that is, preceding transport requests containing conflicts, at the time of importing transport requests or transports of copies to the production or quality assurance system.

    Reason: If the transport request was imported before the predecessor, the predecessor would introduce downgrades when it is imported.

    If such a conflict is detected and the check result is not ignored, the import is canceled and logged. You can also ignore the conflicts on the Downgrade Protection assignment block and restart the import. Instead of ignoring the conflicts, you could import the older transport request first, and then the newer one.

    Example Example

    1. You modify a Customizing entry, Z_CUST1/Key1, and save it in transport request DEVK000001, which is then released.

    2. You modify the entry again, save it to transport request DEVK000002, and then release it, ignoring all conflicts found by downgrade protection. DEVK000001 and DEVK000002 belong to urgent changes UC1 and UC2.

    3. You try to import UC2 into the quality assurance system, where conflicts are detected and the import is canceled. The conflict type is Overtaker warning, which means that there is a predecessor, DEVK000001, which was released earlier, so there is an older version which has not yet been imported and has conflicts with the objects transported in the current request.

    End of the example.

    Note Note

    Import checks depend on the transport requests being imported. Any conflicts found while importing a project or urgent change task list, are displayed in the Downgrade Protection assignment block of the change cycle document. Any conflicts found while importing a change document are displayed in the same assignment block of the change document.

    End of the note.

  • Imminent check

    The system can detect impending (imminent) downgrade conflicts when transport requests are imported. This kind of conflict would become an actual downgrade if you ignore the conflict. The system displays the check result on the Downgrade Protection assignment block. If the check result is not ignored, the system cancels the import and logs it.

    Example Example

    1. Following the example in predecessor check, you ignore the overtaker warning and import DEVK000002 into the quality assurance system.

    2. You try to import UC1 into the quality assurance system. Conflicts are detected and the import is canceled, as this is an imminent downgrade. Reason: Transport request DEVK0000002 modifies the same objects as DEVK0000001 with a newer version, and has already been imported.

    3. You can ignore the conflicts and continue the import. To make the version correct, import the project into the quality assurance system as soon as possible, so that later project imports into the production system will not cause downgrades.

    End of the example.

    Note Note

    You should not ignore the imminent downgrade conflicts on the Downgrade Protection assignment block and restart the import. Import the transport requests in the correct order, including the newer request and its predecessor (if the newer request is in the project import).

    End of the note.

Activities

The following graphic shows the user and system activities during the downgrade protection process.

This graphic is explained in the accompanying text.

Downgrade Protection Process