Compartir a través de


Conectar sistemas

El intercambio eficaz de mensajes a través de distintos sistemas de software en equipos diferentes es un requisito indispensable para la integración. Dada la diversidad de estilos de comunicación que existen, BizTalk Server deben admitir una variedad de protocolos y formatos de mensaje. Como se describe más adelante, una parte importante de este motor se dedica a este trabajo de comunicación. No obstante, un aspecto importante que se ha de tener en cuenta es que el motor sólo trabaja con documentos XML de forma interna. Independientemente del formato en el que llegue el mensaje, debe convertirse a XML. Del mismo modo, si el destinatario del documento no puede aceptarlo en XML, el motor lo convierte en el formato esperado por el destino.

Envío y recepción de mensajes: adaptadores

Dado que BizTalk Server debe comunicarse con una variedad de otros softwares, se basa en adaptadores para que esto sea posible. Un adaptador es una implementación de un mecanismo de comunicación, como, por ejemplo, un protocolo determinado. Los programadores determinan los adaptadores que se utilizarán en situaciones determinadas. Pueden elegir uno de los adaptadores integrados BizTalk Server proporciona, por ejemplo, un adaptador creado para un producto popular, como Windows SharePoint Services, o incluso crear un adaptador personalizado. En todos estos casos, el adaptador se integra en una base estándar, denominada Marco de trabajo de adaptadores. Este marco de trabajo ofrece una manera común de crear y ejecutar adaptadores, y admite las mismas herramientas que se utilizan para administrar todos los tipos de adaptadores.

Microsoft BizTalk Server incluye los siguientes adaptadores nativos:

  • Adaptador de archivos: admite la lectura y escritura en archivos del sistema de archivos de Windows. Puesto que las aplicaciones implicadas en un proceso empresarial pueden tener acceso con frecuencia al mismo sistema de archivos, tanto de forma local como a través de una red, el intercambio de mensajes por medio de los archivos puede resultar una opción práctica.

  • Adaptador ftp: admite el envío y recepción de información entre un servidor de protocolo de transporte de archivos (FTP) y BizTalk Server.

  • Adaptador HTTP: admite el envío y recepción de información mediante HTTP. BizTalk Server expone una o varias direcciones URL para permitir que otras aplicaciones envíen datos a él y puede usar este adaptador para enviar datos a otras direcciones URL.

  • Adaptador de MSMQ: admite el envío y recepción de mensajes mediante Microsoft Message Queuing (MSMQ).

  • Adaptador de WebSphere MQ: admite el envío y recepción de mensajes mediante WebSphere MQ de IBM (anteriormente conocido como MQSeries).

  • Adaptador POP3: admite la recepción de mensajes de correo electrónico y sus datos adjuntos con la versión tres del Protocolo de oficina de correos (POP3).

  • Adaptador SMTP: admite el envío de mensajes mediante SMTP. Las direcciones de correo electrónico estándar sirven para identificar las entidades.

  • Adaptador SOAP: admite el envío y recepción de solicitudes de servicio web para permitir que BizTalk Server se conecten a servicios web.

  • Adaptadores WCF: admite el envío y recepción de información mediante Windows Communication Foundation.

  • adaptador de Windows SharePoint Services (WSS): admite el acceso y la publicación de documentos almacenados en bibliotecas de documentos de Microsoft Windows SharePoint.

    Los adaptadores del software empresarial más actualizado también se encuentran disponibles en Microsoft, y entre ellos se incluyen:

  • Adaptador de Microsoft BizTalk para JD Edwards OneWorld

  • Adaptador de Microsoft BizTalk para JD Edwards EnterpriseOne

  • Adaptador de Microsoft BizTalk para PeopleSoft Enterprise

  • Adaptador de Microsoft BizTalk para TIBCO Rendezvous

  • Adaptador de Microsoft BizTalk para TIBCO Enterprise Message Service

    Para obtener más información sobre estos adaptadores, consulte Adaptadores en BizTalk Server.

    Independientemente del adaptador que se emplee para recibir datos, normalmente los mensajes recibidos deben procesarse antes de que ninguna orquestación pueda obtener acceso a ellos. De igual modo, a menudo es necesario procesar los mensajes salientes producidos por una orquestación antes de que el adaptador los envíe.

Procesamiento de mensajes: canalizaciones

Las aplicaciones subyacentes a un proceso de negocio se comunican intercambiando varios tipos de documentos: para ejemplos, pedidos de compra y facturas. Para que una aplicación de BizTalk Server ejecute un proceso de negocio, debe poder tratar correctamente los mensajes que contienen estos documentos. Este procesamiento puede constar de varias fases, de ahí que la realice una canalización de mensajes. Los mensajes entrantes se procesan a través de una canalización de recepción, mientras que los salientes pasan a través de una canalización de envío.

Por ejemplo, aunque se están diseñando más aplicaciones para comprender documentos XML, muchas (probablemente la mayoría actual) no pueden. Dado que BizTalk Server solo funciona con documentos XML internamente, debe proporcionar una manera de convertir otros formatos hacia y desde XML. Además, es posible que deba cubrir otros servicios, como, por ejemplo, la autenticación del remitente de un mensaje. Para tratar éstas y otras tareas de una forma independiente y personalizada, se crea una canalización con un número de etapas. Cada una de ellas contiene uno o varios componentes de modelo de objetos componentes (COM) o compatibles con .NET. Cada componente se encarga de una parte determinada del procesamiento del mensaje. BizTalk Server proporciona varios componentes estándar que abordan los casos más comunes. Si éstos no son suficientes, los programadores también pueden crear componentes personalizados para las canalizaciones de recepción y envío.

Imagen que muestra la canalización de recepción.

La ilustración anterior muestra las fases de una canalización de recepción, así como los componentes estándar que se proporcionan para cada una. Estas fases y sus componentes asociados son los siguientes:

  • Descodificación: BizTalk Server proporciona un componente estándar para esta fase, el descodificador MIME/SMIME. Este componente puede controlar mensajes y los datos adjuntos que contengan en formatos MIME o Secure MIME (S/MIME). El componente convierte los dos tipos de mensajes en XML, y puede descifrar mensajes en formato S/MIME y comprobar las firmas digitales.

  • Desensamblaje: se proporcionan tres componentes estándar. El componente Desensamblador de archivos sin formato convierte este tipo de archivos en documentos XML. Estos archivos pueden ser posicionales (cada registro tiene la misma longitud y estructura) o delimitados (se utiliza un carácter designado para separar los registros del archivo). El segundo componente estándar, el Desensamblador de XML, analiza los mensajes entrantes que se han descrito como mensajes con formato XML. El tercer componente estándar, muy poco utilizado en la actualidad, es el Desensamblador de BizTalk Framework. Este componente acepta los mensajes enviados con el confiable mecanismo de mensajería definido por BizTalk Framework, que se implementó en BizTalk Server 2000.

  • Validar: BizTalk Server proporciona un componente validador XML para esta fase. Como su propio nombre indica, este componente valida un documento XML producido en la fase de desensamblado. Para ello, toma como base un esquema o un grupo de esquemas especificado y, si el documento no cumple con uno de estos esquemas, devuelve un error.

  • Entidad de resolución: el único componente estándar para esta fase, Resolución de entidades, intenta determinar una identidad para el remitente de este mensaje. Si el mensaje se firmó digitalmente, la firma se usa para buscar una identidad de Windows en la base de datos de administración de BizTalk Server. (Como se describe más adelante, esta base de datos también la usan las herramientas de administración de BizTalk Server). Si el mensaje lleva el identificador de seguridad autenticado (SID) de un usuario de Windows, se usa esta identidad. Si no se consigue aplicar ningún mecanismo, se le asignará al remitente del mensaje una identidad anónima predeterminada.

    Imagen que muestra la canalización de envío.

    Los mensajes salientes también pueden pasar por varias fases, según establezca la canalización de envío que se utilice. La ilustración anterior muestra las fases y los componentes estándar de una canalización de envío. Son las siguientes:

  • Preensamblado: no se proporcionan componentes estándar. En su lugar pueden instalarse componentes personalizados en función de sus necesidades.

  • Ensamblado: paralelización de la fase de desensamblaje en una canalización de recepción, esta fase también tiene tres componentes estándar. El Ensamblador de archivos sin formato convierte un mensaje XML en un archivo sin formato de tipo posicional o delimitado, mientras que el Ensamblador de XML permite agregar un sobre al mensaje XML saliente y realizar otros cambios en él. La tercera opción, el Ensamblador de BizTalk Framework, empaqueta los mensajes con la tecnología de mensajería de BizTalk Framework para enviarlos de forma confiable.

  • Codificación: BizTalk Server define solo un componente estándar para esta fase, el codificador MIME/SMIME. Este componente empaqueta los mensajes salientes en formato MIME o S/MIME. Si se utiliza S/MIME, el mensaje también puede firmarse o cifrarse digitalmente.

    BizTalk Server define algunas canalizaciones predeterminadas, incluido un par simple de recepción/envío que se puede usar para controlar los mensajes que ya se expresan en XML. Asimismo, cualquier programador puede crear canalizaciones personalizadas gracias al Diseñador de canalizaciones. Esta herramienta, que se ejecuta dentro de Visual Studio, proporciona una interfaz gráfica que permite al desarrollador arrastrar y colocar componentes para crear canalizaciones con cualquier comportamiento necesario.

Elegir mensajes: suscripciones

Una vez que se transmite un mensaje por un adaptador y una canalización de recepción, el paso siguiente consiste en determinar su destino. Un mensaje suele dirigirse a una orquestación, pero también es posible que un mensaje vaya directamente a una canalización de envío, lo que permite usar BizTalk Server como un sistema de mensajería puramente. En ambos casos, la correspondencia entre los mensajes y sus destinos se realiza mediante subscripciones.

Cuando una canalización de recepción procesa un mensaje, crea un contexto de mensaje que contiene varias propiedades del mensaje. Una orquestación o una canalización de envío puede suscribir mensajes en función de los valores de estas propiedades. Por ejemplo, una orquestación podría crear una suscripción que coincida con todos los mensajes del tipo "Invoice" o todos los mensajes del tipo "Invoice" recibidos de la corporación QwickBank, o todos los mensajes del tipo "Invoice" recibidos de la corporación QwickBank que son por más de 10 000 USD. Sin embargo, se especifica, una suscripción vuelve a su suscriptor solo los mensajes que coinciden con los criterios que define la suscripción. Un mensaje recibido puede iniciar un proceso empresarial creando una instancia de alguna orquestación, o puede activar otro paso en un proceso empresarial que ya esté en ejecución. De igual modo, cuando una orquestación envía un mensaje, éste se envía a una canalización de envío en función de una suscripción que haya establecido esa canalización.

  • En BizTalk Server, también es posible suscribirse a condiciones de error específicas. Un mensaje de error puede procesarse de una forma determinada o moverse a un destino concreto, como, por ejemplo, a una carpeta de Windows SharePoint Services.

Consulte también

El motor de mensajería de BizTalk Server
Arquitectura de publicación y suscripción
Adaptadores
Canalizaciones