With the following steps, you will be able to setup DGP functionality for Change Request Management.
In addition, I will try to give tips and tricks for the configuration of this functionality in SAP Solution Manager 7.1 SP10 and for troubleshooting possible issues using this functionality.
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, reassigned, 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).
The following downgrade protection checks can be performed by the SAP Solution Manager 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.
- Release check (based on CSOL)
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)
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 requests for import in a system, check for 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)
The system can detect impending (imminent) downgrade conflicts when transport requests are imported.Given a set of requests for import in a system, check for requests already imported in the system that have an object overlap and contain a newer version of the object.
- Reassign check (based on CSOL)
The system performs this check when you reassign a change document or assign or decouple transport requests in a change document.
Since Solution Manager 7.1 SP05, DGP is supported in ChaRM.
Solution Manager 7.1 SP10, DGP is supported in both ChaRM and QGM.
In order to use these five downgrade protection checks you should:
- Configure the Cross System Object Lock scenario as indicated in SCN Wiki How to work with Cross System Object Locked (CSOL).
- You should install software component CTS_PLUG in the SAP Solution Manager system and distribute the CTS plug-ins to all managed systems according to note 1688276. It is very important to keep the CTS Plug-in version up to date.
Note: It is not necessary to use a cCTS enabled project to use DGP functionality; you can use DGP regardless of whether you use a cCTS enabled project or not.
However as some DGP checks are based on cCTS you must install software component CTS_PLUG in the SAP Solution Manager system and distribute the CTS plug-ins to all managed systems.
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, an error will be raised and no transport import can be performed as long as DGP is active.
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:
And for each of the managed system used in the ChaRM project:
Note: Please do not apply the CTSPLUG software component to managed systems manually!
Since it is not possible to remove a once installed software component from a system, a managed system, where CTSPLUG software component is installed once, can no longer be updated with client plugins from the central solution manager. That is, a customer would always need to update the CTSPLUG client version of this system manually by installing a new CTSPLUG version.
- All transport related actions (create, release, import) have to 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.
Note: Operations using the CTS plug-in are blocked with an error message if the CTS plug-in was not installed on a managed system or if the plug-in on a managed system had a lower version than the plug-in on the CTS server (SAP Solution Manager).
In SAP Solution Manager 7.2 with the implementation of SAP Note 2555809 "Report CTS plug-in client checks as warning for CTS plug-in outdated in managed systems" and later 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.
Before using DGP functionality, it must be activated.
In solman 7.1 SP10 call /n/TMWFLOW/CONFIG_LOCK or go to /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” in Expert Mode to Make sure the conflict resolution can be postpone to the lastest point in time (when importing)
3.1. Downgrade Conflict Type
Perform this setting in customizing view “/TMWFLOW/DGP_TYP” or in the spro point “Configure Downgrade Protection”.
Set which check should result in which conflict.
Here you can customize the mapping between checks and conflict types and conflict type icon.
SAP standard and default conflict type and icon customizing delivery is:
- Downgrade warning (check 2 and check 3 – if user continues, he might create a downgrade situation)
- Over taker warning (check 4 – if user continues, he might run into a downgrade issue later)
- Imminent downgrade (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
Perform this setting in customizing view “/TMWFLOW/DGP_SYS” or in the spro point “Configure Downgrade Protection”.
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 systems that will bypass downgrade protection checks (exception list). Configure which system, system role, project or conflict type automatically bypasses the release, reassign (decouple/assign/reassign) or import check, even when conflicts are found. Choose the relevant value in the Cancel at/Action fields.
It is possible to use wildcards (*) for System, Client and Project fields for generic setup.
Note: The value "Never", in 'Cancel at' field, means that the system never cancels the action.
Cancel Action at
Behavior: DGP check at release for all projects development system AB0:100 is ignored and the release will be triggered, as release conflict type is Warning lower than Critical.
Cancel Action at
Behavior: The DGP conflict detected when importing a TR into a quality system will not block the import as the Downgrade conflict type is Critical as you see in the first table, so only imminent downgrade, that is conflict type Very critical, would block the import, not the predecessor check.
If you select the Switch Off flag the conflict are not calculated at all, the value in the Cancel at, Action columns is ignored, and no downgrade protection log entries are generated. Switch Off flag was introduced in SP10.
Note: By default, the table is empty, for security reasons, so all conflicts lead to the cancelation of the action.
The configuration done in /TMWFLOW/DGP_SYS only controlles the DGP check when it is automatically called during transport process (release, import).
Manual check is not considered for this configuration. In se16: /TMWFLOW/DGP_EXC you can decide if you want to deactivate DGP manual check for specific transactions types.
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.
If a user goes to change document 2 and try to release TR2 the system check if there are entries in /n/tmwflow/lockmon 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/lockmon 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 object are still on the way to production.
User needs to go to the Downgrade Protection assignment block (in ChaRM) to check and ignore the Release check conflict. Then the release of TR2 can be done.
Import check- Predecessor conflict
If a user goes to change document 2 and trigger the import of TR2 into a target system like the quality system, 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 the Downgrade Protection assignment block (in ChaRM) 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.
Import check- Imminent downgrade conflict
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 the Downgrade Protection assignment block 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.
When reassigning a change document to another project 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 project. 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 checks
In Change Request Management, you can trigger downgrade checks from the Downgrade Protection assignment block by clicking on Perform Downgrade 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.
DGP manual check is performed asynchronously, so that the UI is not blocked during the check; refresh the DGP assignment block or tab to get up-to-date check results.
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.
4.3. Ignoring a conflict
Conflicts can be manually ignored in the DGP AB, 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. Project level and change level conflicts
Because import check considers the actual set of TRs to be imported, project level import and change level import may result in different conflicts, so conflicts are displayed in the DGP assignment block of the change cycle and the DGP assignment block of the change document, respectively.
a. When conflicts are found during a project level import (triggered by 'Import Transport Requests' (Background) task in the project task list), the conflicts will be displayed in the project cycle document DGP assignment block.
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 DGP assignment block.
c. When conflicts are found during a change level import for an urgent change task list (without CRM document), the conflicts are displayed in the project cycle document DGP assignment block.
Caution: when operating with a Normal Change, unless you are using preliminary import, imports are performed via the project task list, which may result in conflicts in the DGP assignment block of the change cycle; if any conflicts are found, you should go there to ignore them, instead of going to the change 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 DGP assignment block.
This information is helpful in investigating DGP issues.
In SAP Solution Manager 7.1 DGP functionality is not supporting non-ABAP changes.
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).
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.
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 downgrade protection" 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 a error for example by checking the cCTS plugin status of a system in the project involved the DGP manual check will stop immediately and don´t return any results.So the conflicts will not be shown in the CRM UI.
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 project and/or in systems:client. To do so, refer to Downgrade System Configuration for more information.
6.3. Bypass error messages for emergent 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 project.
6.4. DGP Performance issues
Please read note 2073071 DGP: performance issues and resolution
7. Some recommendations from cCTS point of view
- Make sure that the latest version of component CTS_PLUG 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 note 1688276.
- Ensure that the managed systems used in the ChaRM projects, 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 recommended versions of transport tools indicated in 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.
- Make sure that reports RSCTS_OBJ_TRACK_RUN_QUEUE, RSCTS_OBJ_TRACK_CLEANING, and RSCTS_OBJ_TRACK_CLEANING_2 are scheduled to run regularly (we recommend that you run these reports once a week).
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 note 2138047 - DGP: Recommended Housekeeping.
- In cases where transports have been removed from target systems, either manually or by withdrawing a change document, conflicts with those removed transport can occur during DGP check runs.
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.
8. Authorization object
SM_CM_DGP 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
SAP Help: Downgrade Protection
SAP Help: Cross-System Object Lock
Ensure that you have applied the latest version of the Change Request Management master note for your patch level.
1688276 - Distributing CTS plug-ins to managed systems
2116545 - Central CTS: Recommended versions of transport tools
2555809 - Report CTS plug-in client checks as warning for CTS plug-in outdated in managed systems
2138047 - DGP: Recommended Housekeeping
2189071 - DGP: Improved clean up for waiting export entries
2073071 - DGP: Performance issues and resolution