7.2: How to work with Change Request Management Downgrade Protection - DGP

Purpose

With the following steps, you will be able to setup Downgrade Protection DGP functionality for Change Request Management in SAP Solution Manager 7.2.

The main documentation for this functionality can be found in the SAP Help: Downgrade Protection and in the solman_setup related activities for CSOL and DGP.

I will try to add additional information and tips and tricks for the configuration of this functionality and for troubleshooting possible issues using this functionality.

The screenshots provided in this wiki are taken from a SAP Solution Manager 7.2 SP07.

*MANDATORY NOTE* 2912696 - DGP: intrinsic check reporting wrong conflicts

Overview

Software changes are done in one system and will be transported to the system landscape which is linked to this system by transport routes of the Transport Management System. But sometimes there are several developers that required making parallel changes to the same workbench or customizing objects within one landscape.

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, assigned, or imported. This applies to all managed development systems and clients for which the cross-system object lock (CSOL) is active, and the central Change and Transport System (cCTS) plug-in is installed in the Solution Manager system has also been distributed to the managed systems (including development, quality assurance, and production systems).

Note: DGP calculation cross source systems is not supported.

The following downgrade protection checks can be performed by the SAP Solution Manager system:

Cross System Object lock – Check 1

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.

Release check (based on CSOL) – Check 2

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.

Predecessor check (based on cCTS)- Check 4

The system can detect conflicting predecessors, that is, preceding transport requests containing conflicts, at the time of importing transport requests or transport of copies to the production or quality assurance system.
Given a set of transport requests for import in a system, check for transport requests not imported in the system (or preceding systems) that have an object overlap and contain an older version of the object.

Imminent check (based on cCTS) – Check 5

The system can detect impending (imminent) downgrade conflicts when transport requests are imported.

Given a set of transport requests for import in a system, check for transport requests already imported in the system that have an object overlap and contain a newer version of the object.

Reassign check (based on CSOL)- Check 3

The system performs this check when you reassign a change document or assign or decouple transport requests in a change document.

1. Prerequisites

In order to use these five downgrade protection checks you should:

Configure the Cross System Object Lock CSOL scenario globally, and locally in the development system.

Check about this scenario in wiki page 7.2: How to work with Change Request Management Cross System Object Lock CSOL.

The SAP Solution Manager system has an up-to-date CTS plug-in version installed, check SAP Note 1665940 Installing/Updating SAP CTS Plug-In 2.0.

In SAP Note 2231041 you can read:

“We recommend that you always use the latest CTS plug-in support package available on SAP Support Portal”

SAP Solution Manager 7.2 SP7 is coming with CTS_PLUG 200 0023 SAPK-20023INCTSPLUG.

The last available patch level on Sept 2018 is SAPK-20024INCTSPLUG.

Distribute the service plugins using SZENPLUGIN (for downgrade protection without a central CTS).

The import check logic depends on the central CTS import check logic for downgrade protection, which is a part of the CTS plug-in.

Transport tools (tp, R3trans) in the SAP Solution Manager system must be up-to-date.

Authorization object SM_CM_DGPN has been assigned to your role so that you can explicitly ignore conflicts.

Note: It is not necessary to use a cCTS enabled cycle to use DGP functionality; you can use DGP regardless of whether you use a cCTS enabled cycle or not.

Before making the DGP check, SAP Solution Manager system will firstly get the cCTS plug-in version on the corresponding target system. In case there is any problem like CTS plug-in was not installed on a managed system, an error will be raise and no transport import can be performed as long as DGP is active.

With the implementation of SAP Note 2555809 "Report CTS plug-in client checks as warning for CTS plug-in outdated in managed systems" the behavior varies depending on whether the CTS plug-in is not yet installed or the plug-in on the systems is out of date. If the plug-in on a system is out of date, you can still perform operations that use central CTS or downgrade protection.

So please ensure in /nszenplugin, Change and Transport System - Plug-in Management, that the SAP Solution Manager system and Managed systems are up-to-date and consistent.

Validation should be correct for the SAP Solution Manager system, see an example below:

And for each of the managed systems used in the ChaRM cycle, see example below:

All transport related actions (create, release, import) must be executed from SAP Solution Manager side only. Otherwise there could be data inconsistency for the object tracking in cCTS side regarding your transport requests.

2. Activation

Before using DGP functionality, it must be activated.

Since Solman 7.2 SP07 the CSOL and DGP settings are moved to the Administration Cockpit, tab: Cross-System Object Lock and Downgrade Protection:

Before this patch you need to perform these settings in /n/TMWFLOW/CONFIG_LOCK or in /nspro: SAP Solution Manager-> Capabilities -> Change Control Management -> Extended Configuration -> Cross-System Object Lock and Downgrade Protection.

Here you will see that you need to activate CSOL globally to be able to select Enable Downgrade Protection later.This means that CSOL activation is a prerequisite to use DGP.

Note: When DGP is active put CSOL to “Warning Only” to make sure the conflict resolution can be postponed to the latest point in time (when importing).

3. Configuration

3.1. Downgrade Check Type

Here you can customize the mapping between checks types and Check type icon:

SAP standard and default conflict type and icon customizing delivery is:

Release Check/Reassign Check (check 2 and check 3 – if user continues, he might create a downgrade situation)
Predecessor Check (check 4 – if user continues, he might run into a downgrade issue later)
Imminent Check (check 5 – if user continues, he will commit a downgrade)

Note: Don’t touch these settings as the initial setup follows best practice.

3.2. Downgrade System Configuration

Generally when meeting conflicts during an action, the action would be terminated, and user would be asked to ignore the conflicts first before proceeding with the action again.

Here you can customize the exception list. Configure for which landscape, branch, cycle type, which system, system role, check type with Check Mode you need:

•You can use wildcards (*) for the System, Client, Landscape, and Branch fields so that the settings apply to all systems, clients, landscapes, and branches.

•If there is more than one matching record in the configuration for a particular cycle, system, role, and conflict type combination, the record with the first non-wildcard (specific) field value reading the table from the left will be applied.

Check Mode:

• Warning mode: A DGP conflict popup appears if conflict is found so that user can choose to:

a) Ignore and go on or to

b) Cancel the operation.

• Stop Mode: For release/import: the operation will always be stopped if any conflict is found; user has to ignore the conflict manually in the DGP tab of Transport-Related Checks assignment block.

Note: IT Operation/Change Manager/Administrator have the authorization to ignore the conflict manually in the DGP tab of Transport Related Checks assignment block; then user can trigger the transport operation again.

For decouple/assign/reassign, or selective import: a DGP conflict popup appears if conflict is found so that user can choose to a) ignore and go on or b) cancel the operation.

Note: Only Administrator has the authorization to ignore the conflict in stop mode.

• Silent Mode: The operation will always automatically continue without any need for user interaction; DGP conflicts will be logged instead. If user performs manual check, the records should be displayed with status open, while a message should be available to inform user that Silent Mode is on, and conflicts can be automatically ignored if user proceeds with further actions.

• Off Mode: No DGP check will be performed at all.

Examples from the solman_setup documentation::

Example 1:

•Landscape: SLAN

•Branch: *

•Cycle Type: All

•System Name: AB1

•System Type: AS ABAP

•Client: 200

•Role: T

•Check Type: Imminent Check

•Check Mode: Silent

The downgrade protection function allows an import to system AB1, client 200 if the check type is Imminent Check and the system role is T (by default, the quality assurance system). This applies to all branches (*). If a row contains a landscape and branch, the record is effective only for that solution.

To switch off downgrade protection for a particular system or branch, specify the system or branch in the relevant columns. Enter an asterisk in other key fields (up to Check Type column). Then, select Any Check Type in the Check Type column, and select Off as check mode.

Example 2 of switched-off downgrade protection for the Predecessor Check for branch DEVELOPMENT of landscape LS_1:

•Landscape: LS_1

•Branch: DEVELOPMENT

•Cycle Type: All Types of Cycle (equivalent to “*”)

•System Name: *

•System Type: *

•Client: *

•Role: *

•Check Type: Predecessor Check

•Check Mode: Off

Example 3 of switched-off downgrade protection for the Release Check for system DV1:

•Landscape: *

•Branch: *

•Cycle Type: All Types of Cycle (equivalent to “*”)

•System Name: DV1

•System Type: *

•Client: *

•Role: *

•Check Type: Release Check

•Check Mode: Off

Please see the Conditions for Ignoring Conflicts matrixes to know per each check mode selected who can ignore the conflict and from where.

Point 2 refers to the case that there are not entries in the exception list:

Check Mode:

Warming mode: refers to check 2 Release check and check 3 Reassign check
Stop mode: refers to check 4 Predecessor check and check 5 Imminent check

Ignoring Conflict in DGP (or Transport-Related Checks) Popup means to ignore the conflict from the popup that appears when the release or import action is being triggered from a change document PPF action or from the task list action.

Popup name is: Result from Transport-Related Checks

Selective import refers to the import option used from the task list, sm34 /TMWFLOW/VC_IMPS settings for the data used for this cycle task list and for the system:client where the import is going to be triggered from the task list.

Ignoring Conflict in DGP AB (or Transport- Related Checks AB) means to ignore the conflict in the change document Transport-Related AB, Downgrade protection tab before the release or import action is being triggered:

Note:

Point 4 refers to the case that there are systems that are set to explicitly use the WARNING check mode in the table above:

Point 5 refers to the case that there are systems that are set to explicitly use the STOP check mode in the table above:

Stop mode for an import action means that the user must talk to the ITO, CM or ADM to ignore the conflict in transport-related checks assignment block.

Stop mode means there is something really downgrading happening. This is not a small risk action and must be taken very carefully. It is not appropriate to allow normal user to ignore it in the import popup because the system might be damaged badly.

Note: In se16: /TMWFLOW/DGP_EXC you can decide if you want to deactivate DGP manual check for specific transactions types.

4. Operation

4.1. Typical user case of DGP

Cross System Object Lock check

As soon as a developer modifies an object in the development system and saves it into a transport request created/managed by ChaRM, some lock entries are created in the central SAP Solution Manager system containing the objects information in that request for all production systems which it will be delivered to. As an example, this would be developer 1, TR1 and change document 1.

When somebody, say developer 2, tries to modify the same object for another time, the system will issue a popup to remind the user that this object is already locked in another transport request TR1, this would be TR2 created from change document 2. This would be the first DGP check – Cross system object lock.

Release check

If a user goes to change document 2 and try to release TR2 the system check if there are lock entries in se16 /TMWFLOW/LOCKPCN and/or /TMWFLOW/LOCKPRN for other transport requests containing the same objects included in TR2 with the same production system as target. If yes, user will get a message in the change document saying that the release of TR2 is not possible due to open conflicts. This would be the second DGP check – Release check.

Remember that these entries in /n/tmwflow/lo* tables are there until the transport request is successfully imported to the production systems and the transport request no longer exists in the import buffer of the production system. If the import is failed and you have corrected it manually, in CSOL we will treat it the same as successfully imported request.

It does not matter if the initial TR1 is already released or not, its purpose is to warn the user that changes done before to those objects are still on the way to production.

User needs to go to the Transport-Related Checks assignment block – Downgrade Protection tab to check the Release check conflict.

Depending on the Downgrade Protection system configuration settings developer will be able to ignore the conflict at release in the Transport-Related Check popup that appears when executing the PPF action that triggers the transport request ( for an urgent change PPF action Pass Urgent Change to Test ZMHF_TO_BE_TESTED) or the transport of copies release ( for an normal change PPF action Pass Normal Change to Test ZMMJ_TO_BE_TESTED_MJ) , then the release of TR2/TOC2 can be done.

Note: For an urgent change in status “In development” when executing the action Pass Urgent Change to Test ZMHF_TO_BE_TESTED the release and import of the associated transport requests is triggered, this means that two conflicts needs to be ignored. Initially only one conflict will be shown in the Transport-Related Checks assignment block of the document – Downgrade Protection tab, the conflict at release.

When executing the action run action Pass Urgent Change to Test ZMHF_TO_BE_TESTED the first time the developer will need to ignore this conflict at release in the Transport-Related check popup. However, the change document status switches will fail due to a new conflict, this time for the conflict at import:

The conflict at import needs to be ignored by IT Operator, Change manager or Admisnitrator from the Transport-Related Checks AB of the change document. After this the developer needs to trigger action Pass Normal Change to Test ZMMJ_TO_BE_TESTED a second time to get the urgent change in status “To be tested”.

Note: For a normal change in status “In development” if the SOCM action COPY_ALL_ENH is in used in sm34 AIC_SETTINGS, the PPF action Pass Normal Change to Test ZMMJ_TO_BE_TESTED_MJ will trigger the create and release of a TOC and also the import of the TOC into the first target system.

So, again two different conflicts need to be ignored from the Result from Transport-Related Checks popup, one for the TOC release and a second one for the import of the TOC. Action Pass Normal Change to Test ZMMJ_TO_BE_TESTED needs to be executed two times.

When running the first time action Pass Normal Change to Test ZMMJ_TO_BE_TESTED the first conflict shown in the Result from Transport-Related Checks popup can be ignored by the developer.

Then the change document status switches will fail due to a new conflict at TOC import. Only the IT Operator, Change manager, or Administrator can ignore the conflict from the Transport-Related Checks AB of the change document. After this the developer needs to trigger action Pass Normal Change to Test ZMMJ_TO_BE_TESTED a second time to get the normal change in status “To be tested”.

Due to the DGP popup framework it is not possible to raise popup twice during on a PPF action.

Import check- Predecessor check

If a user goes to change document 2 and trigger the import of TR2 into a target system like the quality system (for an urgent change or a normal change using the preliminary import), the system will check if there are other released transport requests in the import buffer of the quality system that contains the same objects, like TR1, and these objects has an older version that the one coming for objects in TR2.

The object version is based on release timestamp.

Note: the system will check the import buffer, here we will have the transport request not yet imported and also the ones flagged for re-import. Transport request TR2 could be also a Transport of copies.

If this is the case user will get a message in the change document saying that the import of TR2 is not possible due to open conflicts with TR1. This would be the fourth DGP check – Predecessor check.

User needs to go to Transport-Related Checks assignment block – Downgrade Protection tab to check and ignore the Predecessor check conflict. Then the import of TR2 can be done.

Its purpose is to warn the user that he is importing an object version newer that another object version that is still in a TR in the import buffer of target system.

Note: For a normal change using preliminary import remember that you can ignore the conflict at import from the normal change however when you trigger the import for the same system:client from the task list you will get a DGP conflict reported on Cycle level. Preliminary imports are subset imports therefore they are not affected by the conflict in Change Cycle document.

Import check- Imminent check

If a user goes now to change document 1 and trigger the import of TR1 into the quality system, the system will check that the version of the objects in TR1 is older than the version already in the system where the TR1 is going to be imported.

If this is the case user will get a message in the change document saying that the import of TR1 is not possible due to open conflicts with TR2. This would be the fifth DGP check – Imminent check.

User needs to go to Transport-Related Checks assignment block – Downgrade Protection tab to check and ignore the Imminent check conflict. Then the import of TR1 can be done.

Its purpose is to warn the user that he is importing an object version older than the system object version that is already imported in the target system. If the TR is imported, it would cause a downgrade.

Reassign check

When reassigning a change document to another cycle or assigning/decoupling a transport request in a change document or task list, the conflict calculation is performed in simulation mode, as if the operation (reassignment or assignment) is already performed; its purpose is to warn the user of potential conflicts after the operation is performed. This would be the third DGP check – Reassign check.

When decoupling a TR, the conflict calculation is the same as in release check; its purpose is to warn the user of the current conflicts, which would become uncontrolled after decoupling.

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

A popup is shown in such conflicts, and all conflicts in the popup can only be ignored at once (no individual ignore); the action of ignoring will be logged.

4.2. Ways to trigger downgrade protection checks

Manually

In Change Request Management, you can trigger downgrade checks from the Transport-Related Checks assignment block by clicking on Perform check. 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 actions.

Results are displayed in the Downgrade Protection tab of this assignment block.

Transport-Related Checks are performed asynchronously, so that the UI is not blocked during the check; refresh the assignment block to get up-to-date check results.

Details:

Automatically

Downgrade checks are triggered automatically when releasing transport requests, importing, decoupling, assigning transport requests or when reassigning a change document. In case of a conflict, the operation (release or import) is canceled, unless you have ignored the conflict.

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: The manual check analyzes 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.

Import checks depend on the transport requests being imported. Any conflicts found while importing a change cycle 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.

The check for potential downgrades is carried out both when you perform a preliminary import of a change (normal change or urgent change) and when you import via the task list for the change cycle. The duplicate check ensures that potential downgrades are identified even if changes belong to the same change cycle. If you plan to ignore the conflicts, pay attention to the type of import operation you are performing. If you perform a preliminary import, the system prompts you to ignore the conflicts at change level. When you later import the changes at cycle level, the system prompts you to ignore the changes again, but this time at cycle level. If you import changes only at cycle level, you have to ignore only the cycle-level conflicts.

4.3. Ignoring a conflict

Conflicts can be manually ignored in the Transport-Related Checks assignment block – Downgrade Protection tab, or in the DGP Popup, or can be automatically ignored via DGP System Configuration customizing.

When a conflict is manually ignored, the conflict will no longer participate in blocking the release/import operation, but as long as the operation is not yet carried out, the conflict is still active, so we can see it in the Downgrade Protection assignment block.

Information about automatic ignore is not displayed on the DGP assignment block, but it will take effect during release/import.

4.4. Cycle level and change level conflicts

Any conflicts found while importing a change cycle 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 documents, so:

a. When conflicts are found during a cycle level import (triggered by 'Import Transport Requests' (Background) task in the cycle task list), the conflicts will be displayed in the cycle document Transport-Related Checks-Downgrade protection assignment block, you should go there to ignore them, instead of going to the change document.

b. When conflicts are found during a change level import for a change document (Normal Change preliminary import or Urgent Change import), the conflicts are displayed in the change document Transport-Related Checks-Downgrade protection assignment block.

The check for potential downgrades is carried out both when you perform a preliminary import of a change (normal change or urgent change) and when you import via the task list for the change cycle. The duplicate check ensures that potential downgrades are identified even if changes belong to the same change cycle. If you plan to ignore the conflicts, pay attention to the type of import operation you are performing. If you perform a preliminary import, the system prompts you to ignore the conflicts at change level. When you later import the changes at cycle level, the system prompts you to ignore the changes again, but this time at cycle level. If you import changes only at cycle level, you have to ignore only the cycle-level conflicts.

Note: DGP conflicts are not appearing in a Defect Correction document assignment block even though it's assigned Transport Request has open conflicts in another Change Document.

Defect Corrections can only be imported via Change Cycle task list. Therefore, the DGP check for Change Cycle task list should always be checked in the Cycle document and not the Defect Correction document.

4.5. Archived conflict

If conflicts were detected before an attempt to release/import, when the release/import is actually carried out (after ignoring the conflicts), the conflict information is archived.

Archived conflicts can be displayed by using Show Conflict History button in the Transport-Related Checks assignment block, Downgrade Protection tab:

This information is helpful in investigating DGP issues.

4.6. Import Groups in Downgrade Protection

An import group comprises transport requests that are imported into the same production system in the sequence in which they were released. If the same object is changed in different transport requests, but the transport requests belong to the same import group, the system does not detect a conflict because there is no risk of a potential downgrade.

Import groups are used by the following downgrade protection checks when dealing with conflicts:

•Cross-system object lock

•Release check

•Reassign check

See more information in the application help Import Groups in Downgrade Protection.

4.7. DGP and Release cycles

A release cycle has the property of a version number, such as a cycle for major release 1 and a cycle for minor release 1.1. There is order requirement between their go live dates, so that the versions are released in ascending order. With this support, the customer can perform parallel development on the same landscape. In this case, the customer will try to avoid editing the same set of objects in different releases, but this may still happen. In case the objects are the same, CSOL and DGP release/reassign checks should give warnings only for those real potential downgrades.

The general idea is that, if both the cycle of the checked TR and the cycle of the conflicting TR are release cycles, and the status/position of the TRs in their “lifecycle” are opposite to the go-live order of the release cycles, then report the conflicts; otherwise, do not report the conflicts. This is because, as the go-live dates are in the opposite order, the TR may potentially be imported in the wrong order and cause downgrade.

Affected downgrade check types:

Check1: on Save;

Check2: on Release;

Check3: on Reassign.

Check4 (Predecessor Check) and Check5 (Imminent Check) are not affected, because they are calculated based on actual import order, rather than planned Go-live dates.

4.7. Delta Downgrade Protection Check

The delta downgrade protection check (delta DGP check) is an incremental check based on a previous complete downgrade check.

The delta DGP check is an import check (predecessor or imminent check) check, which is triggered automatically when you import the transport requests of a change cycle or scenario into the follow-on system (for example the quality assurance system or production system). You can also trigger it with a manual downgrade check of the change cycle or QGM scenario. The delta DGP check is intended for the following use case:

Before a go-live phase, you made a complete manual downgrade check of all transport requests in the change cycle (or QGM scenario) to identify conflicts before transporting the changes to the follow-on system (for example, the quality assurance or production system). After this complete downgrade check, new transport requests have been added to the import buffer of the follow-on system. If you then trigger the import of the transport requests of the cycle (or scenario) to the follow-on system, instead of a new complete downgrade check, which would check again all transport requests, a delta DGP check is performed to check only the transport requests that have been added since the last complete check. Since the delta DGP check checks only the transport requests that have been added since the last complete downgrade check, the delta DGP check is much faster than a complete check.

To enable the delta DGP check, do the following:
In transaction SM30 (Maintain Table Views) , open table AGS_WORK_CUSTOM (Workcenter Customizing).

In the table, for the parameter key AIC_DGP_DELTA_SWITCH, enter the value X.

5. Limitations

In SAP Solution Manager 7.2 since SP05 downgrade protection is available for ABAP systems as well as for non-ABAP systems.

For non-ABAP systems, only imminent downgrade and predecessor checks are supported, the checks based on cCTS, no the check based on CSOL.

See SAP note 2904186 - Downgrade Protection: non-ABAP system type is not allowed in Downgrade System Configuration , required for SP05 and SP06.

6. Troubleshooting

First thing to do always is to get the associated transport request transport logs.

You can find the associated transport requests for a change document, task list in table /TMWFLOW/TRORD_N. You can find the transport logs directly in the managed system or in table /TMWFLOW/TRACK_N.

6.1. DGP conflict is not appearing

Ensure that all transport related actions (create, release, import) were executed from SAP Solution Manager side only. Otherwise there could be data inconsistency for the object tracking in cCTS side regarding your transport requests.

If this was the case then ensure that DGP feature is switched on, check database table SCTS_TRACK_META on the SAP Solution Manager system. If DGP feature is not enabled please run report RSCTS_OBJ_TRACK_CONF with all desired options and 'Enabled' checked (see note 2173173 for details).

X Enable Transport Tracking

It is at release time of a transport request or transport of copies when all DGP tracking information is created and stored in database tables like SCTS_TRACK_UPQUE and SCTS_TRACK_MAIN. Look for entries in these table for your transport request in field REQUEST_ID.

Note: Please remove the flag from "Track transport of copies" if you don´t want to take the transport of copies TOC into consideration for DGP check. From ChaRM perspective the standard recommendation and SAP best practices is not to take the transport of copies into consideration for DGP checks as the ToC will never reach production system hence there is no "real" downgrade.

Note: also please implement SAP Note 3302933 - Performance Improvement for the Transport of Copies Creation - Change Control Management

If tracking of transport of copies is disabled, the deletion of related tracking data from DGP tracking tables must be executed manually. Se SAP Note 2570713 - DGP: Report to delete ToC-related tracking data.

See also SAP Note 2073071 - DGP: performance issues and resolution.

Also check the Release action logs in the corresponding M* or H* task list, if you see entry:

Downgrade protection added transport request to the tracking database. Message no. /TMWFLOW/CSL069, this would mean that the object tracking in cCTS side was correct.

In the case that you see warning entries like:

cCTS plugin has error in system. Message no. /TMWFLOW/CSL061

Change tracking reported an error. Message no. /TMWFLOW/CSL060

Then the object tracking in cCTS side was not correct and DGP checks cannot be correct.

Ensure that user running this release action has display rights in the respective system:client for authorization object S_TRANSPRT.

When you are running a manual check "Perform Check" in a change document DGP will make a DGP release check, predecessor check, imminent check one by one.

DGP manual check will show the conflicts together after doing all the DGP checks. In the case that during this check DGP found an error for example by checking the cCTS plugin status of a system in the cycle involved the DGP manual check will stop immediately and don´t return any results. So the conflicts will not be shown in the Transport-Related Checks AB.

6.2. DGP conflict appears incorrectly

Before DGP check, system will firstly get the cCTS plugin version on the corresponding target system. In case there is any problem, an error will be raised and no transport can be performed as long as DGP is active. If you have urgent actions to be performed and cannot install cCTS plugin right away, you may switch it off in DGP customizing temporarily.

So always validate the system where you are trying to trigger the import in /nszenplugin- Change and Transport System - Plug-in Management.

You can set the system to automatically ignore conflicts in specific cycle and/or in systems:client. To do so, refer to Downgrade System Configuration for more information.

6.3. Bypass error messages for emergency changes

It might happen that your DGP check gives the user an error when performing some emergent changes. In such cases, if you cannot move those previous transport requests which contain the conflicts to the production systems immediately, you may want to find a way to “ignore” those errors and “forcibly” save the change. In general there are two ways which can be used for this purpose and you can choose either one of them to suit your own needs:

Temporarily deactivate DGP globally
Temporarily change the DGP system configuration setting to switch off the DGP customizing for a particular cycle system.

6.4. DGP Performance issues

Please read KBA 3015525 - DGP: performance issues and resolution in Solution Manager 7.2

7. Some recommendations from cCTS point of view

Make sure that the latest version of component CTS_PLUG and patch level is installed on your SAP Solution Manager System and distribute the CTS plug-ins on the managed systems (including development, quality assurance, and production systems) according to SAP Note 1688276.
Ensure that the managed systems used in the ChaRM cycles, where you are trying to trigger the import, are updated and consistent in /nszenplugin- Change and Transport System - Plug-in Management.
Make sure that you use the latest recommended versions of transport tools tp and R3trans indicated in SAP Note 2116545 on the managed systems.
Start report RSCTS_OBJ_TRACK_CONF

Please see note 2173173 - DGP: Details on how to use report RSCTS_OBJ_TRACK_CONF:

Please note that when running report RSCTS_OBJ_TRACK_CONF, it will adjust the configuration to exactly the checked options and inputs. Please make sure to always completely check all desired options and enter all values. Otherwise older configurations will be overwritten. E.g. when changing options always check the 'Enable Transport Tracking', otherwise DGP will be switched off. As mentioned before from ChaRM perspective the standard recommendation and SAP best practices is to deactivate ToCs tracking for DGP. The reason behind this if that ToC will never reach production system hence there is no "real" downgrade. This will help to improve performance when moving to "To Be Tested".

Note: also please implement SAP Note 3302933 - Performance Improvement for the Transport of Copies Creation - Change Control Management

Ensure that the DGP housekeeping report RSCTS_OBJ_TRACK_HOUSEKEEPING is scheduled in the Solman system for regular execution. Please note, that the user executing the report needs to have authorization object S_CTS_ADMI with value TADM assigned, e.g. as part of role SAP_BC_CTS_ADMIN.

This will help prevent database tables that support DGP from growing too large. The CTS downgrade protection feature (DGP) creates database tables containing all relevant tracking information (mainly database table SCTS_TRACK_MAIN). If the DGP feature is switched on, those tables will be filled constantly with new tracking information.

See details in SAP Note 2444942 - Unified DGP Housekeeping Report for ST 7.2.

In cases where transports have been removed from target systems import buffers, either manually or by withdrawing a change document, conflicts with those removed transports can occur during DGP check runs as the entries for the related transport requests are still in tables SCTS_TRACK_UPQUE and SCTS_TRACK_MAIN.

Execute the report RSCTS_OBJ_TRACK_REMOVE in the SAP Solution Manager system and supply the requests in question and execute it. The program will remove all provided requests from the tracking database. This ensures that no more conflicts will be detected involving those transports. Details in SAP Note 2108353 - DGP: Report to remove obsolete requests.

If you decommissioned a SAP systems or you see entries in tables SCTS_TRACK_* like SCTS_TRACK_MAIN for a system which is not part of a logical component or are not used by ChaRM/QGM at all, please run report RSCTS_OBJ_TRACK_REMOVE_SYSTEM, check SAP Note 2350223 - DGP: Removal of not required systems from tracking.

8. Authorization object

SM_CM_DGPN is the authorization object to control DGP functions in Change Management.

9. Downgrade Protection tables

/TMWFLOW/DGP_CHK Downgrade Protection Check Results

/TMWFLOW/DGP_CNF Downgrade Protection Check Result Details

/TMWFLOW/DGP_ARC Downgrade Protection Check Results - Archive

/TMWFLOW/DGP_ARS Downgrade Protection Check Result Details – Archive

SCTS_TRACK_UPQUE cCTS: Object tracking update queue

SCTS_TRACK_MAIN cCTS: Main persistence for object level tracking

Page tree