The BizTalk Rules Engine Call Rules shape enables you to invoke a rules policy created using the Business Rules Composer. As part of rules invocation, you can pass BizTalk messages and variables as parameters to your rules policy.
在Biztalk Server 2004中，要求规则引擎要在一个作用于（atomic scope)中调用。这个会导致一个Persistence Point，进而带来性能的开销。但是在Biztalk Server 2006中，已经去掉了这个限制。
一个消息在一个规则引擎中执行后，会设置一些数据到这个消息上，这个不是打破消息不变的规则，而是导致了一个新消息的创建。注意，新消息的创建中，可能导致消息上下文的丢失，所以在创建新消息的时候，确保新消息拥有源消息的上下文。
在和一个客户的交流中，了解到客户有这样的需求，他们在进行科研成果申报的系统中，因申报的成果内容比较多，在线申报的时候，经常会出现Session过期的问题，这样原来已经填报的信息就丢失了，就得重来，而且在网页中申报用户体验也不是很好。
这是一个很适合的OBA应用的场景。我给客户出的方案是利用Word 2007做数据填报，在Word 2007中定制表单的模版，在Word 2007中填写好数据后，对数据进行合法性检验，然后将数据填报到系统中。这个方案要解决如下几个关键问题：
- 实现类似网页一样的数据联动，比如选择了省份后，省后面对应的市县列表也要随之发生改变；
- 锁定表单内容，填写者不能编辑表单的样式；
- 填写数据的验证；
- 数据的提交。
接下来的几章里面，我就采用OBA（Office Business Application）中的相关技术来实现客户的相关需求。
业务场景
假设有这样一个业务场景，某机构需要进行成果申报，需要在表单中填写：姓名，出生年月日，机关（省份/县市），业绩这样几个字段。填写完毕后，点击提交按钮，将数据提交到数据库中，在提交前要对数据进行数据合法性检验。
在Biztalk solution中，你经常会碰到需要访问Biztalk Message中的某部分数据，一个建议是，你不必要把整个消息都加载到内存中来处理消息的指定部分数据，这样操作起来也比较复杂（需要采用XPath来访问这些数据），特别是对大的消息体来说更是如此。属性的提升就是一个解决之道，他可以让你更方便的访问消息的某部分数据。
属性的提升也会带来一些性能的开销，因此，在解决方案中，不必要提升的属性就不要提升。Distinguished Promotions带来的系统性能开销要小于属性的提升（Property Promotions）。
Distinguished Promotions（显式提升）
Distinguished Promotions只是简单的XPath语句定义。一个显示提升可以是XML Schema中的任意元素的数据，最重要的是，它必需在Schema中只存在一次（唯一的），也就是说，重复的元素是不被支持的。显式提升只能在Orchestration范围内使用，也就是说，它只能被Orchestration开发者使用，而不能被Biztalk Runtime所使用，因为这种提升只是在Orchestration中是可见的，并且带来较少的性能开销，因此，除非你需要使用这些数据的相关性，或者用它来路由消息，或者在Adapter或者Pipeline中，否则，你应该使用显式升级。
Property Promotions（属性提升）
属性升级和显式升级的主要区别是，属性升级可以在消息结构层和Orchestration中都可见。属性的提升是将提升后的属性存储到消息的上下文中。属性提升限制在255个字符内。
属性提升的一个典型的应用是在基于消息内容路由的场景。比如，有两个Orchestration订阅了Order消息，一个是大客户流程，一个是普通客户处理流程，可以通过提升Order消息的Customer Type元素，在Receive Shape中设置过滤，这样普通客户的消息就会到普通客户的流程，而大客户就可以到大客户的流程。
另外一个场景是在发送端口中，可以设置过滤，根据消息内容的不同发送到不同的端口。