BizTalk Server 能够从编排中同步调用管道。 这使业务流程能够利用管道中封装的消息处理(发送或接收)针对数据主体,而无需通过消息基础结构发送这些数据。
可以使用此功能使业务流程能够调用发送管道,以便将多个消息聚合到单个传出交换中。 相反,编排可以调用接收管道来解码和拆分从消息基础结构外部获取的交换,而无需产生通过消息框的处理成本。
详细信息
业务流程使用 XLANGPipelineManager 类中的方法(在 Microsoft.XLANGs.Pipeline 命名空间中)调用发送或接收管道。 接收管道处理单个消息或一个交换集合,并生成零个或多个消息,就像管道在 BizTalk 消息传送中执行接收消息的过程中一样。 发送管道使用一个或多个消息,并再次生成单个消息或交换,就像管道在 BizTalk 消息传送中发送消息的上下文中一样。
调用接收管道
为了在业务流程中调用接收管道,应用程序会调用 XLANGPipelineManager 类的方法 ExecuteReceivePipeline()。 此方法使用单个交换并返回零个或多个消息的集合(包含在 ReceivePipelineOutputMessages 类的实例中)。 此方法的语法在 XLANGPipelineManager 类的 .NET 类库参考中详细介绍。
在编排中执行接收管道的 API 是:
// Execute receive pipeline
static public ReceivePipelineOutputMessages ExecuteReceivePipeline(System.Type receivePipelineType, XLANGMessage msg);
对接收管道的调用通常在业务流程中的 表达式 形状中完成。
若要从业务流程内部调用接收管道,开发人员必须在业务流程项目中引用管道程序集。 下面是调用接收管道的业务流程的示例:
有关更详细的示例,请参阅 SDK 示例撰写消息处理器(BizTalk Server 示例)。
注释
ReceivePipelineOutputMessages 类型的变量只能在业务流程中的原子范围内声明。 这是因为此类型的变量不可序列化,因此不会在业务流程的持久性中幸存下来,并且业务流程在原子范围内执行时永远不会持久保存。 这意味着接收管道只能在原子范围内执行。
注释
从业务流程中调用 PassThruReceive 管道或自定义管道组件时,无论传入消息是否为 XML 类型,您必须将传入消息的变量类型声明为 System.Xml.XmlDocument。 因此,如果在传入消息是非 XML 消息(如平面文件格式消息)的情况下尝试对它进行作,则可能会遇到异常。 这是因为编排引擎打算在上述方案中对任何类型的传入消息使用 System.Xml.XmlDocument。
调用发送管道
若要从业务流程中调用发送管道,应用程序调用 XLANGPipelineManager 类的 ExecuteSendPipeline() 方法。 此方法使用一个或多个消息的集合(包含在 SendPipelineInputMessages 类的实例中),并返回单个交换。 此方法的语法在 XLANGPipelineManager 类的 .NET 类库参考中详细介绍。 由于执行发送管道会产生新的交换,因此必须在消息分配形状中调用 ExecuteSendPipeline() 方法,例如:
从编排中执行发送管道的 API 为:
// Execute a send pipeline
static public ExecuteSendPipeline(System.Type sendPipelineType, SendPipelineInputMessages inputMsgs, XLANGMessage msg);
对发送管道的调用必须在编排中的 消息分配 组件中完成。
若要从编排中调用发送管道,开发人员必须在编排项目中引用管道程序集。 调用发送管道的编排示例:
注释
调用默认的 XMLTransmit 管道时,必须将消息上下文属性 XMLNORM.EnvelopeSpecName 设置为信封模式的完全限定名称。 例如:
MyMessage(XMLNORM.EnvelopeSpecName) = "PipelineSchemas.POEnv, PipelineSchemas, Version=1.0.0.0, Culture=nuetral, PublicKeyToken=12e5cc95621c33e8";
有关更详细的示例,请参阅 SDK 示例聚合器(BizTalk Server 示例)。
管道执行 - 行为差异
当业务流程编排调用时,发送或接收管道的执行与在消息传送基础结构中执行相同管道(即在接收位置或发送端口)时基本相同。 但是,下面指出了某些行为差异。
管道阶段内的差异
从业务流程中调用的发送或接收管道的阶段执行,与从 BizTalk 消息传输基础结构调用这些管道时的阶段执行几乎相同,以下列阶段中所指出的例外情况为准。
汇编程序/反汇编程序:汇编程序和反汇编程序阶段不会处理 跟踪配置文件 数据。
编码器/解码器:MIME 编码器使用在主机关联的主机上配置的证书对消息进行数字签名。 SMIME 编码器使用传递到管道的消息上下文中的证书加密消息。
模式解析
在从编排中执行管道时,支持两种模式查找算法。
按类型解析
按名称解析
在部署重复架构的情况下,用于选择适当架构的算法逻辑与在消息传送基础结构上下文中执行时使用的架构相同。
事务管道
调用事务组件的管道阶段将没有事务上下文可用。 对 IPipelineContext.GetTransaction() 的任何调用都将引发 NotSupportedException。 这并不排除从业务流程执行此类管道,但这意味着管道必须检测和处理这种情况。
消息目标
在此上下文中不支持通过管道组件控制消息目标。 设置上下文属性 MessageDestination 或 SuspendOnRoutingFailure 将导致抛出 XLANGPipelineManagerException。
管道组件类型
管道组件必须基于以下内容才能从业务流程中调用:
.NET Framework v1.1
.NET Framework v2.0
.NET Framework v3.0
.NET Framework v3.5
.NET Framework v4.0
.NET Framework v2.0
COM
限制
无法从编排流程中执行以下类型的管道:
事务管道
可恢复管道
调用 BAM 侦听器 API 的管道(将引发 NotSupportedException )。
同一个管道实例不能在并行结构的不同分支中执行,除非它位于每个分支的同步范围内。
基于 BizTalk Server 2006 SDK 生成的现有管道(程序集)。
故障模式和效果
如果在 BizTalk Server 消息基础结构中调用此管道时发生执行失败,原本会导致消息挂起,但现在将会抛出异常。 引发的异常的类型 为 Microsoft.XLANGs.Pipeline.XLANGPipelineManagerException。 此引发的异常可以在调用业务流程中的 catch 块中进行处理。 如果业务流程未捕获引发的异常,XLANG 引擎会报告错误,其中文本包括引发的异常中的异常信息。
异常执行管道组件生成的错误消息的格式设置。
XLANGPipelineManagerException 类的 Message 属性包含管道执行错误的详细信息。 此详细信息采用以下格式:
执行管道<类型>失败。 错误详细信息 <格式化的错误消息>。
在此消息中, <管道类型> 是管道类的名称, <格式化的错误消息> 是管道执行期间发生的特定故障的说明。
例如,如果一个编排调用了接收管道,并且因管道的所有组件都未能识别消息而导致执行失败,那么 XLANGPipelineManagerException的属性值将是:
XLANGPipelineManagerException 属性 | 价值 |
---|---|
消息 | 执行接收管道“MyPipelines.ReceivePipeline”失败。 错误详细信息:“没有反汇编阶段组件可以识别数据。 |
组件 | 字符串.空 |
例如,如果业务流程调用发送管道,并且该管道的执行因验证失败而失败,则 XLANGPipelineManagerException 的 Message 属性中的文本将为:
XLANGPipelineManagerException 属性 | 价值 |
---|---|
消息 | 执行发送管道“MyPipelines.SendPipeline”失败。 错误详细信息:“未能验证文档:” <元素名称> 元素无效 - 值 <元素值> 根据其数据类型“String”无效 - 模式约束失败。 |
组件 | “Microsoft.BizTalk.Component.XmlValidator” |