Bereinigen der Importqueues

Übersicht

Conigma führt vor jedem Import ausgiebige Situationsanalysen durch. Es werden fehlende Vorgänger ermittelt, um den Benutzer auf eventuelle Risiken hinzuweisen und es werden zur Downgrade-Verhinderung notwendige Reimporte dem Importset hinzugefügt. Diese Ermittlungen finden auf Basis der Importqueues statt. Deswegen ist die Größe der Importqueues einer der primär relevanten Faktoren (neben den Auftragsgrößen) für die Performance der Vorberechnungen.

Damit die Performance nicht im Laufe der Zeit abnimmt, ist es notwendig die Importqueues periodisch zu bereinigen. Conigma stellt hierfür 3 Reports zur Verfügung, welche unterschiedliche Bereinigungstasks durchführen:

• /GAL/CCM_DMWB_CLEANUP_QUEUE: Dieser Report dient zur Bereinigung schon importierter Aufträge unter Betrachtung ihrer Notwendigkeit zur Downgrade-Verhinderung.

• /GAL/CCM_DMWB_CLEANUP_QUEUE_EX: Dieser Report dient zur Bereinigung der Aufträge mit frei definierbaren Konditionen.

• /GAL/CCM_DMWB_CLEANUP_QUEUE_LO: Dieser Report dient zur Bereinigung nicht importierter Aufträge, welche als Altlasten in der Queue sind und nie wieder zum Import anstehen.

Report /GAL/CCM_DMWB_CLEANUP_QUEUE

Einplanung

Der Report /GAL/CCM_DMWB_CLEANUP_QUEUE ist für die standardmäßige Bereinigung importierter Aufträge zuständig. Er sollte immer eingeplant sein.

Der Report muss auf einem beliebigen Conigma System eingeplant werden, er kann via RFC alle Systeme bereinigen. 

Um eine optimale Performance der Conigma Importvorberechnungen zu erreichen ist eine tägliche Einplanung empfehlenswert.

Funktionsweise

Die Bereinigung erfolgt auf Basis der Importqueue sowie der Inhalte der sich dort befindlichen Aufträge. Ein Auftrag kann bereinigt werden, sofern er nicht mehr als Überholer zur Downgrade-Verhinderung benötigt wird. Hierzu prüft Conigma ob es einen älteren, nicht zu bereinigenden Auftrag gibt, welcher Überschneidungen zum geprüften Auftrag hat. Basis hierfür ist die Reihenfolge in der Importqueue, welche auch der Importreihenfolge bei gemeinsamen Importen entspricht. Hierzu werden alle Workbench- und Customizinginhalte aufgelöst und geprüft. Es werden also auch z.B. Überschneidungen zwischen Klassen und einzelnen Methoden oder zwischen Views und einzelnen Tabelleneinträge gefunden.

Geprüft und ggf. entfernt werden grundsätzlich nur bereits importierte Aufträge, für nicht-importierte "Altlasten" ist der Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO zuständig. 

Selektionsparameter

Der Report  /GAL/CCM_DMWB_CLEANUP_QUEUE kommt mit einer sinnvollen Defaulteinstellung. Nichtsdestotrotz können je nach Anforderungen und Setup andere Einstellungen besser geeignet sein. 

Im Folgenden werden die Reportparameter beschrieben.

Repository ID: Das für die Ermittlung der Systemdaten verwendete Repository. Sollten mehrere Repositories existieren, so ist hier im Normalfall das produktive Repository zu verwenden. Es ist zu beachten, dass die Importqueues unabhängig vom Conigma Repository sind und eine Bereinigung somit repositoryübergreifend wirkt. Die Auswahl des Repositories betrifft also nur die Frage woher Einstellungen gezogen werden (z. B. welche Systeme für System ID '*' genommen werden).

System ID: Das/die zu bereinigende(n) System[e]. Bei System-ID '*' werden alle im Repository vorhandenen Systeme bereinigt. Hierbei ist zu berücksichtigen, dass Aufträge für eine erfolgreiche Bereinigung u. U. eine schon erfolgte Bereinigung im Vorsystem benötigen. Gerade in performancekritischen Umgebungen ist demzufolge eine Bereinigung in mehreren Steps nach dem Muster DEV -> QA -> PRD zu empfehlen.

Synchronize delivery targets: Wenn dieser Parameter gesetzt ist, werden bei einer Bereinigung auch die Unconditional Modes in den Queues der Folgesysteme angepasst. Hier wird das F-Flag entfernt, welches für "Im Vorsystem noch nicht abschließend importiert" steht. Im Normalfall sollte diese Option immer gesetzt sein, um die Queues untereinander konsistent zu halten.

Cleanup non-ABAP systems: Ist diese Option gesetzt, so wird auch für non-ABAP Systeme (i.e. nur Java Stack) eine rudimentäre Bereinigung durchgeführt.

Mark requests as "finally imported": Aktiviert die Funktion zum Abhaken von Transportaufträgen in der Importqueue. In diesem Falle werden nicht mehr benötigte Aufträge in der Importqueue behalten, aber mit einer finalen Importmarkierung versehen. Derartig markierte Aufträge werden für Importvorberechnungen nicht mehr in Betracht gezogen.

Über die assoziierten Parameter müssen ein minimales Alter sowie ein minimaler Rückgabewert beim Import spezifiziert werden.

Remove requests from import queue: Aktiviert die Funktion zum Löschen von Transportaufträgen aus der Importqueue. In diesem Fall werden nicht mehr benötigte Aufträge aus der Importqueue entfernt.  Somit werden diese Aufträge für Importvorberechnungen nicht mehr in Betracht gezogen.

Über die assoziierten Parameter müssen ein minimales Alter sowie ein minimaler Rückgabewert beim Import spezifiziert werden.

Clean buffer files: Ist diese Funktion aktiviert, so wird mithilfe des SAP Transportsteuerungsprogramms eine Bufferbereingung durchgeführt (Kommando 'tp cleanbuffer').

Diese Funktion kann Reihenfolgeprobleme in der Queue verursachen, sofern diese Transporte von Kopien enthält und ist nur nach einer vorhergehenden Queueanalyse zu empfehlen.

Remove unneeded overtakers: Überholer entfernen, welche vollständig in einem neueren Überholer (für den selben Mandanten) enthalten sind. 

Ignore nonreadable TRs: Wenn aktiviert, werden fehlerhafte Aufträge, welche nicht gelesen werden können, nicht als Bereinigungsblocker für alle neueren importierten Aufträge angesehen. 

F-Flag handling: Diese Parametergruppe dient zur Konfiguration der Bereinigung von als im Vorsystem noch nicht final importiert markierten Aufträgen. Es können die im Vorsystem noch nicht bereinigten Aufträge auf 3 Arten gehandhabt werden:

• Bereinigen

• Behalten

• Status mit den zur Option angegebenen Vorsystemen erneut abgleichen und entsprechend handeln (Bereinigung im Fall fehlerhafter Kennzeichnungen).

Create Backups: Ein Backup der Queue im Buffer Verzeichnis erstellen (empfohlen).

Direct update: Änderungen von Queueeinträgen nicht als gesammelte Transaktion durchführen, sondern jede Änderung direkt einzeln schreiben. Dies kann angewendet werden, wenn es beim transaktionalen Prozessieren zu Problemen kommt (z. B. aufgrund von hohem Queueänderungsaufkommen).

Force initial dequeue: Sollte die Queue mit einer (z. B. via Conigma erstellten) TMS Sperre gesperrt sein, so kann sie mit dieser Option automatisch entsperrt werden. In der STMS gesetzte Queuesperren sind von dieser Option nicht betroffen.

Extended protocols: Erweiterte Protokollausgabe. Es wird für jeden Auftrag ausgegeben, warum er bereinigt beziehungsweise nicht bereinigt wird.

Only process n entries: Hiermit kann festgelegt werden, dass nur die ersten n Einträge der Importqueue geprüft werden. Diese Option ist nur bei Laufzeit- oder Performanceproblemen notwendig.

Simulation mode: Die Änderungen werden nur simuliert aber nicht wirklich durchgeführt. Über die Reportausgabe kann das Simulationsergebnis kontrolliert werden.

Report /GAL/CCM_DMWB_CLEANUP_QUEUE_EX

Einplanung

Der Report /GAL/CCM_DMWB_CLEANUP_QUEUE_EX kann für die Bereinigung der Aufträge nach frei definierten Kriterien verwendet werden.

Der Report kann auf einem beliebigen Conigma System eingeplant werden, er kann via RFC alle Systeme bereinigen.

Funktionsweise

Die Bereinigung erfolgt auf Basis der Importqueue sowie der Attribute der sich dort befindlichen Aufträge. Ein Auftrag kann bereinigt werden, sofern er die in dem Selektionsparameter Expression definierte Vorbedingung erfüllt. Die Conigma-Expression wird für jeden Auftrag in der Queue ausgeführt und muss True zurückliefern, wenn der Auftrag gelöscht werden kann. In der Expression kann auf die Konstante BUFFER zugegriffen werden, die eine Struktur vom Typ /GAL/CCM_ST_IMPORT_QUEUE ist und alle Queue-Attribute enthält.

Selektionsparameter

Der Report  /GAL/CCM_DMWB_CLEANUP_QUEUE_EX enthält defaultmäßig eine leere Expression und somit werden keine Aufträge gelöscht. 

Im Folgenden werden die Reportparameter beschrieben.

Repository ID: Das für die Ermittlung der Systemdaten verwendete Repository. Sollten mehrere Repositories existieren, so ist hier im Normalfall das produktive Repository zu verwenden. Es ist zu beachten, dass die Importqueues unabhängig vom Conigma Repository sind und eine Bereinigung somit repositoryübergreifend wirkt. Die Auswahl des Repositories betrifft also nur die Frage woher Einstellungen gezogen werden (z. B. welche Systeme für System ID ausgewählt werden könnnen).

System ID: Das/die zu bereinigende(n) System[e]. Bei leerem Selektionsfeld werden alle im Repository vorhandenen Systeme bereinigt.

Expression: Die Vorbedingung für das Löschen kann hier mit Conigma-Expression definiert werden.  Die Conigma-Expression wird für jeden Auftrag in der Queue ausgeführt und muss True zurückliefern, wenn der Auftrag gelöscht werden kann. In der Expression kann auf die Konstante BUFFER zugegriffen werden, die eine Struktur vom Typ /GAL/CCM_ST_IMPORT_QUEUE ist und alle Queue-Attribute enthält. Die Expression wird auf dem Conigma-Instanz des aktuellen SAP Systems ausgeführt, deshalb ist es auch möglich den Auftrag, sowie den zugehörigen Conigma CR zu instanzieren. 

Display CR data: Der Report gibt auch Daten zum zugehörigen Conigma Change Request aus.

Direct update: Änderungen von Queueeinträgen nicht als gesammelte Transaktion durchführen, sondern jede Änderung direkt einzeln schreiben. Dies kann angewendet werden, wenn es beim transaktionalen Prozessieren zu Problemen kommt (z. B. aufgrund von hohem Queueänderungsaufkommen).

Simulation mode: Die Änderungen werden nur simuliert aber nicht wirklich durchgeführt. Über die Reportausgabe kann das Simulationsergebnis kontrolliert werden.

Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO

Einplanung

Der Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO ist für die standardmäßige Bereinigung nicht importierter und nicht mehr benötigter Aufträge zuständig. Ob eine Einplanung notwendig ist, ist entsprechend der Kundenprozesse zu entscheiden. Werden freigegebene Aufträge im Rahmen der Prozesse verworfen und nicht komplett durchtransportiert, so ist der Report vonnöten.

Funktionsweise

Der Report kann noch nicht importierte Aufträge aus den Importqueues löschen.

Eine genaue Spezifikation auf welche Arten nicht mehr benötigte Aufträge aus den Queues gelöscht werden ist der folgenden Auflistung der Selektionsparameter zu entnehmen.

Selektionsparameter

Der Report /GAL/CCM_DMWB_CLEANUP_QUEUE_LO führt in der Defaultselektion keine Bereinigung durch. Die gewünschten Bereinigungen müssen erst über die Selektionsparamter spezifiziert werden. 

Im Folgenden werden die Reportparameter beschrieben.

Repository ID: Das für die Ermittlung der Systemdaten verwendete Repository. Sollten mehrere Repositories existieren, so ist hier im Normalfall das produktive Repository zu verwenden. Es ist zu beachten, dass die Importqueues unabhängig vom Conigma Repository ist, eine Bereinigung also repositoryübergreifend wirkt. Die Auswahl des Repositories betrifft also nur die Frage woher Einstellungen gezogen werden (z.B. welche Systeme für System ID '*' genommen werden).

System ID: Das/die zu bereinigende(n) System[e]. Bei System-ID '*' werden alle im Repository vorhandenen Systeme bereinigt.

Remove requests associated with Conigma CR (by status): Mithilfe dieser Option können Aufträge, welche einem Conigma Change zugeordnet sind, entfernt werden. Es kann ein Change Prozess sowie ein Mindeststatus angegeben werden. Transportaufträge deren Change diesen Status erreicht hat ohne dass diese importiert wurden, werden aus der Importqueue gelöscht.

Remove requests associated with Conigma CR (by condition): Mithilfe dieser Option können Aufträge, welche in einem Conigma Change zugeordnet sind, entfernt werden. Die Bedingung zur Entscheidung ob ein Auftrag bereinigt werden soll, kann flexibel als Conigma Expression angegeben werden.

Remove requests not associated with any Conigma CR:  Mithilfe dieser Option können Aufträge, welche keinem Conigma Change zugeordnet sind, entfernt werden. Dies gilt sowohl für Aufträge, welche noch nie einem Change zugeordnet waren, als auch für Aufträge, welche von ihrem Change abgehängt wurden.

Ignore new requests: Um das ungewollte Abhängen von Aufträgen zu verhindern, können Zeitspannen definiert werden, um die Bereinigung einzuschränken. Es kann ein minimales Freigabealter sowie eine minimale, seit dem Abhängen vom Change verstrichene Zeitspanne definiert werden. Letztere Option gilt für die Bereinigung von Aufträgen welche keinem Change zugeordnet sind.

Ignore requests used in foreign repositories: Ist diese Option aktiviert, so werden Aufträge, welche in anderen Repositories als dem angegebenen verwendet werden, grundsätzlich nicht bereinigt.

Simulation mode: Die Änderungen werden nur simuliert, aber nicht wirklich durchgeführt. Über die Reportausgabe kann das Simulationsergebnis kontrolliert werden.