关于 CRM 中间件系统设计的一些常见问题

我们有时候会在中间件的事务码SMQ2即Inbound队列查看器里观察到以CSA开头的队列:

这些队列的作用是什么呢？在SAP community上已经有很多朋友提出了相同的问题，也有专家在下列两个连接里给予了解答:

http://scn.sap.com/thread/2056716

http://scn.sap.com/thread/2079157

简单地说，每次CRM系统里的object发生修改后，如果该object在后台配置里被设置为需要将其修改同步到其他的接收方，则会自动生成这些CSA队列，通过这些队列把修改同步到其他接收方。

在下图167行执行之前，BDOC的状态如下:

167行执行完毕之后，BDOC状态发生了变化。

所有注册了CRM BDOC HIERARCHY_PROD变化的监听者列表通过function module SMW3_FLOW_GETLIST返回。

对于BDOC HIERARCHY_PROD来说,当前我使用的系统里有三个注册的监听者:

当变化发生时，这些监听者在SMW3_FLOW_EXECUTE里的循环体内逐一执行。

更多细节请参阅文章开头提到的两个SAP community的讨论issue。

这个表存放的内容是CRM产品同名settype COM_TA_R3_ID对应的业务数据。

表里的数据从来源上分两类：

1. 直接创建自CRM系统的相关数据

2. 从ERP下载的相关数据，如设备(equipment)

第一类的例子如下图：

字段R3SER_NO存储的序列号内容。

这个序列号在WebClient UI的ERP Identification处维护：

第二类的例子:ERP系统里设备的ID存储在字段R3IDENT里：

UI上对应显示在字段Technical Asset NO上：

对应ERP里维护的设备如下：

在中间件事务码R3AC1可以为一个中间件的适配器对象维护Block size的大小。

以上图的尺寸为50为例，假设在ERP系统里有110个设备(equipment)需要下载，那么CRM中间件会自动生成3个inbound队列执行下载任务,其中2个队列各下载50个设备，另外1个队列下载剩下的10个设备。

这些下载队列的事务处理是彼此隔离的，也就是说即使某个队列的下载出了错，这个队列里待下载的ERP设备未能成功存储到CRM系统里，但是并不会影响到其他队列的处理。

我的SAP community博客Step by step to debug Product Initial Download in CRM system 介绍了在CRM端如何调试中间件的步骤，在CRM端inbound处理的function module里能清楚观察到这个block size如何起作用的：包含来自ERP的数据的internal table的行数=block size