Arensmeyer / Hegenbart SAP Integration Suite

Das Praxishandbuch
1. Auflage 2024
ISBN: 978-3-8362-9935-0
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Deutsch, 451 Seiten

Reihe: SAP Press

Verbinden und automatisieren Sie Ihre Geschäftsanwendungen mit der SAP Integration Suite. Lernen Sie die Funktionen der Plattform kennen und finden Sie heraus, wie Sie damit eine integrierte Unternehmenslandschaft verwalten. Sie nutzen noch SAP PO oder PI? Die Experten zeigen Ihnen, wie Sie Ihre Schnittstellen migrieren und für den Einsatz in der SAP Integration Suite optimieren.

Aus dem Inhalt:

• Plug-and-Play-Integration
• Cloud Integration
• B2B- und Drittanbieterintegration
• Integration Advisor
• Trading Partner Management
• API Management
• Open Connectors
• SAP Event Mesh und Advanced Event Mesh
• Integration Assessment
• Edge Integration Cell
• Cloud Connector
• PO/PI-Migration

Jan Arensmeyer hat einen Bachelor of Science in Wirtschaftsinformatik und ist seit 2015 als Berater und Entwickler in den SAP-Bereichen SD und Integration tätig. In diesem Kontext begleitete er mehrere Projekte auf der SAP-Plattform, die sich heute zur SAP Integration Suite entwickelt hat. Er beschäftigt sich, passend zu den beiden Fachrichtungen, mit der Anbindung von Webshops, mit der Integration in verschiedene CRM-Systeme sowie mit der Kommunikation mit Lieferantenportalen. Passend zum Thema Integration bildet er dabei stets ein wichtiges Bindeglied zwischen Fachbereichen und technischen Experten.

Autoren/Hrsg.

Arensmeyer, Jan

Hegenbart, Enrico

Inhaltsverzeichnis

Einleitung ... 13  1.  Einführung ... 19  1.1 ... Was ist Integration? ... 19  1.2 ... Konzept der Enterprise Application Integration ... 22  1.3 ... Integrationsmuster ... 24  1.4 ... SAP Integration Suite im Rahmen aktueller Trends ... 28  1.5 ... Historische Entwicklung der SAP-Integrationsplattformen ... 30  2.  SAP Business Technology Platform ... 33  2.1 ... Funktionen und Lizenzierung ... 34  2.2 ... Laufzeitumgebungen ... 36  2.3 ... Grundkonfiguration eines Tenants ... 37  2.4 ... Verwaltung des SAP-BTP-Accounts ... 40  2.5 ... Services und Instanzen ... 46  2.6 ... Destinationen ... 56  2.7 ... Zusammenfassung ... 57  3.  SAP Integration Suite auf einen Blick ... 59  3.1 ... Bedeutung der SAP Integration Suite ... 59  3.2 ... Architektur und Komponenten ... 60  3.3 ... Vorteile und Nachteile der SAP Integration Suite ... 69  3.4 ... Bedeutung des Apache Camel Frameworks in der SAP Integration Suite ... 70  3.5 ... SAP Integration Solution Advisory Methodology ... 73  3.6 ... Oberfläche ... 75  3.7 ... Zusammenfassung ... 97  4.  Plug-and-Play-Integration ... 99  4.1 ... Vordefinierte Pakete mit dem SAP Business Accelerator Hub ... 99  4.2 ... SAP Discovery Center ... 104  4.3 ... GitHub-Integration für Best Practices und Code-Beispiele ... 109  4.4 ... Zusammenfassung ... 116  5.  Cloud Integration ... 117  5.1 ... Artefakte, Integrationsobjekte und Adapter ... 117  5.2 ... Simulieren, Testen und Debuggen ... 190  5.3 ... Kundenspezifische Adapter entwickeln ... 198  5.4 ... Designrichtlinien zur Anwendung von Komponenten ... 209  5.5 ... Zusammenfassung ... 214  6.  B2B- und B2G-Integration ... 215  6.1 ... Integration Advisor ... 216  6.2 ... Trading Partner Management ... 235  6.3 ... Zusammenfassung ... 250  7.  Drittanbieterintegration ... 251  7.1 ... API Management ... 252  7.2 ... Open Connectors ... 287  7.3 ... Zusammenfassung ... 304  8.  Enterprise Messaging ... 305  8.1 ... Eventgesteuerte Architektur ... 305  8.2 ... SAP Event Mesh ... 312  8.3 ... SAP Integration Suite, Advanced Event Mesh ... 334  8.4 ... Beispiel einer Industrie-4.0-Integration mit Event Mesh ... 336  8.5 ... Zusammenfassung ... 338  9.  Cloud Connector ... 339  9.1 ... Grundlagen ... 339  9.2 ... Wichtigste Einstellungen ... 340  9.3 ... Principal Propagation ... 344  9.4 ... Zusammenfassung ... 346

10.  Hybride Szenarien ... 347  10.1 ... Cloud Integration Content in SAP Process Orchestration ... 348  10.2 ... Edge Integration Cell ... 359  10.3 ... Zusammenfassung ... 373

11.  Migration von SAP Process Orchestration nach SAP Integration Suite ... 375  11.1 ... Verbindung über den Cloud Connector einrichten ... 376  11.2 ... Einzelne Integrationsobjekte migrieren ... 382  11.3 ... Migration von ABAP-Proxys ... 389  11.4 ... Migration Assessment und Migration Tooling ... 396  11.5 ... Zusammenfassung ... 407

12.  Praxisbeispiele ... 409  12.1 ... API für Aufträge anbieten ... 409  12.2 ... Metriken für das API Management ... 423  12.3 ... Groovy-Code-Snippets ... 426  12.4 ... Z-Feld-Erweiterung von Standardschnittstellen ... 431  12.5 ... Zusammenfassung ... 436  Anhang ... 437  A ... Glossar ... 437  B ... Abkürzungsverzeichnis ... 443  Autoren ... 445  Index ... 447

Leseproben

1.3    Integrationsmuster

Integrationsmuster sind bewährte Lösungsansätze für typische Probleme, die bei der Integration von Systemen, Anwendungen und Daten auftreten können. Diese Muster bieten Ihnen einen Leitfaden oder eine »Blaupause« für die Gestaltung von Schnittstellen. Wie bereits beschrieben, hilft es, wenn Sie für Ihre Unternehmensschnittstellen Standards definieren. Etablierte Vorlagen und Muster helfen Ihnen dabei, schnell auf neue Anforderungen zu reagieren. Jedes Muster bietet Ihnen jeweils ganz eigene Vor- und Nachteile und ist für bestimmte Anwendungsfälle geeignet. Neue Anforderungen können Sie kategorisieren und sparen dadurch viel Zeit bei der Implementierung neuer Schnittstellen. Die Muster etablieren sich außerdem mit der Zeit, und Sie können diese weiter optimieren und weitere Verbesserungen in Ihre Vorlagen einbauen. Dies hilft Ihnen langfristig, robuste und performante Schnittstellen bereitzustellen. Integrationsmuster dienen vor allem aber auch als gemeinsame Sprache für ganze Teams von Entwickler*innen und Architekt*innen. Sie erleichtern die Kommunikation und sorgen dafür, dass die Entwicklungs- und Integrationsprozesse klar dokumentiert sind. Wenn in Ihrem Unternehmen alle auf die gleichen Vorlagen und Standards zurückgreifen, erspart es Ihnen Einarbeitungszeit, wenn Sie Schnittstellen Ihrer Kolleg*innen analysieren oder erweitern sollen. Im Folgenden möchten wir Ihnen daher einige gängige Schnittstellenmuster sowie ihre Vor- und Nachteile und typische Einsatzzwecke näherbringen.

Eines der wichtigsten Merkmale dabei ist, ob es sich um eine synchrone oder um eine asynchrone Kommunikation handeln soll. Dies bezieht sich auf die Art und Weise, wie Daten zwischen verschiedenen Komponenten oder Systemen übertragen werden. Bei der Definition Ihrer Schnittstellen sollten Sie sich die Fragen stellen, ob eine direkte Rückmeldung des Empfängers zwingend erforderlich ist und ob das Empfängersystem überhaupt in der Lage ist, eine Rückmeldung in einem angemessenen Zeitfenster zu liefern. Bei der Eingabe einer PIN am Bankautomaten möchten Sie z. B. direkt wissen, ob die Geheimzahl korrekt eingegeben wurde und andernfalls den Prozess abbrechen.

Synchrone Schnittstellen funktionieren in der Art, dass das Quellsystem auf eine direkte Rückmeldung wartet. Aus diesem Grund eignen sich solche Schnittstellen eher für kleinere Datenmengen. Je größer die Datenmenge, desto länger dauert die Verarbeitung im Zielsystem und desto länger wartet das Quellsystem auf eine Rückmeldung. Dies blockiert gegebenenfalls sogar den Prozess bzw. die Schnittstelle, sodass in der Zwischenzeit keine weiteren Daten gesendet werden können. Eine neue Anfrage kann erst gesendet werden, nachdem der aktuelle Aufruf beendet worden ist (siehe Abbildung 1.3).

Abbildung 1.3     Synchrone und asynchrone Kommunikation

Auf der anderen Seite ermöglicht die Rückmeldung eine direkte Reaktion des Quellsystems. Dieses kann auf die Antwort des Zielsystems reagieren und im Falle eines Fehlers z. B. die Daten erneut senden oder die Kommunikation pausieren, bis der Fehler behoben ist. Je nachdem, welche Anforderungen Sie an die Schnittstelle haben, können Sie den Prozess mit einer synchronen Kommunikation sehr gezielt steuern. Eine asynchrone Kommunikation eignet sich hingegen eher für große Datenmengen. Das Quellsystem überträgt alle Daten und trennt anschließend die Verbindung zum Zielsystem. Es wird nicht abgewartet, ob die Daten verarbeitet werden können oder ob es im weiteren Verlauf gegebenenfalls zu Fehlern kommt. Dadurch sind Schnittstellen dieser Art schneller wieder bereit, weitere Daten zu senden. Alle folgenden Kategorien fallen in eines dieser beiden Muster.

Pull-Schnittstellen (vom engl. »ziehen«) sind eine Art der Schnittstellenarchitektur, bei der die Initiative für den Datenaustausch von Empfänger oder Verbraucher ausgeht. Anders ausgedrückt: Der Empfänger zieht oder fordert Daten aktiv von der Quelle an, wenn er bereit ist, sie zu empfangen. Der Empfänger bestimmt also den Bedarf an neuen Daten bzw. den Zeitplan der Kommunikation. Diese Vorgehensweise eignet sich besonders für die Übertragung von Massendaten, indem der Empfänger in einem definierten Zeitrhythmus alle relevanten Daten auf einmal anfordert. Hierbei sind zwei Sonderfälle zu berücksichtigen, nämlich dass zum Zeitpunkt der Nachfrage entweder keine Daten vorliegen – der Empfänger fragt also unnötig an – oder dass zum Zeitpunkt der Nachfrage sehr viele Daten vorliegen. Beide Fälle können zulasten der Performance gehen, und sollten daher bei der Implementierung berücksichtigt werden. Ein typisches Beispiel für Pull-Schnittstellen sind RESTful Web Services, bei denen der Client mittels eines HTTP-Aufrufs aktiv Ressourcen von einem Server anfordert. Pull-Schnittstellen werden oftmals in Umgebungen verwendet, in denen die Datenübertragung nach Bedarf und nach einem definierten Zeitplan erfolgt. Dabei ist es weniger relevant, ob zeitnah neue Daten übertragen werden sollen.

Im Gegensatz dazu geht die Kommunikation bei der Verwendung von Push-Schnittstellen von der Quelle aus. Anders ausgedrückt: Die Daten werden aktiv von der Quelle zum Empfänger geschoben, unabhängig davon, ob dieser bereit ist, diese zu empfangen. Dabei hängt es von der Konfiguration des Sendersystems ab, ob in der Push-Kommunikation einzelne Datensätze oder Massendaten übertragen werden. Das IDoc-Format aus dem SAP-Kontext arbeitet in der Regel nach diesem Muster und wird häufig auch für Massendaten verwendet. Eine Kommunikation über Push-Nachrichten mit Einzeldatensätzen ist die Grundlage für Echtzeitanwendungen oder Systeme, die kontinuierlich Aktualisierungen erfordern. Ein Hauptvorteil dabei ist, dass unnötige Aufrufe vermieden werden, da die Übertragung nur stattfindet, wenn neue Daten vorliegen. Auf der Gegenseite führt dies gegebenenfalls zu einer Vielzahl an Aufrufen, da für jeden neuen Datensatz ein Push ausgelöst wird. Insgesamt bieten Push-Schnittstellen eine dynamische und reaktive Art der Datenübertragung, was in bestimmten Anwendungsfällen, insbesondere in Echtzeitszenarien, von Vorteil ist.

Eine spezielle Variante der Push-Schnittstellen stellt die ereignisbasierte Kommunikation dar. Dabei sendet das Quellsystem für definierte Statuswechsel eine Ereignisbenachrichtigung aus. Eine Besonderheit dabei ist, dass jedes Event einem Thema zugeordnet ist – einer Kategorisierung des Ereignisses. Zielsysteme können sich für die jeweils relevanten Themen registrieren, was zu einer äußerst flexiblen Architektur führt. Des Weiteren können Zielsysteme jederzeit weitere Themen anfordern, und es können ohne größeren Aufwand weitere Zielsysteme integriert werden, ohne dass die Architektur ergänzt werden muss. Weitere Details zu einer ereignisbasierten Architektur finden Sie in Kapitel 5, »Cloud Integration«.

Ein weiteres wiederkehrendes Muster in der Integration ist die Pipeline. Dieses Konzept kann u. a. auf Schnittstellen angewendet werden. Es bezieht sich darauf, verschiedene Schritte oder Prozesse in einer sequenziellen Reihenfolge zu durchlaufen – die namensgebende Pipeline. Jeder Schritt kann auf den vorangehenden Schritt aufbauen und auf deren Ergebnisse zugreifen. Die einzelnen Teilprozesse erfüllen jeweils eine spezielle Aufgabe:

• Transformation

• Mapping

• Daten anreichern

• Zwischenspeichern

Die Art, wie Schnittstellen in der SAP Integration Suite aufgebaut sind, erinnert stark an das Konzept der Pipelines. In der SAP Integration Suite spricht man von Integration Flows. Diese Integration Flows bestehen analog zu den Pipelines aus einzelnen Schritten (siehe Abbildung 1.4).

Abbildung 1.4     Ablauf eines Integration Flows

Ein Vorteil solcher Abfolgen ist, dass sie wiederholbar und konsistent sind. Das bedeutet, dass sie bei gleichbleibendem Input den Prozess wieder und wieder durchlaufen können und zum gleichen Ergebnis kommen. Dabei können Sie jeden einzelnen Schritt überwachen und analysieren, an welcher Stelle die Schnittstelle vom erwarteten Ergebnis abweicht. Weitere Informationen über die einzelnen Schritte eines Integration Flows finden Sie in Kapitel 5, »Cloud Integration«.

Darüber hinaus gibt es weitere Muster, an denen Sie sich orientieren können. Jedes davon eignet sich für ganz eigene Anforderungen. Wir möchten damit vor allem verdeutlichen, dass Sie bei der Planung von Schnittstellen nicht auf sich allein gestellt sind. Greifen Sie auf die Theorie und Erfahrungen anderer zurück, z. B. auch auf die Unterstützung von SAP-Entwickler*innen. In Kapitel 4, »Plug-and-Play-Integration«, zeigen wir Ihnen z. B. einige Möglichkeiten, wie Sie auf Vorlagen von SAP und anderen Expert*innen zurückzugreifen können. Zusammenfassend sollten Sie Ihre Schnittstellen anhand der folgenden Merkmale kategorisieren (Die Konzeption der Schnittstelle kann...

Über Autor(innen)

Arensmeyer, Jan
Jan Arensmeyer hat einen Bachelor of Science in Wirtschaftsinformatik und ist seit 2015 als Berater und Entwickler in den SAP-Bereichen SD und Integration tätig. In diesem Kontext begleitete er mehrere Projekte auf der SAP-Plattform, die sich heute zur SAP Integration Suite entwickelt hat. Er beschäftigt sich, passend zu den beiden Fachrichtungen, mit der Anbindung von Webshops, mit der Integration in verschiedene CRM-Systeme sowie mit der Kommunikation mit Lieferantenportalen. Passend zum Thema Integration bildet er dabei stets ein wichtiges Bindeglied zwischen Fachbereichen und technischen Experten.

Hegenbart, Enrico
Enrico Hegenbart ist SAP Finance und Integration Specialist bei der objective partner AG, einem SAP-Goldpartner in Deutschland. Zusammen mit Jan Arensmeyer setzt er Projekte zu den Themen SAP Process Integration, SAP Process Orchestration und SAP Integration Suite um. Ein großer Fokus seiner Arbeit liegt auf den Finanz-Geschäftsprozessen innerhalb sowie auch außerhalb von SAP. Neben seiner Tätigkeit als Experte für Integrationsthemen berät und schult er Kund*innen deutschlandweit im SAP-Finance-Umfeld und entwickelt Anwendungen mit ABAP. Nach seinem Bachelorstudium in Wirtschaftsinformatik 2012 beschloss Enrico Hegenbart sich auf SAP-Anwendungen zu fokussieren und begann seine Karriere als SAP-FI-Anwendungsbetreuer. Während seines Masterstudiums wurde er auf SAP Process Integration aufmerksam. Er entschloss sich, seine Masterarbeit diesem Thema zu widmen. Im Verlauf der nächsten zwölf Jahre sammelte er Erfahrung bei der Umsetzung von Process-Orchestration-, Process-Integration und Integration-Suite-Projekten. Neben der reinen Beratung in den genannten Anwendungen hat er sowohl Java-, Groovy- als auch ABAP-Quellcode implementiert.