biztalk中使用信封(Envelope)消息

一.   信封(envelope)的作用

一般的传送消息就传送一个单个的消息，这个消息架构由一个消息schema定义。但是有时候可能需要同时传送多个消息到同一个接收点，如果一个个的传送就显得效率比较低，biztalk支持信封消息功能。所谓信封消息是将多个消息打包成一个交换（interchange），就是用信封（envelope）将多个消息封装起来，形成一个貌似单个xml消息的功能。

Biztalk收到信封消息，将信封拆开，分别取出其中的消息正文，然后单独的处理每个消息正文。

信封消息还可以在信封部分定义升级属性，信封部分的升级属性可以被带入到所有的消息正文的上下文中。

二.   信封(envelope)的设置

要使用信封，首先要定义信封的架构schema，并指示哪些部分是属于信封部分，哪些部分是要被装入的消息正文的位置。

定义信封架构形式上跟定义一般的schema没什么区别，只是需要设定一些特殊的属性。

要把一个schema设置为信封架构，可以在这个schema的<schema>标签的“Envelope”属性设为“Yes”，表示这个架构是个信封架构。

<schema>标签下可以包含多个根元素，表示可以有多个信封的架构，但是使用时只能使用其中一种信封架构。一般就定义一个根元素。

根元素有个“Boby Xpath”属性，用来指示这个信封架构中的哪个位置是消息正文的位置。

看下面这个信封架构，根元素Envelope的“Boby Xpath”属性设置为“Envelope/Boby”，表示消息正文在Boby元素里面的位置，除此之外，别的部分都属于信封部分。

  “Boby Xpath”属性指定的那个元素里面就是消息正文所在的位置，这个元素其下只能包含一个<any>元素（不能包含其他任何元素），这是个特殊的元素，含义就是消息正文的占位符，可以被任意的或者<any>元素的属性所限定的消息正文所替换。

<any>元素相关属性说明：

1.        Process Contents

此属性指示消息正文验证的级别，有四个可能的的值：

Lax ――宽松的验证级别，这种设置，只有在收到的消息正文对应的schema在信封schema中已经被import的情况下才会验证此消息正文，否则不验证。

Skip ――不验证收到的任何消息正文。

Strict ――严格的验证级别，这种设置，所有可能收到的消息正文对应的schema都必须在信封schema中预先导入，对每个消息都要进行验证。

Default ――缺省设置等同于“Strict”

如果<any>元素的Process Contents设置为“Strict”或者“Default”（缺省设置为Strict），按文档的描述，在消息实例进入管道后，XML拆装器会寻找每个跟对应<any>位置的元素的名称空间相对应的schema验证这个元素，如果在信封schema中不到相应的schema被import，则这个元素会验证失败。但是实际测试中发现<any>元素Process Contents的“Strict”设置并没有起作用，在信封schema中没有import输入的消息实例名称空间对应的schema，消息依然传送成功。原因不明。

2.        Namespace

表示可以接受的消息正文的名称空间，如果指定了名称空间，则只有属于这个名称空间的消息正文可以被接受，其他的不被接受。如果不设置名称空间，表示接受任何名称空间的消息正文。

3.        Max Occurs、Min Occurs

表示消息正文可以出现的最小次数和最大次数，正文可以再次重复出现。但是这两个属性好像对<any>元素不起作用。

在实际测试中，设置<any>元素的这两个属性都为1，这个信封消息应该只能包含一条正文消息，但是测试信封消息中包含两条消息正文，依然被接受，被正常拆封，正常的把两条消息正文路由到订阅的服务。

三.   信封(envelope)的拆装

信封的拆装是在pipeline的第二阶段拆装阶段（Disassemble）。

接收位置的接收pipeline要选XmlReceive（其中包含XML Disassembler），或者自建pipeline并使用XML Disassembler，因为只有XML Disassembler 才具有拆装信封消息的功能。

看一下XML Disassembler是如何处理信封消息的，消息进入到消息管道，经过第一阶段的解码后到达拆装阶段，XML Disassembler对消息的处理步骤如下：

1.       删除信封

首先根据消息类型在已部署的schema查找，看这个消息是否能跟哪个信封架构匹配，如果匹配不到信封架构，则继续匹配一般架构。如果匹配到信封架构，则根据信封架构的定义把所有的消息正文提取出来，去掉信封。

2.       拆装消息正文和升级属性

分别处理每一个消息正文，根据每个消息正文的消息类型（名称空间#根元素名）在已部署的schema中匹配，匹配到后，给这个消息建立上下文，先把信封部分升级的属性加入到消息上下文，然后根据消息架构升级这个消息本身的属性。

每条消息都如此处理，直到都处理完毕。如果一切正常，每个消息都匹配到合适的schema，则biztalk把所有的消息正文作为独立的消息发送到MessageBox等待路由。

如果匹配消息中出现问题，比如某一条消息没有匹配到schema，那么会有两种情况出现，跟接XML收管道的设置有关。

XmlReceive管道有个RecoverableInterchangeProcessing属性（在biztalk管理器中，查看相应的接收位置的属性，在接收管道的右边有个省略号按钮，点击可以配置一些接收管道的属性，RecoverableInterchangeProcessing属性就在这里），这个属性缺省为false，这时如果消息匹配中有某一条消息出现没有匹配到schema的情况，则所有的消息正文都不被处理，整个消息被挂起。如果这个属性设置为true，则只有没有匹配到schema的那个消息正文被挂起，其他的消息正文被发送到MessageBox等到路由。