Conigma CCM

Cleaning up the import queues

Overview

Conigma carries out detailed analyses before each import. Missing predecessors are identified to inform the user about possible risks and reimports necessary for downgrade prevention are added to the import set. These determinations take place on the basis of the import queues. Therefore, the size of the import queues is one of the primarily relevant factors (besides the request sizes) for the performance of the precalculations.

So that performance does not decrease over time, it is necessary to clean the import queues periodically. Conigma provides 2 reports for this purpose, which perform different cleaning tasks:

  • /GAL/CCM_DMWB_CLEANUP_QUEUE: This report is used to clean up requests that have already been imported, taking into account their potential need to prevent downgrades.

  • /GAL/CCM_DMWB_CLEANUP_QUEUE_EX: This report is used to clean up requests with a freely definable preconditions.

  • /GAL/CCM_DMWB_CLEANUP_QUEUE_LO: This report is used to clean up unimported requests that are legacy entries in the queue and never need to be imported again.

Report /GAL/CCM_DMWB_CLEANUP_QUEUE

Scheduling

The report /GAL/CCM_DMWB_CLEANUP_QUEUE is responsible for the standard cleanup of imported requests. It should always be scheduled.

The report can be scheduled on any Conigma system, it can clean up all systems via RFC.

To achieve an optimal performance of the Conigma import pre-calculations a daily scheduling is recommended.

Operating principle

The clean up takes place on the basis of the import queue and the contents of the requests located there. An request can be cleaned if it is no longer needed as an overtaker to prevent a downgrade. For this Conigma checks whether there is an older, not to be cleaned up request, which has overlaps to the examined request. The basis for this is the sequence in the import queue, which also corresponds to the import sequence for subset imports. All Workbench and Customizing contents are analyzed and checked. For example, overlaps between classes and individual methods or between views and individual table entries are also found.

Only requests that have already been imported are checked and, if necessary, removed. The report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO is responsible for non-imported "legacy requests".

Selection parameter

The report/GAL/CCM_DMWB_CLEANUP_QUEUE comes with a useful default setting. Nevertheless, depending on requirements and setup, other settings may be more suitable.

The report parameters are described below.

Repository ID: The repository used to determine the system data. If several repositories exist, you should normally use the productive repository here. Please note that the import queues are independent of the Conigma Repository and that a cleanup is therefore effective across repositories. The selection of the repository therefore only affects the question of where the settings are taken from (for example, which systems are used for system ID '*').

System ID: The system(s) to be cleaned. If the system ID is '*', all systems in the repository are cleaned. It should be noted here that a successful cleanup of requests may require an finished cleanup in the previous system. Especially in performance critical environments a cleanup in several steps according to the pattern DEV -> QA -> PRD is recommended.

Synchronize delivery targets: If this parameter is set, the unconditional modes in the queues of the subsequent systems are also adjusted during a cleanup. The F flag, which stands for "Not yet finally imported in the previous system" is removed here. Normally, this option should always be set in order to keep the queues consistent with each other.

Cleanup non-ABAP systems: If this option is set, a rudimentary cleanup is also performed for non-ABAP systems (i.e. Java stack only).

Mark requests as "finally imported": Activates the function for marking transport requests in the import queue as finally imported. In this case, requests that are no longer required are kept in the import queue, but marked as finally imported. Requests marked in this way are no longer taken into account for import precalculations.

The associated parameters must specify a minimum age and a minimum return value for the import.

Remove requests from import queue: Activates the function for deleting transport requests from the import queue. In this case, requests that are no longer required are removed from the import queue. These requests are therefore no longer taken into account for import precalculations.

The associated parameters must specify a minimum age and a minimum return value for the import.

Clean buffer files: If this function is activated, the SAP transport control program performs a buffer cleanup (command 'tp cleanbuffer').

This function can cause sequence problems in the queue if it contains transports of copies and is only recommended after a previous queue analysis.

Remove unneeded overtakers: Remove overtakers that are fully contained in a newer overtaker (for the same client). 

Ignore nonreadable TRs: If enabled, faulty requests that cannot be read are not considered cleanup blockers for all newer imported requests. 

F-Flag handling This parameter group is used to configure the cleanup of requests marked as not yet finally imported in the previous system. The requests not yet cleaned in the previous system can be handled in 3 ways:

  • Clean up

  • Keep

  • Reconcile the status with the source systems specified for the option and act accordingly (perform a clean up in case of incorrect labels).

Create Backups: Create a backup of the queue in the buffer directory (recommended).

Direct update: Do not perform all changes to queue entries as a transaction, but write each change directly and individually. This can be used if problems occur during transactional processing (for example, due to a high number of queue changes).

Force initial dequeue If the queue is locked with a TMS lock (e.g. created via Conigma), it can be unlocked automatically with this option. Queue locks set in the STMS are not affected by this option.

Extended protocols: Extended protocol output. For each request, a log is displayed why it is cleaned or not cleaned.

Only process n entries: This can be used to specify that only the first n entries of the import queue are checked. This option is only necessary for runtime or performance problems.

Simulation mode The changes are only simulated but not really made. The simulation result can be checked via the report output.

Report /GAL/CCM_DMWB_CLEANUP_QUEUE_EX

Scheduling

The report /GAL/CCM_DMWB_CLEANUP_QUEUE_EX can be used to clean up requests with a freely definable precondition.

The report can be scheduled on any Conigma system, it can clean up all systems via RFC.

Operating principle 

The clean up takes place on the basis of the import queue and the attributes of the requests located there. A request can be cleaned if it meets the precondition defined in the selection parameter Expression. The Conigma Expression is executed for each request in the queue and it has to return True in order to delete the current request. In the Expression the constant BUFFER is available, which has the structure type /GAL/CCM_ST_IMPORT_QUEUE containing all import queue attributes.

Selection parameter

The report /GAL/CCM_DMWB_CLEANUP_QUEUE_EX contains an empty expression by default, hence no requests will be deleted. 

The report parameters are described below. 


Repository ID: The repository used to determine the system data. If several repositories exist, you should normally use the productive repository here. Please note that the import queues are independent of the Conigma Repository and that a cleanup is therefore effective across repositories. The selection of the repository therefore only affects the question of where the settings are taken from (for example, which systems can be selected).

System ID: The system(s) to be cleaned. If this select option is empty,  all systems in the repository are cleaned.

Expression: The precondition of the cleanup can be defined here. The Conigma Expression is executed for each request in the queue and it has to return True in order to delete the current request.  In the Expression the constant BUFFER is available, which has the structure type /GAL/CCM_ST_IMPORT_QUEUE containing all import queue attributes.  The Expression is executed on the Conigma instance of the current SAP system, hence the request as well as the related Conigma change request can be instanced. 

Display CR data: In the output list will also be displayed details for the assigned Conigma change request.

Direct update: Do not perform all changes to queue entries as a transaction, but write each change directly and individually. This can be used if problems occur during transactional processing (for example, due to a high number of queue changes). 

Simulation mode The changes are only simulated but not really made. The simulation result can be checked via the report output.

Report/GAL/CCM_DMWB_CLEANUP_QUEUE_LO

Scheduling

Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO is responsible for the standard cleanup of requests that have not been imported and are no longer required. Whether scheduling is necessary must be decided according to the customer processes. If released requests are discarded within the processes and not completely transported through the whole landscape, the report is required.

Operating principle

The report can delete requests that have not yet been imported from the import queues.

The following list of selection parameters contains an exact specification of how requests that are no longer required are deleted from the queues.

Selection parameter

Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO does not clean up anything when used with default parameters. The required cleanups must first be specified using the selection parameters.

The report parameters are described below.

Repository ID: The repository used to determine the system data. If several repositories exist, you should normally use the productive repository here. Please note that the import queues are independent of the Conigma Repository, so a cleanup is effective across repositories. The selection of the repository therefore only affects the question of where settings are made (for example, which systems are used for system ID '*').

System ID: The system(s) to be cleaned. If the system ID is '*', all systems in the repository are cleaned.

Remove requests associated with Conigma CR (by status): This option can be used to remove requests that are assigned to a Conigma Change. A change process and a minimum status can be specified. Transport requests whose change has reached this status without being imported are deleted from the import queue.

Remove requests associated with Conigma CR (by condition):This option can be used to remove requests that are assigned in a Conigma Change. The condition for deciding whether an order is to be cleaned up can be specified flexibly as Conigma Expression.

Remove requests not associated with any Conigma CR This option can be used to remove requests that are not assigned to a Conigma Change. This applies both to requests that have never been assigned to a Change, and to requests that have been detached from their Change.

Ignore new requests To prevent unwanted request detaching, time spans can be defined to limit the cleanup. You can define a minimum release age and a minimum period of time that has elapsed since the request was detached from the Change. The latter option applies to the cleanup of requests that are not assigned to a change.

Ignore requests used in foreign repositories If this option is activated, requests that are used in repositories other than the specified one are not cleaned up.

Simulation mode The changes are only simulated, but not actually made. The simulation result can be checked via the report output.