1. 回復力のある非同期統合を構築するためのベストプラクティス
  2. Oracle Integrationを使用したレジリエンシの設計

Oracle Integrationを使用した耐障害性の設計

これらのベスト・プラクティスは、回復力のある統合を設計する際に使用します。

設計統合

ここでは、REST APIを介してアップストリーム・アプリケーションからリクエストを受信し、解析、検証してダウンストリーム・アプリケーションに送信する基本的なインバウンド統合フローを示します。

アップストリーム・アプリケーションがリクエストを送信しているときに、ダウンストリーム・アプリケーションが応答しなくなる場合があります。これらのリクエストは、ダウンストリームでは確認されません。バッチ、複雑なメッセージ相関/フロー、スロットルなど、多くの処理課題があります。

REST APIを使用してOracle Financialsクラウドにエンティティを作成する例を見てみましょう。リクエストは、統合RESTエンドポイントによって受信される必要があります。Financials Cloudで発生したリクエストを動的に抑制し、リクエストのステータスを追跡して、失敗したリクエストを再送信できる必要があります。このソリューションでは、3つの統合とAutonomous Transaction Processingデータベースが表示されます。駐車場の実装は、データベースやCoherenceなどの様々なストレージ・テクノロジを使用して行うことができます。ただし、わかりやすくするためにAutonomous Transaction Processingデータベース表を使用しています。

oic_extended_parkinglot_eh.pngの説明が続きます
図oic_extended_parkinglot_eh.pngの説明

示されているイメージでは、アップストリーム・アプリケーションがリクエストを送信すると、リクエスト・パーシスタ・インターグレーションはリクエストをデータベースに送信し、アップストリーム・アプリケーションを確認します。データベースでは、駐車場パターンにリクエスト・メタデータおよびステータス情報が格納され、入力リクエストが入ってきた順序に基づいて処理されます。各メッセージはストレージにx分間(駐車時間)駐車されるため、統合フローは同時に処理されるメッセージの数を抑制できます。

オーケストレーションされたスケジュール・ディスパッチャ統合は、スケジュールによってトリガーされます。この統合実行をスケジュールすると、選択した日時にデータベースからリクエストをコピーできます。また、統合の頻度を定義することもできます。これらのリクエストは、非同期プロセッサ統合に渡されます。非同期プロセッサ統合では、受信リクエストが処理され、ダウンストリーム・アプリケーションに送信されます。

設計コンポーネント

高レベルの設計には、3つの統合と1つのデータベースがあります。アカウント作成を例にとりますが、実際には、Oracle SaaS REST APIによって公開されているビジネス・オブジェクトである可能性があります。

POSTリクエスト

Request Persister統合は、RESTトリガー・エンドポイントを公開します。このエンドポイントは、アップストリーム・アプリケーション(クライアント)によってコールされ、アカウント作成リクエストをPOSTできます。

この永続統合では、クライアント・アプリケーションからの受信時にアカウント作成リクエストがAutonomous Transaction Processingデータベースに即時にロードされ、HTTP 202/Acceptedの受信が確認されます。口座IDおよびペイロード全体が、後続の処理のために駐車場表に保持されます。

要求を駐車場表にロード

ここでのAutonomous Transaction Processingデータベースには、処理前に受信したすべてのリクエストがパーク状態になる駐車場表が保持されます。簡単にするために、ペイロードを保持し、リクエスト・ステータスおよびエラー情報を追跡するための単純な表が表示されます。

アカウント作成JSONリクエスト・ペイロードは、完全に文字列として駐車場表に格納されます。CLOBまたはエンコードされた文字列として格納するユース・ケースがあり、表に表示可能なペイロードを持つことが望ましくない場合があります。ただし、ペイロードをjsonとして格納すると、エラーの再発行中にペイロードを変更できます。

必要に応じて、JSONリクエスト全体を表に格納できます。これは、2つのステージで実行できます。
  • スキーマ・ファイルを作成するためのリクエスト・ペイロードのJSONサンプルを使用するステージWrite。
  • 不透明なスキーマを使用したステージRead Entire File 操作。

    JSONペイロード文字列のbase64エンコード値を指定します。次に、組み込み関数decodebase64(opaqueElement)をマッパー(または代入)で使用して、JSON文字列値を取得できます。ステージ読取り時に使用される不透明なスキーマxsdファイルは、このソリューションの後半で説明するGitHubにあります。

スケジュールに従って要求を発送

スケジュールされた統合は、必要な頻度で実行されるようにスケジュールされています。実行ごとに、設定された数のリクエストがフェッチされ、処理のために各リクエストが非同期プロセッサ統合にディスパッチされてループされます。

多数のリクエストをスケジュール済パラメータとしてフェッチして、リクエスト処理を抑制または高速化したり、値を動的に変更するように構成できます。たとえば、駐車場テーブルからのリクエストがリクエストのステータスに基づいてフェッチされるようにテーブルを設定できます。NEWおよびERROR_RETRYステータス・リクエストをフェッチし、処理のために渡すことができます。

次に、このスケジュール済ディスパッチャはフェッチされたリクエスト数をループし、アカウント作成のために各リクエストを非同期プロセッサに渡します。スケジューラ(親)フローが一方向非同期統合(子)フローをコールしていることを確認します。非同期プロセッサは応答を返さないため、スケジューラスレッドは解放され、残りの要求をループしてディスパッチします。これにより、スケジュールの特殊なユースケース用のスケジューラ・スレッドが長期処理で保持されなくなります。リクエスト処理自体のビジネス・ロジックは、Oracle統合で使用可能な非同期処理リソースによって処理されます。

スケジュール済オーケストレーションのベスト・プラクティスを次に示します: スケジュール済統合から非同期ハンドオフを使用して、常にスケジューリング・ロジックをビジネス・ロジックと切り離します。これにより、スケジューラ・スレッドがアカウント作成に使用されなくなります。
  • スケジュールされたオーケストレーションは、スケジューリング・フローの特定の要件を満たすことを目的としており、Async-handoffを使用してフローを解放すると、多数のリクエストを処理する際にソリューションがスケーラブルでパフォーマンスを発揮します。
  • スケジュール済オーケストレーションは、アプリケーション駆動オーケストレーションの代替として使用しないでください。

オーケストレーションされた統合にアクションを追加できます。for-eachアクションを使用する場合は、繰返し要素をループオーバーしてfor-eachアクションのスコープ内の1つ以上のアクションを実行できます。ループの繰返し回数は、ユーザー選択の繰返し要素に基づきます。たとえば、多くのファイルをダウンロードして、そのファイルの出力をループ処理する必要がある統合を使用する場合があります。for-eachアクションにより、このタスクを実行できます。一部のfor-eachループに対して「Process Items in Parallel」を選択できることに注意してください。これにより、for-eachループ内のアクティビティが統合によってバッチ化され、パラレルに実行されます。統合によって並列性が無視される特定の条件があります。このような場合、並列度は、同時実行性の問題を回避するために1に設定されます。

アカウントの作成

非同期プロセッサ統合では、スケジュール済ディスパッチャからの受信リクエストが処理され、ダウンストリーム・アプリケーションに送信されます。

非同期プロセッサはRESTインタフェースを公開します。この統合を一方向の非同期フローとしてモデル化して、スケジューラ統合を解放することが重要です。非同期統合を一方向で設定する場合は、RESTトリガーがPOSTメソッドを公開し、RESTフローがクライアントにレスポンスを返さないことを確認してください。
  1. これら2つは、Restエンドポイントの構成ウィザードで構成できます。
    1. RESTアダプタがまだリストされていない場合は、統合キャンバスの「トリガー」ペインで「REST」をクリックします。
    2. 統合接続をキャンバス上のSTARTの下のプラス・アイコンにドラッグします。「RESTエンドポイントの構成」構成ウィザードが表示されます。
  2. ウィザードの「基本情報」ページで、「エンドポイントで実行するアクション」のドロップダウン・リストから「POST」を選択します。
  3. 「Configure a request payload for this endpoint」エンドポイントを選択します。

非同期フローは実際のアカウント作成を行うため、駐車場テーブルのリクエスト・ステータスを更新します。アカウントが正常に作成されると、駐車場表のSTATUS列がPROCESSEDに更新されます。

失敗したリクエストの処理

失敗したリクエストの再送信は、駐車場テーブルから制御できます。スコープ・レベルのエラー・ハンドラは、アカウント作成中のフォルトを処理し、エラーのステータスをERROREDに更新します。駐車場テーブルでは、理由とエラーの詳細も更新されます。これは、後でリクエストを再送信できるかどうかを判断するのに役立ちます。エラー通知電子メールを統合管理者に送信することもできます。

フォルト・ハンドラは、失敗したリクエストを駐車場表でERROREDステータスに設定します。これらのリクエストは、表のERROR_RETRYステータスに更新でき、スケジュール済ディスパッチャのAutonomous Transaction Processingデータベース呼出しの選択基準により、次の再処理スケジュールで選択されます。

このような再送信をトリガーする様々なオプションがあります。
  • ERROR_RETRYへのERROREDリクエストの更新は、データベースの管理者が実行できます。
  • また、毎日または任意の頻度で実行される再発行統合フローを追加し、すべてのERROREDレコードをERROR_RETRYに更新することもできます。
  • 非同期プロセッサ統合のフォルト・ハンドラは、ステータスを直接ERROR_RETRYに設定できるため、すべての障害が次のスケジュールで自動的に再発行されます。

ペイロード訂正

駐車場表にアカウント作成ペイロードを保存することで、再送信前にデータ・エラーのペイロードを修正できるようになりました。ペイロードを更新し、ステータス列をERROR_RETRYに設定して、修正されたペイロードでリクエストを再送信します。