Procesamiento del mensaje

Todos los componentes descritos hasta ahora desempeñan un papel en el procesamiento de mensajes a medida que fluyen a través de BizTalk Server. En esta sección se proporciona más detalles sobre cómo interactúan estos componentes de forma funcional, empezando por recibir un mensaje. En la ilustración siguiente se muestra la creación de un puerto de recepción y el flujo de un mensaje a través del proceso de recepción.

Un puerto de recepción consta de una o varias ubicaciones de recepción y cero o más mapas. Los mapas son hojas de estilo de Transformaciones de Lenguaje de Hojas de Estilo Extensible (XSLT) que se usan para transformar mensajes XML de una estructura o formato a otro distinto y a menudo se utilizan durante el proceso de recepción para normalizar los mensajes en un formato interno. Las ubicaciones de recepción controlan los puntos de conexión que reciben los mensajes. Una ubicación de recepción consta de la configuración de un punto de conexión para un adaptador de recepción y una canalización de recepción.

El rol del adaptador

El adaptador de recepción inicia el proceso de recepción de mensajes leyendo un flujo de datos y creando un mensaje. Por ejemplo, el adaptador de archivos ve que un archivo se ha colocado en su ubicación configurada y lee ese archivo en una secuencia. El adaptador crea un mensaje (una implementación de la interfaz Microsoft.BizTalk.Message.Interop.IBaseMessage), agrega una parte a él (una implementación de la interfaz Microsoft.BizTalk.Message.Interop.IBasePart) y proporciona el flujo de datos como contenido de la parte.

Además, el adaptador escribe y promueve en las propiedades de contexto del mensaje aspectos relacionados con la ubicación, el tipo de adaptador y otros elementos vinculados al adaptador. Una vez creado el mensaje y su contexto, el adaptador pasa el mensaje al Administrador de puntos de conexión. A continuación, el mensaje se procesa a través de la canalización de recepción, que se ha configurado para la ubicación de recepción. Una vez que el mensaje ha sido procesado por la canalización, se puede utilizar un mapa para transformar el mensaje en el formato deseado antes de que Endpoint Manager publique el mensaje con el Agente de Mensajes.

Rol de la canalización

Aunque es el adaptador que crea el mensaje inicial, la mayoría del procesamiento que se produce en un mensaje recibido se produce en la canalización de recepción. El procesamiento de canalizaciones se ocupa del contenido del mensaje, así como del contexto del mensaje. Por lo general, el contenido del mensaje se controla en las fases de descodificación, desensamblaje y validación, mientras que el contexto del mensaje se puede controlar en todas las fases. Sin embargo, una canalización no actúa necesariamente en el contenido ni en el contexto. Por ejemplo, la canalización de paso a través predeterminada no tiene componentes configurados y no realiza ningún procesamiento en el contenido o el contexto del mensaje. Por motivos de simplicidad, este documento se centra en los componentes de desensamblaje, ya que generalmente tienen el mayor impacto en el enrutamiento de mensajes.

El trabajo del desensamblador es procesar un mensaje entrante desde un adaptador y desensamblarlo en muchos mensajes y analizar los datos del mensaje. Cuando un mensaje entrante tiene muchos mensajes más pequeños, esto se conoce como intercambio. Tanto el desensamblador de archivos planos como el desensamblador XML controlan los intercambios al permitir que un desarrollador configure información sobre el contenido de envoltura (es decir, un esquema de encabezado y final para el desensamblador de archivos planos y un esquema de envoltura para el desensamblador XML) y el contenido del cuerpo, que puede repetirse. Además, ambos desensambladores analizan el mensaje original en contenido XML. Un desensamblador personalizado no analiza necesariamente el contenido en XML si no se requiere procesamiento XML adicional en BizTalk Server. Un escenario de ejemplo podría incluir una situación de enrutamiento sencilla en la que los mensajes que entran en el sistema en una ubicación de recepción determinada se envían a un puerto de envío específico sin asignación ni a otro procesamiento basado en XML.

Enrutamiento con el tipo de mensaje

Una de las propiedades de mensaje más comunes que se usan en el enrutamiento es el tipo de mensaje. Cuando un desarrollador crea un esquema para definir la estructura de los mensajes, este esquema define el tipo de mensaje para ese mensaje. El tipo viene determinado por el nodo raíz y el espacio de nombres en la definición de esquema. Por ejemplo, un documento XML similar al siguiente tendría un tipo de mensaje. http://tempuri.org/samples/MessageType#Message

<Message xmlns=http://tempuri.org/samples/MessageType>  
<SomeOtherElement type="sample"/>  
</Message>  

Para usar el tipo de mensaje en el enrutamiento, debe ser promovido al contexto. Los desensambladores se usan para promover este valor en el contexto del mensaje, así como los componentes de canalización con el conocimiento más específico de la estructura del mensaje. Los desensambladores XML y Archivos planos promueven el tipo de mensaje a medida que procesan mensajes, y cualquier desensamblador personalizado también debe promover esta propiedad para garantizar el enrutamiento adecuado.

Es importante tener en cuenta que no se requiere que un mensaje tenga un tipo. Como se mencionó anteriormente, las partes de un mensaje pueden ser datos binarios y no necesitan tener un esquema que defina su estructura. Este tipo de elemento de mensaje suele pasarse a través de BizTalk Server sin mucho, si existe, el procesamiento realizado en él por el propio BizTalk Server, aunque los componentes de canalización personalizados, los adaptadores o el código llamado desde orquestaciones pueden interactuar con estas partes.

Los componentes del pipeline, como los adaptadores, también escriben y promueven propiedades en el contexto del mensaje. De hecho, los componentes de canalización son el mecanismo más común que usan la mayoría de los desarrolladores para obtener propiedades en el contexto del mensaje. Los desarrolladores crean esquemas y pueden promover propiedades en el esquema. Esta información se almacena en el esquema como anotaciones que los componentes de canalización pueden usar. Todos los componentes integrados de desensamblador y ensamblador ( FlatFile, XML y BizTalk Framework) usan el esquema de documento para recuperar información sobre las propiedades que se van a promover. Con la instrucción del lenguaje de ruta XML (XPath) a partir de las anotaciones, el desensamblador sabe la ubicación en el documento de los elementos que se van a promover. Durante el proceso de streaming a través del documento, el desensamblador busca los elementos que coinciden con una de las instrucciones XPath y promueve o escribe el valor en el contexto según corresponda.

Los componentes de canalización personalizados también se pueden escribir para controlar la obtención de propiedades en el contexto de datos arbitrarios en un mensaje recibido o enviado. Para promover una propiedad en el contexto y que sea útil para el enrutamiento, que presumiblemente es la razón por la cual se promueve el valor, se debe crear e implementar un esquema de propiedad con una definición para la propiedad en BizTalk Server. Antes de definir un esquema de propiedades que usarán los componentes personalizados, debe comprender los distintos tipos de propiedades promocionadas. Las propiedades promocionadas definidas en un esquema de propiedades pueden tener uno de los dos tipos base:

• Microsoft.XLANGs.BaseTypes.MessageContextPropertyBase o

• Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase

  Una propiedad con un tipo base de MessageDataPropertyBase indica que el valor de esta propiedad procede del contenido del mensaje. Este es el valor predeterminado para las propiedades definidas en un esquema de propiedades y es el uso más común. MessageContextPropertyBase indica una propiedad que está pensada para formar parte del contexto del mensaje, pero no procede necesariamente de los datos del mensaje directamente. Las propiedades con MessageContextPropertyBase como su tipo base suelen promoverse mediante adaptadores y desensamblajes e incluyen propiedades comunes, como el tipo de mensaje y el tipo de adaptador.

  Es importante comprender los distintos tipos y usarlos adecuadamente al definir propiedades. Una de las implicaciones más significativas se produce al acceder a las propiedades de contexto de un mensaje en una orquestación. Si una propiedad se identifica como MessageDataPropertyBase, el Diseñador de orquestaciones examina el esquema del mensaje que se recibe y garantiza que define una propiedad promocionada coincidente. Si no se encuentra ninguna propiedad en el esquema vinculado a la propiedad promocionada a la que se accede, el Diseñador no le permite acceder a ella. Por otro lado, si la propiedad se define como *MessageContextPropertyBase*, el tipo de mensaje no importa y se puede acceder a la propiedad.

  En canalizaciones personalizadas, el mecanismo para promover o escribir propiedades en el contexto es muy similar. Para escribir propiedades, se usa una llamada al método IBaseMessageContext Write para colocar el valor en el contexto. En el caso de las propiedades promocionadas, simplemente se usa el método IBaseMessageContext Promote en su lugar. Cada uno de estos métodos toma un nombre de propiedad, un espacio de nombres y un valor. Para las propiedades promocionadas, el nombre y el espacio de nombres son los de la propiedad definida en el esquema de propiedades, y se puede acceder a ellos más fácilmente haciendo referencia al ensamblado del esquema de propiedades y utilizando las propiedades de la clase creada específicamente para ella. Los campos distintivos usan un espacio de nombres común, http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFieldsy la expresión XPath que se usa para recuperar el valor normalmente se usa como nombre.

  El código a continuación muestra un ejemplo de cómo promover y escribir propiedades en el contexto. Tenga en cuenta que, en este ejemplo, se escribe un campo distintivo en el contexto. Esto solo es útil para las orquestaciones en las que el esquema de mensaje identifica el campo distintivo para que el Diseñador de orquestaciones conozca el campo. Puede ser útil escribir propiedades en el contexto para su uso por otros componentes de canalización en el lado receptor o de envío.

//create an instance of the property to be promoted  
SOAP.MethodName methodName = new SOAP.MethodName();  
  
//call the promote method on the context using the property class for name   
//and namespace  
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,   
"theSOAPMethodName");  
  
//write a distinguished field to the context  
pInMsg.Context.Write("theDistinguishedProperty",   
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",   
"theDistinguishedValue");  

Tenga en cuenta los siguientes hechos al escribir o promover valores en el contexto:

• Escribir un valor en el contexto con el mismo nombre y espacio de nombres que se usaron anteriormente para promover la propiedad hace que esa propiedad ya no se promueva. Básicamente, la escritura sobrescribe la promoción.

• Al escribir un valor null en el contexto, se elimina el valor porque no se permiten propiedades con valores NULL.

• Las propiedades promocionadas están limitadas a 256 caracteres de longitud, mientras que las propiedades escritas no tienen ninguna limitación de longitud.

  Las propiedades promocionadas se usan en el enrutamiento de mensajes y tienen un tamaño limitado por motivos de eficacia en comparación y almacenamiento. Aunque las propiedades escritas no tienen límites estrictos sobre el tamaño, el uso de valores excesivamente grandes en el contexto tendrá un impacto en el rendimiento, ya que esos valores deben procesarse y pasarse con el mensaje.

  Cuando un mensaje está listo para enviarse desde BizTalk Server, se somete a un proceso complementario en el puerto de envío. Los mapas se aplican a los mensajes antes de que se ejecute la canalización de envío, lo que permite transformar un mensaje en un formato específico de cliente o aplicación antes de que la canalización lo procese y envíe a través del adaptador. En la canalización de envío, en lugar de promover propiedades en el contexto del mensaje, las propiedades se degradan del contexto al mensaje.

  

Véase también

Arquitectura en tiempo de ejecución
Cómo BizTalk Server procesa mensajes grandes