¿Cómo resolver un servicio de transformación con BRE que ocurre después de una orquestación en un itinerario?
https://stackoverflow.com/questions/2999139
-
24-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Al intentar implementar una integración simple patrones Con BizTalk ESB Toolkit 2.0, me enfrento a un problema tratando de resolver un servicio de itinerario de transformación que ocurre después de una orquestación.
Estoy usando el resolución de BRE para ejecutar reglas que necesitan inspeccionar la propiedad de tipo de mensaje de contexto para determinar el mapa apropiado para usar. Sin embargo, una vez que el mensaje alcanza el paso en el itinerario asociado con el servicio de transformación, el mapa no se ejecuta.
Desde una investigación cuidadosa, parece que el tipo de mensaje no se suministra al objeto "resolución" que el resolución BRE usa internamente. De hecho, dado que se escribe el mensaje que abandona la orquestación anterior System.Xml.XmlDocument, el tipo de mensaje está "degradado" del contexto.
Mediante el seguimiento de las reglas de ejecución del motor, puedo observar que el tipo de mensaje es de hecho perdió Al llegar al resolutor BRE. El tipo de mensaje está vacío, mientras que el documento es muy tipado es Microsoft.XLANGs.BaseTypes.Any.
El servicio de orquestación que uso se toma directamente de las muestras que se envían con ESB Toolkit 2.0.
¿Hay alguna forma de realizar la resolución BRE basada en el contexto? después ¿Una orquestación en un itinerario?
Solución
Respondiendo a mi propia pregunta ... En resumen, la clave es prever el contexto del mensaje original y promover la propiedad de contexto MessageType. En los siguientes párrafos, reproduco una próxima publicación en mi blog:
Servicio de itinerario de orquestación 101
Después de luchar para hacer que esto funcione y probar diferentes soluciones, finalmente tuve éxito con un conjunto de reglas simples a seguir. En esta publicación, me gustaría describir lo que constituye una orquestación ESB Toolkit 2.0 para el bien portátil de ESB que puede usarse como un servicio de itinerario y aún aprovechar el resolución del motor de reglas comerciales para la transformación dinámica en función del tipo de contexto de un mensaje de un mensaje .
Suscripción de contexto para un servicio de itinerario
Primero, una orquestación diseñada para usarse como un servicio de itinerario debe tener un puerto lógico directo, vinculado a una forma de recepción que define una suscripción amigable con ESB como así:
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"
La documentación no menciona esto, pero esto deja en claro que las operaciones de puerto de unión directa deben asignarse a mensajes de tipo System.xml.xmlDocument. De hecho, si ese no es el caso, la orquestación no se ejecutará y un Falla de enrutamiento El mensaje de error se registrará en el Caja de mensaje.
Por cierto, esto significa que el mismo tipo de mensaje no tiene en cuenta en absoluto. Y esto explica en gran medida por qué, después de la ejecución de la orquestación, el resolución del motor de reglas comerciales no puede determinar la transformación correcta.
Llegar al itinerario
El siguiente código en forma de expresión al comienzo de la orquestación ayuda a recuperar el paso de itinerario actual:
// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);
Preservar el contexto del mensaje original
A continuación, el contexto del mensaje original debe conservarse (en su mayor parte) en cada paso de la orquestación. Esto es de particular importancia al tener varias formas de construcción intermedia en la orquestación para llevar a cabo el escenario específico en cuestión.
OutboundMessage(*) = SourceMessage(*)
Observe que escribí "en su mayor parte" en la oración anterior. De hecho, como veremos en un minuto, el tipo del mensaje resultante debe estar presente en el contexto al final de la orquestación. Probablemente, esto será un diferente tipo que el mensaje de entrada original. Y desde que asignó al solo lectura Bts.messageType La propiedad no es posible, esto puede ser bastante difícil de lograr a veces.
Es posible que deba recurrir para ejecutar una tubería personalizada dentro de la orquestación u otras técnicas exóticas para que este sea el caso. La mayoría de las veces, sin embargo, la sintaxis que se muestra arriba debería funcionar.
Avanzando el itinerario
El siguiente código muy sencillo no debe olvidarse al final de la orquestación:
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);
Promoción de propiedades de contexto
los documentación No explica bastante claramente qué pasos exactos deben seguirse, o incluso si las propiedades deben promover de tal orquestación, pero mirando las muestras proporcionadas como código fuente, se pueden encontrar que las siguientes propiedades participan en el mecanismo de resolución:
Sin embargo, en el escenario descrito en esta publicación, esto definitivamente no es suficiente.
Para que las reglas basadas en el contexto funcionen después de la orquestación, la propiedad BTS.MessageType también debe promoverse. Esto se puede lograr fácilmente inicializando una correlación en la forma de envío al final de la orquestación.
¡Y funciona!
Promover el tipo de mensaje en el contexto del mensaje resultante fue lo que faltaba en mi intento original. Una vez que esto fue identificado, ¡el itinerario funcionó como un encanto!
Aunque la solución puede parecer obvia después del hecho, seguro que me habría ayudado si lo hubiera sabido antes. Espero que esta publicación ayude a quienes afectan el mismo problema.
