遞延要求佇列

在一些使用案例中，會將實體的狀態設成先等待後續任務以非同步方式執行，然後才能在其生命週期中繼續進行。實作這類任務時，是使用外掛至實體業務物件狀態定義的監視規則搭配批次控制來實作。當記錄進入該狀態時，系統不會立即處理這些監視規則，而是會遞延至相關批次接下來執行時才處理。

當應儘快處理遞延任務時，可以將訊息新增至「遞延要求佇列」，以接近即時的方式執行該任務。此機制提供受管理的訊息佇列，每則訊息皆代表一個執行指定實體之遞延監視規則的要求，與批次處理這些規則的方式類似。
備註：此機制僅適用於雲端安裝。
注意：此功能應該只用來支援具有需要接近即時處理之時間相依事件的業務流程。所有其他非同步流程應保持遞延至批次處理。

下列各節描述接近即時處理機制的概念與功能。

要求接近即時的處理

當實體進入與時間相依遞延監視規則相關的狀態時，可以要求在確認目前交易後儘快處理這些規則。

本產品支援下列選項，可要求對實體進行接近即時的監視：

  • 若要在實體達到特定狀態時一律傳送實體進行接近即時的處理，請將「新增遞延要求」(F1-DFREQADDN)「允入」演算法新增至個別的業務物件狀態定義。如需詳細資訊，請參考演算法詳細描述。

  • 您可以在基於 Groovy 的演算法中使用 DeferredRequestAPI 函式，以實作有關何時及如何將這類要求新增至佇列的自訂規則。

  • 一般資料同步功能 (如果適用) 也支援使用了「遞延要求」佇列之接近即時處理的選項。

例外處理

當即時佇列代理程式順利處理遞延要求時，相關實體會依據其業務物件規則進行更新。不過，如果該要求在重試數次後仍持續失敗，佇列代理程式就會捨棄該要求，而相關實體則會保持其目前狀態，等待被對應的遞延監視批次拾取。屆時，如果錯誤仍然存在，批次就會如常回報問題。
警告：請勿將遞延批次控制從業務物件狀態定義中移除。基於資料完整性考量，這些流程必須依照設計維持遞延至批次。

傳送要以接近即時方式處理的實體 (如果適用) 可以降低相對應監視批次的排程頻率，因為已不再需要滿足接近即時的頻率需求。由於大多數記錄都已由接近即時機制順利處理，因此監視批次主要用來處理例外。

相關要求

佇列中的訊息預設並無特定處理順序。如果有多個訊息更新相同的資源，則可能需要依序處理這些訊息，以避免發生並行錯誤。

將訊息新增至佇列時，訊息可以選擇性地參考其更新的主要實體，以便使其與更新相同實體的其他訊息相互關聯。系統會依序處理明確參考相同主要實體的訊息。

套用輪詢遞延

當實體的目前狀態與等待滿足特定條件以決定實體下一個轉變狀態的監視規則相關聯時，僅執行一次這些監視規則是不夠的。該條件可能在一開始並未滿足，但可以在短期間內滿足。在此情況下，置於佇列中的遞延要求可以指示需要輪詢遞延。

要求輪詢遞延時，會以下列方式處理佇列中的遞延要求訊息：

  • 將訊息新增至佇列時，會註記相關實體的目前狀態。
  • 在順利處理訊息之後，如果相關實體的狀態保持不變，佇列代理程式就會完成目前的訊息，並在短暫的時間延遲後將另一個訊息新增至佇列，亦即，將實體設定為稍後再次處理。
  • 此處理會在有限的嘗試次數內重複自我執行。隨著每次嘗試，延遲秒數也會增加。
  • 如果在所有嘗試後，相關實體的狀態保持不變，則會毫無例外地捨棄訊息。相關實體會如常被下一個排定的批次執行監視。