工作原理

项目
07/21/2023

示例应用程序生成一组 SOAP 标头，其中包含从 Scatter-Gather 行程文件加载的行程，从磁盘加载指定的消息文件，将路线标头追加到消息，并通过 on-ramp 将其提交到 ESB 进行处理。如果行程生成响应，应用程序将收集此响应并将其显示在应用程序窗口中。

为了帮助你了解行程服务如何在消息中使用行程信息，以下列表显示了名为 ScatterGatherItinerary.xml 的示例行程配置文件。此行程的第一部分指定两个服务调用步骤。

<Itinerary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" uuid="" beginTime=""   
    completeTime="" state="Pending" isRequestResponse="false"   
    xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">  
  <ServiceInstance uuid="" name="ScatterGather" type="Orchestration"  
                   state="Pending" position="0"   
                   isRequestResponse="false" xmlns="" />  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="ScatterGather"  
             type="Orchestration" state="Pending" isRequestResponse="false"  
             position="0" serviceInstanceId="" />  
  </Services>  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="DynamicTest"  
             type="Messaging" state="Pending" isRequestResponse="false"  
             position="1" serviceInstanceId="" />  
  </Services>  
</Itinerary>  
...

遵循行程中服务调用步骤列表的部分包含解析程序的详细信息和连接字符串，这些解析程序和连接字符串允许行程服务查找在行程中定义的每项服务，如以下 XML 所示。

<ResolverGroups xmlns="">  
 <Resolvers serviceId="ScatterGather0"><![CDATA[BRE:\\policy=ResolveEndPointScatterGather;version=;useMsg=;]]><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:purchaseordersubmitorderservicebinding;credentialType=Ntlm]]></Resolvers>  
<Resolvers serviceId="DynamicTest1"><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:orderfileservicebinding;credentialType=Ntlm]]>  
</Resolvers>  
  </ResolverGroups>

在此示例中，应用程序执行 SubmitPOService Web 服务两次，因为两个解析程序连接字符串都解析为此服务的位置 (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). 消息上下文将 Broker 业务流程指定为要激活的第一个路线服务，在示例中定义如下。

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "ScatterGather")  
     && (Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState ==   
    "Pending") && (Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType   
    == "Orchestration")

Broker 业务流程分析其行程步骤的设置，并检索与行程步骤关联的解析程序集合。对于其中每个解析程序，业务流程使用 Microsoft BizTalk ESB 工具包解析程序和适配器框架来解析服务终结点。然后，Broker 业务流程异步激活 n 个 ServiceDispatcher 业务流程， (其中 n 是行程中与 ScatterGather 服务关联的解析程序数，) 使用以下参数调度请求消息：

TransportLocation。解析程序填充此参数。
TransportType。解析程序填充此参数。
ResolverDictionary。此参数包含由具体解析程序实例填充的解析程序事实的集合。
InboundMessage。此参数包含包含行程的原始消息。
ServiceResponsePort。此参数是将接收来自 ServiceDispatcher 业务流程实例的响应的自相关响应端口的名称。

ServiceDispatcher 业务流程的每个实例都使用 ResolveMapScatterGather 策略根据 TransportType 和 TransportLocation 属性解析请求和响应消息的 Microsoft BizTalk 映射类型。业务流程实例使用解析的映射将入站消息转换为 Web 服务调用的请求消息。

ESB 适配器管理器在请求消息上设置出站传输上下文属性，BizTalk 随后会将该属性转发到名为 ServiceRequestPort 的 solicit-response 端口。

从服务接收响应消息时，ServiceDispatcher 业务流程使用解析的映射信息将入站响应消息转换为规范格式。然后，它将修改后的响应包装在 ServiceResponse 信封中，并通过自相关端口将其转发到 Broker 业务流程。 Broker 业务流程使用 GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline 聚合所有传入响应并准备最终响应消息，如以下代码所示。

AggregatedResponse.Body = null;  
AggregatedResponse(*) = InboundMessage(*);  
Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteSendPipeline(  
    typeof(GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline),  
    messageAggregator,AggregatedResponse);

此代码将整批响应包装在预定义的信封中。然后，Broker 业务流程将行程推进到 DynamicTest 行程步骤，如以下代码所示。

// Copy the context and advance the itinerary.  
OutboundMessage = AggregatedResponse.Body;  
OutboundMessage(*) = AggregatedResponse(*);  
// Advance the Itinerary to the next step.  
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep);

由于名为 DynamicTest 的服务类型属性设置为 Messaging， 因此，ItineraryHelper 类会将解析程序属性提升到名为 OutboundMessage 的消息的上下文中。代理业务流程将此消息发送到 BizTalk 直接绑定端口。然后，BizTalk 将消息转发到 由 ServiceName 订阅表示的动态发送端口，即 DynamicTest。此发送端口将最终聚合响应序列化到 \Source\Samples\DynamicResolution\Test\Filedrop\Out 文件夹。

通过

工作原理

反馈

其他资源