Planung des Migrationsprozesses

SAP Process Orchestration bietet mehrere Landschafts-Deployment-Lösungen, die als zentrale, verteilte (Modell 1) oder verteilte (Modell 2) Domänen kategorisiert werden können.

Ein einzelner Integration Server, der mit allen Business-Systemen kommuniziert. Die zentrale Implementierung von SAP Process Orchestration ist eine gemeinsame Architektur für die meisten Unternehmen, da sie den kleinstmöglichen Installationsspeicherbedarf darstellt und die damit verbundenen Gesamtbetriebskosten (TCO) Vorteile bietet.

Ein einzelner Integration Server mit einer oder mehreren dezentralen Adapter Engines, die mit relevanten Business-Systemen kommunizieren. Sie wird häufig in Unternehmen gefunden, in denen Performance- oder Sicherheitsgründe im Vergleich zur Zentralisierung eine komplexere Lösung vorschreiben. Hierbei handelt es sich um einen hybriden Ansatz zwischen zentralen und föderierten Modellen, der die Vorteile von Performance und Sicherheit mit den Vorteilen einer zentralen Governance, Wartung und Überwachung kombiniert.

Zwei oder mehr Integrationsserver (Domänen) innerhalb einer einzelnen Landschaftsschicht, die mit relevanten Business-Systemen kommunizieren. Der Einsatz zusätzlicher dezentraler Adapter Engines pro Integration Server ist ebenfalls möglich und erhöht die Komplexität. Aufgrund der komplexeren Architektur ermöglicht das zweite verteilte Domänenmodell mehr Flexibilität, allerdings zu Lasten höherer Gesamtbetriebskosten. Solche Organisationen sind in der Regel größer und erfordern ein hohes Maß an Abstraktion in ihrer Landschaft.

Im Gegensatz zu kundenorientierten Gründen für dieses Modell gibt es auch einige SAP-gesteuerte Gründe, z.B. Isolation für die Unabhängigkeit von Upgrade-Pfaden oder Entkopplung von Business-Systemen und Portal-UI-Bindungen.

Der SAP Business Accelerator Hub (https://hub.sap.com) ist eine Webanwendung, die von SAP gehostet wird, um SAP- und Partner-APIs (Application Programming Interfaces) zu entdecken, zu erkunden und zu testen, die zum Erstellen von Erweiterungen oder Prozessintegrationen erforderlich sind.

APIs in SAP-Lösungen verwenden verschiedene Protokolle, Dokumentation und Zugriffsmechanismen. Anwendungs- und Integrationsentwickler müssen einen konsistenten Überblick über die APIs haben, die in den relevanten SAP-Systemen verfügbar sind (On-Premise und in der Cloud implementiert). Das Testen von APIs und das Erstellen von Prototypen umfasst auch die Organisation des Zugriffs auf relevante Systeme und Tenants für Entwickler.

SAP Business Accelerator Hub löst diese Herausforderungen, indem er einen zentralen Katalog von APIs zusammen mit einer integrierten Testumgebung in der Cloud für einfache Tests bereitstellt. SAP Business Accelerator Hub deckt APIs von SAP S/4HANA, SAP SuccessFactors, SAP BTP, SAP Hybris und mehr ab.

Das Aggregatormuster ist ein grundlegendes Enterprise-Integrations-Pattern, das in Systemen wie SAP Integration Suite verwendet wird, um mehrere zugehörige Nachrichten zu gruppieren und in Massenverarbeitung zu verarbeiten. Dieses Muster ist von entscheidender Bedeutung für Szenarios, in denen einzelne Nachrichten gesammelt und verwaltet werden müssen, z.B. das Zusammenfassen mehrerer Auftragspositionen in einem einzigen Auftragsbeleg. Die aggregierte Nachricht wird dann an den tatsächlichen Empfänger gesendet.

Die Abbildung „Aggregatormuster" erläutert die Unterschiede zwischen der Musterimplementierung in SAP Process Orchestration und SAP Integration Suite.

Da das Aggregator-Muster einen Status behält, ist SAP Business Process Management (SAP BPM) erforderlich, um den Nachrichtenfluss zu koordinieren. Für den eigentlichen Nachrichtenaustausch mit den beteiligten Systemen wird die SAP-Process-Integration-Laufzeit von SAP Process Orchestration verwendet.

Wie Sie im Integration-Flow-Modell sehen können, wird SAP Integration Suite mit einem dedizierten Aggregatorablaufschritt ausgeliefert. Daher müssen Sie das Muster nicht in einer Schleife modellieren, wie es für SAP Process Orchestration angezeigt wird. Im Ablaufschritt Aggregator definieren Sie Ihre Korrelationsbedingung sowie die Erledigungsbedingungen. Derzeit werden die letzte Nachrichtenbedingung und die Zeitüberschreitung bei Abschluss unterstützt. Leider wird die maximale Anzahl von Meldungen noch nicht unterstützt. Die restlichen Ablaufschritte werden verwendet, um die Sammlung von Positionen dem richtigen Nachrichtenformat zuzuordnen, in unserem Fall einen Auftrag mit Auftragskopfinformationen und allen Positionen, wodurch redundante Informationen entfernt werden.

Dieses Muster wird verwendet, wenn eine Nachricht mit mehreren Elementen verarbeitet werden muss und jedes Element eine andere Verarbeitung erfordert. Die Nachricht wird in Teilnachrichten aufgeteilt und zur Verarbeitung an verschiedene Empfänger gesendet. Die Ergebnisse werden dann zu einer einzigen Nachricht zusammengefasst.

In diesem Beispiel wird ein allgemeiner Splitter verwendet, um den Auftrag in mehrere Einzelnachrichten aufzuteilen, entsprechend der Anzahl der Positionen innerhalb des ursprünglichen Auftrags. In einem nachfolgenden Schritt leitet der Router die Positionen je nach Produktkategorie an ein anderes Bestandssystem weiter. Der Content Enricher liest dann synchron Daten aus einem externen System und hängt die zusätzlichen Informationen an die ursprüngliche Nachricht an, bevor er an den eigentlichen Empfänger weiterleitet. Schließlich aggregiert der Schritt Sammeln die Mehrfachantworten erneut in einer einzigen Nachricht in der ursprünglichen Reihenfolge.

Mit dem Muster Scatter-Gather können Sie eine Nachricht an mehrere Empfänger senden und die Antworten erneut in einer einzigen Nachricht aggregieren.

Der Referenz-Scatter-Collect-Pattern-Integration-Flow besteht aus zwei Integrationsprozessen: einem für den Scatter-Teil und einem für den Sammelteil.

In diesem Beispiel nimmt der Scatter-Teil die Anforderung und sendet sie an mehrere Banken. Vor diesem Punktteil wird der Timer über eine separate Nachricht ausgelöst, die an den Sammelteil gesendet wird.

Der Integrationsprozess Sammeln empfängt die Angebote von den Banken, aggregiert sie, berechnet das beste Angebot und sendet schließlich das beste Angebot an den Anforderer zurück.

Der Content Enricher liest Daten synchron aus einem externen System und hängt die zusätzlichen Informationen an die ursprüngliche Nachricht an, bevor er an den eigentlichen Empfänger weiterleitet.

Die Abbildung „Content-Enricher-Pattern" erläutert dieses Muster in SAP Process Orchestration und in SAP Integration Suite.

Im obigen Beispiel beginnt der Prozess mit dem Sammeln einer Auftragsliste für einen bestimmten Mitarbeiter. Die Kundendetails fehlen. Sie müssen aus einem anderen System abgerufen werden. Daher führen Sie eine Schleife über die Liste der Aufträge aus und führen in jedem Schleifendurchlauf einen Web-Service-Aufruf mithilfe einer automatisierten Aktivität durch. Innerhalb der automatisierten Aktivität werden die zusätzlichen Informationen dann der entsprechenden Auftragsposition zugeordnet, wodurch die Nachricht angereichert wird.

In SAP Integration Suite können Sie den Content Enricher entweder über das Request-Response-Muster oder über einen dedizierten Content-Enricher-Ablaufschritt modellieren.

Der Ablaufschritt Content Enricher gleicht die Antworten automatisch mit den verschiedenen Positionen der ursprünglichen Nachricht ab. Sie eignet sich insbesondere zur Anreicherung von Massendaten. Die Verwendung dieser Option ist im Vergleich zu einem Request-Response-Muster performanter. Hier müssen Sie nicht alle Elemente durchlaufen, die einzelne Lookup-Aufrufe ausführen. Sie führen einfach einen Aufruf durch, und der Abgleich erfolgt automatisch basierend auf Ihrem Schlüssel.

Je nach Anwendungsfall stehen mehrere Optionen für das Splitter-Muster zur Verfügung. Mit dem Splitter-Pattern können Sie eine Message in mehrere einzelne Messages aufteilen, je nach Anzahl der Elemente.

Es gibt zwei Anwendungsfälle:

• Aufteilen einer Bulk-Auftragsnachricht in mehrere Aufträge
• Splitten eines einzelnen Auftrags mit mehreren Positionen

Variante mit iterierendem Splitter

Beim Splitten einer Bulk-Auftragsnachricht in mehrere Aufträge können Sie die Variante mit iterierendem Splitter verwenden.

Die Abbildung „Variante mit iterierendem Splitter" veranschaulicht dieses einfache Szenario mit einem iterierenden Splitter-Schritt.

Variante mit allgemeinem Splitter

Mit dem allgemeinen Splitter können Sie einen einzelnen Auftrag mit mehreren Positionen in einzelne Nachrichten aufteilen. Der allgemeine Splitter dupliziert automatisch die Kopfinformationen des Auftrags für jede einzelne Nachricht.

Der Integration-Flow Variant with General Splitter enthält einen allgemeinen Splitter-Schritt.

Variante mit Message-Mapping

Verwenden Sie diese Variante, wenn Sie bestimmte Anforderungen haben, die nicht vom allgemeinen Splitter abgedeckt werden, oder wenn Sie das Mapping aus Ihrem SAP-Process-Orchestration-System wiederverwenden möchten.

Die Abbildung „Variante mit Message-Mapping" zeigt die erforderlichen Ablaufschritte.

Mit dem inhaltsbasierten Routing können Sie Nachrichten abhängig vom Inhalt einer Nachricht an den richtigen Empfänger weiterleiten.

Für jeden Empfänger können Sie eine Bedingung in Form eines XPath-Ausdrucks pflegen. Der XPath-Ausdruck kann entweder auf den Payload-Daten oder auf dem Message-Header basieren. Während der Message-Verarbeitung wertet Cloud Integration die Bedingung aus und leitet die Message bei Erfüllung an den entsprechenden Empfänger weiter. Wenn kein Empfänger ermittelt werden kann, kann Cloud Integration nach den folgenden Varianten fortfahren:

• Nachricht an einen Standardempfänger senden
• Meldung ignorieren
• Fehler auslösen

Nachricht an einen Standardempfänger senden

Im Beispiel-Integration-Flow wird die Message abhängig von einer bestimmten Routing-Bedingung an verschiedene Empfänger weitergeleitet. Wenn keine der beiden Routing-Bedingungen erfüllt ist, sendet Cloud Integration die Nachricht an einen Standardempfänger.

Die Abbildung „Variante „Message an einen Standardempfänger senden" zeigt den iFlow.

Meldung ignorieren

Bei dieser Variante kann zur Laufzeit kein Empfänger ermittelt werden, da keine Routing-Bedingung erfüllt ist.

Für jeden Empfänger ist die Routing-Bedingung entsprechend konfiguriert. Darüber hinaus wird eine Route konfiguriert, die auf ein Endereignis verweist.

Fehler auslösen

In diesem Beispiel wird ein Fehler ausgegeben, wenn abhängig vom XPath-Ausdruck kein Empfänger ermittelt werden kann. Nun führt die Standardroute zu einem Fehlerendereignis.

Für den Ausnahme-Teilprozess sind verschiedene Optionen für die Message-Verarbeitung modelliert. Die Optionen hängen davon ab, ob das Ereignis durch das Ereignis Error End innerhalb des Hauptintegrationsprozesses oder durch einen anderen Fehler ausgelöst wird, der während der Message-Verarbeitung auftreten kann.

Mit dem Empfängerlisten-Integrations-Pattern können Sie eine oder mehrere Nachrichten an verschiedene Empfänger senden. Ähnlich wie bei einer Bestellung möchten Sie an verschiedene Lieferanten senden, je nachdem, welches Produkt Sie bestellen möchten. Daher werden die jeweiligen Lieferanten dynamisch anhand der jeweiligen Waren ermittelt. Außer für den inhaltsbasierten Router wird eine Kopie der Nachricht an mehrere Empfänger gesendet.

Beim Implementieren des Empfängerlistenmusters gibt es zwei Optionen:

• Statisches Routing mit XPath-Bedingungen
• Dynamisches Routing über Mapping zur Ermittlung der Empfänger

Statisches Routing

In dieser Variante gibt es eine feste Liste von potentiellen Empfängern. Das Empfängerlistenmuster wird durch eine Kombination aus Multicast- und Nachrichtenfiltern realisiert.

Die Abbildung „Variantenempfängerliste mit statischem Arbeitsplan" zeigt einen Beispiel-iFlow. Der Multicast-Schritt wird verwendet, um Kopien derselben Nachricht an mehrere Routen zu senden. Der Message-Filter ist ein bestimmter Typ des Message-Routers, der nur einen einzigen Empfängerkanal hat. Der Nachrichtenfilter wertet jede eingehende Nachricht aus. Wenn die Message die im Message-Filter festgelegten Kriterien erfüllt, wird die Message an den Empfänger weitergeleitet, andernfalls wird sie verworfen.

Dynamisches Routing

Außer für die statische Arbeitsplanvariante müssen Sie keine feste Anzahl von Empfängern im Integration-Flow pflegen.

Wie in der obigen Abbildung dargestellt, ist der Empfängerermittlungsteil von der empfängerspezifischen Zustellung der Nachricht entkoppelt. Daher wird ein Hauptintegrationsprozess modelliert, der die Empfängerermittlung enthält, und ein Integration-Flow wird für jeden potenziellen Empfänger modelliert. Das Hauptmodell und die einzelnen Integration-Flows sind über den ProcessDirect-Adapter gekoppelt. Die ProcessDirect-Adresse wird dynamisch basierend auf der Empfängerermittlung festgelegt.

Mit dem Muster Nachrichtenfilter können Sie alle Daten aus einem Kanal entfernen, an dem Sie nicht interessiert sind. Der Message-Filter ist ein bestimmter Typ des Message-Router-Musters, das nur einen einzigen Empfängerkanal hat. Jede eingehende Message wird ausgewertet. Wenn sie die im Message-Filter angegebenen Kriterien erfüllt, wird die Message an den Empfänger weitergeleitet, andernfalls wird sie verworfen.

Das Muster Message-Filter ähnelt dem Muster Content-Based Routing, bei dem die Message ignoriert wird, wenn Sie den Empfänger nicht ermitteln können.

Für das Message-Filter-Pattern definieren Sie jedoch nur einen einzelnen Empfänger.

Im Integration-Flow Pattern Message Filter definieren Sie eine Routing-Bedingung, die auf der Produktkategorie basiert. Wenn die Routing-Bedingung nicht erfüllt ist, wird die Nachricht verworfen. Sie können dieses Verhalten erreichen, indem Sie eine Standardweiterleitung hinzufügen, die auf ein Endereignis verweist.

Mit dem Content-Filter-Pattern können Sie Daten aus einer Nachricht entfernen, die in Ihrem Anwendungssystem nicht benötigt werden.

Bei der Implementierung eines solchen Szenarios gibt es zwei Möglichkeiten:

• Schritt Filter verwenden
• Message-Mapping verwenden

Filterschritt verwenden

In dieser Variante wird der Filter verwendet, um alle unnötigen Datenelemente aus der Nachricht zu entfernen. Der Message-Header bleibt jedoch erhalten.

Die Abbildung „Variante mit Filterschritt" veranschaulicht dieses einfache Szenario.

Message-Mapping verwenden

In dieser Variante wird das Message-Mapping verwendet, um alle unnötigen Datenelemente aus der Message zu entfernen, aber der Message-Header wird beibehalten.

Der Integration-Flow enthält nur das Message-Mapping.

Edge Integration Cell ist als Teil der vorhandenen SAP Integration Suite (für Standard- und Premium-Editionen und Cloud Platform Enterprise Agreement (CPEA) und Pay-as-you-go (PAYG) enthalten. Zusätzliche Edge-Integrationszellen können über ein separates Add-on Stock Keeping Unit (SKU) erworben werden. Nur 50 % der Nachrichten, die von Edge Integration Cell verarbeitet werden, sind kostenpflichtig (ausgenommen nicht modifizierter Standardinhalte für SAP-zu-SAP-Software).