機械翻訳について

一般的な統合パターンの回避Pitfalls

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

Chatty統合

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

パターン アンチ・パターンの理由 ベスト・プラクティス
外部APIをレコードごとに起動するには、ループ構文内でinvokeアクティビティを使用します。
  • ダウンストリーム・アプリケーションでは、大量のアトミック・リクエストが受信されます。 これにより、システム全体がduressの下に置かれます。
  • 使用ベースの価格設定モデルは、高コストに変換されます。
  • アプリケーション機能を利用して、単一のリクエストで複数のレコードを受け入れます:
    • Salesforce: 200 records, Oracle Engagement Cloud/Oracle ERP Cloud: 100 records, Oracle Service Cloud: 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のインポート・マップ機能を使用します。
    • メタデータの一貫性を維持し、検証を利用します。
    • マッパーは、インポートされたマップを表示して編集できます。

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

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

パターン アンチ・パターンの理由 ベスト・プラクティス
  • 多数の起動ロジックを使用して設計された大規模な同期統合。
  • 多くの反復を伴うループ内での起動との同期。
  • タイムアウトの可能性があります。 マーシャリングの速度が低下すると、すべて追加されます。
  • コールをブロックしています。 リソースおよび星その他の統合を保持します。
  • 完全に非同期統合に移行することを検討してください(起動および忘れた非同期レスポンス)。
    • 統合プラットフォームは、メッセージを受信したときにクライアントに確認を提供します。
    • 統合プラットフォームは、保証された処理を保証し、障害の再発行もサポートします。
  • レスポンスを送信する前に必須処理が含まれる同期統合に分割し、他の処理ロジックに対する別の非同期の起動と忘れた統合をトリガーします。
  • 複数のチャット・コールを置き換えるために、大まかな外部APIを使用して同期処理を最適化します。

統合の接続が多すぎます

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

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

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

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

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

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

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

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