Resiliente asynchrone Integrationen erstellen

Manchmal stellen Sie fest, dass Ihre Integrationen spröde sind und auch kurze oder vorübergehende Unterbrechungen nicht bewältigen können. Sie benötigen Ihre asynchrone Integration, um effizient zu skalieren, und Sie benötigen Optionen für die Entwicklung und das Testen solcher Integrationen, um sicherzustellen, dass sie in der Produktion wie erwartet funktioniert. In diesem Lösungs-Playbook werden vorgeschlagene Ansätze für die Erstellung asynchroner Integrationen vorgestellt, die den Realitäten moderner Netzwerke und Infrastrukturen widerstandsfähig sind.

Beispiel: Wenn Sie Entitys mit den REST-APIs in einer Financial Cloud erstellen, können bei der Erstellung von Spesenabrechnungen, Bankkonten oder anderen Entitäten vorübergehende Unterbrechungen auftreten. Um solche Anfragen, die auf Financial Cloud treffen, dynamisch zu drosseln, wird das Parkmuster in diesem Handbuch erläutert. Mit dem Parkplatzmuster können Sie die Daten in einer Zwischenstufe speichern, bevor Sie die Daten verarbeiten, um Verarbeitungsprobleme wie Batch, komplexe Nachrichtenkorrelation/-abläufe und Drosselung zu vermeiden.

Informationen zu Integrationen in Oracle Integration

Integrationen sind der Hauptbestandteil von Oracle Integration. Eine Integration umfasst mindestens eine Trigger-(Quell-)Verbindung (für Anforderungen, die an Oracle Integration gesendet werden) und eine (Ziel-)Verbindung (für Anforderungen, die von Oracle Integration an das Ziel gesendet werden) sowie die Feldzuordnung zwischen diesen beiden Verbindungen.

Wenn Sie Integrationen erstellen, bauen Sie auf den bereits erstellten Verbindungen auf, indem Sie definieren, wie die Daten für den Trigger (Quelle) verarbeitet und (Ziel-)Verbindungen aufgerufen werden. Dazu kann die Definition des Typs der Vorgänge, die für die Daten ausgeführt werden sollen, der Geschäftsobjekte und Felder, für die diese Vorgänge ausgeführt werden sollen, der erforderlichen Schemas usw. gehören. Um dies zu erleichtern, werden die komplexesten Konfigurationsaufgaben von Oracle Integration verarbeitet. Nachdem die Trigger-(Quell-) und Aufruf-(Ziel-)Verbindungen konfiguriert wurden, werden die Mapper zwischen den beiden aktiviert, sodass Sie definieren können, wie die Informationen sowohl für die Anforderungs- als auch für die Antwortnachrichten zwischen den Trigger-(Quell-) und Aufruf-(Ziel-)Datenstrukturen übertragen werden.

Über Parkplatz Muster

Im Parkplatzmuster werden Daten in einer Zwischenstufe gespeichert, bevor die Verarbeitung der Daten von der Zwischenstufe zum Endsystem abgeschlossen wird.

Hier sind einige der möglichen Alternativen zur Speicherung der tatsächlichen Daten auf dem Parkplatz. Jede Option hat unterschiedliche Eigenschaften, die berücksichtigt werden müssen:

Der einfachste Ansatz besteht darin, Daten als CLOB in XML-Form zu speichern. Diese Methode fügt zusätzliche Overhead-Schreibvorgänge und das Lesen des CLOB sowie die Transformation zwischen XML und CLOB hinzu.
Sie können Daten separat in anderen Tabellen mit vollständig realisierten Spalten speichern. Diese Methode ist am besten geeignet, wenn der De-Batching-Prozess in der Anwendung die Eingabe-Payload bereits in ein Tabellenformat in der Datenbanktabelle kopiert. Damit das Datenformat für den Parkplatz genutzt werden kann.
Kombinieren Sie den Tisch mit dem Parkplatz selbst. Während sich diese Lösung als die leistungsstärkste erweisen könnte, kann sie nur für einfache Datenstrukturen auf dem Parkplatz funktionieren.

Über Resilienz

Bevor Sie sich mit dem befassen, was Ihre Umgebung widerstandsfähig macht, müssen Sie zunächst definieren, was Resilienz für Sie und Ihr Unternehmen bedeutet.

Mit anderen Worten: Welche Kosten sind mit einem Ausfall Ihrer Integrationsprozesse verbunden? Für einige Kunden ist ein Ausfall von ein paar Minuten vollkommen akzeptabel und verzögert einen Batchprozess, der gut in seinem Verarbeitungsfenster läuft, nur teilweise. Für andere führen selbst ein paar Sekunden Ausfall zu finanziellen Verlusten, die sich direkt auf das Geschäft auswirken.

Aus dieser Perspektive ist es wichtig, die folgenden Elemente zu betrachten:

Wie lange dauert ein akzeptabler Ausfall in Ihrer Umgebung? Hier sollten Sie die Kosten für das Unternehmen bei einem Ausfall definieren und darlegen, wie sich dieser Ausfall mit der Dauer des Ausfalls entwickelt.
Welche Technologien werden verwendet und wie können sie das erwartete SLA einhalten? Nehmen Sie einen Echtzeit- oder Batch-Ansatz? Oder eine Kombination der beiden? Wie viele Daten verarbeiten Sie?