Package Studio Tutorial Teil 1 - Ein Anruf vom Einkauf
"Hallo Nils, kannst Du uns bitte die Bestellungen des kompletten letzten Jahres für den Buchungskreis DAB1 in einer Datenbank zur Verfügung stellen. Waren- und Rechnungseingänge bitte inklusive. Und ein paar Details zu den Lieferanten wäre auch toll. Ich hoffe das klappt bis heute nachmittag? Danke!"
Wer kennt es nicht, kurzfristige und messerscharf formulierte Anforderungen aus dem Fachbereich, die am Besten gleich gestern schon erledigt gewesen wären.
Aber gut, legen wir los - so komplex kann das schon nicht sein.
Die erste wichtige Entscheidung
Nach Erstellen des Paketes, dem Auswählen eines halbwegs sprechenden Namens und dem Füllen einer kurzen Beschreibung, befinden wir uns im Package Designer auf der sogenannten grünen Wiese.
Die erste grundlegende Entscheidung, die zu treffen ist, ist welches SAP System wir für das Erstellen des Paketes verwenden. Da ausgewählte System ist unten links in der Visualisierungsfläche zu erkennen und kann bei Bedarf im Menü ob unter "SAP System" > "Switch to" geändert werden. Wir belassen es in diesem Fall beim S/4 HANA System, weil sich besagter Buchungskreis DAB1 auf genau diesem befindet.
Die ersten Tabellen
Wenn ich die Anforderung der Kollegen nochmal Revue passieren lasse, dann kommen da die Begriffe Bestellungen, Waren- und Rechungseingang und Lieferant vor. Als erfahrener SAP-Datenanalyst weiß ich sofort in welche Tabellentöpfe ich also greifen muss:
- EKKO für die Bestellköpfe
- EKPO für die Positionsdetails
- EKBE für die Bestellhistorie, also Waren- und Rechnungseingang
- LFA1 für die Lieferantenstammdaten
Wir betätigen also das kleine Tabellensymbol mit dem Plus, tragen den ersten Tabellennamen ein und wählen ihn aus der Liste aus.
Da die Kollegen nicht genauer spezifiziert haben, welche Informationen sie genau haben möchten, wähle ich den einfachen Weg und selektiere auf der rechten Seite der Tabellendetails erstmal alle Felder.
Diesen Prozess wiederholen wir auch für die anderen 3 Tabellen und haben anschließend eine Liste von 4 Tabellen mit jeweils voller Feldauswahl.
Alles ist zuviel - wir müssen filtern
Da unser System Daten von sowohl früheren Zeiträumen, als auch anderen Buchungskreisen beinhaltet, müssen wir unser Paket, bzw. die Tabellen filtern, wo es möglich ist.
dab Nexus Package Studio erlaubt uns zum einen die Tabellen direkt zu filtern, indem ich bestimmte Werte auf bestimmte Felder anwende. Zum anderen ist dies aber nicht immer möglich und ich möchte Tabellen in Abhängigkeit zu anderen Tabellen filtern. Dies machen wir über sogenannte Dependencies zwischen Tabellen. Grundlage einer Dependency ist immer ein Repository, welches eine Liste an Werten oder Wertkombinationen enthält, die in einer Tabelle gesammelt werden, um in der anderen Tabelle bei der Filterung Verwendung zu finden.
Beginnen wir mit dem einfacheren Teil, dem Filtern.
Ein Filter für den Extraktionszeitraum
Ich möchte einen Filter für den Extraktionszeitraum anlegen. Dafür drücke ich das kleine Filtericon mit dem Plus oben links und vergeben einen Filternamen - hier "Extraction Period".
Im Detailbereich zum Filter auf der rechten Seite konfiguriere ich nun die Verwendung des Filters.
Den Mode "Initial/Delta/Initial&Delta" ignorieren wir vorerst genauso wie die Optionen Required und Offline. Eine Erklärung zu diesen Optionen erfolgt an späterer Stelle.
Die erste wichtige Option ist der Type. Hier stehen uns mit Input, Fixed Value und Well Known drei Optionen Möglichkeiten zur Verfügung.
Die Frage die der Packagedesigner sich hier stellen muss ist, ob ein Filterwert beim Erstellen des Tasks festgelegt werden soll, oder unveränderbar im Package fixiert sein soll.
Ist letzteres der Fall, wählen wir den Type "Fixed Value" und legen den oder die fixen Werte fest.
Wollen wir erst beim Erstellen des Extraktionstasks die Werte eingeben, wählen wir Input und im Anschluss den DataType.
Wollen wir den Wertebereich der Eingabe auf Werte beschränken, die vom SAP-System vorgegeben werden, nutzen wir die vordefinierten "Well-Known" Filter. Diese werden beim Buchungskreis näher erklärt.
Da wir unserem Package die Flexibilität geben wollen, auch andere Zeiträume abzudecken als nur fix das letzte Jahr, wählen wir "Input". Anschließend stellen wir den DataType auf "Date" und die Condition auf "Between", da wir einen von/bis Zeitraum abdecken wollen.
Den Scope "Global/System" verwenden wir, um in der Lage zu sein bei einer Multi-System Extraktion in der Lage zu sein, Filter individuell pro System setzen zu können. Ein Extraktionszeitraum ist ein klassischer globaler Scope.
Zu guter Letzt müssen wir dem Package noch mitteilen, wie der Filter verwendet wird. In unserem Fall wollen wir Bestellungen nach Erstelldatum filtern und weisen ihn also der Tabelle EKKO und dem Feld AEDAT zu.
Filtern auf den Buchungskreis
Der zweite Filter, den wir benötigen, ist ein Filter auf den vom Einkauf gewünschten Buchungskreis DAB1. Auch hier ist es so, dass wir dieses Package so bauen wollen, dass es in der Zukunft wieder verwendbar ist.
Wir vergeben den Buchungskreis DAB1 also nicht als fixen Filterwert, sondern wollen beim Erstellen des Extraktionstasks den oder die Buchungskreise eingeben können. dab Nexus kann uns dabei bei der Auswahl von Werten behilflich sein, indem es uns eine Werteliste aus dem verbundenen SAP-System liefert, aus der wir auswählen können. Dieser Filtertyp nennt sich "Well Known".
Bei Well-Known wählen wir "Company Code" für den Buchungskreis, der Scope ist "System" weil die Buchungskreise eben systemspezifisch sind und abschließend weisen wir den Filter dem Feld BUKRS in der Tabelle EKKO zu.
Damit haben wir den Grundscope eigentlich abgedeckt. Alle Bestellungen (EKKO) zu einem bestimmten Zeitraum (letztes Jahr) für den Buchungskreis DAB1. D.h. unsere Tabelle EKKO wird nach der Extraktion alle benötigten Einträge beinhalten.
Dann widmen wir uns den "abhängigen" Tabellen.
Die ersten einfachen Repositories
Wie erwähnt beinhaltet unsere gefilterte Bestellkopftabelle EKKO jetzt alle Datensätze, die für den Einkauf relevant sind und wir können die anderen Tabellen auf Basis der EKKO filtern. Dazu verwenden wir Repositories. Ein Repositories sammelt Werte und nutzt diese gesammelten Werten dann, um die anderen Tabellen entsprechend einzugrenzen.
Wichtig dabei ist, zu verstehen über welche Felder die relevanten Tabellen miteinander zu verknüpfen sind. EKKO, EKPO und EKBE haben die Einkaufsbelegnummer als gemeinsames Feld und somit ist es logisch, alle in der EKKO Extraktion gesammelten Einkaufsbelegnummern aus den anderen Tabellen anzufordern.
Zu diesem Zweck erzeugen wir links ein neues Repository und benennen es entsprechend.
Ein Repository besteht immer aus mindestens einem Feld, das in ihm gesammelt wird. Es kann aber auch mehrere Felder enthalten. In unserem Fall wollen wir aus der EKKO alle Werte der Einkaufsbelegnummer sammeln. Technisch abgelegt sind die Werte im Primärschlüsselfeld EBELN der EKKO.
Wir ergänzen das Repository also um ein Feld und benennen es EBELN.
Abschließend muss ich dem Package noch mitteilen aus welcher Tabelle und welchem Feld / welchen Feldern sich das Repository speist (Source-Tables) und welche Tabellen und Felder daraus konsumieren (Target-Tables).
In unserem Fall sind es jeweils die Felder EBELN aus EKKO als Source und EKPO/EKBE als Target.
Das 'A' bei der Zuordnung indiziert, dass das Feld des Repositories automatisch einem technischen Feld der Tabelle zugeordnet werden konnte.
Jetzt fehlen uns also nur noch die Details zu den Lieferanten aus der Tabelle LFA1. Viele Extraktionen neigen dazu Stammdatentabellen wie die LFA1 in voller Gänze abzuziehen. Dies kann bei einem großen SAP-System und einem im Extremfall recht kleinen Buchungskreis aber ein ziemlich großer Overhead sein, den man unnötigerweise mit extrahiert. Aus diesem Grund arbeiten wir mit einem zweiten Repository, da die Lieferantennummer als Feld LIFNR in der EKKO vorhanden ist und wir damit ein zweites Repository erstellen können und so die LFA1 einschränken.
Damit haben wir unser erstes, kleines Extraktionspaket für den Einkauf mit den dab Nexus Package Studio erstellt.
Ob der Einkauf die Daten jetzt noch bis heute Nachmittag erhält, liegt nun an der Größe der Daten. dab Nexus mit seinem effizienten und intelligenten Extraktionsalgorithmus wird sein Bestes geben.
dab Nexus visualisiert uns auch entsprechend das Package und die Beziehungen untereinander.
Wie es aber fast immer der Fall ist, braucht der Einkauf nach einer ersten Sichtung der Daten aber noch mehr.
Im zweiten Teil geht es weiter, in dem wir das Package um einige Aspekte erweitern.
