DGP – Downgrade Protection for CTS
The purpose of this document is to explain the concept of DGP for CTS and the various Clenaup / Update reports available.
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.
Downgrade protection is available only for ABAP systems. Downgrade protection can be used in Change Request Management and in Quality Gate Management. The function is identical, however, the user interfaces and the related terminology can be different.
In Change Request Management, 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.
In Quality Gate Management, information related to downgrade protection is displayed on the Downgrade Protection Tab.
There are two ways to trigger downgrade checks:
Manually In Change Request Management, you can trigger downgrade checks from the Downgrade Protection assignment block. In Quality Gate Management, you can trigger the check from the Project Overview and the Changes tab. The system analyses 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. The check is performed asynchronously. Refresh the assignment block or tab page to display up-to-date check results.
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 cancelled, 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 cancellation of the operation. A link to the change cycle document in the WebClient UI, where the conflicts can be checked and handled, is provided.
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.
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.
Reassign check : The system performs this check when you reassign a change document or assign or decouple transport requests in a change document.
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.
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 following graphic shows the user and system activities during the downgrade protection process.
Downgrade Protection Process
DGP Housekeeping :
If DGP feature is switched on (you have configured downgrade protection and the cross-system object lock, in Customizing, under SAP > Solution Manager > Capabilities > Change Control Management > Cross-System Object Lock and Downgrade Protection) those tables will be filled constantly with new tracking information. In order to ensure those tables are not growing indefinitely, do not contain outdated or wrong information, and changes in the CTS landscape are handled correctly (eg removing or adding a system) housekeeper is required.
Clean-up reports :
Update reports :
The update reports basically query for the import status of all requests (in the respective target systems), where the tracking framework did not yet receive a final import status (e.g. because transport was not imported yet, or no update was done since import). Currently, DGP is based on a pull-mechanism – we don’t get any notifications of an import. Hence, we query for that data. Each line in SCTS_TRACK_UPQUE represents one request in one logical system, where we don’t have the ‘final import’ status persisted in the SolMan. If we retrieved this exact status, the line is deleted from SCTS_TRACK_UPQUE and the STATUS field in SCTS_TRACK_MAIN is adjusted. The different reports now leverage different query mechanisms – the best way is to ask tp in the target system. However, this is super slow (tp takes 500ms per request, plus remoting, plus persistence). For large SCTS_TRACK_UPQUE tables, this simply does not work. RSCTS_OBJ_TRACK_RUN_QUEUE_ALT uses SolMan tracking tables instead – so no tp, no remoting and optimal queries, its not as 100% as the tp version, but gets the job done much faster.
If the downgrade protection feature is switched on in SAP Change Request Management or SAP Quality Gate Management, the reports listed below should be executed on a regular basis in your SAP Solution Manager system:
All reports can be triggered manually (e.g. using transaction SE38) or can be scheduled as batch jobs (using transaction SM36). Depending on the average transport volume, we recommend to execute the reports at least weekly. In very agile environments, with several hundred requests a day, a daily execution is recommended.
This is how SAP recommends the reports be utilised and in this order :
The queue-reports basically update information which is needed for the clean-ups. However, if those reports are scheduled daily, the core sequence is not that relevant, as the clean-ups on the next day will leverage the information retrieved before. But as a simple rule of thumb, running the queue-related reports before the clean-up ones is recommended.
SCTS_TRACK_UPQUE contains all transport request/system combinations, where SCTS_TRACK_MAIN still has STATUS = WAITING | REWAITING. Since we don’t get synchronous updates, when a transport request was imported, we have to query for it. The basis for those queries is the information in SCTS_TRACK_UPQUE. Once we detect a transport being successfully imported in a given system, we remove the corresponding entry in SCTS_TRACK_UPQUE.
Report RSCTS_OBJ_TRACK_REMOVE_SYSTEM can be used to remove obsolete / decommissioned SAP systems as DGP clean-up reports RSCTS_OBJ_TRACK_CLEANING and RSCTS_OBJ_TRACK_CLEANING_2 will not removed these (per standard) from SCTS_TRACK_MAIN.
Report RSCTS_OBJ_TRACK_REMOVE_SYSTEM can be used as per Step 2 of SAP Note # 2077091.
Report RSCTS_OBJ_TRACK_REMOVE can be used to remove obsolete requests. Simply execute the report in the SAP Solution Manager system and supply the requests in question and execute it. You can find more information in SAP note # 2108353.
Report RSCTS_OBJ_TRACK_ADD can be used to add transport requests that were created before SAP Solution Manager 7.1 Support Package 05.
In SAP Solution Manager 7.2 systems, the DGP housekeeping and clean-up reports are obsolete (RSCTS_OBJ_TRACK_CLEANING, RSCTS_OBJ_TRACK_CLEANING_0, RSCTS_OBJ_TRACK_CLEANING_2, RSCTS_OBJ_TRACK_RUN_QUEUE, RSCTS_OBJ_TRACK_RUN_QUEUE_ALT, RSCTS_OBJ_TRACK_RUN_QUEUE_MAX, RSCTS_OBJ_TRACK_CLEANING_PIL_0, RSCTS_OBJ_TRACK_CLEANING_PIL_1) and replaced by one unified report : RSCTS_OBJ_TRACK_HOUSEKEEPING. For more on this development / change please see SAP note # 2444942
List of relevant and important notes :
1897459 CTS DGP: Fixing performance issue for large repositories
1957898 DGP: Conflicts occur with already imported objects
1970273 DGP: Incorrect results for already imported objects
1972808 DGP: Cleanup Report for invalid or finished entries
2011014 DGP: Improvement of RSCTS_OBJ_TRACK_CLEANING
2077091 DGP: Refresh DGP-data after system copy/refresh
2196868 DGP – Cleanup Decommissioned SAP Systems
2097533 DGP: Manual update of tracking data for requests
2108353 DGP: Report to remove obsolete requests
2118375 DGP: False conflicts are reported for PFCG transports
2138047 DGP: Recommended Housekeeping
2164852 DGP: Roles are not always tracked
2173173 DGP: Details on how to use report RSCTS_OBJ_TRACK_CONF
2187926 DGP: Query optimization for update mechanism
2189071 DGP: Improved clean up for waiting export entries
2202616 DGP: Option for report RSCTS_OBJ_TRACK_RUN_QUEUE
2209499 DGP: Update report for large queues
2209856 DGP: Parameter ‘cache expiration’ not working
2216849 DGP: Performance improvements for long running clean-up/queue runs
2231112 cCTS DGP: Update of report RSCTS_OBJ_TRACK_CLEANING
2073071 DGP: performance issues and resolution
2363546 DGP Housekeeping Tool
At first I would like to thank you for giving some details around the DGP Housekeeping jobs… When reading the current version of the blog, I am however still a bit confused about which cleanup and update reports I should schedule when having DGP activated….
In one section of the blog it is stated that the following housekeeping jobs should be scheduled:
1. Report RSCTS_OBJ_TRACK_CLEANING and
2. Report RSCTS_OBJ_TRACK_CLEANING_2 and
3. Report RSCTS_OBJ_TRACK_RUN_QUEUE
This is based I assume on SAP Note 2138047 DGP Recommende Housekeeping jobs.
In another section of the blog it states that the following jobs should be scheduled:
The blog also states that:
“SAP recommends to use RSCTS_OBJ_TRACK_CLEANING_0 in all cases, its a more efficient version of _2 and the core report.”
– Is it possible to clarify which housekeeping jobs must be scheduled?
– Should we Always schedule all cleaning reports or only RSCTS_OBJ_TRACK_CLEANING_0?
– Is it correct to only schedule RSCTS_OBJ_TRACK_RUN_QUEUE_MAX as update report?
I've updated the blog so hope its more clear now.
We recommend that you schedule all 3 cleaning reports for best results.
If scheduling RSCTS_OBJ_TRACK_RUN_QUEUE_MAX as the update report then that is sufficient.
If there are any issues then please fee free to contact SAP through an incident or Expert Chat.