SAP PO verwendet eine Vielzahl von Abkürzungen und Begriffen. Die folgende Aufstellung soll helfen, sich im SAP PO besser zurecht zu finden.

• Advanced Adapter Engine (AAE): ist der Name einer zentralen Komponente im SAP PO. Diese Engine (englisch für motor) ist der Enterprice Services Bus. Die AEE verschickt Nachrichten von A nach B und von C nach D. Bei Bedarf werden die Nachrichten auch von einer technischen Struktur in eine andere technische Struktur übersetzt.
• Advanded Adapter Engine Extended (AEX): Sammelbegriff für die AAE, das Integration Directory, das ESR und das Monitoring des PO).
• BPE: diese Komponente verarbeitet die Regeln aus dem ccBPM
• Business Process Management (BPM): Nachfolger von ccBPM. Dient zur Prozessdefinition.
• BPMN: Business Process Modeling Notation: Darstellungsform von Geschäftsregeln in einer standardisierten Form. Sie stammt nicht von SAP, sondern von der Object Management Group (OMG). SAP hat sie dann unter dem Namen BPM implementiert.
• BRM: Business Rules Management: dient zur Implementation von Geschäftsregeln
• Business-System: Ein internes System (on-premise, sonst ggf. noch ein eigenes Cloudsystem), mit dem im Rahmen des PO gearbeitet werden kann. Es ist zu unterscheiden von dem technischen System. Das Business-System ist quasi ein „logisches System“. Der Nachrichtentransfer im PO erfolgt Businesssystemen und nicht mit technischen Systemen. Das erlaub es beispielsweise, ein technisches System neu aufzusetzen und einen Teil der darauf beannten Businesssysteme umzuziehen.
• ccBPM (Komponentenübergreifendes Business Process Management): ein mittlerweile veraltetes System zur Ausführung von Geschäftslogik. Ist im AS Java ersetzt durch das BPM (SAP Business Process Management). Es gibt keine automatische Migration. Man muss die Logig im neuen System nachprogrammieren.
• Datentyp/data type: Unterster Baustein im ESR. Besondes wichtig sind aggregierte Datentypen. (Das ist das PO-Äquivalent zu einem struct.)
• Eclipse: Quelloffene Entwicklungsumgebung für diverse Programmiersprachen. SAP hat hiervon eine eigene Variante herausgebracht, die es erlaubt, auch PO-Objekte zu bearbeiten, das NWDS
• Enterprice Services Builder (ES Builder): Java-Swing basiertes Programm zum Bearbeiten von Objekten im ESR. Wird in Zukunft durch Eclipse abgelöst.
• Enterprise Services Bus (ESB): Ein Verfahren zur Integration verschiedener Systeme. Es gibt ein zentrales System, mit dem alle anderen Systeme reden. Jedes externe System braucht damit nur noch die Verbindung zu einem einzigen anderen System, dem Bus. Dies hat Vorteile gegenüber der Punkt-zu-Punkt-Integration.
• Enterprise Services Repository (ESR): eine der zentralen Komponenten von SAP PO. Das ESR ist eine Datenbank von Servicebeschreibungen. Beschrieben werden Schnittstellen, die darin verwendeten Datenstrukturen sowie Mappingregeln, wie eine technische Datenstruktur ggf. in eine andere zu übersetzen ist. Zwischen den 3 Systemen Entwicklung, Test, Produktion bzw. Development, QA und Production sind die Daten des ESR nach der Inbetriebnahme gleich. Das ESR ordnet alle Objekte jeweils einer Softwarekomponente zu. Diese sollten auch im SLD bekannt sein. Daher: erst im SLD anlegen und dann ins ESR importieren. Das ESR beantwortet damit auch die Frage, welche Schnittstellen gehören zu welcher Softwarekomponente.
• ICM (Internet Communication Manager): Bestandteil vom SAP ERP zur Kommunikation mittels HTTP/HTTPS/SMTP. Wird damit auch zur Kommunikation mit dem PO benötigt.
• IDoc: „intermediate document“, Ein Objekt zum Datenaustausch zwischen SAP-ERP-Systemen (ABAP-Systemen). Im ABAP-System ist die Darstellung eine andere, aber nach Außen wird das IDoc als ein XML-Dokument formatiert und kann von externen Systemen dann wie jedes andere XML-Dokument behandelt werden.
• Integration Builder (IB): Java-Swing basiertes Programm zum Bearbeiten von Objekten aus dem Integration Directory. Wird zukünftigt durch Eclipse abgelöst. Ich finde aber, es arbeitet sich im IB übersichtlicher als in Eclipse.
• Integration Directory (ID): eine der zentralen Komponenten von SAP PO: es ist eine Datenbank mit Informationen über verschiedene Systeme, über die dort bereitgestellten Schnittstellen und darüber wie diese angesprochen werden können. Diese werden zu sog. „Szenarien“ gruppiert. Zwischen Entwicklung, Test und Produktion gibt es hier (anders als im ESR) typischerweise Unterschiede: die angeschlossenen SAP-Systeme sind verschieden. Bei FTP-Verbindungen (sofern man ein Testsystem hat…) sind die Server andere, oder zumindest die Verzeichnisse, auf denen gearbeitet wird. Diese sind DAUERHAFT verschieden. Deshalb gibt es bei den Swing-Werkzeugen auch zweie: den ESB und den ID. Im Eclipse sind beide gleichermaßen bearbeitbar, sie sind nur in zwei Eclipse-Perspektiven getrennt.
• ICO (Integrierte Konfiguration): Zentrale Struktur im Integration Directory, Welcher Kommunikation im Sendersystem schickt die Nachricht? An welches System (oder an welche Systeme) wird die Nachricht gesendet? Über welchen Empfängerkanal geht die Nachricht raus.
• IE: diese Komponente verarbeitet die Nachrichten gemäß den Regeln aus dem Integration Directory (IE)
• Integration Designer: eine Perspektive im NWDS (Eclipse)
• IF/Integration Flow: ein grafischer Ansatz zum Design vom Nachrichtentransfer zwischen Systemen. Der IF schafft Übersichtlichkeit, er kann aber unterm Strich nicht mehr als eine Inegrierte Konfiguration. Er wird aber nicht direkt ausgeführt, sondern „deployt“. Deployment bedeutet, dass der IF in eine Integrated Configuration umgesetzt (verstehe das als Programmierer als „compiliert“) wird. Das heißt auch: wenn man das macht, wird in Zukunft der IF bearbeitet und nicht mehr die autogenerierte IC.
• Mapping: Umsetzen von Daten eines Interfaces zur passenden Datenstrukur eines anderen Interfaces. Der Bedarf daran entsteht oft. Vielleicht steht in der sendenden Schnittstelle „matnr“ und in der empfangenden heißt das Feld „artikel“? Mappings lassen sich vielfältig erstellen. Häufig verwendet wird ein grafischer Mapper, der daran krankt, dass man keine Kommentare verwenden kann. Außerdem werden unterstützt Java (bei sehr komplexen Aufgaben sehr hilfreich, könnte man dann gerne häufiger verwenden), XSLT (eine sichere Arbeitsbeschaffungsmaßnahme für die Zukunft, weil kaum jemand heutzutage so viel XSLT programmieren kann, dass man darin Fehler suchen kann) und ABAP (allerdings nicht mehr ab PO 7.5, also Finger weg bei der Neuentwicklung). Man kann mappen: Strukturen (andere Namen, anderer hierarchischer Aufbau der Datenstruktur), aber auch Werte ( 001 auf der einen Seite, 19% auf der anderen Seite).
• Namensraum/name space: ein Ordnungskriterium im ESR. An sich ist es ein praktisch beliebiger String. Üblich ist es aber, den Webdomainnamen einer Firma mit aufzunehmen. Alle Schnittstellenobjekte im ESR haben einen Namensraum, zu dem sie gehören. Das erlaubt es, verschiedenen Firmen denselben Namen wie „MT_message“ wiederzuverwenden, ohne dass es zwischen ihnen zu konflikten kommt.
• Nachrichtentyp/message type: Wichtiger Baustein im ESR. Schnittstellen/Interfaces verwenden message types. Der Message type selbst hat genau einen Datentyp. Dies ist in der Regel ein aggregierter Datentyp. Mehrere Messagetypes können denselben Datentyp verwenden. Das ist dasselbe Prinzip wie in ABAP das Datenelement im Vergleich zur Domäne.
• NWA: Netweaver Administrator. Eine Weboberfläche zur Administration des PO,
• NDWS: SAP Netweaver Developer Studio: eine von SAP bereitgestellte Variante der quelloffenen Entwicklungsumgebung Eclipse (www.eclipse.org), die es erlaubt Objekte im PO zu bearbeiten. Dieses Eclipse kann weiterhin alles, was Eclipse von Haus aus kann, also z.B. Javaentwicklung. SAP hat aber mehrere SAP-spezifische „Perspektiven“ (so der Eclipse-Begriff) hinzugefügt: Process Development, Rules Composer, Process Integration Designer, Enterprise Services Repository.
• Produkt: Betriff aus SLD und ESR: eine Bündelung von mehreren Softwarekomponenten, die gemeinsam ausgeliefert werden. Auch Produkte können versioniert werden. Im Laufe der Zeit ändert sich dabei ggf. auch die Liste der enthaltenen Komponenten. Einige kommen hinzu, andere fliegen raus. Merkhilfe: installiert wird das Produkt.
• Punkt-zu-Punkt-Integration: das Gegenteil vom Enterprise Services Bus: jedes System redet mit jedem anderen System direkt.
• SAP Process Orchestration: SAP-Marketingbegriff für das Sammelpaket aus Process Integration (PI), Business Process Management (BPM) und Business Rules Management (BRM)
• SAP-GUI: Programm zum Zugriff auf ein SAP-System (ABAP)
• Service Interface: ein Grundbegriff im ESR. Es modelliert einen Punkt in einem System, aus dem Nachrichten herauskommen oder in das Nachrichten hineingehen. Unterschieden werden: inbound und outbound bzw. Sender und Empfänger/Receiver. Betrachtet wird dies IMMER aus Sicht des externen Systems. Das produziert immer wieder einen Knoten im Hirn. Man wollte beim Design des PO nicht der Nabel der Welt sein, auch wenn man das als Zentralkomponente des Enterprise Services Bus eigentlich ist. Ein Sendersystem ist ein externes System, das eine Nachricht an das PO sendet. Das PO empfängt diese Nachricht, dieses Interface ist aber outbound, weil das externe System sendet. Ein Interface, bei dem eine Nachricht vom PO zum externen System gesendet wird, ist inbound, weil das externe System diese Nachricht empfängt. Diese Sichtweise sollte man bis zur vollen Geläufigkeit wiederholen. In älteren Systemen funktioniert die Verarbeitung ggf. auch dann, wenn die Kategorie falsch herum ist. Man muss aber damit rechnen, dass dies bei neueren Systemen richtig gemacht werden muss. Ganz zentral ist es bei F4-Auswahlhilfen. Diese filtern strikt nach inbound vs. outbound. Wenn also in einer Auswahlliste ein Wert nicht drinsteht, der drinstehen sollte, dann ist der erste Kandidat für die Fehlersuche ein Dreher zwischen inbound und outbound.
  Der Datentransfer im PO geschieht immer von einem outbound-Interface zu einem (oder mehreren) inbound-Interfaces. Ein Service Interface sollte schon im Namen erkennbar ein inbound/outbound haben. Wie genau hängt von den Namensvorgaben des Kunden ab. Ein nachgestelltes _outb oder _inb kommt vor. Oder ein _i vs. _o. Service Interfaces gehören immer zu einer Softwarekomponentenversion. Service Interfaces können auf drei Wegen ins ESR kommen:
  • Anlegen von Service Interface und enthaltener Service Operation
  • Import einer externen Definition (WSDL, XSD, DTD)
  • Import eines Objekts (IDoc oder RFC)
• Serviceorientierte Architekture (SOA), englisch: service-oriented architecture
• Schnittstelle/interface: allgemeine Bezeichnung für einen Punkt, an dem Daten ausgetauscht werden.
• Single Stack vs. Dual Stack: SAP-Bezeichnung für eine Softwareinstallation. Zu unterscheiden sind AS Java von AS ABAP. Das PO war ursprünglich in ABAP programmiert. Später kam eine parallele Entwicklung in Java hinzu. Ab PO 7.5 wird nur noch der AS Java verwendet. Das bedeutet: ABAP Mappings sind nicht mehr möglich und müssen gegen andere Mappings ausgetauscht werden.
• Softwarekomponente: Begriff aus SLD und ESR: eine modulare Einheit, die in mehreren Produkten eingesetzt werden kann. Die Möglichkeit, sie in mehreren Produkten einzusetzen, wir außerhalb von SAP nur selten verwendet. Eine Softwarekomponente kann mehrere Versionen haben. In dem Augenblick, in dem man das tut, schafft man meistens Unordnung. In einem Fall aus der Praxis bin ich einem System begegnet, in dem mehrere Stufen der Entwicklung neuer Schnittstellen jeweils in eine neue Komponentenversion gepackt wurden. Die Version 2 enthielt aber nur Schnittstellen, die an dieser Stufe neu waren. Es handelte sich noch nicht einmal um einen Ersatz für Schnittstellen aus der Stufe 1. Dafür ist das aber nicht da. Die Idee von Versionen ist schon die, dass man am Ende im Produktivsystem entweder die eine oder die andere im Betrieb hat, aber nicht mehrere.
• Szenario: Begriff aus dem Integration Directory: eine Gruppierung von Systemen und Schnittstellen. Diese können je nach Bedarf auch in mehreren Szenarien enthalten sein. Die Szenarien stellen sich daher als ein Ordnungssystem heraus. Es schafft übersicht, es funktioniert aber auch alles, ohne dass man diese Objekte verschiedenen Szenarien zuweist.
• System Landscape Directory (SLD): das SLD gibt es auch außerhalb vom PO. Es ist aber für das Funktionieren des PO ausgesprochen wichtig. Es ist eine Datenbank mit Informationen über interne Systeme („on premise“) und darüber, welche Softwarekomponenten auf diesem Systeme installiert sind. Damit wird auch festgelegt, welche Schnittstellen auf welchem System überhaupt möglich sind. Unterschieden werden
  • technische Systeme
  • Businesssysteme
  • Softwarekatalog, bestehend aus Produkten und Softwarekomponentenversionen)
• technisches System: tatsächlich real existierendes System, das im SLD bekannt ist.
• UDF (user-defined function): ein Begriff aus dem grafischen Message-Mapper. Hier kann man eigene Funktionen hinzufügen, die in Java programmiert werden. Dies sind dann „benutzerdefinierte Funktionen“. Bei komplizierten Sachverhalten im Mapping ist es ggf. einfacher, diese mit ein paar Zeilen Java zu realisieren, statt einen ganzen Zoo von grünen Kästchen zu malen.