CRM客户主数据UI上有哪些字段可以触发partner determination
CRM客户主数据UI上有哪些字段可以触发partner determination
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。
