Der Verdacht

Drucken

Irgendwie kann ich es kaum glauben, dass unsere ALE-Szenarien in der Testumgebung funktionieren. Die schriftliche Abnahmemail der Testabteilung zur Systemkopie habe ich zwar gut aufgehoben, aber was nützt das, wenn es klemmt? Ich hege den Verdacht, dass einige Geschäftsprozesse nur zu besonderen Feierlichkeiten getestet werden. Es wäre nicht das erste Mal, dass wir einen Incident mit der präzisen Fehlerbeschreibung "nichts funktioniert" eingestellt bekommen und sich später herausstellt, dass wir eine unentdeckte systematische Lücke in den Nacharbeiten haben. Manchmal habe ich auch den Verdacht, dass die als Fehler gemeldete Funktion noch NIE funktioniert hat und erst eingerichtet werden muss. Da nicht alle Änderungen als Change über uns laufen und ich als Basis-Admin bei den fachlichen Geschäftsprozessen an Grenzen stoße, kann ich nicht sicher sein ob wir bei der Kopie etwas "vergessen" haben

Wenn ich das ALE-Kapitel in unserem aktuellen Kochbuch der Systemkopie-Nacharbeiten weniger wohlwollend zusammenfasse, dann kann man es auf "vorher anschauen und gut merken – hinterher nochmal anschauen und ggf. anpassen" reduzieren. Wer kein fotografisches Gedächtnis besitzt, müsste an die 100 Bildschirmfotos sichern und hinterher kontrollieren. Das kostet viel Zeit und ist nicht fehlerfrei möglich. In der Praxis werden viele dieser Fotos weggelassen, weil es guten Grund zur Annahme gibt, dass die Detailbilder alle identisch sind. Im aktuellen Projekt wird sich das ändern und man müsste die Details nun tatsächlich vergleichen.

Spätestens jetzt ist es an der Zeit das Thema so aufzuarbeiten, dass wir zu einem gesicherten und effizienten Verfahren kommen. In einem SAP-System ist das eigentlich ganz einfach: wir brauchen nur die Tabellen zu exportieren, in denen sich die ALE-Einstellungen befinden. Auf den ersten Blick schrecken die 80.000 ERP Tabellen etwas ab. Zudem weiß man nicht, in wie vielen Tabellen die Einstellungen verstreut sind. Man ist gezwungen das altbekannte Analyseverfahren zu verwenden: SQL Trace anschalten, Transaktion ausführen, Ergebnis analysieren.

Da SAP bei jedem Bildwechsel wer-weiß-wie-viele Tabellenzugriffe macht, überlege ich mir, wie ich mir die spätere Analyse möglichst einfach machen kann. Wenn ich Einstellungen anlege oder ändere, dann kann ich meine Auswertung des Trace auf INSERT/UPDATE Einträge beschränken. Das sollte machbar sein.

Die ersten Versuche bringen schnell die Erkenntnis, dass das in einem produktiven System nicht ganz so einfach ist. Bestehende Einstellungen können teilweise nicht nochmal in anderem Kontext angelegt werden und wenn man nicht speichert, schreibt SAP nicht in die Datenbank. Die protokollierten SELECT Statements liefern indes erwartungsgemäß so viele verschiedene Tabellen, dass die Auswertung davon sinnlos wäre. Ich suche mir also ein leeres Testsystem und lege ein ALE Verteilungsmodell neu an.

Ich verifiziere, dass weder Partnervereinbarungen noch Ports existieren. Damit ich ein möglichst vollständiges Bild aller beteiligten Tabellen bekomme, erstelle ich eine mandantenübergreifende Verteilung mit BAPI und IDOC innerhalb des Systems. Nur die RFC Destinationen sind schon vorhanden. In diesen hinterlege ich meine Anmeldedaten, damit ich später den SQL-Trace einfacher filtern kann. Die Planung des Verteilungsmodells ist der komplizierteste Teil des Vorhabens. Ich rechne damit, dass die unterschiedlichen Nachrichtentypen bzw. BAPIs mit der Vielfalt an Partnerarten und Ports nicht alle in denselben Tabellen dargestellt werden können. Ich will aber wenigstens "meine" Landschaft vollständig sichern.

Bevor ich sichere, stelle ich der Transaktion ST05 denn SQL-Trace mit Filter auf meinem Namen ein. Dann verteile ich das Verteilungsmodell in den zweiten Mandanten. Zum Schluss müssen für Sender und Empfänger die Partnervereinbarung generieren werden. In einem leeren System werden damit alle Einstellungen aus den Transaktionen WE20/WE21 vorgenommen. Für einen vollständigen Trace ist entscheidend, dass noch keine Einstellung existierte. Ein sauberes Protokoll quittiert die erfolgreiche Anlage.

Am besten gleich den Trace wieder ausschalten, um ihn schön schlank zu halten. Außerdem bin ich neugierig und will ihn sofort auswerten. Ich reduziere den Trace mit der Funktion "Traceliste -> zusammengefasste Tabellenzugriffe" und filtere danach im Feld "Anweisung" nach "INSERT" und "UPDATE" Befehlen. Um Duplikate besser überspringen zu können, sortiere ich die Ausgabe nach Tabellenname.

Jetzt ist ein bisschen Kreativität und Erfahrung gefragt:

Ein Blick in die jeweilige Kurzbeschreibung der restlichen Tabellen über TA SE11 und ein Blick in den Tabelleninhalt bestätigen den Verdacht, dass sie alle gesichert werden müssen! Was man hier nicht sieht: Es ist enorm wichtig, dass man mit dem SQL-Trace echte Objekte beobachtet. So kann es in anderen Szenarien, bei denen die RFC-Schnittstelle mittels sog. BAPI-Reduzierung verkleinert wird, noch Einträge in den Tabellen TBDBR und TBDRF geben. Die hier verwendete Methode garantiert nämlich keine 100% Vollständigkeit, sie reicht lediglich für die eigene Umgebung aus.

Es lohnt sich auch immer, die "benachbarten" Tabellen im ABAP Dictionary anzuschauen, in diesem Fall also EDI*, EDP* und TBD* -> hier könnte man Anregungen finden, welche Sonder-Szenarien ggf. in andere Tabellen geschrieben werden. Z.B. finden sich Tabellen für Serialisierungsgruppen - aber die benutzen wir nicht… Aber wir finden dennoch fündig: Tabelle EDP21. Wir haben die Eingangsparameter-Einstellungen für den Empfänger der Kommunikation übersehen. Diese Parameter werden erst beim Generieren der Partnervereinbarung im Zielsystem (in diesem Fall Mandant 099) geschrieben. Der Vollständigkeit halber trace ich die Generierung und stelle fest, dass nur noch EDP21 gefehlt hat und nehme sie in meine Liste auf.

Stellt sich die Frage, wie man die Einstellungen sichert?

a) Mit einem SAP-Transport: Diese Variante ist geeignet, wenn man sich in der SE01 gut auskennt und eine einmalige Sicherung anfertigen möchte. Das erfordert ein bisschen Fleiß bei jeder Umsetzung und ohne Betriebssystem-Zugriff ist es die einzige Möglichkeit.

b) Export der Tabellen mit R3trans: Macht man vielleicht nicht so oft, kann man aber gut in einer Dokumentation zur Systemkopie. Es kann dann mittels Copy-Paste oder als Script angewendet werden. Für den Export wird eine ASCII Datei "export.ctl" auf SAP-Server benötigt.

export
client = all
file = 'ALE.export.data'
select * from EDIPOA
select * from EDIPORT
select * from EDP13
select * from EDP21
select * from EDPP1
select * from TBD00
select * from TBD00T
select * from TBD05
select * from TBD06
select * from TBDBR
select * from TBDBRF

Der Export erfolgt mit

sidadm > R3trans export.ctl

Details gibt es im Protokoll "trans.log". Für den Import wird eine weitere ASCII Datei "import.ctl" benötigt.

import
file = 'ALE.import.data'
buffersync = yes

Nach der Systemkopie können die Daten mit dieser wieder importiert werden

sidadm > R3trans import.ctl

Ein Blick in den Source-Code unseres Mandantenkopier-Tools gibt mir letzte Gewissheit: Wir sichern die ALE-Einstellungen vollständig! Das bedeutet, wir können die aufwendige "Sicherung" und anschließende Kontrolle über Screenshots in Zukunft komplett weglassen – und wenn etwas fehlt, dann hat es vor der Kopie auch schon gefehlt.