機械翻訳について

このレシピについて

このレシピでは、外部システムからダウンストリーム給与システムに従業員銀行詳細をインポートするユース・ケースの例を使用して、ダウンストリーム・スロットルおよびエラーを処理するためにParking lotパターンを使用する方法を示します。 Parking lotパターンの実装には、Oracle Autonomous Transaction Processing (ATP)データベース表が使用されます。

レシピを使用するには、レシピをインストールし、レシピ内の接続およびその他のリソースを構成する必要があります。 この例では、CSVファイルのOracle HCM Cloudなどの外部システムから従業員銀行詳細を受信します。 その後、CSVファイルがFTPサーバーまたはファイル・サーバーのローカル・ディレクトリにダウンロードされます。 その後、従業員の銀行詳細がATPデータベース表にバッチで登録され、さらに処理する前に特定の期間パークされます。 したがって、統合フローでは、同時に処理されるバッチの数を抑制できます。 準備完了バッチは処理のためにステージングされた方法でピック・アップされ、処理済データは最終的にダウンストリーム給与システムに更新されます。

レシピの統合フローの概要:

  • 「リクエストの永続性」統合(SR_BulkDownload_RequestPersister_ATP)は、外部システムから受信したCSVファイルを読み取り、FTPのローカル入力ディレクトリに書き込みます。 バッチ構成(group_idやgroup_typeなど)を読み取り、ATPデータベース表にメタデータを書き込みます。 登録されたバッチは、ATPの「Parking lot」表に特定の期間パークされます。
  • 「スケジュール済ディスパッチャ」統合(SR_ScheduledDispatcher_CSVBatch)は、必要な頻度で実行するようにスケジュールされます。 実行ごとに、ATPの「Parking lot」表からバッチ・リクエストをフェッチし、処理のために「非同期バッチ・プロセッサ」統合にディスパッチします。 したがって、「非同期バッハ・プロセッサ」統合がトリガーされ、処理のために発行されたバッチが処理されます。
  • 「非同期プロセッサ」統合(SR_OneWay_Processor_HCM_To_Payroll)は、発行されたすべてのバッチ・リクエストを処理します。 また、ATPの「バッチ統計」表のバッチ・ステータスが更新されます(たとえば、バッチが正常に処理されると、ステータスがPROCESSEDに更新されます)。 処理が成功すると、別の統合(このレシピのSR_MOCK_EmpBankAccountProvider統合など)が起動され、処理された情報がREST APIコールを介してダウンストリーム・アプリケーションに送信されます。 ダウンストリーム・アプリケーションからレスポンスで受信したエラーは、FTPの「エラー」フォルダに書き込まれます。 これらのペイロード・エラーは、ATPの「ペイロード・エラー・レコード」表にも書き込まれます。
  • 「再発行プロセッサ」統合(SR_ScheduledDispatcher_PayrollErrors)は、修正されたバッチ・リクエストの失敗/エラーを再送信するために使用されます。 READY状態のレコードを「ペイロード・エラー・レコード」表からフェッチし、処理のために再発行します。

システムおよびアクセスの要件

  • Oracle Integration 3

  • セキュアFTP (sFTP)サーバーまたはファイル・サーバー

  • sFTPサーバーにアクセスするためのFTPクライアント

  • Oracle Autonomous Transaction Processing

  • 管理者ロールを持つOracle Autonomous Transaction Processingのアカウント

レシピ・スキーマ

このセクションでは、レシピのアーキテクチャの概要について説明します。


「parking-lot-pattern.pngの説明は以下のとおりです
図parking-lot-pattern.pngの説明」

Oracle HCM Cloudなどのアップストリーム・アプリケーションからの従業員銀行詳細を含むCSVファイルが、FTPサーバーまたはファイル・サーバーにダウンロードされます。 Oracle Integrationの最初の統合フロー(「リクエストの永続性」)は、ATPデータベースにバッチを登録します。 各バッチ・リクエストは、ATPデータベースParking lot表に一定期間パークされるため、統合フローでは、同時に処理されるバッチの数を抑制できます。 Oracle Integrationの2番目のスケジュール済統合フロー(「スケジュール済ディスパッチャ」)は、ATPのParking lot表から選択した日時でバッチをフェッチし、さらに処理するためにバッチをディスパッチします。 2番目の統合は、ディスパッチされたバッチを処理する3番目の統合フロー(「非同期プロセッサ」)をトリガーします。 その後、処理されたバッチは、REST APIコールを介して給与システムなどのダウンストリーム・アプリケーションに送信されます。 ダウンストリーム・アプリケーションからのレスポンスとして受信されたエラーは、修正され、Oracle Integrationの4番目の統合フロー(「再発行プロセッサ」)によって処理のために再送信されます。