# Sent: Monday, June 8, 2015 2:44 PM
Subject: Jerry's research on "Find out all fields which can be used to trigger the BP determination" - part one
我將我研究這個task的思路一步步寫下來，僅供大家參考。
我先把這封郵件最後得出的結論列出來。
圖二： WebUI裡會trigger partner determination的14種可能的情況
首先要弄清楚 partner determination API和1order framework的交互原理
當在WebUI上點creation button，在popup window裡選擇某個transaction type時，會trigger determination API, 原因是因為這個subroutine：
這個EC – event callback是怎樣註冊的？tcode CRMV_EVENT: 進入之後，維護如下search attribute：30是從debug裡找到的。 30 = End of header processing
得到如下結果：
圖一： Partner determination 入口function module在SPRO裡的註冊位置
再結合callstack，得出第一個重要結論：
在1order 標準代碼裡，SAP predeliver了一些time slot，在1order處理完某個動作後到達這些timeslot，然後1order會call 上圖line 14的function module，去customizing裡取針對這些timeslot註冊的event callback，例如圖一： Partner determination 入口function module在SPRO裡的註冊位置 裡的partner determination API。
大家可以把這套東西和event subscribe & raise做類比：event raise是1order完成的，event subscribe和通常的事件處理不一樣，這裡是採用SPRO裡做配置的方式實現的。
從drop down 裡也能看到所有SAP 支持的execution time:
所以我們原始的任務（找到所有能夠trigger partner determination的fields），也就轉換為“在什麼情況下能trigger 入口函數CRM_PARTNER_DETERM_INITIAL_EC”
通過ST05找到tcode CRMV_EVENT後臺的對應table。根據入口函數名稱做filter，得出以下14條記錄。
圖二： WebUI裡會trigger partner determination的14種可能的情況
根據這14條記錄，我總結出所有能夠觸發partern determination 的情況： 小括號後是對應table entry的行號
在WebUI 使用copy with reference button創建opp ( 1 & 2 )
Existing opp的item level的PARTNER object發生變化 ( 4 )
Existing opp的item level的PARTNER object 第一次創建(5)
…
到這一步後，又產生了2個新的open question:
表裡的object，比如PARTNER,和WebUI上的fields對應關係是怎樣？
Event Column裡TRIGGER_FUNCTION到底是什麼含義？
只要解決了這兩個open questions，再把圖二的14種情況對應的field列出來，就是這個task research最終的output.
Part two: 任務是搞清楚exe_time – 30 ( end of header processing ) 裡對應的PARTNER object到底對應WebUI 哪些fields。
首先說個和這個task無關的，1order裡的object本身也是在tcode CRMC_OBJECTS裡配的：
至於每個object到底對應WebUI上哪些fields，這個mapping 關係沒有任何table來維護，而是在代碼裡體現的。
我的思路還是debug：在callstack裡觀察到CRM_EVENT_PUBLISH_OW raise出的event所對應的name是PARTNER，
這樣就和前一封郵件partner one的finding銜接起來了：正是這個event publish動作會導致SPRO裡註冊的partner determination API被調用。
從line 436能找到在什麼時候會publish partner的這個event：
如果CRM_ORDER_MAINTAIN裡的it_partner不為空：
這種情況如果不看代碼很難發現：
什麼時候CRM_ORDER_MAINTAIN被調用時，it_partner不為空？
觀察BOL layer裡哪些bol entity包含了partner change：
至此，我們可以得出結論，只要Opportunity WebUI上BTPartner這個bol node下面model的fields發生變化，則會trigger partner determination。
剩下的步驟就簡單了。
打開Opportunity的UI，找到綁到BOL node “BTPartnerSet”和”BTPartner”的context node，
然後再到configuration page裡找哪些field是綁到了這些context node上 – 這些field 發生change即trigger partner determination。
Part three 需要解決的三個遺留問題：
14個result裡的 event = PROCESS_PARTNER_DETERMINATION是什麼含義？
答案：看這個FM裡什麼情況下lv_proceed_partner會置為true就知道了。
Event = trigger_function, attr1 = partner_determ是什麼含義？
答案：external consumer raise event explicitly:
Line 429的註釋什麼意思？
TO BE confirmed by Ross whether IBASE integration should be considered.
From: Wang, Jerry
Sent: Monday, June 8, 2015 3:29 PM
To: DL AI DEV CRM CN FIORI (External)
Subject: RE: Jerry's research on JIRA task "Find out all fields which can be used to trigger the BP determination" - part two
Part two: 任務是搞清楚exe_time – 30 ( end of header processing ) 裡對應的PARTNER object到底對應WebUI 哪些fields。
首先說個和這個task無關的，1order裡的object本身也是在tcode CRMC_OBJECTS裡配的：
至於每個object到底對應WebUI上哪些fields，這個mapping 關係沒有任何table來維護，而是在代碼裡體現的。
我的思路還是debug：在callstack裡觀察到CRM_EVENT_PUBLISH_OW raise出的event所對應的name是PARTNER，
這樣就和前一封郵件partner one的finding銜接起來了：正是這個event publish動作會導致SPRO裡註冊的partner determination API被調用。
從line 436能找到在什麼時候會publish partner的這個event：
如果CRM_ORDER_MAINTAIN裡的it_partner不為空：
這種情況如果不看代碼很難發現：
什麼時候CRM_ORDER_MAINTAIN被調用時，it_partner不為空？
觀察BOL layer裡哪些bol entity包含了partner change：
至此，我們可以得出結論，只要Opportunity WebUI上BTPartner這個bol node下面model的fields發生變化，則會trigger partner determination。
剩下的步驟就簡單了。
打開Opportunity的UI，找到綁到BOL node “BTPartnerSet”和”BTPartner”的context node，
然後再到configuration page裡找哪些field是綁到了這些context node上 – 這些field 發生change即能夠trigger partner determination。
閱讀更多 汪子熙的游泳故事 的文章
