使用 Oracle Integration 設計抗逆力

設計彈性整合時，請使用這些最佳做法。

指定整合

以下是透過 REST API 接收上游應用程式要求、剖析、驗證並將其傳送到下游應用程式的基本輸入整合流程。

在上游應用程式傳送要求時，下游應用程式可能會沒有回應。下游不會認可這些要求。有許多此類處理挑戰，例如批次、複雜訊息關聯 / 流程和節流。

舉例說明如何使用 REST API 在 Oracle Financials 雲端上建立實體。要求必須由整合 REST 端點接收。您應該能夠動態調節擊中 Financials Cloud 的要求，並追蹤要求的狀態，然後重新提交任何失敗的要求。此解決方案顯示三個整合和一個 Autonomous Transaction Processing 資料庫。您可以利用各種儲存技術 (例如資料庫或 Coherence) 來實行停車場。不過，我們使用 Autonomous Transaction Processing 資料庫表格來簡化作業。

oic_extended_parkinglot_eh.png 圖解說明

在顯示的影像中，當上游應用程式傳送要求時，「要求永久」整合會將它傳送到資料庫並認可上游應用程式。在資料庫中，停車場模式會儲存要求中繼資料與狀態資訊，並會根據輸入要求的輸入順序來處理輸入要求。每個訊息都會停留在儲存體中 x 分鐘 (停車時間)，因此整合流程有機會調節並行處理的訊息數目。

協調的「排程分配器」整合是由排程觸發。您可以排定此整合執行，在您選擇的日期和時間從資料庫複製要求。您也可以定義整合的頻率。這些要求會交由「非同步」處理器整合處理。非同步處理器整合會處理內送要求並將其傳送到下游應用程式。

設計元件

高階設計有三個整合與一個資料庫。我們將帳戶建立作為範例，但實際上，這可能是任何 Oracle SaaS REST API 公開的任何業務物件。

Post 要求

「要求保存者」整合會公開 REST 觸發器端點，上游應用程式 (從屬端) 可以呼叫此端點來 POST 帳戶建立要求。

此永久整合會在收到用戶端應用程式時立即將帳戶建立要求載入至 Autonomous Transaction Processing 資料庫，並確認收到 HTTP 202/Accepted 的收據。「帳戶 ID」與整個有效負載會保留在停車場表中供後續處理使用。

將請求載入停車場表格

此處的 Autonomous Transaction Processing 資料庫包含停車場表格，所有收到的要求都會在處理前停駐。為了簡化，系統會顯示一個簡單的表格來保存有效負載，並追蹤要求狀態和任何錯誤資訊。

帳戶建立 JSON 要求有效負載完全以字串形式儲存在停車場表格中。在某些情況下，可能會使用案例儲存為 CLOB 或編碼字串，而此字串不希望在表格中包含可見的有效負載。不過，將有效負載儲存為 json，可讓您在重新提交錯誤時變更有效負載。

您可以視需要將整個 JSON 要求儲存在表格中。您可以在兩個階段執行此動作：

• 使用要求有效負載之 JSON 範例建立綱要檔案的階段 Write。
• 使用不通透綱要的階段 Read Entire File 作業。

  提供 JSON 有效負載字串的 base64 編碼值。接著可以在對應程式 (或指派) 中使用內建函數 decodebase64 (opaqueElement) 取得 JSON 字串值 ！。GitHub 中提供階段讀取期間所使用的不通透綱要 xsd 檔案，稍後會在本解決方案中討論。

根據排程分派要求

排定的整合已排定以所需的頻率執行。在每次執行時，它會擷取已設定數目的要求和迴圈，然後將每個要求分派至「非同步處理器」整合以進行處理。

您可以設定將一些要求擷取為排定的參數來調節或加速要求處理，也可以動態變更值。例如，您可以設定表格，以便根據要求狀態擷取停車場表的要求。您可以擷取 NEW 和 ERROR_RETRY 狀態要求並傳入進行處理。

接著，此「排定的分配器」會循環擷取的要求數目，然後將每個要求交由「非同步」處理器處理，以建立帳戶。確定「排程器」(父項) 流程呼叫一種「非同步整合」(子項) 流程。「非同步」處理器不會傳回任何回應，因此排程器執行緒會釋出以返回並循環處理其餘要求並加以分配。這可確保用於排程特殊使用案例的排程器執行緒不會保留在長期處理中。要求處理本身的商業邏輯是由 Oracle Integrations 中可用的非同步處理資源所處理。

以下是排定協調流程的一些最佳做法：一律使用排定整合的「非同步移交」將排程邏輯與業務邏輯脫鉤。這將確保排程器執行緒不會用於建立帳戶。

• 排定的協調流程主要是滿足排程流程的特定需求，並使用「非同步交接」將它們釋出，讓解決方案在處理大量要求時可擴展且效能優異。
• 排定的協調流程不應作為應用程式導向協調流程的替代項目。

您可以新增動作至協調整合。如果您使用 for-each 動作，則可以對重複元素執行迴圈，並在 for-each 動作的範圍內執行一或多個動作。迴圈重複數目取決於使用者選取的重複元素。例如，您可能有一個整合，其中已下載一些檔案，而想要對檔案的輸出執行迴圈。for-each 動作可讓您執行此工作。請注意，您可以為部分 for-each 迴圈選取平行處理項目。這樣可確保 for-each 迴圈內的活動會被整合批次處理，並平行執行。在某些情況下，整合會忽略平行程度。在此情況下，平行程度將設為 1 以避免並行問題。

建立帳戶

非同步處理器整合會處理來自「排定的分配器」的內送要求，並將它傳送到下游應用程式。

非同步處理器會公開 REST 介面。請務必將此整合建立為單向非同步流程的模型，以釋出排程器整合。當您以一種方式設定非同步整合時，請確定 REST 觸發程式會公開 POST 方法，而且 REST 流程不會傳回從屬端的回應。

1. 您可以在設定 Rest 端點精靈中設定這兩者。
   1. 在整合工作區的觸發程式窗格中，如果尚未列出 REST 轉接器，請按一下 REST 。
   2. 將您的整合連線拖曳至工作區開始下方的加號圖示。這會顯示設定 REST 端點組態精靈。
2. 在精靈的「基本資訊」頁面上，從端點要執行什麼動作的下拉式清單中選取 POST 。
3. 選取設定此端點的要求有效負載端點。

由於非同步流程會執行實際帳戶建立，因此會負責更新停車場表中的要求狀態。帳戶建立成功之後，停車場表中的 STATUS 資料欄就會更新為 PROCESSED 。

處理失敗的要求

重新提交失敗的要求可從停車場表進行控制。範圍層次錯誤處理程式會在建立帳戶時處理任何錯誤，並將狀態更新為 ERRORED 以取得任何錯誤。原因與錯誤詳細資料也會在停車場表中更新。這有助於判斷要求是否可於稍後重新提交。您也可以將錯誤通知電子郵件傳送給整合管理員。

錯誤處理程式會將停車場表格中的失敗要求設為錯誤狀態。這些要求可以在表格中更新為 ERROR_RETRY 狀態，並會因為 Scheduled Dispatcher 的 Autonomous Transaction Processing 資料庫呼叫選取條件，而在下一個排程中進行重新處理。

有多種選項可觸發此類重新提交：

• 管理員可以在資料庫上執行對 ERROR_RETRY 的 ERRORED 要求更新。
• 您甚至可以新增每日或任何所需頻率的「重新提交」整合流程，並將所有錯誤記錄更新為 ERROR_RETRY 。
• 「非同步處理器」整合的錯誤處理程式可以直接將狀態設為 ERROR_RETRY ，讓每個失敗都會自動在下一個排程中重新送出。

有效負載更正 (Payload Correction)

將帳戶建立有效負載儲存在停車場表中，讓我們能夠在重新提交之前更正資料錯誤的有效負載。更新有效負載並將狀態資料欄設為 ERROR_RETRY ，以重新提交含已更正有效負載的要求。