回復可能な非同期統合の構築について

統合が脆く、短時間または一時的な中断を処理できない場合があります。効率的に拡張するには非同期統合が必要であり、このような統合を開発およびテストして本番環境で期待どおりに機能させるためのオプションが必要です。このソリューション・プレイブックでは、最新のネットワークとインフラストラクチャの現実に回復力のある非同期統合を構築するための推奨アプローチを紹介しています。

たとえば、REST APIを使用して財務クラウドにエンティティを作成する場合、経費精算書、銀行口座またはその他のエンティティの作成時に一時的な中断が発生する可能性があります。このような要求をFinancial Cloudで動的に抑制するには、このプレイブックで駐車場パターンについて説明します。駐車場パターンを使用すると、データを処理する前に中間ステージにデータを格納して、バッチ、複雑なメッセージの相関/フロー、スロットルなどの処理の問題を回避できます。

Oracle Integrationでの統合について

統合は、Oracle Integrationの主な構成要素です。統合には、少なくとも1つのトリガー(ソース)接続(Oracle Integrationに送信されるリクエスト用)と呼出し(ターゲット)接続(Oracle Integrationからターゲットに送信されるリクエスト用)と、これら2つの接続間のフィールド・マッピングが含まれます。

統合を作成する場合、すでに作成した接続に対して、トリガー(ソース)接続と起動(ターゲット)接続のデータを処理する方法を定義することで統合を構築します。これには、データに対して実行する操作のタイプ、それらの操作を実行する対象のビジネス・オブジェクトとフィールド、必要なスキーマなどの定義が含まれます。これを容易にするために、最も複雑な構成タスクがOracle Integrationによって処理されます。トリガー(ソース)接続と起動(ターゲット)接続が構成されると、2つの間のマッパーが有効化され、リクエスト・メッセージとレスポンス・メッセージの両方についてトリガー(ソース)・データ構造と起動(ターゲット)データ構造の間に情報をどのように転送するかを定義できます。

駐車場パターンについて

駐車場パターンでは、データは中間ステージからエンド・システムへのデータの処理を完了する前に、中間ステージに格納されます。

ここでは、実際のデータを駐車場に保存するためのいくつかの選択肢があります。各オプションには、考慮する必要がある様々なプロパティがあります。

最も簡単な方法は、データをCLOBとしてXML形式で格納することです。この方法では、CLOBの書込みと読取り、およびXMLとCLOB間の変換にオーバーヘッドが追加されます。
完全に実現された列を含む他の表にデータを個別に格納できます。この方法は、アプリケーション内でバッチ解除プロセスが入力ペイロードをデータベース表内の表形式にすでにコピーしている場合に最適です。そのため、データ形式を駐車場に活用できます。
テーブルを駐車場自体と組み合わせます。このソリューションは最も高性能であることが証明されるかもしれませんが、駐車場内の単純なデータ構造でのみ動作できます。

レジリエンスについて

環境に対する回復力を高める前に、まず、自己回復性が企業にとって何を意味するかを定義する必要があります。

つまり、統合プロセスの停止に伴うコストはいくらですか。一部の顧客の場合、数分の停止は完全に許容可能であり、処理ウィンドウ内で適切に実行されるバッチ・プロセスは部分的にしか遅延しません。他の人にとっては、数秒の停電でさえ、ビジネスに直接的な影響を与える財務上の損失をもたらします。

この観点から、次の要素を確認することが重要です。

ご使用の環境で許容される停止の期間はどれくらいですか。ここでは、停止の場合にビジネスにかかるコストを定義し、その停止が停電の期間とともにどのように進化するかの概要を説明する必要があります。
どのようなテクノロジが使用され、想定されるSLAでどのように実現できますか。リアルタイムまたはバッチ方式を採用していますか?それとも、その二つの組み合わせでしょうか。どのくらいのデータを処理していますか?