設計のベスト・プラクティス

スケジュール統合を慎重に作成

構成されているスケジュール統合が多すぎる場合、リソースが使用可能になるか、以前の統合実行が完了するまで、インスタンスはバックログされる可能性があります。これによって、一部のインスタンスが待機状態にある必要以上に長く、スケジュールがスケジュールされた時間に開始されない場合の処理が遅延する可能性があります。

ベスト・プラクティスとして、同時に実行するようにスケジュールされているスケジュール統合を多すぎないようにしてください。可能なかぎり、次のガイドラインに従ってください。

アクティブ・スケジュールが絶対に必要でない場合、スケジュールされたトリガーのかわりに非同期RESTアダプタ・トリガーを使用します。
長時間実行のスケジュール統合(完了など、1時間以上かかるスケジュール統合)は作成しないでください。これにより、スケジューラ・リソースが他のスケジュール済実行に影響を与えるようにブロックされます。
スケジュール・クラスタを回避するために、スケジュールを時間の経過に伴って分散します。

スケジュール統合をRESTアダプタのトリガー・ベースのアプリケーション統合に変換できます。「RESTアダプタへのスケジュール統合の変換:トリガーされたアプリケーション統合」を参照してください。

非常に多くのスケジュール統合が必要で、前述の問題が発生した場合は、ソリューションとして次の設計変更が推奨されます:

スケジュール統合ごとに、RESTアダプタのトリガー・ベースのアプリケーション統合に変換します。「RESTアダプタへのスケジュール統合の変換:トリガーされたアプリケーション統合」を参照してください。
上のステップ1で変換したアプリケーション統合の非同期起動のみを実行する新しいスケジュール統合を作成します。
このソリューションを使用すると、スケジュール統合をスケジュールされた時間に開始し、RESTアダプタのトリガー・ベースの子統合を非同期で起動し、ミリ秒以内に完了できます。この方法により、スケジューラ・リソースを囲むバックログと競合が減少します。
変換する多数のスケジュール統合がある場合は、次の統合から開始するステージング済のアプローチをお薦めします。
- 最長実行スケジュールの統合。
- 最も短い頻度(たとえば、10分以下ごとに実行される統合)で構成された統合をスケジュールします。
前述の設計プラクティスとの新しいスケジュール統合を設計します。

「スケジュール統合が時間どおりに実行されていない」と「スケジュール統合インスタンスが終了した場合」を参照してください。

同期統合のガイドラインに従う

同期統合を設計する際は、次のベスト・プラクティスに注意してください。

任意の非同期リクエスト・レスポンス・サービスを呼び出す同期統合:
- 非同期の火災と忘れ(一方向)を呼び出すことは許容されます。
- Oracle Integrationは現在、非同期リクエスト・レスポンス・サービスのモデリングを許可していません。ただし、すべてのスケジュール統合では、非同期リクエスト・レスポンスが内部的に使用されます。したがって、スケジュール統合を使用した同期統合は反パターンです。
5分を超える複数のサービスを呼び出す同期統合は、スタック・スレッドとして報告されます。

非同期としての長期にわたる統合の設計

長時間実行する統合または時間がかかる統合を設計する場合は、次のベスト・プラクティスに注意してください。

長時間実行または時間がかかる統合は、同期フローとして公開しないでください。このアクションにより、クライアント・アプリケーション(他の統合を含む)がタイムアウトする可能性があります。同期統合には、サーバー側のタイムアウトもあります。かわりに、非同期フローとして2分を超える同期統合をモデル化します。

同期統合でのタイムアウトの理解

Oracle Integrationからの同期起動(他の統合へのコールを含む)によってコールがブロックされ、300秒以内に完了する必要があるシナリオがある場合があります。

呼び出しには1つ以上のプロキシが含まれる可能性があるため、各プロキシのタイムアウトは似ている可能性があります。たとえば、Oracle Public Cloudのデフォルト・プロキシのタイムアウト値は120秒です。オンプレミス・サービスへのコールがファイアウォールの背後にある場合、構成されたプロキシには独自のタイムアウト値も設定できます。

タイムアウトが複数のレイヤーで定義されている場合、サービス起動は最初のタイムアウトで失敗します。

サードパーティ・システムへのデータの効率的な送信

アウトバウンド統合でデータを異なるサード・パーティ・システムにパラレルに送信することを自動的に有効にする特定の統合設計はありませんが、アウトバウンド統合でのパラレル処理の使用など、このシナリオを可能にする統合設計アプローチがあります。

統合を複数の統合に分割します:

データの受信/処理のみを行うメイン親統合を作成します。
個別の子統合を作成して、アウトバウンドRESTの個々の呼出しを実行します。

メイン統合と個別の子統合の間のインタフェースは、次のアプローチに従います:

ダミーのRESTコールで構成されていますが、非同期である必要があります。基本的に、非同期コールはレスポンスによってブロックされず、ファイア・アンド・フォーゲット設計を使用すると、使用可能なスレッドが使用可能なシステム・リソース内で、子統合処理に関する作業をパラレルに行うことができます。このタイプの設計をお薦めします。すべての同期RESTコールが同じ統合で実行される場合、各同期コールにかかる時間の合計が5分を超えるとタイムアウト・エラーが発生する可能性があります。
パブリッシュ/サブスクライブの設計方法に従います(たとえば、データ・イベントをキューに配置し、各子フローをキューからサブスクライブする、など)。