BizTalk Server的基本机制（二） 上下文属性（Context Property）

嗯，今天说的是上下文属性（Context Property）
今天用问答方式吧…

上下文属性是个啥？从哪来上哪去？
上一篇讲了BizTalk Server的基本机制，发布与订阅。服务的提供者，将服务的消息结构发布于消息数据库，服务的消费者，订阅这些消息结构。当消息数据库收到消息后，会自动把消息发送到指定的服务消费者。

服务的消费者在订阅的过程中，必须提供订阅条件，才能实现订阅。举个简单的例子。

一个服务负责处理报销单，服务的提供者注册了被处理报销单的格式。业务逻辑中定义保险单大于5000元的时候采用一种处理方式，小于5000元的时候使用另一种处理方式。那么订阅的时候，即应该定义两种消息的消费者，一种是5000元以下的处理流程，另一种是5000元以上的。两种消息的消费者都订阅这个消息，不同的是，两个订阅制定了不同的订阅条件，一个是订阅5000以上，一个是订阅5000元以下。

这是订阅条件的一个例子。那么上下文属性是啥，上下文属性，就是可以被用来作为订阅条件的属性。
上下文属性又分为两种，一种是提升的上下文属性“promoted property”，另一种是未提升的上下文属性“not promoted property”。提升的上下文属性，可以被用作路由条件，也就是订阅条件，未提升的上下文属性，不能用于订阅。

比如上面的例子中，我们首先需要把“报销金额”指定为提升的上下文属性之后，两个订阅者才能指定“报销金额”为各自的订阅条件。

每个消息都有上下文属性吗？
是的。如果没有上下文属性的话，那么这个消息无法被任何消费者订阅。因为所有订阅条件都是基于上下文属性的。
假设有一个消息，没有任何提升的上下文属性，那么我们可以肯定，这个消息无法路由给任何消息消费者，因为这个消息无法满足任何订阅条件。因为订阅条件只能对提升的上下文属性生效。

所有可以用作订阅条件的属性都必须是提升的上下文属性“promoted property”吗？
是的，我们前面有过截图，能看到用户定义的订阅条件。订阅条件中，所有用来判断的条件，都要从上下文属性中读取。如果一个消息不具备订阅条件中指定的某个属性，那么该消息就会被判定为不符合订阅条件。

所有指定的订阅条件，都会出现在每一个消息的提升上下文属性中吗？
不是，每个消息所拥有的上下文属性，提升的上下文属性都不一样。这由接受处理消息的管道“Pipeline”决定的。使用了不同的管道“Pipeline”处理后的消息，会拥有不同的上下文属性。消息如果不具备订阅条件要求的属性，或者订阅条件要求的上下文属性并不是提升的上下文属性“promoted property”，则被判定为该消息不符合订阅条件。

我觉得单纯从上下文属性的角度，这个概念还是不难理解的。

下面我们来看看，在BizTalk Server系统的哪里可以看到上下文属性。
我们上面说了，每一个消息都会带有上下文属性。

那么我们就模拟两个消息，这两个消息分别通过BizTalk Server默认的两个不同的管道接收进来的，这两个消息将拥有不同的上下文属性。

我们先来看第一个使用了XMLReceive管道处理过的消息。
我们打开BizTalk Server管理控制台，->选择组->新建查询，查询条件选择为“Message”消息。查询后，我们选择我们想看的消息。（我写的测试消息，通过XMLReceive管道处理过的消息）。


选择这个消息之后双击，可以看到消息的详细信息。
 

从左边选项卡选择“Context”上下文。就可以看到上下文属性了。

我们可以很清楚的看到，每个上下文属性的名字，和值。以及这个上下文属性是否进行了提升（Promoted，Not Promoted）。

好的，我们再来看一下使用PassThruReceive管道接受的消息，  此消息的内容与上一个消息完全相同。
我们采用相同的操作：


双击消息条目，查看消息信息。


选择“Context”选项卡。查看上下文属性。


我们对比使用了不同的两个管道接收到的消息的上下文属性，可以看到明显的不同。

好的，关于上下文属性，我们今天就讲到这里。

我们的基本概念已经足够我们写一个“Hello world”了。

下一篇，我将为大家带来一个最基本的BizTalk 程序，并为大家演示，如何使用提升上下文属性，实现基于消息的订阅条件实现的消息路由。

 

欢迎大家讨论。完全原创，转帖请务必注明出处。