基于消息粒度转换，关联集，Sequence Convey模式进行消息合并

在一些B2B集成场景中，客户信息可能是分成Header, Detail两个文件传送的。以PO为例，两个文件的记录之间通过PONum值关联。如何把这两个独立的消息合并为对业务系统有意义的单个消息呢？

方法一：把两个文件打包为一个zip文件，以zip文件的形式接收。然后在Receive Pipeline中对zip流unzip,编程对记录分组排序。这样处理的结果是一个符合PO模式的单个消息。

方法二：基于消息粒度转换，关联集，Sequence Convey模式进行合并消息
消息粒度：对Detail文件来说，对应同一个PONum的DetaiItem可能会有多个，并且物理上可能是不连续的。按照通用的消息建模方式，DetailItem是基本的消息粒度。实际的需求中，我们希望合并的结果中，一个HeaderItem后面有若干DetailItem,它们具有相同的PONum。也就是说，POItem中需要的粒度是DetailItemsWithSamePONum。这样我们需要对Detail消息进行消息粒度转换，建立一DetailItemsWithSamePONum粒度的新消息模式。这样在管道拆分时，原始的Detail文件中，相同PONum的记录会放在一起，成为一个独立消息。

关联集：Orchestration中的重要概念。对于当前的需求，建立一个属性模式。把Header,Detail中的PoNum域提升到这个属性模式中。建立一个关联集类型，把PONum域配置为关联域。

Sequence Convey：在Orchestration Panel上，创建一个Logical Receive Port。添加两个操作，一个接收Header类型的消息，另外一个接收
DetailItemsWithSamePONum类型的消息。为什么一个Logical Receive Port会设计为可以配置若干个操作呢？在BTSAdmin上可以看出一个Logical Receive Port只能与一个物理Receive Port绑定。但是一个物理Receive Port可以有多个Receive Location，每个Location可以设计为接收不同类型的消息，刚好可以与多个操作相对应。创建一个关联集变量，属于前面的关联域类型。建立两个Receive Shape，分别接收两个操作中的Header, Detail消息。第一个Receive Shape设置为激活，初始化那个关联集变量；第二个Receive Shape跟随前面的关联集变量。由于两个Receive Shape是有前后顺序关系的，那么需要把Port的Ordered Delivery属性设置为true,默认是false。这样在Orchestration视图上的关联集中，关联集变量会把两个Receive Shape罗列在一起，表明它们接收的消息通过PONum关联。最后建立一个目标PO模式，通过一个Transform把接收到的两个消息转换为PO消息。Orchestration中的map与通用map的区别就是，前者支持多个source,即multi-part message。

这样处理的结果是：对于Header中的一个header记录会与detail文件中若干个PONum相同的Detail Item共同构成一个独立消息。如果需要把这些PONum不同的独立消息合并为一个物理消息文件。那么可以用前面的方法对结果消息再处理一次。不过，这次关联集的粒度需要再高一个级别，比如通过文件名来关联什么的。具体的实现就要看具体的需求了。