Das intelligente Unternehmen Teil II - Cloud Integration Suite

Im ersten Teil habe ich die Methodiken aufgezeigt und auf abstrakter Ebene die Vorgehensweise skizziert.

In diesem Post werde ich mich mit Cloud-Integrationszenarien , Design-Beispielen und den Tools beschäftigen, die zur Erstellung von Integrationsartefakten verwendet werden.

Ich habe bereits die Philosophie hinter der Integration erörtert, warum sie so wichtig ist und wie man die Komplexität der Integrationsverwaltung in einer hybriden und heterogenen Landschaft bewältigen kann.

Nun ist es an der Zeit, die Ärmel hochzukrempeln und zur praktischen Seite überzugehen. Wir werden den Detailierungsgrad für Architekten im Allgemeinen so anpassen, dass sie die wesentlichen Informationen erfassen können, um Integrationsdienste in ihre Architekturentwürfe einzubinden. Der Inhalt bietet also Köln Schritt-für-Schritt-Details für den Aufbau von Integration, stattdessen werde ich Themen aus der Architekturperspektive aufzeigen.

Wie im vorigen Post ( https://www.lagerfeuer.online/post/das-intelligente-unternehmen-teil-i ) beschrieben , gibt es mehrere Integrationsstile und -muster. Um den Fokus beizubehalten, werde ich die Design-Diskussion unter den Überschriften Cloud-Integration und Datenintegration behandeln.

In diesem Post werden folgende Hauptthemen behandelt werden:

• Entwurf von Szenarien zur Anwendungsintegration

• API-basierte Integration

• Vereinfachte Konnektivität mit Anwendungen von Drittanbietern

• Event-based Integration

• Integration von Stammdaten

Entwurf von Szenarien zur Anwendungsintegration

Angenommen , Sie haben bereits eine Integrationsmethodik eingeführt. In diesem Fall haben Sie für ein bestimmtes Szenario bereits einen großen Teil der Integrationsarbeit geleistet, da Sie auf einem von Ihrer Methodik vorgegebenen Integrationsmuster aufbauen werden.

Ich beginne mit dem Entwurf typischer Prozessintegrationszenarien , die mit der Cloud-Integrationsfunktion der SAP Integration Suite implementiert werden können.

Anatomie eines Integrationsflusses

Ein Integrationsfluss dient dazu, die Nachricht zu verarbeiten, die die Cloud Integration durchläuft. Sie können Ihrem Integrationsfluss Operatoren hinzufügen, die Schritte genannt werden, um zu definieren, wie die Nachricht verarbeitet wird.

Diese Schritte können Folgendes tun:

• Den Inhalt der Nachricht umwandeln

• Konvertieren zwischen verschiedenen Formaten

• Aufruf externer Komponenten zur Anreicherung des Nachrichteninhalts

• Meldungen aufrechterhalten

• Sicherheitsmaßnahmen anwenden

Die Abbildung zeigt ein Beispiel für einen Integrationsablauf. In der MItte ist der Hauptintegrationsprozess zu sehen, der einen Exception Subprocess und viele Integrationsschritte enthält. Unten rechts befindet sich ein lokaler Integrationsprozess.

Neben den Integrationsprozessen und -schritten gibt es zwei Arten von weiteren Elementen in einem Integrationsfluss:

• Auf der linken Seite hat der Integrationsfluss einen Absender, der die Anwendung darstellt, die die Nachricht sendet. Anhand des Pfeils , der vom Absender ausgeht, können wir sehen, dass die eingehende Nachricht über das HTTPS-Protokoll empfangen wird.

• Schließlich gibt es noch zwei Empfänger-Komponenten. Die obere ist das Standardziel , und anhand des Pfeils, der in diesem Empfänger endet , können wir feststellen, dass die ausgehende Nachricht als E-Mail gesendet wird. Der Empfänger darunter (mit der Bezeichnung Alerting) scheint für das Ausnahmemanagement vorgesehen zu sein, bei dem der Ausnahme-Subprozessor eine Nachricht über das OData-Protokoll an eine andere (alarmierende) Anwendung sendet.

Verarbeitung von Nachrichten

In ihrer einfachsten Form fungiert die Cloud-Integration als Nachrichtenumwandler und Router zwischen den Systemen und ermöglicht den Nachrichtenaustausch zwischen ihnen:

Wie in der Abbildung dargestellt, wird die vom Sendersystem empfangene Message durch mehrere integrationsprozessschritte verarbeitet. Dabei können die Schritte während der Laufzeit der Message-Verarbeitung Daten im Message-Header und Body verändern.

Schritt-Typen

Folgende Schritttypen sind verfügbar:

• Ereignisse: Ein Integrationsfluss hat Start- und Endereignisse , die den Beginn und das Ende der Integrationsprozesse oder des gesamten Flusses markieren. Mit verschiedenen Ende-Ereignissen können Sie den Endzustand eines Integrationsflusses festlegen. Wenn der Integrationsfluss bei bestimmten Adaptertypen , wie z.B. HTTPS, endet wie die verarbeitete Message auch als Antwort an das Sendersystem gesendet.

• Mappings: Die Integration zwischen zwei Systemen erfordert häufig die Definition eines Mappings zwischen den Datenstrukturen von Quell- und Zielsystemen. Mit diesen Schritttyp können Sie die Regeln für das Mapping definieren, indem Sie Felder der Nachrichtenstruktur abgleichen, vordefinierte Funktionen verwenden und benutzerdefinierte Skripte erstellen. Ein Mapping kann gespeichert werden, so dass es in mehreren Abläufen wiederverwendet werden kann.

• Transformation: Cloud Integration bietet mehrere Optionen zur Umwandlung von Integrationsinhalten . Mit Content Modifier können Sie Nachrichtenköpfe und Austauscheigenschaften hinzufügen oder entfernen. Außerdem können Sie den Nachrichtentext ändern. Mit Converters können Sie den Nachrichtentext in verschiedene Formate konvertieren, z.B: CSV,XML, JSON und EDI. Mit Kodierern und Dekodieren können Sie Nachrichten kodieren oder dekodieren, sie komprimieren oder MIMIE Multiparty-Kodierer/Dekodierer verwenden, um Nachrichten mit Anhängen zu verarbeiten.

• Anrufe: Sie können externe Anrufschritte verwenden, um externe Systeme anzurufen.

• Weiterleitung: MIt diesen Schritten können Sie verschieden Verarbeitungszweige erstellen, den Fluss auf der Grundlage von Bedingungne durch einen Zeig leiten, dieselbe Nachricht per Multicast übertragen, die Nachricht in kleiner Nachrichten aufteilen und diese nach der Verzweigung sammeln oder zusammenführen.

• Validierer: Um die Arbeit mit Standardformaten zu erleichtern, kann ein Integrationsablauf Schritte zur Validierung von Nachrichten enthalten, z.B die XML-Validierung anhand eines XML-Schemas oder die Validierung einer EDI-Nachricht anhand eines EDI-Schemas.

API-based Integration

Anwendungsprogrammierschnittstellen (APIs) sind das Herzstück der digitalen Transformation und ermöglichen die Flexibilität und Offenheit, die für die schnelle Vernetzung von Lösungen erforderlich sind.

In Anbetracht der bedeutenden Rolle von APIs ist es für einen Anbieter unumgänglich, eine Kontrollschicht zwischen den APIs und ihren Nutzern einzurichten.

SAP APIM-Elemente

In der Abbildung sind die meisten Elemente von SAP APIM dargestellt, und nun ist es an der Zeit , sie zu beschreiben. Die gestichelten Linien stellen die Beziehungen zur Entwurfzeit dar, und die durchgehenden Linien bezeichnen die Anfrage-Antwort-Pipeline zur Laufzeit.

API-Richtlinientypen

Wir können die Richtlinientypen in vier Gruppen einteilen.

Sicherheitsrichtlinien: Mit Sicherheitsrichtlinien können Sie verwalten, wie APIs vor unberechtigten Zugriff geschützt werden-

Verkehrspolitik: Wenn Sie Ihre Systeme über SAP APIM für externe Parteien öffnen, müssen Sie möglicherweise den Datenverkehr aus Sicherheitsgründen oder als Teil einer kommerzieellen Tarifbegrenzen kontrollieren.

Mediationsverfahren: Da SAP APIM als Vermittler zwischen dem Verbraucher und dem Anbieter fungiert, können Sie auch Richtlinien anwenden, um den Nachrichteninhalt zu Vermittlungszwecken zu manipulieren.

Policy der Erweiterung: bei komplexen Anforderungen müssen Sie möglicherweise umfassendere Richtlinie hinzufügen.

Vereinfachte Konnektivität mit Anwendungen von Drittanbietern

IT-Landschaften werden immer heterogener. Aus diesen Grund besprechen wir nun eine Funktion der SAP Integration Suite, Open Connectors, sie hilft, die Herausforderungen bei der Integration von Anwendungen verschiedener Hersteller zu bewältigen.

Die Elemente von SAP Open Connectors

• Konnektoren: Ein Konnektor ist eine vorgefertigte integrationskomponente , die explizit für die Zielanwendung erstellt wurde, z.B. ServiceNow, Salesforce, usw.

• Konnektor-Instanz: Um eine integration mit einer Unterstützung Drittanbieteranwendung zu erstellen, erstellen Sie eine Konnektorinstanz, indem Sie sich bei einem Konto auf der Anbieterseite authentifizieren.

• Gemeinsame Ressource: Sie können davon ausgehen, dass Anwendungen die ähnliche Funktionen ausführen, auch ähnliche Datenmodelle haben, diese sind jedoch nicht immer gleich benannt oder strukturiert.

• Formel: Sie können einfache Workflows erstellen, um einfache Integrationszenarien mit Formeln auszuführen.

Ereignisgesteuerte Integration

Seien wir dieses Mal etwas bedantisch und definieren wir zuerst ein Ereignis. Laut Cambridge Dictionary ist ein Ereignis alles , was passiert , insbesondere etwas Wichtiges oder Ungewöhnliches. Diese Definition funktioniert ziemlich gut, wenn man sie auf das Ereigniskonzept in der IT anwendet. In objektorientierten Geschäftsmodellen kann das Ereignis beispielsweise mit einer einer Änderung des Zustands eines Objekts verknüpft werden, z.B mit einem Lebenszyklusstatus wie „BusinessPartner changed?“. Damit sind Ereignisse mehr als bloße Nachrichten , da sie Informationen über Zustandsänderungen vermitteln. Dies steht im Gegensatz zur nachrichtengesteuerten Integration, bei der sie Nachricht den etablierten Zustand eines Objekts enthält, wie bei Representational State Transfer (REST) oder einer Aktion, die mit einer SOAP-Nachricht ausgelöst wird.

Bei der Integration muss es Teilnehmer geben: Der Produzent oder die Quellanwendung löst ein Ereignis aus, und die Verbraucheranwendungen hören zu, um auf das Ereignis reagieren zu können.

Warum brauchen wir eine ereignisgesteuerte Integration?

Wenn es darumg geht, dass eine Anwendung Informationen über eine eingetretene Änderung sendet und eine andere Anwendung diese empfängt, wie unterscheidet sich dann die ereignisgesteuerte Integration von anderen?

Ereignisgesteuerte Architekturen beruhen auf der Forderung nach einem sehr hohen Maß an Skalierbarkeit. Skalierbarkeit ist bei Cloud-nativen Anwendungen un der Integration zwischen ihnen unerlässlich. Dies gilt sowohl für die Entwurfzeit, in der Sie Lösungskomponenten unabhängig voneinander erstellen, als auch für die Laufzeit, in der diese Komponenten skalierbar ausgeführt werden müssen.

Ein Hindernis für die Skalierbarkeit ist die enge Abhängigkeit zwischen den Komponenten einer Lösung, und die synchrone Integration ist der Hauptverursacher dieser engen Abhängigkeiten. Wenn also Skalierbarkeit unser Hauptanliegen ist, müssen wir die enge Abhängigkeit aufbrechen und eine lose Kopplung der Komponenten mit asynchroner Integration einführen.

Der Mangel an Synchronität mag den Eindruck erwecken, dass die Integration nicht nahezu in Echtzeit erfolgen kann, doch das ist nicht der Fall. Dennoch haben die Empfängeranwendungen die Flexibilität , Nachrichten in ihrem eigenen Tempo zu konsumieren.

SAP Event Mesh

SAP Event Mesh ist ein Event-Broker als Service, der in der SAP BTP bereitgestellt wird. SAP Event Mesh kann als Message Broker genutzt werden und bietet Muster für die asynchrone, nachrichtengesteuerte Integration zwischen einer Produzenten- und einer Konsumentenanwendung .

Die Ermöglichung der ereignisgesteuerten Integration erleichtert die Erstellung von Side-by-Side-Erweiterungen. In Anbetracht der Tatsache, dass die künftige Richtung für betriebswirtschaftliche Kernsoftware in Richtung SaaS geht, unterstützt dies die relevante Philosophie „Keep the Core Clean“. SAP Event Mesh kann hier eine zentrale Rolle spielen.

SAP Event Mesh implementiert eine ereignisgesteuerte Integrationsarchitektur unter Verwendung des Publish-and-Subs-Modells (pub/sub) mit den folgenden Elementen, dargestellt sind:

SAP Event Mesh unterstützt die messagingspezifischen Protokolle Advanced Message Queuing Protocol (AMQP) und Message Queuing Telemetry Transport (MQTT) sowie die HTTP-basierten REST-APIs. Darüber hinaus unterstützt es die folgenden Quality-of-Service (QoS)-Stufen:

• Höchstens einmal(0): Dies ist der Fall, wenn die veröffentlichte Nachricht nach bestem Bemühen zugestellt wird und keine Bestätigung vom Empfänger erwartet wird.

• Mindestens einmal (1): In dieser Stufe wird die Nachricht in der Warteschlange gehalten, bis eine Bestätigung vom Teilnehmer eingeht. Bei dieser QoS-Stufe kann die Nachricht jedoch mehrfach zugespielt werden.

Integration von Stammdaten

Viele Unternehmen haben Schwierigkeiten, ihre Stammdaten über mehrere Systeme hinweg konsistent und sauber zu halten. Außerdem entstehen in verschiedenen Systemen Datensilos, die schließlich zu inkonsistenzen führen. Wenn diese Datensilos nicht mehr miteinander verbunden sind, werden sie zu einem Innovationshindernis.

Ein Ansatz zu besseren Bewältigung dieser Herausforderung ist die Einführung eines gut organisierten Mechanismus zur Stammdatenintegration. Auf diese Weise können Sie eine einzige Quelle der Wahrheit bestimmen und die Stammdaten konsistent an andere relevante Systeme verteilen und die Datenqualität hoch halten.

Mit Blick auf heterogene und hybride Landschaften übernimmt SAP die Stammdatenintegration hauptsächlich durch zwei Komponenten:

• SAP One-Domain Model (ODM)

• SAP Master Data Integration (MDI)

Aus einer anderen Perspektive , neben der Motivation, den Kunden das Leben mit einer Vielzahl von Systemen zu erleichtern, führt SAP mit diesen Lösungen einen einheitlichen Einstiegspunkt und eine Stammdaten-Zugriffsschicht ein , die die Daten mehrerer Lösungen überspannt. Unter der Haube mag die Modularisierung sinnvoll sein, die meisten Kunden bevorzugen jedoch eine einheitliche Bedienung dieser Lösungen auf der Präsentationsschicht.

Voriger Post:

https://www.lagerfeuer.online/post/das-intelligente-unternehmen-teil-i