設計新要求

下列各區段重點說明設定新「要求」的重要考量。

定義要求處理明細

定義新的要求物件時，您必須先決定要擷取哪些資訊才能執行要求。某些靜態明細，例如用於通知的待辦事項類型，可以在要求類型業務物件上設定。其他明細，例如受影響的記錄明細，可能需要記錄在要求記錄中。這些元素是使用標準 UI 提示語法，在要求的業務物件資料區域中定義。

此外，視使用案例的複雜性而定，處理要求可能會有幾個步驟。要求在處理之前，可能需要經過核准或複查。這些步驟是使用要求業務物件生命週期來建立模型。

系統提供資料更正要求的「根」業務物件 (F1-DataCorrectionRoot)，可用作多步驟處理的範例。您的特定產品可以提供其他要求業務物件。

使用者通常希望在提交進行處理前，預覽要求的結果範例。系統提供下列支援預覽功能。

要求預覽服務指令檔的特殊業務物件選項。此指令檔會擷取使用者要求預覽要求時顯示的資訊。
F1-DataCorrectionReqActions 對應片段。此對應片段包含使用指令檔 F1ReqPrvwAct 的預覽動作支援。此指令檔會叫用在要求業務物件上設定的要求預覽指令檔，使用預覽指令檔結構來產生 UI 並顯示結果。對應也支援根據要求業務物件中設定的標誌，來隱藏編輯和預覽動作。

假設允入演算法會負責處理要求。要求通常會在背景中而非即時進行處理。標準技術是使用遞延監視將要求轉變為已外掛演算法的狀態。F1-OrphanRecordDeletion 業務物件使用了此技術。

部分使用者可能未獲提交特定要求的授權。新增要求時，可用要求類型的列表會限制為使用者能安全存取相關要求業務物件之應用服務的類型。這可能會影響應用服務的選擇，以及新要求業務物件所需的其他組態。