Ausfallsicherheit mit Oracle Integration entwerfen

Verwenden Sie diese Best Practices beim Entwerfen Ihrer resilienten Integrationen.

Designintegrationen

Im Folgenden finden Sie einen grundlegenden eingehenden Integrationsfluss, der Anforderungen von einer Upstreamanwendung über eine REST-API empfängt, parst, validiert und an die Downstreamanwendung sendet.

Es kann vorkommen, dass die Downstreamanwendung nicht mehr reagiert, wenn die Upstreamanwendung Anforderungen sendet. Diese Anfragen werden vom Downstream nicht bestätigt. Es wird viele solche Verarbeitungsherausforderungen geben, wie Batch, komplexe Nachrichtenkorrelation/-abläufe und Throttling.

Nehmen wir ein Beispiel für die Erstellung von Entitys in der Oracle Financials Cloud mit den REST-APIs. Die Anforderungen müssen von einem Integrations-REST-Endpunkt empfangen werden. Sie sollten in der Lage sein, die Anforderungen, die auf Financials Cloud treffen, dynamisch zu drosseln, den Status der Anforderungen zu verfolgen und alle nicht erfolgreichen Anforderungen erneut weiterzuleiten. Für diese Lösung werden drei Integrationen und eine Autonomous Transaction Processing-Datenbank angezeigt. Die Implementierung des Parkplatzes kann mit verschiedenen Speichertechnologien wie Datenbank oder Coherence erfolgen. Der Einfachheit halber verwenden wir jedoch eine Autonomous Transaction Processing-Datenbanktabelle.

Beschreibung der Abbildung oic_extended_parkinglot_eh.png

Wenn die Upstreamanwendung in der gezeigten Abbildung eine Anforderung sendet, sendet die Request Persister-Intergration diese an die Datenbank und bestätigt die Upstreamanwendung. In der Datenbank speichert das Parkplatzmuster Anforderungsmetadaten und Statusinformationen und verarbeitet die Eingabeanforderung basierend auf der Reihenfolge, in der sie eingehen. Jede Nachricht wird für x Minuten (Parkzeit) im Speicher geparkt, sodass der Integrationsfluss die Anzahl der gleichzeitig verarbeiteten Nachrichten drosseln kann.

Eine orchestrierte Terminplan-Dispatcher-Integration wird durch einen Zeitplan ausgelöst. Sie können diese Integrationsausführung so planen, dass Anforderungen zu einem beliebigen Zeitpunkt aus der Datenbank kopiert werden. Sie können auch die Häufigkeit der Integration definieren. Diese Anforderungen werden an die asynchrone Prozessorintegration übergeben. Die asynchrone Prozessorintegration verarbeitet die eingehenden Anforderungen und sendet sie an die Downstreamanwendung.

Designkomponenten

Das High-Level-Design verfügt über drei Integrationen und eine Datenbank. Wir betrachten die Erstellung als Beispiel, aber in Wirklichkeit könnten es alle Geschäftsobjekte sein, die von jeder Oracle SaaS-REST-API verfügbar gemacht werden.

Anforderungen buchen

Die Integration "Request Persister" stellt einen REST-Triggerendpunkt bereit, der von einer Upstreamanwendung (Client) aufgerufen werden kann, um die Accounterstellungsanforderungen zu POSTEN.

Diese Persister-Integration lädt Kontenerstellungsanforderungen sofort nach Erhalt von Clientanwendungen in die Autonomous Transaction Processing-Datenbank und bestätigt eine Quittung mit HTTP 202/Accepted. Die Konto-ID und die gesamte Nutzlast werden zur späteren Verarbeitung in der Parkplatztabelle gespeichert.

Anforderungen in Parkplatztabelle laden

Die Autonomous Transaction Processing-Datenbank enthält hier die Parkplatztabelle, in der alle eingegangenen Anforderungen vor der Verarbeitung geparkt werden. Der Einfachheit halber wird eine einfache Tabelle angezeigt, in der die Payload persistiert und der Anforderungsstatus sowie eventuelle Fehlerinformationen verfolgt werden.

Die JSON-Anforderungs-Payload für die Accounterstellung wird vollständig in der Parkplatztabelle als Zeichenfolge gespeichert. Es kann Anwendungsfälle geben, die als CLOB oder codierte Zeichenfolge gespeichert werden, bei denen es nicht wünschenswert ist, eine sichtbare Payload in der Tabelle zu haben. Wenn Sie die Payload jedoch als json speichern, können Sie die Payload bei erneuten Weiterleitungen von Fehlern ändern.

Wenn Sie möchten, können Sie die gesamte JSON-Anforderung in der Tabelle speichern. Dies ist in zwei Phasen möglich:

• Eine Phase Write, die das JSON-Beispiel der Anforderungs-Payload zum Erstellen einer Schemadatei verwendet.
• Ein Staging-Vorgang Read Entire File mit undurchsichtigem Schema.

  Gibt den codierten Wert base64 der JSON-Payload-Zeichenfolge an. Dann kann die integrierte Funktion decodebase64(opaqueElement) in mapper (oder assign) verwendet werden, um den JSON-Zeichenfolgenwert ! abzurufen. Die beim Lesen der Phase verwendete undurchsichtige xsd-Schemadatei ist in GitHub verfügbar. Diese Datei wird später in dieser Lösung beschrieben.

Dispositionsanforderungen nach Plan

Die geplante Integration ist für die Ausführung mit der erforderlichen Häufigkeit geplant. Bei jeder Ausführung wird eine konfigurierte Anzahl von Anforderungen abgerufen und durchlaufen, die jede Anforderung an eine Async Processor-Integration zur Verarbeitung senden.

Sie können konfigurieren, um eine Reihe von Anforderungen als geplanten Parameter abzurufen, um die Anforderungsverarbeitung zu drosseln oder zu beschleunigen, und den Wert auch dynamisch zu ändern. Beispiel: Sie können eine Tabelle so einrichten, dass die Anforderungen aus der Parkplatztabelle basierend auf dem Status der Anforderungen abgerufen werden. Sie können die Statusanforderungen NEW und ERROR_RETRY abrufen und zur Verarbeitung weitergeben.

Dieser geplante Dispatcher durchläuft dann die abgerufene Anzahl von Anforderungen und übergibt jede Anforderung an den asynchronen Prozessor zur Accounterstellung. Stellen Sie sicher, dass der Scheduler-Ablauf (übergeordnete) einen einseitigen asynchronen Integrationsfluss (untergeordnete) aufruft. Der Async-Prozessor gibt keine Antwort zurück. Daher wird der Scheduler-Thread freigegeben, um die restlichen Anforderungen zurückzugehen und in Schleifen zu durchlaufen und zu verteilen. Dadurch wird sichergestellt, dass Scheduler-Threads, die für den speziellen Anwendungsfall der Planung bestimmt sind, nicht in der Langzeitverarbeitung gehalten werden. Die Geschäftslogik der Anforderungsverarbeitung selbst wird von asynchronen Verarbeitungsressourcen verarbeitet, die in Oracle Integrations verfügbar sind.

Im Folgenden finden Sie einige Best Practices für die geplante Orchestrierung: Entkoppeln Sie die Planungslogik immer mit der Geschäftslogik, indem Sie eine Async-Übergabe von der geplanten Integration verwenden. Dadurch wird sichergestellt, dass die Scheduler-Threads nicht für die Accounterstellung verwendet werden.

• Geplante Orchestrierungen sollen bestimmte Anforderungen an Planungsabläufe erfüllen. Wenn sie mit Async-Handoff freigegeben werden, wird die Lösung bei der Verarbeitung einer großen Anzahl von Anforderungen skalierbar und performant.
• Geplante Orchestrierungen sollten nicht als Ersatz für App-gesteuerte Orchestrierungen verwendet werden.

Sie können Aktionen zur orchestrierten Integration hinzufügen. Wenn Sie "for-each" verwenden, können Sie einen Schleifen über ein sich wiederholendes Element ziehen und eine oder mehrere Aktionen im Rahmen der for-each-Aktion ausführen. Die Anzahl der Loop-Iterationen basiert auf einem vom Benutzer ausgewählten wiederholten Element. Beispiel: Sie haben eine Integration, in der Sie eine Reihe von Dateien heruntergeladen haben und die Ausgabe der Dateien in Schleifen durchlaufen möchten. Mit der for-each-Aktion können Sie diese Aufgabe ausführen. Beachten Sie, dass für einige der for-each-Schleifen Parallele Verarbeitungselemente ausgewählt werden kann. Dadurch wird sichergestellt, dass die Aktivitäten innerhalb der for-each-Schleife durch Integration in einem Batch zusammengefasst und parallel ausgeführt werden. Es gibt bestimmte Bedingungen, unter denen die Integration die Parallelität ignoriert. In solchen Fällen wird der Parallelitätsgrad auf 1 gesetzt, um Probleme mit gleichzeitigem Zugriff zu vermeiden.

Account erstellen

Die asynchrone Prozessorintegration verarbeitet die eingehenden Anforderungen vom geplanten Dispatcher und sendet sie an die Downstream-Anwendung.

Der asynchrone Prozessor stellt eine REST-Schnittstelle bereit. Es ist wichtig, dass diese Integration als ein unidirektionaler asynchroner Fluss modelliert wird, um die Scheduler-Integration freizugeben. Wenn Sie die asynchrone Integration auf eine Weise einrichten, stellen Sie sicher, dass der REST-Trigger eine POST-Methode bereitstellt und der REST-Ablauf keine Antwort an den Client zurückgibt.

1. Sie können diese beiden Optionen im Assistenten Rest-Endpunkt konfigurieren konfigurieren.
   1. Klicken Sie auf der Integrationsleinwand im Bereich Trigger auf REST, wenn die REST-Adapter noch nicht aufgeführt sind.
   2. Ziehen Sie die Integrationsverbindung auf das Pluszeichen unter START auf der Leinwand. Dadurch wird der Konfigurationsassistent REST-Endpunkt konfigurieren angezeigt.
2. Wählen Sie auf der Seite "Basisinformationen" des Assistenten in der Dropdown-Liste Welche Aktion möchten Sie am Endpunkt ausführen? die Option POST aus.
3. Wählen Sie den Anforderungs-Payload für diesen Endpunkt konfigurieren aus.

Da der asynchrone Ablauf die tatsächliche Accounterstellung ausführt, ist er dafür verantwortlich, den Anforderungsstatus in der Parkplatztabelle zu aktualisieren. Nach erfolgreicher Accounterstellung wird die Spalte STATUS in der Parkplatztabelle in PROCESSED aktualisiert.

Nicht erfolgreiche Anforderungen verarbeiten

Die erneute Weiterleitung fehlgeschlagener Anforderungen kann über die Parkplatztabelle gesteuert werden. Ein Error Handler auf Umfangsebene verarbeitet alle Faults während der Accounterstellung und aktualisiert den Status auf ERRORED bei Fehlern. Die Grund- und Fehlerdetails werden ebenfalls in der Parkplatztabelle aktualisiert. Dies ist nützlich, um zu bestimmen, ob die Anforderung zu einem späteren Zeitpunkt erneut weitergeleitet werden kann. Sie können auch E-Mails zu Fehlerbenachrichtigungen an Integrationsadministratoren senden lassen.

Fault Handler haben nicht erfolgreiche Anforderungen in der Parkplatztabelle auf den Status ERRORED gesetzt. Diese Anforderungen können in der Tabelle in den Status ERROR_RETRY aktualisiert werden und werden im nächsten Zeitplan für die erneute Verarbeitung aufgrund der Auswahlkriterien des Autonomous Transaction Processing-Datenbankaufrufs des geplanten Dispatchers ausgewählt.

Es gibt verschiedene Optionen, um solche erneuten Weiterleitungen auszulösen:

• Die Aktualisierung von ERRORED-Anforderungen an ERROR_RETRY kann von einem Administrator für die Datenbank ausgeführt werden.
• Sie können sogar einen Integrationsablauf für die erneute Weiterleitung hinzufügen, der täglich oder in einer beliebigen Häufigkeit ausgeführt wird, und alle ERRORED-Datensätze in ERROR_RETRY aktualisieren.
• Der Fault Handler der asynchronen Prozessorintegration kann den Status direkt auf ERROR_RETRY setzen, sodass jeder Fehler im nächsten Zeitplan automatisch erneut weitergeleitet wird.

Payload-Korrektur

Durch das Speichern der Nutzdaten für die Accounterstellung in der Parkplatztabelle können wir die Nutzdaten von Datenfehlern vor der erneuten Weiterleitung korrigieren. Aktualisieren Sie die Payload, und setzen Sie die Statusspalte auf ERROR_RETRY, um eine Anforderung mit der korrigierten Payload erneut weiterzuleiten.