Package Studio Tutorial Teil 2 - Das geht uns noch nicht weit genug
Interne Kunden und Konsumenten von Datenextraktionen sind wie Kinder. Erstmal einfach zufrieden zu stellen, aber wenn sie sich eine Zeit lang mit etwas beschäftigt haben wird die Zufriedenheitsschwelle nach unten durchstoßen und sie wollen mehr. Es war also keine Überraschung, dass auch der Einkauf nach einigen Tagen sich wieder bei mit meldete.
"Hallo Nils, die Daten der Bestellungen sind grundsätzlich super, aber wir bräuchten noch die ein oder andere Ergänzung. Zum Einen würden wir gerne sehen, welche Änderungen zu diesen Bestellungen und den Positionen vorgenommen worden sind. Zum anderen haben wir festgestellt, dass die Bestelltabellen EKKO und EKPO auch Kontrakte und Anfragen beinhalten. Da würden uns tatsächlich die Bestellungen und Lieferpläne reichen. Allerdings würden wir gerne zu den Bestellungen die Kontrakte in einer separaten Tabelle haben. Und zwar alle Kontrakte, die einer Bestellung zum letzten Jahr zu Grunde liegen, also durchaus auch aus Vorjahren. Geht das?"
Geht nicht, gibt's nicht - also ran ans Werk.
Ich erkenne drei Anforderungen:
- die Bestelltabellen nur auf Bestellungen und Lieferpläne filtern
- die zu Grunde liegenden Kontrakte auch aus Vorjahren in eigene Tabellen extrahieren
- alle Änderungen der Bestellungen und Lieferpläne
Ein Fixfilter geht fix
Anforderung 1 ist relativ einfach umzusetzen. Es geht hier um den Bestelltypen im Feld BSTYP, den wir filtern müssen. Da dies SAP-Standard Setup ist und in der Regel auch nicht keinem Customizing unterliegt, wissen wir, dass wir auf die Werte F für Bestellung und L für Lieferplan filtern können.
Dazu erzeugen wir einen neuen Filter vom Typ FixedValue, tragen die beiden Werte unter Values ein und weisen ihn dem Feld BSTYP in der EKKO zu.
Somit wäre der Scope bereinigt auf die gewünschten Bestelltypen. Da wir alle anderen Tabellen mittles Repositories extrahieren, müssen wir hier nichts weiter anpassen.
Die Abhängigkeit von der Abhängigkeit
Das Füllen von Repositories beschränkt sich nicht auf die erste bzw. oberste Ebene der Tabellen. Eine Tabelle die bereits als Ziel eines Repository fungiert, kann dabei gleichzeitig auch als Quelle eines weiteren Repository dienen. Dies machen wir uns beim Selektieren der Kontrakte zu nutze.
Die Referenz auf eine Kontraktposition verbirgt das SAP-Datenmodell in den Bestellpositionen bzw. der Tabelle EKPO. Streng genommen ist diese Referenz Positionsgenau, aber wir werden das vereinfachen und den kompletten Kontrakt extrahieren mit allen Positionen, sofern er in der EKPO als Referenz vorkommt.
Zuerst erzeugen wir also ein weiteres Repository in dem wir die Kontraktnummern (EKPO-KONNR) sammeln.
Da die Kontrakte und deren Positionen selbst in den Tabellen EKKO und EKPO gespeichert werden, wird es jetzt etwas kniffelig. Da der Einkauf die Kontraktdaten in eigenen Tabellen will, müssen wir schonmal eine weitere EKKO und EKPO anlegen. Da das Package Studio eine Eindeutigkeit für das Schreiben in den SQL Server braucht, müssen wir hier zum Ersten mal einen Tabellenalias verwenden.
Wir geben beiden Tabellen also den Suffix '_Kontrakte' und wählen wieder alle Felder aus.
Jetzt kommt der etwas kompliziertere Teil. Wir haben im Repository das Feld EKPO-KONNR gesammelt. Dies verweist nun in den Kontrakttabellen aber auf das Bestellnummernfeld EBELN. D.h. wir müssen beim Zuweisen des Repository ein Feldmapping vornehmen.
Dazu fügen wir das Repository der Kontrakte als Dependency bei der Tabelle EKKO hinzu, klicken auf das 'A' für das Mapping, setzen den Haken bei Custom Mapping und ändern das Feld rechts von KONNR auf EBELN.
Den gleichen Vorgang wiederholen wir bei der Tabelle EKPO.
Ein erstes Date mit den Änderungsbelegen
Kommen wir zur letzten Anforderung: alle Änderungen der Bestellungen und Lieferpläne im Scope. Änderungen an Stamm- und Transaktionsdaten führen uns immer in die Tabellen CDHDR (Change Document Header) und CDPOS (Change Document Position).
Mit diesem Wissen beschließen wir, beide Tabellen CDHDR und CDPOS mit einem FixValue Filter auf die Objektklasse "EINKBELEG " zu filtern und das bereits aufgebaute Repository der Einkaufsbelegnummer zu verwenden, um nur die Belege im Scope zu Filtern.
Hier müssen wir eine kurzen Blick in die Datenstrukturen der SAP-Tabellen werfen. Des Feld EBELN in der EKKO hat 10 Stellen und das Feld OBJECTID in der CDHDR und CDPOS, auf das es gemapped werden muss, hat 90 Stellen. D.h. also hier müssen wir zusätzlich zum Mapping auch noch eine Transformation verwenden.
Beim Anlegen der Tabellen CDHDR und CDPOS vergeben wir einen Alias und nennen sie jeweils _EINKBELEG um zu indizieren welche Objektklasse wir gefiltert haben.
Wir erstellen den Filter ObjClass_Einkbeleg und lassen die Standardwerte auf "Fixed Value", "String", "Equal" und "Global" stehen. Als Value tragen wir EINKBELEG ein. Danach weisen wir ihn den beiden Änderungstabellen zu.
Im letzten Schritt springen wir zum Repository Repo_Einkaufsbeleg und ergänzen die CDHDR_EINKBELEG und die CDPOS_EINKBELEG als Target Tables. Dazu stellen wir das Mapping auf Custom um. wählen das Feld OBJECTID und die Transformation Substring mit den Werten 10 und 0 bei Länge und Offset.
Das gleich wiederholen wir für die CDPOS_EINKBELEG und am Ende erhalten wir ein um die Anforderungen des Einkaufs erweitertes Package.
Ob es das schon gewesen ist? Ich mach jetzt erstmal ne Testextraktion.
Weiter geht es mit Teil 3, denn jetzt wird es langsam komplex...
