Cómo usar expresiones para ejecutar canalizaciones

BizTalk Server tiene la capacidad de llamar de forma sincrónica a una canalización desde una orquestación. Esto permite a las orquestaciones aprovechar el procesamiento de mensajes encapsulado en una canalización (tanto envío como recepción) frente a un conjunto de datos sin tener que enviar los datos a través de la infraestructura de mensajería.

Puede usar esta característica para permitir que una orquestación llame a una canalización de envío a fin de agregar varios mensajes en un único intercambio de salida. A la inversa, una orquestación podría llamar a una canalización de recepción para descodificar y desensamblar un intercambio obtenido fuera de la infraestructura de mensajería, sin incurrir en los costos de procesamiento derivados de atravesar el cuadro de mensajes.

Detalles

Las orquestaciones usan métodos en la clase XLANGPipelineManager (en el espacio de nombres Microsoft.XLANGs.Pipeline ) para llamar a canalizaciones de envío o recepción. Una canalización de recepción consume un solo mensaje o un intercambio y produce cero o más mensajes, del mismo modo que cuando la canalización se ejecuta al recibir un mensaje dentro de la mensajería de BizTalk. Una canalización de envío consume uno o más mensajes y produce un solo mensaje o intercambio, también del mismo modo que cuando la canalización se ejecuta al enviar un mensaje dentro de la mensajería de BizTalk.

Llamar a una canalización de recepción

Para llamar a una canalización de recepción desde una orquestación, la aplicación llama al método ExecuteReceivePipeline() de la clase XLANGPipelineManager . Este método consume un único intercambio y devuelve una colección de cero o más mensajes (contenidos en una instancia de la clase ReceivePipelineOutputMessages ). La sintaxis de este método se detalla en la referencia de la biblioteca de clases de .NET para la clase XLANGPipelineManager .

La interfaz API para ejecutar una canalización de recepción desde una orquestación es la siguiente:

// Execute receive pipeline

static public ReceivePipelineOutputMessages ExecuteReceivePipeline(System.Type receivePipelineType, XLANGMessage msg);

Normalmente, una llamada a una canalización de recepción se realizaría en una forma expresión dentro de la orquestación.

Para llamar a una canalización de recepción desde una orquestación, el programador debe hacer referencia al ensamblado de canalización en el proyecto de orquestación. A continuación se muestra un ejemplo de una orquestación que llama a una canalización de recepción:

Para obtener un ejemplo más detallado, consulte el sdk de ejemplo procesador de mensajes compuestos (ejemplo de BizTalk Server) .

Nota

Una variable de tipo ReceivePipelineOutputMessages solo se puede declarar dentro de un ámbito atómico en una orquestación. Esto se debe a que las variables de este tipo no son serializables y, por lo tanto, no sobrevivirían a la persistencia de la orquestación. Además, las orquestaciones nunca persisten al ejecutarse en un ámbito atómico. Esto significa que una canalización de recepción solo se puede ejecutar en un ámbito atómico.

Nota

Al llamar a la canalización PassThruReceive o al componente de canalización personalizado desde una orquestación, debe declarar el tipo de variable para el mensaje entrante como System.Xml. XmlDocument a pesar del tipo de mensaje entrante es XML o no. Por lo tanto, puede producirse una excepción si intenta trabajar con él si el mensaje entrante no es un mensaje XML, como un mensaje de archivo de texto sin formato. Esto se debe a que el motor de orquestaciones pretende usar System.Xml.XmlDocument para cualquier tipo de mensaje entrante en el escenario descrito anteriormente.

Llamar a una canalización de envío

Para llamar a una canalización de envío desde una orquestación, la aplicación llama al método ExecuteSendPipeline() de la clase XLANGPipelineManager . Este método consume una colección de uno o varios mensajes (contenidos en una instancia de la clase SendPipelineInputMessages ) y devuelve un único intercambio. La sintaxis de este método se detalla en la referencia de la biblioteca de clases de .NET para la clase XLANGPipelineManager . Dado que la ejecución de una canalización de envío produce un nuevo intercambio, la llamada al método ExecuteSendPipeline() debe realizarse dentro de una forma de asignación de mensajes, como tal:

La interfaz API para ejecutar una canalización de envío desde una orquestación es:

// Execute a send pipeline

static public ExecuteSendPipeline(System.Type sendPipelineType, SendPipelineInputMessages inputMsgs, XLANGMessage msg);

Una llamada a una canalización de envío debe realizarse en una forma de asignación de mensajes dentro de la orquestación.

Para llamar a una canalización de envío desde una orquestación, el programador debe hacer referencia al ensamblado de canalización en el proyecto de orquestación. A continuación se muestra un ejemplo de una orquestación que llama a una canalización de envío:

Nota

Al llamar a la canalización XMLTransmit predeterminada, debe establecer la propiedad de contexto de mensaje XMLNORM.EnvelopeSpecName en el nombre completo del esquema de sobres. Por ejemplo:

MyMessage(XMLNORM.EnvelopeSpecName) = "PipelineSchemas.POEnv, PipelineSchemas, Version=1.0.0.0, Culture=nuetral, PublicKeyToken=12e5cc95621c33e8";

Para obtener un ejemplo más detallado, consulte el agregador de ejemplo del SDK (ejemplo de BizTalk Server) .

Ejecución de canalización: diferencias de comportamiento

La ejecución de una canalización de envío o recepción llamada por una orquestación es, en gran parte, la misma que cuando la misma canalización se ejecuta en una infraestructura de mensajería (es decir, en la ubicación de recepción o en el puerto de envío). No obstante, hay algunas diferencias de comportamiento que se detallan a continuación.

Diferencias dentro de las fases de canalización

La ejecución de las fases dentro de una canalización de envío o recepción a la que se llama desde una orquestación es prácticamente idéntica a la ejecución de dichas fases cuando se llama a la canalización desde la infraestructura de mensajería de BizTalk, con las excepciones que se apuntan a continuación.

• Ensamblador/Desensamblador: las fases de ensamblador y desensamblador no procesarán los datos del perfil de seguimiento .

• Codificador o descodificador: el codificador MIME firma digitalmente los mensajes mediante el certificado configurado en el host con el que está asociado el host. El codificador SMIME cifra mensajes mediante el certificado en el contexto del mensaje pasado a la canalización.

Resolución de esquemas

Hay dos algoritmos de búsqueda de esquemas que son compatibles al ejecutar una canalización desde una orquestación:

• Resolución por tipo

• Resolución por nombre

  En los casos en los que se implementan esquemas duplicados, la lógica del algoritmo para seleccionar el esquema adecuado es idéntica a la usada al ejecutarlo en el contexto de la infraestructura de mensajería.

Canalizaciones transaccionales

Las canalizaciones cuyas etapas llaman a componentes transaccionales no tendrán un contexto transaccional disponible. Cualquier llamada a IPipelineContext.GetTransaction() iniciará NotSupportedException. Esto no impide la ejecución de tal tipo de canalizaciones desde una orquestación. No obstante, significa que la canalización tendrá que detectar y controlar esta situación.

Destino de mensaje

En este contexto, no se admite controlar el destino de mensaje mediante componentes de canalización. Si se establecen las propiedades de contexto MessageDestination o SuspendOnRoutingFailure , se producirá una excepción XLANGPipelineManagerException .

Tipos de componentes de canalización

Los componentes de canalización deben estar basados en el siguiente orden para poder ser llamados desde una orquestación:

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

Restricciones

Los siguientes tipos de canalizaciones no se pueden ejecutar desde una orquestación:

• Canalizaciones transaccionales.

• Canalizaciones recuperables

• Canalizaciones que llaman a la API del interceptor de BAM (se producirá una excepción NotSupportedException ).

• La misma instancia de canalización no se puede ejecutar en distintas ramas de la forma paralela a menos que esté colocada en un ámbito sincronizado en cada rama.

• Canalizaciones existentes (ensamblados) compiladas con el SDK de BizTalk Server 2006.

Modos de error y efectos

Cualquier error en la ejecución de canalizaciones que podría haber tenido como consecuencia un mensaje suspendido si se hubiese llamado a esta canalización desde la infraestructura de mensajería de BizTalk Server, generará una excepción en su lugar. La excepción producida es de tipo Microsoft.XLANGs.Pipeline.XLANGPipelineManagerException. Esta excepción generada se puede controlar en un bloque de filtrado dentro de la orquestación que llama. Si la orquestación no filtra la excepción generada, el motor XLANGs notifica un error cuyo texto incluye la información de excepción en la excepción generada.

La excepción da formato a los mensajes de error generados por los componentes de la canalización.

La propiedad Message de la clase XLANGPipelineManagerException contiene detalles del error de ejecución de la canalización. Estos datos tienen el siguiente formato:

• Error al ejecutar el tipo> de canalización de canalización<. Mensaje de error con formato de detalles <del error>.

  En este mensaje, <el tipo> de canalización es el nombre de la clase de canalización y <el mensaje> de error con formato es una descripción del error específico que se produjo durante la ejecución de la canalización.

  Por ejemplo, si una orquestación llama a una canalización de recepción y se produce un error en la ejecución de esa canalización porque ninguno de los componentes de la canalización reconoce el mensaje, los valores de las propiedades de XLANGPipelineManagerException serían:

Propiedad XLANGPipelineManagerException	Value
Message	Error al ejecutar la canalización de recepción "MyPipelines.ReceivePipeline". Detalles del error: "Ningún componente de fase de desensamblaje puede reconocer los datos.
Componente	String.Empty

Como otro ejemplo, si una orquestación llama a una canalización de envío y se produce un error en la ejecución de esa canalización porque se produce un error de validación, el texto de la propiedad Message de XLANGPipelineManagerException sería:

Propiedad XLANGPipelineManagerException	Value
Message	Error al ejecutar la canalización de envío "MyPipelines.SendPipeline". Detalles del error: "No se pudo validar el documento: "El <elemento name> del elemento no es válido: el valor del <elemento value> no es válido según su tipo de datos "String" - Error en la restricción Pattern".
Componente	“Microsoft.BizTalk.Component.XmlValidator”