Mappings Reorganisieren

Diese Transaktion wird verwendet zum:

• Erstellen einer SWH-Tabelle auf der Grundlage einer bestehenden SWM-Tabelle, wenn eine entsprechende SWH-Tabelle noch nicht existiert. Dies geschieht, um die Mappings wie eine Standard Stammdaten-Transaktion mit Versionsanzeige, 4-Augen-Kontrolle usw. zu behandeln.
• Reorganisieren “alternativer Mappings” einer Nachricht zu den “normalen” Mappings, bevor neue alternative Mappings für ein zukünftiges Release in die Installation importiert werden können. Wird dies nicht getan, gehen die derzeit gültigen Mappings verloren. Dies muss vermieden werden, und um eine reibungslose Abwicklung zu gewährleisten, wird die bestehende Transaktion “REOSWH” (jetzt umbenannt in “Reorganize Mappings”) erweitert, um die Reorganisationsaufgabe zu unterstützen.

Reorganisieren “alternativer mappings”:

Diese Transaktion archiviert alte Mappings und verschiebt alternative Mappings in “normale” Mappings. So können neue alternative Zuordnungen importiert werden, ohne dass noch benötigte Zuordnungen überschrieben werden. Die Transaktion führt während der Ausführung automatisch die folgenden Schritte aus:

• Es wird geprüft, ob in der Umgebung, in der die Transaktion ausgeführt wird, alternative Mappings verfügbar sind. Falls vorhanden, werden alle Mappings (alternative und nicht alternative) in eine Zip-Datei in der Datenpartition (z.B. T:\xxx\data\swm) exportiert.
• Für jede Nachricht mit einem “Alternativen Mapping” wird geprüft, ob ein nicht-alternatives Mapping existiert,
  • Wenn ein nicht-alternatives Mapping für die Nachricht (z.B. MT 760) existiert, dann wird das alte Mapping ohne das gesetzte Flag gelöscht und dann das Flag “Alternatives Mapping” aus dem alternativen Mapping gelöscht, so dass dieses zum aktuell existierenden Mapping wird, welches dann ausgeführt wird.
  • Wenn es für die Nachricht kein alternatives Mapping gibt (d.h. diese Nachricht wurde mit dem “Standards Release 2021” eingeführt, z.B. MT 765), wird das Flag “Alternatives Mapping” aus dem alternativen Mapping gelöscht, so dass dieses zum aktuell existierenden Mapping wird, welches dann ausgeführt wird.
• Sobald alle Mappings aktualisiert sind, werden die aktuellen Mappings (ohne alternatives Mapping) wieder in den Ordner “T:\xxx\data\swm” exportiert.
• Es ist wichtig, dass während der Ausführung der REOSWH-Transaktion die Tabellen “SWH” und “SWM” nicht gesperrt sind, d. h., dass niemand sonst irgendwelche Zuordnungen aktualisiert. Treten während dieses Prozesses Fehler auf, wird der Prozess gestoppt und alle Änderungen werden rückgängig gemacht.

Sobald die Transaktion ausgeführt wurde, ist es wichtig, die Protokolle zu prüfen und in DBxSWH gegenzuprüfen, dass keine “Alternativen Mappings” existieren. Nachdem der oben beschriebene Prozess erfolgreich abgeschlossen wurde, können die neuen “Alternativen Mappings” für das kommende Release in das System importiert werden.

Reorg