研究partner determination的邏輯能否抽出來，以API的形式被我們Odata service implementation code里調(diào)用？

研究partner determination的邏輯能否抽出來，以API的行駛被我們Odata service implementation code里調(diào)用？

Yes. 我在AG3寫了一個小的report ZPARTNER_DETERMINE_VIA_CODE，partner determination的核心是function module CRM_PARTNER_DETERMINATION_OW，關(guān)于如何使用這個FM，runtime時需要傳遞哪些參數(shù)，請參考該report的代碼。
最后determination的output是一個internal table，里面包含了每個determine出來的BP id即partner function。在我的這個例子里，determine出來的是employee responsible，如下圖：

將Partner determination的邏輯抽出來之后，研究能否在CRM_ORDER_MAINTAIN里suppress住里面內(nèi)嵌的partner determination call？

Technically speaking，我們的需求是在callstack 28的CRM_ORDER_MAINTAIN的整個sub callstack里，不應(yīng)該出現(xiàn)partner determination API的調(diào)用。
但是現(xiàn)在callstack 36出現(xiàn)了，從代碼發(fā)現(xiàn)callstack 35 ， line 374靜態(tài)地調(diào)用了這個FM，并沒有一個開關(guān)，形如下面的語句來選擇性地進(jìn)行調(diào)用：

IF iv_partner_determination_active = ‘X’.
CALL FUNCTION ‘CRM_PARTNER_DETERMINATION_OW’
ENDIF.

所以我需要做的research就是，看是否有方法讓CRM_ORDER_MAINTAIN里的這個determination call執(zhí)行但不生效。我已經(jīng)有了一些idea，需要寫個POC驗證。

CRM_ORDER_MAINTAIN里的partner determination也可以disable，方法如下：

如下面郵件第二個截圖，我們雖然沒法阻止CRM_PARTNER_DETERMINATION_OW 這個FM本身被調(diào)用，但我們可以做到讓這個FM被call到了之后，不做任何事情，直接return，從而也就達(dá)到了disable determination的目的。

我們只需在call order maintain時傳個switch參數(shù)進(jìn)去：（Ａ代表不執(zhí)行partner determination, 我試過傳B不行，傳B的話，partner determination會在CRM_ORDER_MAINTAIN subcallstack的另一處執(zhí)行）

這樣determination API被call到的時候，里面會去檢查這個flag，如果為A，則EXIT，這樣真正的determination step不會執(zhí)行。

Last step：寫一個report，將partner_determ置為inactive，然后用CRM_ORDER_MAINTAIN創(chuàng)建一個order，
hard code一個BP進(jìn)去，如果最后call CRM_ORDER_SAVE之后order仍然能夠看到這個BP，說明這條路沒問題。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的研究partner determination的逻辑能否抽出来，以API的形式被我们Odata service implementation code里调用？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。