機械翻訳について

一般的な統合スタイルの落とし穴と設計のベスト・プラクティス

統合の設計時には、次のベスト・プラクティスおよび統合スタイルの落とし穴に注意してください。

共通統合スタイルの落とし穴を回避

最初から適切に統合を設計すれば、再処理の量を節約できます。 この項では、一般的な統合スタイルの落とし穴(アンチ・パターンと知られる)とこれらの落とし穴を回避するためのベスト・プラクティスについて説明します。

Chatty統合

ユース・ケース: ファイルまたは大規模データ・セットのレコードを外部システムと同期します(たとえば、仕訳トランザクションの同期化やOracle HCM Cloudへの従業員レコードのアップロード)。

パターン アンチ・パターンの理由 ベスト・プラクティス
外部APIをレコードごとに起動するには、ループ構文内でinvokeアクティビティを使用します。
  • ダウンストリーム・アプリケーションでは、大量のアトミック・リクエストが受信されます。 これにより、システム全体がduressの下に置かれます。
  • 使用ベースの価格設定モデルは、高コストに変換されます。
  • アプリケーション機能を利用して、単一のリクエストで複数のレコードを受け入れます:
    • Salesforce: 200 records, Oracle Engagement Cloud/ERP Cloud: 100レコード、サービス・クラウド: 1000レコード
  • アダプタ機能を利用して、大きいデータ・セットをアタッチとして送信します。
    • Salesforceアダプタ: 10,000レコード/10 MBのファイル、Oracle ERP CloudアダプタではFBDIファイルがサポートされています
  • ステージ・ファイル・アクションを使用する(ファイルに追加オプション) - 宛先の末尾にファイルを送信します。

進行を停止しないスケジュール済ジョブ

ユース・ケース: サービス・レベル契約(SLA)が厳格な一連のファイル内でレコードを処理します(たとえば、従業員レコードをOracle HCM CloudからActive Directoryに同期したり、福利厚生情報を送信します)。

パターン アンチ・パターンの理由 ベスト・プラクティス
スケジュールされた統合では、処理するすべてのファイルを検索し、ファイルが残っていないまで、すべてを順次処理にループします。
  • 多数のファイルが存在する場合、スケジュール済ジョブの1回の実行が長時間実行されて、他のジョブが停止してフレームワークにより終了することがあります。
  • 単一のサーバーに関連付けられた処理: これにより、クラスタの複数のノードは利用されません。
  • スケジュールされた1回の実行で処理するファイルの数を制限します。
    • リスト・ファイルの結果を制限します。
  • スケジュール・パラメータを使用して、次回実行時に最後に処理されたファイルを記憶します。
  • 予定されている次の実行の処理が実行可能でない場合、同じ統合から即時実行コマンドを起動して次のファイルの処理をトリガーします。

外部で更新されたIARファイルをインポート

ユース・ケース: マッパーで使用できない詳細なXSLコンストラクトを利用する必要があります。

パターン アンチ・パターンの理由 ベスト・プラクティス
IARファイルを外部で更新してから、Oracle Integrationにインポートします。
  • これにより、メタデータの一貫性が損われ、検証が失敗することがあります。
  • アクティブ化の失敗が発生する可能性があります。
  • Oracle Integrationのインポート・マップ機能を使用します。
    • メタデータの一貫性を維持し、検証を利用します。

同期統合の深さが多すぎます

ユース・ケース: リクエストにより、複数のシステム間でエンリッチメントおよび更新が関与する複雑な処理がトリガーされます。

パターン アンチ・パターンの理由 ベスト・プラクティス
  • 同期統合が大容量の場合、 /conditionalロジックを起動します。
  • 多くの反復を伴うループ内での起動との同期。
  • Susceptible to timeouts - マーシャリングの速度が低下すると、すべて追加されます。
  • ブロッキング呼出し - リソースおよび星その他の統合を保持します。
  • 非同期統合への完全な移動の探索 - 非同期レスポンスが起動され、忘れた場合。
    • 統合プラットフォームは、メッセージの受信時にクライアントに確認を提供します。
    • プラットフォームにより、保証付き処理が保証され、障害の再送信もサポートされます。
  • レスポンスを送信する前に必須処理が含まれる同期統合に分割し、他の処理ロジックに対する別の非同期の起動と忘れた統合をトリガーします。
  • 複数のチャット・コールを置き換えるために、大まかな外部APIを使用して同期処理を最適化します。

統合の接続が多すぎます

ユース・ケース: 開発者は統合を作成するときに、同じアプリケーションを指し示す独自の接続を定義します。 これにより、多くの接続が重複します。

パターン アンチ・パターンの理由 ベスト・プラクティス
すべての開発者は、異なる構成/資格証明セットを使用して独自の接続を作成します。
  • 接続の数が多くなると、管理性の手間がかかり、特にエンドポイント、資格証明、構成などを更新する必要がある場合に役立ちます。
  • アプリケーションのアップグレードまたはメタデータ/座標の変更がある場合に影響分析を完了します。
  • 管理者が必要な接続を作成し、同じタイプの接続が重複して作成されないようにしてください。
    • 命名規則および一連の構成の維持に関するベスト・プラクティスをビルドします。

多数のレコードを含むファイルの読取り

ユース・ケース: 多数のレコードが含まれるファイルを読み取り、個々のレコードを処理します。

パターン アンチ・パターンの理由 ベスト・プラクティス
ファイルの読取りオプションを使用し、レコードごとにレコードを処理して、メモリー内のファイル全体を読み取ります。
  • 大量のメモリーを消費し、他のシステム処理に影響を与えます。
  • 順次処理では、組込みのマップ削減機能は利用されません。
  • ファイルのダウンロード・オプションを使用して、ステージングのロケーションにファイルをダウンロードします。
    • ステージ・ファイルは、インスタンスの完了時に保護および削除されます。
  • セグメントを含む読取りファイル・オプションを使用します。
    • セグメント処理内のレコード・レベル処理を引き続きモデル化できます。
    • プラットフォームでは、セグメントがパラレルで自動的に処理されます。
    • プラットフォームを選択すると、必要に応じてファイルの一部のみがメモリーに書き込まれます。

ビジネス要件の変更に関係なく、変更のない統合の実行

ユース・ケース: 最初の実装時に作成された統合/スケジュールは、業務要件が時間とともに変更されても引き続き実行されます。

パターン アンチ・パターンの理由 ベスト・プラクティス
  • 最初の製品実装時に作成された統合およびスケジュール済ジョブは、変化するビジネス・ニーズに対して再評価されません。
  • 統合の急増は、既存の統合を参照せずに発生します。
  • 不要な作業を処理するジョブの実行。
  • 類似の機能を持つ複数の統合の非最適化呼出し。
  • デッド統合、ライフ・サイクル管理(LCM)オーバーヘッドによるクローニング、開発者の混乱。
  • 現在のビジネス・ニーズに対して既存の統合/スケジュールを定期的に分析します。
    • 履歴実行のモニタリング・データを参照してください。
  • 非常に似ている統合を統合します。
    • Oracle Engagement Cloudで顧客が作成したイベントをサブスクライブする統合aとb - エンドポイントBを起動するためのエンドポイントaと統合bを起動するための統合a。
  • もう関係のない統合を非アクティブ化します。
    • パートナが不要になった場合、パートナ消費向けのファイルを生成するための統合は関係ありません。
  • 頻度を低くする必要がある統合のスケジュールを調整し、不要になったスケジュールを削除します。
    • 毎月生成されたファイルでは、数分ごとにスケジュールが実行されます。
    • ビジネス・ニーズの変化により、特定のスケジュールを完全に不要にすることができます。

スケジュール済統合が多すぎることの作成の回避

構成されたスケジュール済統合の数が多すぎる場合、インスタンスはリソースが使用可能になるのを待機するか、以前の統合の実行が完了するのを待機する可能性があります。 これにより処理遅延が発生し、一部のインスタンスが待機状態より長く、スケジュールが予定時間に開始されない可能性があります。

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

スケジュール済の統合を、アプリケーション駆動のオーケストレーション済RESTアダプタのトリガー・ベースの統合に変換できます。 「スケジュール済統合からRESTアダプタによってトリガーされるオーケストレーション統合への変換」を参照してください。

スケジュールされた多数の統合が確実に必要で、上記の問題が発生した場合は、次の設計変更をソリューションとして推奨します:
  1. スケジュールされた統合ごとに、アプリケーション駆動型オーケストレーションのRESTアダプタ・トリガー・ベースの統合に変換します。 「スケジュール済統合からRESTアダプタによってトリガーされるオーケストレーション統合への変換」を参照してください。
  2. 前述のステップ1で変換したアプリケーション駆動型オーケストレーション統合の非同期起動のみを実行する、新しいスケジュール済統合を作成します。

    このソリューションでは、スケジュールされた統合がスケジュールされた時間に開始し、RESTアダプタのトリガー・ベースの子統合を非同期に起動して、ミリ秒で完了できます。 この方法により、スケジューラ・リソースを囲むバックログと競合が減少します。

    変換するスケジュール済の統合の数が多い場合は、次の統合で始まる段階的なアプローチをお薦めします。
    • 最長実行スケジュール済統合。
    • 最短頻度(10分ごとに実行される統合など)で構成されたスケジュール済統合。

    前述の設計プラクティスを使用して、新しいスケジュール済みの統合を設計します。

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

同期統合のベスト・プラクティス

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

  • 任意の非同期リクエスト・レスポンス・サービスを呼び出す同期統合:

    • 非同期の火災と忘れ(一方向)を呼び出すことは許容されます。

    • Oracle Integrationは現在、非同期リクエスト・レスポンス・サービスのモデリングを許可していません。 ただし、すべてのスケジュール済オーケストレーション・スタイルで内部的に非同期リクエスト・レスポンスが使用されます。 したがって、スケジュール済オーケストレーションを使用した同期統合は、アンチ・パターンです。

  • 5分を超える複数のサービスをコールする同期統合は、Oracle WebLogic Serverのスタック・スレッドとしてレポートされます。

設計長い-非同期フローとしての統合の実行または時間のかかる統合

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

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

同期呼出し時のサービス呼出しのタイムアウト

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

コールには1つ以上のプロキシが含まれる場合があるため、各プロキシが同様のタイムアウトになる場合があります。 たとえば、Oracle Public Cloudのデフォルトのプロキシのタイムアウト値は120秒です。 コールが起動ウォールの遅延オンプレミス・サービスに対するものである場合、構成されたプロキシにも独自のタイムアウト値が設定されている可能性があります。

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

アウトバウンド統合のパラレル処理

アウトバウンド統合でデータを複数のサード・パーティ・システムにパラレルで自動的に送信できるようにする特定の統合設計はありませんが、このシナリオを許可する統合設計アプローチがあります。

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

  • データの受信/処理のみを行うメイン親統合を作成します。

  • 個別の子統合を作成して、アウトバウンドRESTの個々の呼出しを実行します。

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

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

  • パブリッシュ/サブスクライブの設計方法に従います(たとえば、データ・イベントをキューに配置し、各子フローをキューからサブスクライブする、など)。