我嘗試在 BOL Browser 裡使用 query 來執行搜尋，並且希望僅返回屬於我在 INSTID 中指定的給定產品的附件例項。
令我驚訝的是，查詢結果不僅包括給定產品的附件，還返回大量屬於我建立的其他產品的附件。
透過除錯，我發現第61行的引數CATID、TYPEID和INSTID沒有傳入主搜尋功能模組，這意味著搜尋時根本不考慮它們。
相反，根據每個附件例項的屬性值“CRM_SEARCH_VISIBILITY”，搜尋結果在 post processing 中透過三個引數進行過濾：
在附件屬性 UI 中，我們可以為“在搜尋中可見”分配三種值：
即 No Restriction，in Business Objects of the same Object Type Only 和 Only in the same Business Object:
這個引數在 Document model workbench 裡被定義成 instance attribute：
根據下面程式碼中的過濾邏輯，該屬性在 CMAdvDocumentFinder 實現中的工作方式如下：
無限制：具有該屬性的附件將不會被過濾。
1 - 僅在相同物件型別的業務物件中：主機業務物件型別不等於搜尋引數 TYPEID 的附件將被過濾掉。
2- 僅在同一業務物件中：主機業務物件例項不等於搜尋引數 TYPEID 和 INSTID 指定的例項的附件將被過濾掉。
上圖程式碼裡提到了 SAP CRM 系統的 BOR 概念。
在 SAP 系統中，BOR (Business Object Repository) 型別是 ABAP 開發中的一個核心概念，尤其在 SAP CRM (Customer Relationship Management) 系統中扮演著關鍵角色。BOR 型別定義了業務物件模型，這些模型是 SAP 系統中進行業務資料處理和互動的基礎。透過使用 BOR，開發人員可以在 ABAP 程式中方便地引用和操作這些業務物件。
BOR 物件提供了一種物件導向的方式來表示和處理企業中的各種業務實體，如客戶、訂單、發票等。每個 BOR 物件都具有一系列的屬性、方法和事件，這些特性使得它們不僅可以儲存資料，還可以執行特定的業務邏輯。
BOR 型別的用途
BOR 型別的主要用途包括但不限於：
- 業務流程的建模和自動化：BOR 型別使得複雜的業務流程能夠在系統中得以建模和自動化執行。透過定義業務物件及其相互作用，企業可以在 SAP CRM 系統中實現高度定製化的業務流程管理。
- 資料封裝和抽象：透過將業務資料和操作邏輯封裝在物件中，BOR 型別提供了一種高度抽象的方式來處理業務實體。這種封裝機制簡化了資料管理和操作，提高了程式碼的可維護性和可重用性。
- 整合和擴充套件性：BOR 型別支援 SAP CRM 系統與其他系統的整合，例如與 ERP (Enterprise Resource Planning) 或 SCM (Supply Chain Management) 系統的整合。透過 BOR 物件，系統間的資料交換和業務流程整合變得更加容易和靈活。
- 工作流和自動任務處理：BOR 型別在 SAP 的工作流中扮演著重要角色。它們可以觸發工作流事件，自動化任務處理和決策流程，從而提高業務流程的效率和響應速度。
示例說明
假設我們在 SAP CRM 系統中處理客戶服務請求的場景。在這個場景中，ServiceRequest 是一個 BOR 型別，它代表了一個服務請求業務物件。該物件可能包括如下屬性：請求 ID、客戶 ID、服務型別、請求狀態等。同時，它還定義了一些方法，例如 Create（建立請求）、Update（更新請求）、Close（關閉請求）等，以及一些事件，如 RequestCreated、RequestClosed。
在處理服務請求的業務流程中，ServiceRequest 物件首先透過 Create 方法被建立。該方法可能會觸發 RequestCreated 事件，該事件可以進一步觸發一個工作流，例如通知服務團隊或分配服務任務。在服務請求的生命週期中，可以使用 Update 方法更新請求的狀態或詳情。最終，當請求被處理完成後，使用 Close 方法關閉服務請求，並可能觸發 RequestClosed 事件，該事件又可以觸發工作流進行後續處理，如傳送服務滿意度調查等。
透過這個例子，我們可以看到 BOR 型別如何在 SAP CRM 系統中為業務流程提供支援和自動化。BOR 物件 ServiceRequest 不僅封裝了服務請求的資料，還定義了處理請求所需的操作邏輯和事件驅動的工作流，極大地提高了業務流程的效率和自動化水平。