Compartir a través de

Cómo funciona el ejemplo de dispersión y recopilación

  • Artículo

La aplicación de ejemplo crea un conjunto de encabezados SOAP que contienen el itinerario cargado desde el archivo de itinerario de Scatter-Gather, carga el archivo de mensaje especificado desde el disco, anexa los encabezados de itinerario al mensaje y los envía al ESB a través de una rampa de procesamiento. Si el itinerario genera una respuesta, la aplicación recopila esto y lo muestra en la ventana de la aplicación.

Para ayudarle a comprender cómo el servicio De itinerarios usa la información del itinerario en un mensaje, en la lista siguiente se muestra el archivo de configuración de itinerarios de ejemplo denominado ScatterGatherItinerary.xml. La primera sección de este itinerario especifica dos pasos de invocación de servicio.

<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>  
...

Siguiendo la lista de pasos de invocación del servicio en el itinerario se encuentra la sección que contiene detalles de los solucionadores y las cadenas de conexión que permiten al servicio itinerario localizar cada servicio definido en el itinerario, como se muestra en el siguiente 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>

En este ejemplo, la aplicación ejecuta el servicio web SubmitPOService dos veces porque ambas cadenas de conexión del solucionador se resuelven en la ubicación de este servicio (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). El contexto del mensaje especifica la orquestación de Broker como el primer servicio de itinerario que se va a activar, definido en el ejemplo como se indica a continuación.

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

La orquestación de Broker analiza la configuración de su paso de itinerario y recupera una colección de solucionadores asociados al paso de itinerario. Para cada uno de estos solucionadores, la orquestación usa el marco de resolución y adaptador de Microsoft BizTalk ESB Toolkit para resolver el punto de conexión de servicio. A continuación, la orquestación de Broker activa n número de orquestaciones serviceDispatcher de forma asincrónica (donde n es el número de solucionadores asociados al servicio ScatterGather en el itinerario) para enviar el mensaje de solicitud con los parámetros siguientes:

  • TransportLocation. El solucionador rellena este parámetro.

  • TransportType. El solucionador rellena este parámetro.

  • ResolverDictionary. Este parámetro contiene una colección de hechos de resolución rellenados por la instancia de resolución concreta.

  • InboundMessage. Este parámetro contiene el mensaje original que contiene el itinerario.

  • ServiceResponsePort. Este parámetro es el nombre del puerto de respuesta auto correlacionado que recibirá respuestas de las instancias de la orquestación ServiceDispatcher.

    Cada instancia de la orquestación ServiceDispatcher usa la directiva ResolveMapScatterGather para resolver los tipos de mapa de Microsoft BizTalk para el mensaje de solicitud y respuesta, en función de las propiedades TransportType y TransportLocation . Las instancias de orquestación usan las asignaciones resueltas para transformar el mensaje entrante en el mensaje de solicitud de la llamada al servicio web.

    El Administrador de adaptadores de ESB establece las propiedades del contexto de transporte saliente en el mensaje de solicitud, que BizTalk reenvía al puerto de solicitud-respuesta denominado ServiceRequestPort.

    Cuando recibe un mensaje de respuesta de un servicio, la orquestación ServiceDispatcher usa la información de mapa resuelta para transformar el mensaje de respuesta entrante a un formato canónico. A continuación, encapsula la respuesta modificada dentro del sobre ServiceResponse y la reenvía a la orquestación de Broker a través del puerto de correlación automática. La orquestación de Broker agrega todas las respuestas entrantes y prepara el mensaje de respuesta final mediante GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline, como se muestra en el código siguiente.

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

Este código ajusta todo el lote de respuestas dentro de un sobre predefinido. A continuación, la orquestación de Broker avanza el itinerario al paso de itinerario DynamicTest , como se muestra en el código siguiente.

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

Dado que el atributo de tipo de servicio denominado DynamicTest se establece en Messaging, la clase ItineraryHelper promueve las propiedades del solucionador en el contexto del mensaje denominado OutboundMessage. La orquestación de Broker envía este mensaje a un puerto enlazado directo a BizTalk. A continuación, BizTalk reenvía el mensaje al puerto de envío dinámico representado por la suscripción ServiceName , que es DynamicTest. Este puerto de envío serializa la respuesta agregada final a la carpeta \Source\Samples\DynamicResolution\Test\Filedrop\Out.