Section 1 - Connectivity and Integration

(23%)
1.1 Identify the components and standards of Web services (including WSDL,
XML, SOAP, HTTPS)

Conceptos basicos de WS

1.2 Select appropriate connectivity protocols

Puede utilizar varios protocolos distintos para conectar sus aplicaciones a intermediarios.
La siguiente información de consulta le ayudará a habilitar las aplicaciones de usuario final para utilizarlas con
WebSphere Message Broker:

 WebSphere MQ Enterprise Transport

 WebSphere MQ Mobile Transport
 WebSphere MQ Multicast Transport
 WebSphere MQ Real-time Transport
 WebSphere MQ Telemetry Transport
 WebSphere Broker HTTP Transport
 WebSphere Broker JMS Transport

1.3 Implement a flow using We bSphere MQ nodes

WebSphere MQ Enterprise Transport

WebSphere MQ Enterprise Transport es un servicio que conecta aplicaciones a middleware de mensajería.

WebSphere MQ Enterprise Transport es el transporte que utiliza WebSphere MQ. WebSphere MQ Enterprise
Transport da soporte a aplicaciones WebSphere MQ que se conectan con WebSphere Message Broker para
beneficiarse de las opciones de direccionamiento de mensajes y transformación.

WebSphere MQ Enterprise Transport proporciona todas las características de mensajería fiables disponibles en
WebSphere MQ. Este transporte proporciona mensajes persistentes y no persistentes y da soporte a
transacciones. Para utilizar WebSphere MQ Enterprise Transport, debe desplegar un flujo de mensajes que
contiene un nodo MQInput con el intermediario. Si este flujo de mensajes envía mensajes de salida a otras
aplicaciones de WebSphere MQ, también debe incluir un nodo MQOutput, MQReply o Publication.

WebSphere MQ Enterprise Transport es un transporte en cola; las aplicaciones se comunican con el intermediario
escribiendo los datos y leyendo los datos de las colas de mensajes. Utilice el WebSphere MQ Enterprise Transport
cuando necesite una entrega segura de mensajes o cuando debe utilizar el soporte de transacciones.

Puesto que WebSphere MQ Enterprise Transport es una opción más potente, no ofrece los mismos niveles de
rendimiento y escalabilidad que WebSphere MQ Real-time Transport.

WebSphere MQ Enterprise Transport lo utilizan clientes de WebSphere MQ o programas de aplicación que se

escriben en la Interfaz de aplicaciones de mensajería (AMI) o en la Interfaz de Colas de Mensajes (MQI). El cliente
utiliza los servicios que proporcionan los flujos de mensajes de uno o varios intermediarios en el dominio de
intermediario interactuando con las colas a las que dan servicio esos flujos de mensajes.

La cola especificada en el nodo MQInput determina la cola en la que el intermediario recibe publicaciones de las
aplicaciones de publicación. Los suscriptores se conectan al intermediario enviando una petición de registro a la
cola SYSTEM.BROKER.CONTROL.QUEUE del intermediario. El suscriptor especifica una cola en la que desea recibir
cualquier publicación sobre el tema registrado en la petición de registro.

Todas las aplicaciones WebSphere Message Broker como, por ejemplo, las aplicaciones WebSphere MQ pueden
utilizar todas las interfaces WebSphere MQ soportadas para colocar los mensajes en las colas del flujo de
mensajes. De hecho, cada aplicación WebSphere MQ es una aplicación WebSphere Message Broker potencial.

Estas aplicaciones utilizan una de dos técnicas para obtener acceso a los servicios del intermediario:

 Una aplicación puede utilizar una conexión de cliente WebSphere MQ. Puede utilizar todos los clientes
WebSphere MQ a los que dé soporte la Versión 6.0 o posterior. Por lo tanto, puede conectar aplicaciones
que se ejecutan en una amplia gama de entornos de su dominio de intermediario. Una aplicación que se
ejecuta en el mismo sistema que el gestor de colas al que se conecta también puede utilizar una conexión
de cliente.
 Una aplicación que se ejecuta en el mismo sistema que un intermediario puede utilizar una conexión local
con el gestor de colas que aloja dicho intermediario. Si utiliza este método, el cliente debe ejecutarse en
el mismo sistema. Puede conectarse a un gestor de colas que dé soporte a un intermediario o a cualquier
otro gestor de colas en la red de WebSphere MQ que tenga una vía de acceso definida en el gestor de
colas de intermediario. (Esa opción no es posible en z/OS, donde no se da soporte a clientes.)

WebSphere Message Broker no impone ninguna condición ni restricción específica a las aplicaciones.

Las aplicaciones de recepción pueden obtener los mensajes transferidos a la cola de salida o a las colas de un flujo
de mensajes cuando dicho flujo de mensajes los haya procesado. Las aplicaciones deben estar conectadas, ya sea
mediante una conexión de cliente/servidor o mediante una conexión local, al gestor de colas propietario de la cola
o colas definidas como el destino de sus mensajes. Si el flujo de mensajes proporciona un servicio de
publicación/suscripción, el nodo Publication transfiere los mensajes a la cola especificada por el suscriptor como su
cola de receptor local.

Las aplicaciones que se conectan mediante WebSphere MQ Enterprise Transport, utilizan una combinación de
modelos de punto a punto y publicación/suscripción.

Para dar soporte a este protocolo se incorporan los siguientes nodos:

 MQInput
 MQOutput
 MQReply
 MQGet
 Publication
 MQHeader

Nodo MQInput

Utilice el nodo MQInput para recibir mensajes de clientes que se conecten al intermediario utilizando WebSphere
MQ Enterprise Transport y que utilicen las interfaces de programación de aplicaciones MQI y AMI.
Finalidad

El nodo MQInput recibe un mensaje de una cola de mensajes WebSphere MQ definida en el gestor de colas del
intermediario. El nodo utiliza MQGET para leer un mensaje de la cola especificada y establecer el entorno de
proceso para el mensaje. Si es adecuado, puede definir la cola de entrada como una cola compartida o una cola de
clúster de WebSphere MQ.

Los flujos de mensajes que manejan los mensajes que se reciben a través de conexiones WebSphere MQ han de
empezar siempre con un nodo MQInput. Puede establecer las propiedades del nodo MQInput para controlar el
modo en que se reciben los mensajes, haciendo que se establezcan las opciones MQGET apropiadas. Por ejemplo,
puede indicar que un mensaje debe procesarse bajo control de transacciones. También puede solicitar que se
realice la conversión de datos al recibir cada mensaje de entrada.

El nodo MQInput maneja mensajes en los siguientes dominios de mensajes:

 MRM
 XMLNSC
 DataObject
 XMLNS
 JMSMap
 JMSStream
 MIME
 BLOB
 XML (este dominio ya no se utiliza; use XMLNSC)
 IDOC (este dominio ya no se utiliza; use MRM)

Si incluye un nodo de salida en un flujo de mensajes que empieza con un nodo MQInput, el nodo de salida podrá
ser cualquiera de los nodos de salida soportados, incluidos los nodos de salida definidos por el usuario; no es
necesario incluir un nodo MQOutput. Puede crear un flujo de mensajes que reciba mensajes de clientes
WebSphere MQ y genere mensajes para clientes que utilizan cualquiera de los transportes soportados para
conectarse al intermediario, porque puede configurar el flujo de mensajes para solicitar que el intermediario
proporcione la conversión que sea necesaria.

Si crea un flujo de mensajes para utilizarlo como subflujo, no puede utilizar un nodo de entrada estándar; debe
utilizar un nodo Input como el primer nodo, para crear un terminal de entrada para el subflujo.

Si el flujo de mensajes no recibe mensajes a través de conexiones de WebSphere MQ, puede elegir uno de los
nodos de entrada soportados.

El nodo MQInput se encuentra en la bandeja de WebSphere MQ de la paleta y está representado en el entorno de

trabajo con el siguiente icono:

Conexión de terminales

El nodo MQInput direcciona al terminal de salida (Out) todos los mensajes que recupera satisfactoriamente. Si falla
esta acción, se vuelve a intentar el mensaje. Si se excede la cuenta de restituciones (según lo definido mediante el
atributo BackoutThreshold de la cola de entrada), el mensaje se direcciona al terminal de anomalías (Failure);
puede conectar nodos a este terminal para manejar esta condición. Si no ha conectado el terminal de anomalías, el
mensaje se escribe en la cola de restitución.

Si este nodo capta este mensaje después de que se genere una excepción más adelante en el flujo de mensajes, el
mensaje se direcciona al terminal de captación. Si no ha conectado el terminal de captación, el mensaje entra en
un bucle continuo a través del nodo, hasta que se resuelve el problema.

Debe definir una cola de restitución o una cola de mensajes no entregados (DLQ) para evitar el bucle continuo del
mensaje a través del nodo.

Configuración de transacciones coordinadas

Cuando se incluye un nodo MQInput en un flujo de mensajes, el valor que se establece para la Modalidad de
transacción indica si los mensajes se reciben bajo el punto de sincronismo.

 Si establece la propiedad en Automática, el mensaje se recibe bajo el punto de sincronismo en el caso de

que el mensaje de entrada esté marcado como persistente; de lo contrario, no se recibe bajo el punto de
sincronismo. Cualquier mensaje enviado posteriormente por un nodo de salida se coloca bajo punto de
sincronismo, según lo determinado por la propiedad de persistencia entrante, a menos que el nodo de
salida haya modificado explícitamente esta propiedad.
 Si establece la propiedad en Sí (el valor predeterminado), el mensaje se recibe bajo el punto de
sincronismo; es decir, dentro de una unidad de trabajo de WebSphere MQ). Cualquier mensaje enviado
posteriormente por un nodo de salida en la misma instancia del flujo de mensajes se coloca bajo punto de
sincronismo, a menos que el nodo de salida haya modificado esto explícitamente.
 Si establece la propiedad en No, el mensaje no se recibe bajo el punto de sincronismo. Cualquier mensaje
enviado posteriormente por un nodo de salida en el flujo de mensajes no se pone bajo punto de
sincronismo, a menos que un nodo de salida individual haya especificado que el mensaje debe ponerse
bajo punto de sincronismo.

El nodo MQOutput es el único nodo de salida que se puede configurar para alterar temporalmente esta opción.

Si ha establecido la propiedad Sólo examinar, se ignorará el valor establecido para la propiedad Modalidad de
transacción puesto que un mensaje no se puede examinar bajo un punto de sincronismo. No obstante, cualquier
mensaje derivado que se propague más adelante por un nodo de salida en la misma instancia del flujo de mensajes
seguirá el comportamiento descrito anteriormente según lo especificado por el valor de Modalidad de transacción.

Nodo MQOutput

Utilice el nodo MQOutput para enviar mensajes a clientes que se conecten con el intermediario utilizando
WebSphere MQ Enterprise Transport y que utilicen las interfaces de programación de aplicaciones MQI y AMI.

Finalidad

El nodo MQOutput entrega un mensaje de salida de un flujo de mensajes a una cola WebSphere MQ. El nodo
utiliza MQPUT para colocar el mensaje en la cola o colas de destino que especifique.

Si es adecuado, defina la cola como una cola compartida o una cola de clúster de WebSphere MQ. Cuando utilice
una cola de clúster de WebSphere MQ, deje el Nombre del gestor de colas en blanco.
Puede configurar el nodo MQOutput para colocar un mensaje en una cola específica de WebSphere MQ que se ha
definido en cualquier gestor de colas a la cual el gestor de colas puede acceder para el intermediario, o en los
destinos identificados en el entorno local asociado al mensaje.

Establezca otras propiedades para controlar la forma en que se envían los mensajes, definiendo las opciones
adecuadas de MQPUT; por ejemplo, puede solicitar que un mensaje se procese bajo control de transacción.
También puede especificar que WebSphere MQ pueda, si es adecuado, dividir el mensaje en segmentos en el
gestor de colas.

Si crea un flujo de mensajes para utilizarlo como subflujo, no podrá utilizar un nodo de salida estándar; utilice una
instancia del nodo Output para crear un terminal de salida para el subflujo a través del cual propagar el mensaje.

Si no desea que el flujo de mensajes envíe mensajes a una cola de WebSphere MQ, elija otro nodo de salida
soportado.

El nodo MQOutput comprueba si hay una cabecera MQMD (WebSphere MQ descriptor de mensaje) en el árbol de
mensajes. Si no hay ninguna cabecera MQMD, el nodo MQOutput crea una en el árbol de mensajes y la llena con
las propiedades predeterminadas de MQMD. Si se encuentra una cabecera MQMD, el nodo MQOutput comprueba
si es una cabecera de tipo WebSphere MQ y si no lo es, establece la propiedad Contexto de mensaje en
Predeterminado. El nodo MQOutput trata cualquier otra cabecera de transporte del árbol de mensajes como
datos. Si estas cabeceras no son necesarias como parte del cuerpo del mensaje, utilice un nodo de transformación
para eliminarlas de árbol de mensajes antes del nodo MQOutput. Si el árbol de mensajes proviene de JMS, puede
utilizar un nodo JMSMQTransform para construir un árbol de mensajes compatible con MQ.

El nodo MQOutput se encuentra en la bandeja de WebSphere MQ de la paleta y está representado en el entorno

de trabajo con el siguiente icono:

Nodo MQReply

Utilice el nodo MQReply para enviar una respuesta al emisor del mensaje de entrada.

Finalidad

El nodo MQReply es una forma especializada de nodo MQOutput que transfiere el mensaje de salida a la cola de
WebSphere MQ identificada por el campo ReplyToQ (cola de respuestas) de la cabecera del mensaje de entrada. Si
es adecuado, puede definir la cola como una cola compartida o una cola de clúster de WebSphere MQ.

El nodo MQReply utiliza las opciones establecidas en el campo Report (Informe) del MQMD. De forma
predeterminada (si no se ha establecido ninguna opción), el nodo MQReply genera un nuevo campo MsgId en el
mensaje de respuesta y copia el ID del mensaje del mensaje de entrada al campo CorrelId del mensaje de
respuesta. Si la aplicación receptora espera otros valores en estos campos, asegúrese de que la aplicación que
transfiere el mensaje a la cola de entrada de flujo de mensajes establezca las opciones de informes necesarias, o
de establecer usted mismo las opciones adecuadas en MQMD durante el proceso del mensaje en el flujo de
mensajes; por ejemplo, utilice un nodo Compute para establecer las opciones de informe en el mensaje.

El nodo MQReply se encuentra en la bandeja de WebSphere MQ de la paleta y está representado en el entorno de

trabajo con el siguiente icono:
Nodo MQGet

Utilice el nodo MQGet para recibir mensajes de clientes que se conecten al intermediario utilizando la WebSphere
MQ Enterprise Transport y las interfaces de programación de aplicaciones MQI y AMI.

También puede utilizar el nodo MQGet para recuperar mensajes que se hayan colocado anteriormente en una cola
de mensajes WebSphere MQ definida para el gestor de colas del intermediario.

mensajes de entrada

Un mensaje que entra en el terminal de entrada del nodo MQGet.

mensaje de cola

Un mensaje que el terminal MQGet lee de la cola.

Finalidad

El nodo MQGet lee un mensaje de una cola especificada y establece el entorno de proceso para el mensaje. Si es
adecuado, puede definir la cola de entrada como una cola compartida o una cola de clúster de WebSphere MQ.

Puede utilizar un nodo MQGet en cualquier parte de un flujo de mensajes, a diferencia de un nodo MQInput, que
sólo se puede utilizar como el primer nodo de un flujo de mensajes. El árbol de mensajes de salida de un nodo
MQGet se construye combinando el árbol de entrada con el árbol de resultados de la llamada MQGET. Puede
establecer las propiedades del nodo MQGet para controlar la forma en que se reciben los mensajes; por ejemplo,
puede indicar que un mensaje se debe procesar bajo el control de transacción o puede solicitar que, cuando se
esté creando el árbol de resultados, se realice la conversión de datos al recibir cada mensaje de entrada.

El nodo MQGet maneja los mensajes en los siguientes dominios de mensaje:

 MRM
 XMLNSC
 DataObject
 XMLNS
 JMSMap
 JMSStream
 MIME
 BLOB
 XML (este dominio ya no se utiliza; use XMLNSC)
 IDOC (este dominio ya no se utiliza; use MRM)

El nodo MQGet se encuentra en la bandeja de WebSphere MQ de la paleta y está representado en el entorno de

trabajo con el siguiente icono:
Nodo Publication

Utilice el nodo Publication para filtrar mensajes de salida de un flujo de mensajes y enviarlos a los suscriptores que
han indicado su interés en un conjunto específico de temas. El nodo Publication debe ser siempre un nodo de
salida de un flujo de mensajes y no tiene terminales de salida propios.

Finalidad

Utilice el nodo Publication si su flujo de mensajes da soporte a aplicaciones publicación/suscripción. Las

aplicaciones que esperan recibir publicaciones deben registrar una suscripción con un intermediario y pueden,
opcionalmente, calificar las publicaciones que obtienen proporcionando criterios restrictivos (como por ejemplo,
un tema de publicación específico).

El nodo Publication se encuentra en la bandeja Direccionamiento de la paleta y está representado en el entorno de

trabajo mediante el siguiente icono:

Nodo MQHeader

Utilice el nodo MQHeader para añadir, modificar o suprimir cabeceras MQMD (MQ Message Descriptor)y MQDLH
(MQ Dead Letter Header).

Finalidad

Puede añadir o suprimir toda la cabecera o puede cambiar únicamente los campos de una cabecera. Puede
establecer estos campos en un valor fijo o en un valor especificado mediante una expresión XPath para acceder a
un valor en uno de los árboles de mensajes. XPath se utiliza para proporcionar una ubicación válida desde la que se
puede copiar un valor para una propiedad. Por ejemplo la ubicación puede ser el cuerpo del mensaje, el árbol del
entorno local o una lista de excepciones.

El nodo MQHeader se encuentra en la bandeja de WebSphere MQ de la paleta y está representado en el entorno

de trabajo con el siguiente icono:

1.4 Implement a flow using JMS nodes

WebSphere Broker JMS Transport

WebSphere Broker JMS Transport es un servicio que conecta las aplicaciones que envían y reciben mensajes que
confirma al estándar JMS (Java Message Service).

Puede utilizar WebSphere Broker JMS Transport para dar soporte a las operaciones siguientes:
  Recibir un mensaje JMS como entrada.
 Crear un mensaje JMS para salida.
 Trabajar con flujos de mensajes que no esperan mensajes JMS.

Todos los mensajes JMS deben ajustarse a la Java Message Service Specification, versión 1.1.

Para utilizar WebSphere Broker JMS Transport, debe desplegar un flujo de mensajes que contenga como mínimo
uno de dos nodos incorporados, el nodo JMSInput y el nodo JMSOutput, que dan soporte al intercambio de
mensajes JMS. Puede crear flujos de mensajes para recibir mensajes de destinos JMS y enviar mensajes a destinos
JMS. A estos destinos se accede mediante una conexión con un proveedor JMS. Al enviar y recibir mensajes, los
nodos JMS se comportan como clientes JMS.

También puede utilizar dos nodos de transformación, el nodo JMSMQTransform y el nodo MQJMSTransform, con
los nodos JMSInput y JMSOutput, de modo que puedan interactuar con nodos que esperan que un mensaje
propagado contenga una cabecera MQMD (y MQRFH2).

 El nodo JMSMQTransform toma la salida del nodo JMSInput y produce un mensaje que el nodo
MQOutput puede manejar.
 El nodo transforma un mensaje MQJMSTransform con una cabecera MQMD (y una MQRFH2 opcional)) en
un mensaje esperado por el nodo JMSOutput.

Si desea cambiar o añadir contenido a las cabeceras en mensajes JMS, puede incluir un nodo JMSHeader en el flujo
de mensajes para modificar campos sin programación.

 Nodo JMSInput
 Nodo JMSOutput
 Nodo JMSMQTransform
 Nodo MQJMSTransform
 Nodo JMSHeader

Nodo JMSInput

Utilice el nodo JMSInput para recibir mensajes de destinos JMS. A los destinos JMS se accede mediante una
conexión a un proveedor JMS.

Finalidad

El nodo JMSInput actúa como consumidor de mensajes JMS y puede recibir los seis tipos de mensajes definidos en
Java Message Service Specification, versión 1.1. Los mensajes se reciben utilizando llamadas de método, que se
describen en la especificación JMS.

El nodo JMSInput se encuentra en la bandeja JMS de la paleta y está representado en el entorno de trabajo
mediante el siguiente icono:

Utilización del nodo JMSInput en un flujo de mensajes

El nodo JMSInput recibe y propaga mensajes con un árbol de mensajes JMS. Puede establecer las propiedades del
nodo JMSInput para controlar el modo en que se reciben los mensajes JMS.

El nodo JMSInput maneja mensajes en los siguientes dominios de mensajes:

 BLOB
 XMLNSC
 XMLNS
 MRM
 JMSMap
 JMSStream
 MIME
 XML (este dominio ya no se utiliza; use XMLNSC)

Los flujos de mensajes que manejan los mensajes que se reciben de las conexiones a proveedores JMS, deben
empezar siempre con un nodo JMSInput. Si incluye un nodo de salida en un flujo de mensajes que empieza con un
nodo JMSInput, éste puede ser cualquiera de los nodos de salida soportados (incluidos los nodos de salida
definidos por el usuario); no es necesario que incluya un nodo JMSOutput. No obstante, si no incluye un nodo
JMSOutput, debe incluir el nodo JMSMQTransform para transformar el mensaje al formato que espera el nodo de
salida.

Nodo JMSOutput

Utilice el nodo JMSOutput para enviar mensajes a destinos JMS.

Finalidad

El nodo JMSOutput actúa como productor de mensajes JMS publicar los seis tipos de mensajes definidos en Java
Message Service Specification, versión 1.1. Los mensajes se publican utilizando llamadas de método, que se
describen en la especificación JMS.

El nodo JMSOutput se encuentra en la bandeja JMS de la paleta y está representado en el entorno de trabajo
mediante el siguiente icono:

Utilización del nodo JMSOutput en un flujo de mensajes

Los flujos de mensajes que manejan los mensajes que se reciben de las conexiones a proveedores JMS, deben
empezar siempre con un nodo JMSInput. Si incluye el nodo JMSOutput en un flujo de mensajes, no será necesario
que incluya un nodo JMSInput: pero si no incluye un nodo JMSInput, deberá incluir el nodo MQJMSTransform para
dar al mensaje el formato que espera el nodo JMSOutput.

Si está propagando mensajes JMS y creando un flujo de mensajes para utilizarlo como un subflujo, utilice una
instancia del nodo JMSOutput como último nodo para crear un terminal de salida para el subflujo.
Nodo JMSMQTransform

Utilice el nodo JMSMQTransform para transformar un mensaje con un árbol de mensajes en un mensaje que tiene
una estructura de árbol de mensajes que es compatible con el formato de mensajes producidos por el proveedor
JMS de WebSphere MQ.

Finalidad

Puede utilizar el nodo JMSMQTransform para enviar mensajes a flujos de mensajes existentes y para trabajar con
JMS de WebSphere MQ y WebSphere Message Broker publicación/suscripción.

El nodo JMSMQTransform maneja los mensajes en todo los dominios de mensajes soportados.

El nodo JMSMQTransform se encuentra en la bandeja JMS de la paleta y está representado en el entorno de

trabajo mediante el siguiente icono:

Nodo MQJMSTransform

Use el nodo MQJMSTransform para recibir mensajes que tengan un formato de árbol de mensajes del proveedor
de JMS de WebSphere MQ y darles un formato que sea compatible con los mensajes que hayan de enviarse a
destinos JMS.

Finalidad

Utilice el nodo MQJMSTransform para enviar mensajes a flujos de mensajes y para interoperar con JMS de
WebSphere MQ y WebSphere Message Broker publicación/suscripción.

El nodo JMSMQTransform maneja los mensajes en todo los dominios de mensajes soportados.

El nodo MQJMSTransform se encuentra en la bandeja JMS de la paleta y está representado en el entorno de

trabajo mediante el siguiente icono:

Nodo JMSHeader

Utilice el nodo JMSHeader para modificar el contenido de las propiedades de Aplicación y Valores_cabecera_JMS
de forma que pueda controlar la salida del nodo sin programación.

Finalidad

Utilice el nodo para controlar la salida de un nodo JMSOutput. En la cabecera JMS se puede modificar un
subconjunto de valores comunes y se pueden añadir, modificar o suprimir las propiedades de la aplicación
seleccionadas por el usuario.
Para las propiedades de Valores_cabecera de JMS, el nodo proporciona un conjunto de campos que puede
modificar utilizando valores predefinidos, valores definidos por el usuario o expresiones XPath. XPath se utiliza
para proporcionar una ubicación válida desde la que se puede copiar un valor para una propiedad. Por ejemplo la
ubicación puede ser el cuerpo del mensaje, el árbol del entorno local o una lista de excepciones.

Para las propiedades de las aplicaciones JMS, el nodo proporciona un modo de añadir, modificar y suprimir los
pares de nombre y valor de las propiedades de la aplicación.

El nodo JMSHeader se encuentra en la bandeja JMS de la paleta y está representado en el entorno de trabajo
mediante el siguiente icono:

1.5 Implement a flow using Web Services (including SOAP, HTTP, WS-Security,
and WS-Addressing).

WebSphere Broker HTTP Transport

El El transporte HTTP conecta aplicaciones mediante protocolo HTTP. Los flujos de mensajes
utilizan nodos HTTPInput, HTTPReply y HTTPRequest para acceder al transporte HTTP.

Puede configurar los flujos de mensajes que incluyen los nodos HTTPInput, HTTPReply y HTTPRequest para poder
acceder al transporte HTTP para trabajar con los siguientes recursos:

 Servicios web basados en SOAP

 Otros estándares de servicios web, tales como REST o XML-RPC
 Mensajería HTTP general, en la que la carga útil puede ser o no XML

Los nodos HTTP pueden procesar mensajes no seguros (HTTP) y mensajes seguros (HTTPS o HTTP a través de SSL).
Para los servicios web basados en SOAP, existen varias ventajas si utiliza los nodos SOAP y el dominio de mensajes
SOAP en lugar de los nodos de transporte HTTP y el dominio de mensajes XMLNSC.

 Soporte de WS-Addressing, WS-Security y cabeceras SOAP.

 Un formato de árbol lógico SOAP común, independiente del formato de la corriente de bits.
 Comprobación en tiempo de ejecución con WSDL.
 Proceso de SOAP automático con adjuntos (SwA).
 Proceso automático de MTOM (Message Transmission Optimization Mechanism).

Aunque los nodos HTTP pueden procesar mensajes SwA, debe utilizar el dominio de mensajes MIME y diseñar el
flujo para manejar los adjuntos de forma explícita, y utilizar lógica personalizada para extraer y analizar SOAP.

Si incluye un nodo HTTPInput en un flujo de mensajes, debe incluir un nodo HTTPReply en el

mismo flujo de mensajes o en otro distinto para enviar una respuesta al cliente.
Nodo HTTPInput

Utilice el nodo HTTPInput para recibir un mensaje HTTP procedente de un cliente HTTP para
que lo procese un flujo de mensajes.

Finalidad
Si utiliza el nodo HTTPInput con los nodos HTTPReply y HTTPRequest, el intermediario puede
actuar como intermediario para los servicios web y las peticiones de servicios web se pueden
transformar y direccionar del mismo modo que otros formatos de mensajes que están
soportados por WebSphere Message Broker.

Las peticiones de servicio web se pueden recibir en formato HTTP (1.0 o 1.1) estándar o en
formato HTTP sobre SSL (HTTPS). Para obtener más información sobre servicios web, consulte
Cómo trabajar con servicios web.

El nodo HTTPInput da soporte a HTTP POST y HTTP GET. Para obtener más información sobre la
habilitación de HTTP GET, consulte Nodo HTTPRequest.

Si los flujos de mensajes procesan mensajes SOAP, utilice los nodos SOAP de preferencia al
nodo HTTPInput para beneficiarse de las funciones mejoradas, incluidas WS-Addressin y WS-
Security.

El nodo HTTPInput maneja mensajes en los siguientes dominios de mensajes:

 MRM
 XMLNSC
 XMLNS
 MIME
 BLOB
 XML (este dominio ya no se utiliza; use XMLNSC)

Los mensajes HTTP nunca son persistentes y no tienen ningún orden asociado.

Los mensajes HTTP no son transaccionales. Sin embargo, si el flujo de mensajes interactúa con
una base de datos u otro recurso externo como, por ejemplo, una cola de WebSphere MQ,
estas interacciones se realizan en una transacción. El nodo HTTPInput proporciona
confirmación o restitución, según cómo haya finalizado el flujo de mensajes y cómo esté
configurado para el manejo de errores (por ejemplo, cómo estén conectados los terminales de
anomalías). Si este nodo restituye el flujo de mensajes, se genera un mensaje de error que se
devuelve al cliente. El formato del error se define mediante la propiedad Formato de error.

Si se produce una excepción en sentido descendente del flujo de mensajes y ésta no se emite
sino que se devuelve a este nodo, el nodo crea una respuesta de error para el cliente. Este error
se obtiene de la excepción y el formato del error se define mediante la propiedad Formato de
error.

Si incluye un nodo de salida en un flujo de mensajes que empieza con un nodo HTTPInput, el
nodo de salida puede ser cualquiera de los nodos de salida soportados (incluidos los nodos de
salida definidos por el usuario). Puede crear un flujo de mensajes que reciba mensajes de
clientes de servicio web y genere mensajes para clientes que utilicen todos los transportes
soportados para conectar con el intermediario. Puede configurar el flujo de mensajes para que
solicite al intermediario que proporcione cualquier conversión que sea necesaria.

Si crea un flujo de mensajes para utilizarlo como subflujo, no puede utilizar un nodo de entrada
estándar; debe utilizar un nodo Input como el primer nodo, para crear un terminal de entrada
para el subflujo.

El nodo HTTPInput se encuentra en el cajón HTTP de la paleta y está representado en el

entorno de trabajo mediante el siguiente icono:

Nodo HTTPReply

Utilice el nodo HTTPReply parar devolver una respuesta a un cliente HTTP desde el flujo de
mensajes. Este nodo genera la respuesta a un cliente HTTP desde el que el nodo HTTPInput ha
recibido un mensaje de entrada y espera la confirmación de que se ha enviado.

Finalidad
El nodo HTTPReply puede utilizarse en un flujo de mensajes que envía una respuesta a un
mensaje de entrada HTTP o HTTPS. El ejemplo más común de este escenario es un flujo de
mensajes que implementa un servicio web.

Dado que todos los mensajes HTTP se gestionan mediante un único escucha de intermediario,
debe desplegar el flujo que incluye el nodo HTTPReply en el mismo intermediario. El grupo de
ejecución no es significativo, porque el escucha se comparte.

El nodo HTTPReply crea un mensaje de respuesta para el cliente de servicio web desde el árbol
de mensajes de entrada completo y lo devuelve al peticionario. Si el mensaje se ha recibido
inicialmente en un nodo HTTPInput de otro flujo de mensajes, la respuesta se asocia con la
respuesta mediante un identificador de solicitud que el nodo HTTPInput almacena en el
entorno local del mensaje.
El nodo HTTPReply se encuentra en el cajón HTTP de la paleta y está representado en el
entorno de trabajo mediante el siguiente icono:

Nodo HTTPRequest

Utilice el nodo HTTPRequest para interactuar con un servicio web.

Finalidad
El nodo HTTPRequest interactúa con un servicio web utilizando todo o parte del mensaje de
entrada como la petición que se envía a ese servicio. También puede configurar el nodo para
crear un mensaje de salida a partir del contenido del mensaje de entrada, aumentado por el
contenido de la respuesta del servicio web, antes de propagar el mensaje a los siguientes nodos
del flujo de mensajes.

En función de la configuración, este nodo construye una petición HTTP o HTTP sobre SSL
(HTTPS) a partir del contenido especificado del mensaje de entrada, y envía esta petición al
servicio web. El nodo recibe la respuesta del servicio web y analiza la respuesta para incluirla en
el árbol de salida. El nodo genera cabeceras HTTP si su configuración las necesita.

Puede utilizar este nodo en un flujo de mensajes que contenga o no un nodo HTTPInput o
HTTPReply.

El nodo HTTPRequest maneja los mensajes en los siguientes dominios de mensaje:

 MRM
 XMLNSC
 XMLNS
 MIME
 BLOB
 XML (este dominio ya no se utiliza; use XMLNSC)

El nodo HTTPRequest se encuentra en el cajón HTTP de la paleta y está representado en el

entorno de trabajo mediante el siguiente icono:
WebSphere Message Broker y servicios web SOAP.

Una aplicación WebSphere Message Broker puede participar en un entorno de servicios web
como peticionario de servicios, como proveedor de servicios o los dos.

El dominio SOAP da soporte a estos formatos:

 Formatos de mensajes de servicios web comunes SOAP 1.1, SOAP 1.2, SOAP con datos adjuntos (SwA) y
MTOM.
 Formato de árbol lógico SOAP coherente, que es independiente del formato de mensaje exacto.
 Estándares WS-Addressing y WS-Security.

Se proporcionan los siguientes nodos para uso en el dominio SOAP:

 Nodo SOAPInput
 Nodo SOAPReply
 Nodo SOAPRequest
 Nodo SOAPAsyncRequest
 Nodo SOAPAsyncResponse
 Nodo SOAPEnvelope
 Nodo SOAPExtract

El soporte de servicios web se ajusta a los siguientes estándares abiertos:

 SOAP 1.1 y 1.2

 Mensajes SOAP con datos adjuntos
 MTOM
 HTTP 1.1
 WSDL 1.1
 WS-Addressing (sólo nuevo dominio SOAP)
 WS-Security (sólo nuevo dominio SOAP)

WSDL también se valida frente a WS-I Basic Profile Versión 1.1. La conformidad con las
directrices de esta especificación mejora la interoperatividad con otras aplicaciones.

Nodo SOAPInput

Utilice el nodo SOAPInput para procesar mensajes SOAP de cliente, de modo que el
intermediario opere como proveedor de servicios web SOAP.

Finalidad
El nodo SOAPInput suele utilizarse con el nodo SOAPReply, que puede incluirse en el mismo
flujo de mensajes, o en un flujo de mensajes distinto con el mismo grupo de ejecución.
Puede conectar un nodo SOAPReply al terminal de salida para manejar las respuestas
satisfactorias.

El nodo SOAPInput se encuentra en el cajón Servicios web de la paleta de nodos del flujo de
mensajes y se representa en el entorno de trabajo mediante el icono siguiente:

Nodo SOAPReply

Utilice el nodo SOAPReply para enviar mensajes SOAP del intermediario al cliente originario en
respuesta a un mensaje recibido por un nodo SOAPInput.

Finalidad
El nodo SOAPReply suele utilizarse con el nodo SOAPInput, que puede incluirse en el mismo
flujo de mensajes, o en un flujo de mensajes distinto con el mismo grupo de ejecución.

El nodo SOAPReply se encuentra en el cajón Servicios web de la paleta de nodos del flujo de
mensajes y se representa en el entorno de trabajo mediante el icono siguiente:

Nodo SOAPRequest

Utilice el nodo SOAPRequest para enviar una solicitud SOAP al servicio web remoto.

Finalidad
El nodo SOAPRequest es un nodo de solicitud y respuesta síncrono, que bloquea el proceso
después de enviar la solicitud hasta que se recibe la respuesta. Este nodo habilita el método
Keep-Alive HTTP 1.1 de forma predeterminada.

El nodo SOAPRequest se encuentra en el cajón Servicios web de la paleta de nodos del flujo de
mensajes y se representa en el entorno de trabajo mediante el icono siguiente:
Nodo SOAPAsyncRequest

Utilice el nodo SOAPAsyncRequest con el nodo SOAPAsyncResponse para construir un par de

flujos de mensajes que llamen a un servicio web de forma asíncrona.

Finalidad
El nodo SOAPAsyncRequest envía una solicitud de servicio web, pero el nodo no espera a que
se reciba la respuesta de servicio web asociada. Esta funcionalidad asíncrona permite realizar
varias solicitudes de salida casi en paralelo, ya que la solicitud de salida no se bloquea en espera
de la respuesta. Sin embargo, cuando se utiliza el transporte HTTP, el nodo SOAPAsyncRequest
espera el acuse de recibo HTTP 202 antes de continuar con el flujo de mensajes, y el nodo
SOAPAsyncRequest se bloquea si no se recibe el acuse de recibo. El nodo SOAPAsyncResponse,
que puede estar en un flujo de mensajes separado, recibe la respuesta del servicio web. Los
nodos se utilizan como par, y correlacionan las respuestas con las solicitudes originales.

El nodo SOAPAsyncRequest es la primera mitad del par de nodos de solicitud y respuesta

asíncronos. El nodo SOAPAsyncRequest llama a un servicio web remoto basado en SOAP. La
solicitud la envía el nodo SOAPAsyncRequest, pero el nodo SOAPAsyncRequest no recibe la
respuesta. La respuesta la recibe un nodo SOAPAsyncResponse que se ejecuta en una hebra
diferente. El nodo SOAPAsyncResponse suele encontrarse al principio de un flujo de mensajes
diferente; no obstante, debe encontrarse en el mismo grupo de ejecución que el nodo
SOAPAsyncRequest.
El nodo SOAPAsyncRequest está basado en WSDL, de una forma parecida al nodo
SOAPRequest.

El nodo SOAPAsyncRequest se encuentra en el cajón Servicios web de la paleta y se representa

en el entorno de trabajo mediante el icono siguiente:

Nodo SOAPAsyncResponse

Utilice el nodo SOAPAsyncResponse conjuntamente con el nodo SOAPAsyncRequest para

construir un par de flujos de mensajes que llamen a un servicio web de forma asíncrona.

Finalidad
El nodo SOAPAsyncRequest envía una solicitud de servicio web, pero el nodo no espera a que
se reciba la respuesta de servicio web asociada. Sin embargo, el nodo SOAPAsyncRequest
espera el acuse de recibo de HTTP 202 antes de continuar con el flujo de mensajes y el nodo
SOAPAsyncRequest se bloquea si no se recibe el acuse de recibo. El nodo SOAPAsyncResponse,
que puede estar en un flujo de mensajes separado, recibe la respuesta del servicio web. Los
nodos se utilizan como par, y correlacionan las respuestas con las solicitudes originales.
El analizador SOAP invoca el analizador XMLNSC para que analice el contenido XML del servicio
web SOAP, y valide el cuerpo XML del servicio web SOAP. Las opciones del analizador SOAP se
pasan al analizador XMLNSC. Para obtener más información, consulte Manipular mensajes en el
dominio XMLNSC.

El nodo SOAPAsyncResponse se encuentra en el cajón Servicios web de la paleta y se

representa en el entorno de trabajo mediante el siguiente icono:

Utilización de este nodo en un flujo de mensajes

La configuración del nodo SOAPAsyncResponse no está basada en WSDL, aunque la lista de
'Cabeceras debe reconocer' configurada en el nodo SOAPAsyncRequest correspondiente es
aplicable al nodo SOAPAsyncResponse.

La mayoría de las opciones de configuración para este nodo se establecen en el nodo

SOAPAsyncRequest emparejado, incluidas las propiedades Destino de restitución y Umbral de
restituciones. No se envía ningún error SOAP cuando se alcanza el umbral de restituciones.

Puede recuperar los datos de contexto que haya almacenado el nodo SOAPAsyncRequest desde
la ubicación siguiente, en el entorno local:

LocalEnvironment.SOAP.Response.UserContext

Nodo SOAPEnvelope

Utilice el nodo SOAPEnvelope para añadir un sobre SOAP a un mensaje existente. Este nodo se
ha diseñado para utilizarse con el nodo SOAPExtract.

Finalidad
El comportamiento predeterminado del nodo SOAPEnvelope es asociar el sobre SOAP a una
ubicación estándar ($LocalEnvironment/SOAP/Envelope) en el árbol del entorno local. Puede
especificar una ubicación explícita utilizando una expresión XPath.

También puede utilizar el nodo en un flujo sin un nodo SOAPExtract correspondiente. El nodo
tiene una opción para crear un sobre SOAP predeterminado.

El nodo SOAPEnvelope se encuentra en el cajón Servicios web de la paleta y se representa en el

entorno de trabajo mediante el siguiente icono:
Nodo SOAPExtract

Utilice el nodo SOAPExtract para eliminar los sobres SOAP, permitiendo tan sólo que se procese
el cuerpo de un mensaje SOAP. También puede direccionar un mensaje SOAP basándose en su
nombre de operación. Las dos funciones son opcionales. Están contenidas en un nodo porque
generalmente se utilizan conjuntamente.

Finalidad
El nodo SOAPExtract puede realizar dos funciones:

Función Extract
El comportamiento predeterminado es separar el sobre SOAP en una ubicación estándar
($LocalEnvironment/SOAP/Envelope) del árbol LocalEnvironment. Alternativamente,
puede especificar una ubicación explícita mediante una expresión XPath. Cualquier
sobre SOAP que exista en la ubicación seleccionada se sustituirá.
Función Direccionamiento
El mensaje SOAP se direcciona a un nodo Label dentro del flujo de mensajes como
identifica la operación SOAP contenida en el mensaje. La operación SOAP se identifica
dentro del código del cuerpo SOAP.

Asegúrese de que las opciones del analizador de mensajes de la carpeta de propiedades del
mensaje de salida se hayan configurado correctamente para analizar el mensaje, copiando el
conjunto de mensajes y el formato de mensaje del mensaje de entrada. El tipo de mensaje se
deriva del primer hijo del cuerpo del mensaje del sobre SOAP.

Sólo se da soporte a un único hijo del cuerpo del mensaje SOAP.

El nodo SOAPExtract está contenido en el cajón de la paleta de Servicios web y se representa en

el área de trabajo mediante el icono siguiente:

WS-Addressing con los nodos SOAPAsyncRequest y SOAPAsyncResponse

El servicio web remoto debe comprender WS-Addressing para poder trabajar con nodos
SOAPAsyncRequest y SOAPAsyncResponse.
Los nodos SOAPAsyncRequest y SOAPAsyncResponse requieren WS-Addressing; por
consiguiente, el servicio web remoto debe comprender WS-Addressing para procesar las
cabeceras WS-Addressing que se envían desde del nodo SOAPAsyncRequest, y para permitir
que la respuesta se envíe al nodo SOAPAsyncResponse correspondiente, que se especifica en la
propiedad address de MAP (Message Addressing Property) ReplyTo.

Nodo SOAPAsyncRequest
El nodo SOAPAsyncRequest tiene una propiedad denominada Utilizar WS-Addressing que es de
sólo lectura y cuyo valor predeterminado es true, lo que indica que WS-Addressing es
obligatorio para este nodo. El efecto de esta propiedad es que activa WS-Addressing de forma
permanente para este nodo y no puede modificarla el nodo ni el WSDL que se utiliza para
configurar este nodo.

Nodo SOAPAsyncResponse
Después de recibir la respuesta a la solicitud, el nodo SOAPAsyncResponse puede eliminar
todas las cabeceras WS-Addressing del mensaje de respuesta y colocarlas en la carpeta
SOAP.Response.WSA para que pueda consultar las cabeceras, si selecciona la propiedad de
nodo Colocar cabeceras WS-Addressing en el entorno local.

1.6 Implement a flow using WebSphere Adapters nodes

Nodo SAPInput

Utilice el nodo SAPInput para aceptar entrada de una aplicación SAP.

Finalidad
Utilice el nodo SAPInput para aceptar entrada de aplicaciones SAP. Por ejemplo, el nodo
SAPInput puede supervisar un sistema SAP para nuevos pedidos de compra. Cuando se produce
un nuevo pedido de compra, el nodo SAPInput genera un árbol de mensaje que representa el
objeto de negocio con los nuevos detalles del pedido de compra. El árbol de mensaje se
propaga al terminal de salida para que el resto del flujo de mensajes pueda utilizar los datos
para actualizar otros sistemas o para auditar los cambios.

El nodo SAPInput se representa en la bandeja WebSphere Adapters de la paleta de nodos de

flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:
Nodo SAPRequest

Utilice el nodo SAPRequest para enviar solicitudes a una aplicación SAP.

Finalidad
Utilice el nodo SAPRequest para enviar solicitudes a aplicaciones SAP. Por ejemplo, el nodo
SAPRequest puede solicitar información de un Sistema de información de empresa (EIS) de SAP.
Se envía un cliente objeto de negocio a SAP, lo que hace que SAP recupere información sobre
un cliente, como un detalles de cuenta y dirección. La información de respuesta que recupera el
nodo SAPRequest se podrá utilizar por el resto del flujo de mensajes. El nodo SAPRequest
puede enviar y recibir datos empresariales.

El nodo SAPRequest se representa en la bandeja WebSphere Adapters de la paleta de nodos de

flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:

Nodo SiebelInput

Utilice el nodo SiebelInput para interactuar con una aplicación Siebel.

Finalidad
Utilice el nodo SiebelInput para interactuar con aplicaciones Siebel. Por ejemplo, un nodo
SiebelInput supervisa un sistema Siebel para un suceso específico. Cuando se produce ese
suceso, el nodo SiebelInput genera un árbol de mensajes que representa el objeto de negocio
con los nuevos detalles de sucesos. El árbol de mensajes se propaga al terminal de salida para
que el resto del flujo de mensajes pueda utilizar los datos para actualizar otros sistemas o para
auditar los cambios.

El nodo SiebelInput se representa en la bandeja WebSphere Adapters de la paleta de nodos de

flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:
Nodo SiebelRequest

Utilice el nodo SiebelRequest para interactuar con una aplicación Siebel.

Finalidad
Utilice el nodo SiebelRequest para interactuar con aplicaciones Siebel. Por ejemplo, un nodo
SiebelRequest solicita información desde un Sistema de información de empresa (EIS) de Siebel.
Se envía un cliente objeto de negocio a Siebel, lo que hace que Siebel recupere información
sobre un cliente, como un detalles de cuenta y dirección. La información de respuesta que
recupera el nodo SiebelRequest se podrá utilizar por el resto del flujo de mensajes. El nodo
SiebelRequest puede enviar y recibir datos empresariales.

El nodo SiebelRequest se representa en la bandeja Adaptadores WebSphere de la paleta de

nodos de flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:

Nodo PeopleSoftInput

Utilice el nodo PeopleSoftInput para interactuar con una aplicación PeopleSoft.

Finalidad
Utilice el nodo PeopleSoftInput para interactuar con aplicaciones PeopleSoft. Por ejemplo, un
nodo PeopleSoftInput supervisa un sistema PeopleSoft para un suceso específico. Cuando se
produce ese suceso, el nodo PeopleSoftInput genera un árbol de mensajes que representa el
objeto de negocio con los nuevos detalles de sucesos. El árbol de mensajes se propaga al
terminal de salida para que el resto del flujo de mensajes pueda utilizar los datos para
actualizar otros sistemas o para auditar los cambios.

El nodo PeopleSoftInput se representa en la bandeja WebSphere Adapters de la paleta de

nodos de flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:

Nodo PeopleSoftRequest

Utilice el nodo PeopleSoftRequest para interactuar con una aplicación PeopleSoft.

Finalidad
Utilice el nodo PeopleSoftRequest para interactuar con aplicaciones PeopleSoft. Por ejemplo,
un nodo PeopleSoftRequest solicita información desde un Sistema de información de empresa
(EIS) de Siebel. Se envía un cliente objeto de negocio a PeopleSoft, lo que hace que PeopleSoft
recupere información sobre un cliente, como un detalles de cuenta y dirección. La información
de respuesta que recupera el nodo PeopleSoftRequest se podrá utilizar por el resto del flujo de
mensajes. El nodo PeopleSoftRequest puede enviar y recibir datos empresariales.

El nodo PeopleSoftRequest se representa en la bandeja Adaptadores WebSphere de la paleta

de nodos de flujos de mensajes, y se representa en el entorno de trabajo con el siguiente icono:

1.7 Implement a flow using File nodes

Cómo trabajar con archivos

Puede utilizar el nodo FileInput en los flujos de mensajes para procesar datos de archivos.
Puede utilizar el nodo FileOutput para enviar datos de un flujo de mensaje a un archivo.

La utilización de archivos es uno de los métodos más comunes de almacenar datos. Puede crear flujos de mensajes
para procesar datos de archivos, aceptar datos de archivos como datos de mensajes de entrada y producir datos
de mensajes de salida para destinos basados en archivos. Se proporcionan los siguientes nodos de archivo:

 Nodo FileInput. Utilice este nodo para recibir mensajes de archivos en el sistema de archivos del
intermediario o, utilizando FTP o SFTP, en un sistema de archivos remoto. El nodo genera datos de
mensajes de salida que puede utilizar cualquiera de los nodos de salida, lo que significa que se pueden
generar mensajes para clientes utilizando cualquiera de los protocolos de transporte soportados para
conectar con el intermediario.
Section 2 - Flow Development (30%)
2.1 Select appropriate built-in nodes based upon requirements

Basicamente existen varios tipos de nodos:

 Nodos de entrada
 Nodos de salida
 Nodos de solicitud
 Nodos para transformar mensajes
 Nodos para la toma de decisiones
 Nodos para controlar operaciones sensibles al tiempo
 Nodos varios

Nodos de entrada
Debe incluir al menos un nodo de entrada en el flujo de mensajes.

Un nodo de entrada es diferente de otros nodos, ya que controla cuando el resto del flujo de
mensajes se desencadena para realizar su proceso. El nodo de entrada está diseñado para
comprobar si existen datos para que el flujo de mensajes los procese, lea esos datos del
transporte o el servidor y presente dichos datos al resto del flujo para su proceso. Los otros
nodos realizan proceso pero no controlan cuándo se invoca el flujo.

Nodo FileInput
Utilice un nodo FileInput si los mensajes son contenido de archivos.
Nodo de entrada HTTP
Utilice un nodo HTTPInput si los mensajes los envía un cliente de servicios web.
Nodo Input
Si está creando un flujo de mensajes que desea incluir en otro flujo de mensajes (un subflujo) que no va a
desplegar flujo de mensajes autónomo, debe incluir, como mínimo, un nodo Input que reciba los
mensajes en el subflujo.

Una instancia del nodo Input representa un terminal In (de entrada). Por ejemplo, si ha
incluido una instancia del nodo Input, el icono de subflujo muestra un terminal de
entrada que se puede conectar a otros nodos del flujo principal del mismo modo que se
conecta cualquier otro nodo.

Nodo JMSInput
Utilice un nodo JMSInput si los mensajes se envían mediante una aplicación JMS.
Nodo MQInput
Utilice un nodo MQInput si los mensajes llegan al intermediario en una cola de WebSphere MQ y el nodo
ha de estar al principio de un flujo de mensajes.
Nodo Real-timeInput o Real-timeOptimizedFlow
Utilice uno de estos nodos si los mensajes los envía una aplicación JMS o de multidifusión.

El nodo Real-timeInput es un nodo de entrada; el nodo Real-timeOptimizedFlow es un

flujo de mensajes completo que proporciona un flujo de mensajes
publicación/suscripción de alto rendimiento que recibe y envía a aplicaciones JMS o de
multidifusión.

Nodo SCADAInput
utilice un nodo SCADAInput si los mensajes los envía un dispositivo de telemetría.
Nodo de entrada SOAP
Utilice el nodo SOAPInput para procesar mensajes SOAP de cliente y para configurar el flujo de mensajes
para que se comporte como un proveedor de servicios web SOAP.
Nodo TCPIPClientInput o TCPIPServerInput
Utilice un nodo TCPIPClientInput o un nodo TCPIPServerInput para crear una conexión TCP/IP cuando se
envíen mensajes a través de sockets TCP/IP puros.
Nodo TCPIPClientReceive o TCPIPServerReceive
Utilice un nodo TCPIPClientReceive o un nodo TCPIPServerReceive para leer los mensajes que lleguen al
flujo de mensajes a través de la conexión TCP/IP.
Nodo de entrada definido por el usuario
Utilice un nodo de entrada definido por el usuario si el origen de mensajes es un cliente o una aplicación
que utiliza un transporte o protocolo distinto.
Nodos de WebSphere Adapters
Utilice los nodos de WebSphere Adapters para interactuar con Sistemas de información de empresa (EIS),
como por ejemplo SAP, Siebel y PeopleSoft. Están disponibles los siguientes nodos de entrada:

 Nodo SAPInput
 Nodo SiebelInput
 Nodo PeopleSoftInput
 Nodo TwineballInput

Nodos de salida

Si desea enviar los mensajes generados por el flujo de mensajes a una aplicación de destino,
incluya uno o más nodos de salida en el flujo.

Nodo EmailOutput
Utilice el nodo EmailOutput para enviar un mensaje de correo electrónico a uno o más destinatarios.
Nodo FileOutput
Utilice un nodo FileOutput si el destino de los mensajes de salida es un archivo.
Nodo HTTPReply
Utilice un nodo HTTPReply si los mensajes son en respuesta a una solicitud de cliente de servicios web.
Nodos JMSOutput y JMSReply
Utilice un nodo JMSOutput si los mensajes son para un destino JMS.
El nodo JMSReply tiene una función similar a la del nodo JMSOutput, pero el nodo JMSReply sólo envía
mensajes JMS al destino de respuesta que se facilita en el campo de cabecera JMSReplyTo del árbol de
 mensaje JMS. Utilice el nodo JMSReply para tratar un mensaje JMS que se genera desde un flujo de
mensajes como respuesta a un mensaje de entrada JMS y cuando no tenga ningún otro requisito de
direccionamiento.
Nodos MQOutput y MQReply
Utilice un nodo MQOutput si la aplicación de destino espera recibir mensajes en una cola WebSphere MQ
o en la cola de respuestas de WebSphere MQ que se ha especificado en el MQMD del mensaje de
entrada.
Utilice un nodo MQReply si la aplicación de destino espera recibir mensajes en la cola de respuestas
WebSphere MQ especificada en el MQMD del mensaje de entrada.
Nodo Output
Si está creando un flujo de mensajes que desea incorporar en otro flujo de mensajes (un subflujo) que no
va a desplegar como flujo de mensajes autónomo, debe incluir un nodo Output, como mínimo, para
propagar mensajes a los nodos siguientes en el subflujo.
Nodo Publication
Utilice un nodo Publication para distribuir los mensajes utilizando la red de publicación/suscripción para
aplicaciones que se suscriben al intermediario a través de todos los protocolos soportados. Un nodo
Publication es un nodo de salida que usa destinos de salida que identifican los suscriptores cuyas
suscripciones coinciden con las características del mensaje actual.
Nodo SCADAOutput
Utilice un nodo SCADAOutput si el destino de los mensajes de salida es un dispositivo de telemetría y el
nodo Publication no es adecuado.
Nodo SOAPReply
Utilice un nodo SOAPReply si la aplicación de destino espera recibir mensajes SOAP como respuesta a un
mensaje enviado al nodo SOAPInput.
Nodo TCPIPClientOutput o TCPIPServerOutput
Utilice un nodo TCPIPClientOutput o un nodo TCPIPServerOutput si los mensajes se van a enviar a la
aplicación de destino a través de sockets TCP/IP puros.
Nodo de salida definido por el usuario
Utilice un nodo de salida definido por el usuario si el destino es un cliente o una aplicación que utiliza un
transporte o protocolo distinto.

Nodos de solicitud

Si desea realizar una solicitud, en medio del flujo, a un sistema externo, y colocar el resultado
en el árbol de mensaje, utilice un nodo de solicitud.

Nodo MQGet
Utilice un nodo MQGet para recuperar un mensaje de una cola de WebSphere MQ, si desea obtener el
mensaje más adelante en el flujo de mensajes.
Nodo HTTPRequest
Utilice un nodo HTTPRequest si el flujo de mensajes interactúa con un servicio web después de que se ha
iniciado.
Nodos de WebSphere Adapters
Utilice los nodos de WebSphere Adapters para interactuar con Sistemas de información de empresa (EIS),
como por ejemplo SAP, Siebel y PeopleSoft. Están disponibles los siguientes nodos de solicitud:

 Nodo SAPRequest
 Nodo SiebelRequest
 Nodo PeopleSoftRequest
  Nodo TwineballRequest

Nodos SOAP
Utilice los nodos SOAP para procesar mensajes SOAP de cliente y para configurar el flujo de mensajes para
que se comporte como un proveedor de servicios web SOAP:

 SOAPRequest
 SOAPAsyncRequest
 SOAPAsyncResponse

Nodos WebSphere Service Registry and Repository (WSRR)

Utilice los nodos WebSphere Service Registry and Repository para recuperar información de servicios
web:

 Utilice el nodo EndpointLookup para recuperar información de punto final de servicio que se
conserva en WebSphere Service Registry and Repository.
 Utilice el nodo RegistryLookup para recuperar cualquier tipo de entidad que se conserve en
WebSphere Service Registry and Repository.

Nodo IMSRequest
Utilice el nodo IMSRequest para enviar una solicitud para ejecutar una transacción en un sistema IBM®
Information Management System (IMS) local o remoto y espere una respuesta. IMS Connect debe
configurarse y ejecutarse en un sistema IMS.
Nodo Database
Utilice el nodo Database para interactuar con una base de datos identificada por las propiedades del
nodo. El nodo Database maneja mensajes predefinidos y autodefinidos. Utilice el editor ESQL para
codificar funciones ESQL para actualizar el contenido de la base de datos a partir del mensaje, insertar
nueva información en la base de datos y suprimir información de la base de datos, utilizando información
del mensaje. No utilice en ningún otro tipo de nodo el código ESQL que desarrolle para utilizarlo en un
nodo Database.

También tiene propiedades que puede utilizar para controlar la forma en que la
interacción participa en las transacciones.

Puede controlar la forma en que este nodo accede a la base de datos especificando la
información de usuario y contraseña para el origen de datos que especifique en las
propiedades del nodo. Utilice el mandato mqsisetdbparms para inicializar y mantener
estos valores.

Desde este nodo sólo puede actualizar bases de datos; no puede actualizar el contenido
de un mensaje. Si desea actualizar el contenido de un mensaje, utilice el nodo Compute
o Mapping.

Nodos DataDelete, DataInsert, DataUpdate

Los nodos DataDelete, DataInsert y DataUpdate son formas especializadas del nodo Database que
proporcionan un solo modo de interacción (supresión de una o más filas, inserción de una o más filas o
actualización de una o más filas existentes).
 Puede utilizar estos nodos para controlar las características transaccionales de las
actualizaciones que realizan.

Desde estos nodos sólo puede actualizar bases de datos; no puede actualizar el
contenido de los mensajes. Si desea actualizar el contenido de un mensaje, utilice el
nodo Compute o Mapping.

Nodo DatabaseRetrieve
Utilice el nodo DatabaseRetrieve para asegurarse de que la información de un mensaje está actualizada.
Utilice el nodo para modificar un mensaje utilizando información de la base de datos. Por ejemplo, puede
añadir información a un mensaje utilizando una clave, como un número de cuenta que esté contenida en
un mensaje. Utilice el nodo DatabaseRetrieve para implementar direccionamiento de mensajes con lógica
mínima de programación. Para obtener escenarios de direccionamiento más avanzados, utilice un nodo
Compute o un nodo JavaCompute.
Nodo Warehouse
El nodo Warehouse proporciona una interfaz de tienda que puede utilizar para almacenar el mensaje,
total o parcialmente, en una base de datos, por ejemplo, debido a una auditoría, El nodo Warehouse sólo
maneja mensajes predefinidos. Utilice el Editor de correlaciones para desarrollar correlaciones que
realicen esta acción. No utilice en ningún otro tipo de nodo las correlaciones que desarrolle para un nodo
Warehouse.

Desde este nodo sólo puede actualizar una base de datos; no puede actualizar el
contenido de un mensaje. Si desea actualizar el contenido de un mensaje, utilice el nodo
Compute o Mapping.

Nodos para la toma de decisiones

Opcionalmente, utilice nodos que determinen el orden y el flujo de control en el flujo de

mensajes de varias formas para tomar decisiones sobre cómo el flujo procesa los mensajes.

Nodo Validate
Utilice el nodo Validate para comprobar que el mensaje que llega al terminal de entrada es el esperado.
Puede comprobar si el mensaje tiene las propiedades de plantilla esperadas (es decir, el dominio de
mensajes, el conjunto de mensajes y el tipo de mensaje) y que el contenido del mensaje es correcto.
Puede comprobar el mensaje con uno o más dominios de mensajes, conjuntos de mensajes o tipos de
mensajes.

Nodo Filter
Utilice el nodo Filter con una sentencia ESQL para determinar el siguiente nodo al cual este nodo envía el
mensaje. No utilice en ningún otro tipo de nodo el código ESQL que desarrolle para utilizarlo en un nodo
Filter.

Los terminales del nodo son True (verdadero), False (falso), Unknown (desconocido) y
Failure (de anomalías); el mensaje se propaga al terminal verdadero si el resultado de la
prueba es satisfactorio y al terminal falso, si no lo es. Si no se puede resolver la
sentencia (por ejemplo, prueba el valor de un campo que no está en el mensaje de
entrada), el mensaje se propaga al terminal desconocido. Si se detecta cualquier otro
error, el mensaje se propaga al terminal de anomalías.

La prueba en la sentencia ESQL puede depender del contenido del mensaje, el

contenido de la base de datos o una combinación de ambos.

Utilice preferentemente este nodo en vez del nodo Compute para permitir la selección y
el direccionamiento de mensajes; el nodo Filter es más eficaz para esta tarea.

Nodo FlowOrder
Puede conectarse a los terminales de este nodo para forzar que el mensaje sea procesado por una
secuencia de nodos, seguido de una segunda secuencia de nodos.

Nodo Passthrough
Utilice el nodo Passthrough para habilitar el control de versiones de un subflujo en tiempo de ejecución.
Utilice este nodo para añadir una etiqueta al subflujo. Mediante la combinación de esta etiqueta con una
sustitución de palabras reservada de su sistema de control de versiones, puede identificar qué versión de
un subflujo está incluida en un flujo de mensajes desplegado. Puede utilizar esta etiqueta para fines
personales. Si ha incluido las palabras clave de versión correctas en la etiqueta, puede ver el valor de la
etiqueta:

 Almacenado en el archivo de archivado de intermediario (BAR), utilizando el mandato

mqsireadbar
 Tal como se desplegó por última vez en un intermediario específico, en las propiedades de un
flujo de mensajes desplegado en el entorno de trabajo
 En el intermediario, si habilita el rastreo de usuario para ese flujo de mensajes

Nodo Route
Utilice el nodo Route para dirigir mensajes que cumplan con determinados criterios por las distintas vías
de acceso de un flujo de mensajes. Por ejemplo, puede reenviar un mensaje a distintos proveedores de
servicio en función de los detalles de la solicitud. También puede utilizar el nodo Route para omitir pasos
innecesarios. Por ejemplo, puede comprobar si determinados datos están en un mensaje y realizar
únicamente una operación de búsqueda en una base de datos si faltan datos. Si establece la propiedad
Modalidad de distribución en Todas, podrá desencadenar varios sucesos que requieran, cada uno,
distintas condiciones. Por ejemplo, puede registrar las solicitudes relacionadas con un identificador de
cuenta determinado y enviar solicitudes relacionadas con un producto específico que requiera una
auditoría.

Utilice el nodo Route para implementar direccionamiento de mensajes con lógica

mínima de programación. Para obtener escenarios de direccionamiento más avanzados,
utilice un nodo Compute o un nodo JavaCompute.

Nodo RouteToLabel
Utilice el nodo RouteToLabel después de un nodo Compute para los direccionamientos complejos. En un
nodo Compute o JavaCompute, defina una lista de destinos sobres los que actúe el nodo RouteToLabel
que interroga sobre los destinos y pasa el mensaje al nodo Label correspondiente.

Nodo DatabaseRoute
Utilice el nodo DatabaseRoute para direccionar un mensaje utilizando información de una base de datos
junto con expresiones de direccionamiento de XPath aplicadas. El nodo busca una colección de valores de
 columna con nombre en una fila de una base de datos localizada y, de forma síncrona, aplica una o más
expresiones XPath a esos valores adquiridos. Utilice el nodo DatabaseRoute para implementar
direccionamiento de mensajes con lógica mínima de programación. Para obtener escenarios de
direccionamiento más avanzados, utilice un nodo Compute o un nodo JavaCompute.

Nodo Label
Utilice el nodo Label como destino para la siguiente secuencia de uno o más nodos que van a procesar un
mensaje. Utilice este nodo en combinación con el nodo RouteToLabel para todos los tipos de mensajes o
con el nodo SOAPExtract para mensajes SOAP.

El nodo Label solamente direcciona el mensaje al siguiente nodo en el flujo y no realiza

ningún proceso.

Nodo ResetContentDescriptor
Utilice el nodo ResetContentDescriptor para establecer nuevas propiedades de mensajes que se utilicen
cuando el siguiente nodo del flujo de mensajes analice la corriente de bits del mensaje.

Nodos para controlar operaciones sensibles al tiempo

Ejecute procesos en horas específicas, o a intervalos fijos, y tome medidas si las transacciones
no se completan en un tiempo definido.

Nodo TimeoutControl
Utilice conjuntamente un nodo TimeoutControl y un nodo TimeoutNotification en un flujo de mensajes
para controlar los sucesos que se producen a una hora específica o a intervalos de tiempo definidos. El
nodo TimeoutControl recibe un mensaje de entrada que contiene una solicitud de tiempo de espera
excedido. Todo o parte de este mensaje de entrada se valida y almacena para que lo propague un nodo
TimeoutNotification en el flujo de mensajes. El mensaje de entrada también se propaga sin modificarse al
siguiente nodo en el flujo de mensajes.

Se puede asociar más de un nodo TimeoutControl a cada nodo TimeoutNotification.

Nodo TimeoutNotification
Utilice un nodo TimeoutNotification autónomo para generar mensajes que se propaguen, a las horas o los
intervalos de tiempo configurados, al siguiente nodo del flujo de mensajes para ser procesados
posteriormente.

Nodos varios

Nodos para realizar diversas tareas.

Nodos para clasificar solicitudes

Utilice los nodos AggregateControl, AggregateReply y AggregateRequest para clasificar

las solicitudes y las respuestas correspondientes. Utilice estos nodos para generar varias
 solicitudes en respuesta a un mensaje de entrada, para controlar y coordinar las
respuestas que se reciben en respuesta a estas solicitudes, y para combinar la
información proporcionada por las respuestas para continuar el proceso.

Nodo para crear colecciones de mensajes

Utilice el nodo Collector para generar colecciones de mensajes y realizar varias

solicitudes síncronas o asíncronas en paralelo. El nodo Collector no necesita una fase de
abanico de salida inicial, y puede agrupar mensajes de entrada no relacionados
correlacionando su contenido. Puede configurar terminales de entrada dinámicos en un
nodo Collector para recibir mensajes de distintos orígenes. También se pueden
configurar propiedades en el nodo Collector, conocidas como manejadores de sucesos,
para determinar cómo se añaden mensajes a una colección de mensajes y cuando una
colección de mensajes se ha completado.

Nodos para manejar e informar de los errores

Utilice los nodos siguientes para manejar e informar de los errores:

Nodo Trace
Incluya un nodo Trace para generar una o más entradas de rastreo para registrar lo que sucede en ese
punto del flujo de mensajes.
Nodo TryCatch
Incluya un nodo TryCatch para controlar el proceso de los errores de proceso cuando se generan
excepciones.
Nodo Throw
Incluya un nodo Throw para forzar la generación de una excepción y especificar la identidad de la misma
con el fin de facilitar el diagnóstico del problema.

2.2 Implement a flow using transformation nodes (including ESQL, Java,

mapping)

ESQL

ESQL (Extended Structured Query Language) es un lenguaje de programación definido por

WebSphere Message Broker para definir y manipular datos en un flujo de mensajes.

ESQL está basado en el Lenguaje de consulta estructurado (SQL) que se utiliza comúnmente con
las bases de datos relacionales como DB2. ESQL amplía las construcciones del lenguaje SQL para
que pueda trabajar con el contenido de base de datos y mensajes para definir el
comportamiento de los nodos en un flujo de mensajes.
El código ESQL que cree para personalizar nodos en un flujo de mensajes se define en un
archivo ESQL, generalmente denominado <nombre_flujo_mensajes>.esql, que está asociado al
proyecto de flujo de mensajes. Puede utilizar ESQL en los siguientes nodos incorporados:

 Nodo Compute
 Nodo Database
 Nodo Filter

También puede utilizar ESQL para crear funciones y procedimientos que puede utilizar en los
siguientes nodos incorporados:

 Nodo DataDelete
 Nodo DataInsert
 Nodo DataUpdate
 Nodo Extract
 Nodo Mapping
 Nodo Warehouse

Desarrollo de Java

Cuando utilice el nodo JavaCompute, personalícelo para determinar el proceso exacto que
proporciona.

Para personalizar el comportamiento de cada nodo, debe crear un archivo de clase Javaque
proporcione el proceso que desea. Los archivos Java se gestionan a través de la perspectiva
Java.

Nodo JavaCompute

Utilice el nodo JavaCompute para trabajar con mensajes utilizando el lenguaje Java.

Finalidad
Utilizando este nodo, puede realizar las tareas siguientes:

 Utilice Java para examinar un mensaje de entrada y, en función del contenido, propagarlo a uno de los
dos terminales de salida del nodo; el nodo se comporta de un modo similar a un nodo Filter, pero utiliza
Java en lugar de ESQL para determinar qué terminal de salida utilizar.
 Utilice Java para cambiar parte de un mensaje de entrada y propagarlo al mensaje cambiado a uno de los
terminales de salida.
 Utilice Java para crear y compilar un mensaje de salida nuevo que sea totalmente independiente del
mensaje de entrada.

El código Java utilizado por el nodo se almacena en un proyecto Java de Eclipse.

El nodo JavaCompute se encuentra en la bandeja Transformación de la paleta y está
representado en el entorno de trabajo mediante el siguiente icono:

2.3 Implement a flow using routing nodes

SE hizo en el laboratorio..
2.4 Navigate the message tree based upon a message domain Commented [s1]: ???

2.5 Understand default errors processing Commented [s2]: ??

2.6 Develop message flows that publish or subscribe

El nodo publish se utiliza para las publicaciones de otras apliaciones.

Su especificación se coloco arriba
Al parecer las subscriciones empiezan cuando una persona o alguien se sucribe..
Sin embargo no parace haber ningún nodo de subcricion al parecer se hace mediante las colas o los tópicos a los
cuales una aplicación se subcribe..
SEgunla documentación el
El suscriptor envía una solicitud de suscripción a un intermediario, especificando las publicaciones que desea
recibir. La solicitud define el tema, el filtro y el punto de suscripción de cada publicación, y también especifica el
nombre de una cola a la que deben enviarse las publicaciones. Esta cola se conoce como cola de suscriptores.
Los mensajes publicados por un publicador pueden ser recibidos por más de un suscriptor, y un suscriptor puede
recibir mensajes, sobre el mismo tema u otros distintos, de más de un publicador.
2.7 Explain when it is necessary to implement a user defined extension (including
custom plugin node) and the high level components required to create one

Puede crear e implementar los siguientes tipos de extensión definida por el usuario:

 Nodos definidos por el usuario

 Analizadores definidos por el usuario
 Salidas definidas por el usuario

Los nodos, analizadores y salidas definidos por el usuario que cree pueden utilizarse con los
nodos y analizadores que se suministran con el producto, y con nodos y analizadores
suministrados por proveedores de software independientes.

Para escribir extensiones definidas por el usuario tiene que ser un programador experto, con conocimientos de
WebSphere Message Broker y su arquitectura, por lo tanto, asegúrese de que tiene la experiencia y los
conocimientos necesarios. También debe tener el tiempo necesario para probar y depurar el nodo o analizador
definido por el usuario, y un entorno seguro en el que llevarlo a cabo.

Una extensión definida por el usuario puede resultar apropiada en las situaciones siguientes:
  Cuando no pueda manipular los nodos o analizadores proporcionados para realizar la
función que necesita. Por ejemplo, es posible que desee conectarse con otro
componente de software del flujo de mensajes fuera de WebSphere MQ. Si no se
proporciona ningún nodo para hacerlo, debe crear su propio nodo.
 Cuando pueda mejorar el rendimiento, la facilidad de uso o la fiabilidad utilizando sus
propias extensiones definidas por usuario, en lugar de los nodos o analizadores
suministrados.
 Si las opciones disponibles no son las apropiadas para sus requisitos. Puede crear
extensiones definidas por el usuario para manejar formatos de mensaje comerciales
internos, específicos del cliente o genéricos.

2.8 Design for message affinity and scalability requirements Commented [s3]: ???

2.9 Implement a flow using service registry nodes. Commented [s4]: Ver manana

Ya estan arriba…
Section 3 - Message Modeling (23%)
3.1 Describe the different message domains supported by WebSphere Message
Broker (including SOAP, XMLNSC, MRM, MIME, JMS) including the limitations
of each

Analizadores del cuerpo del mensaje

WebSphere Message Broker proporciona soporte incorporado para mensajes en los dominios
de mensaje siguientes, proporcionando analizadores de cuerpo de mensaje:

 MRM (Analizador y dominio MRM)

 XMLNSC, XMLNS y XML (Analizadores y dominios XML)
 SOAP (Analizador y dominio SOAP)
 DataObject (Analizador y dominio DataObject)
 JMSMap y JMSStream (Analizadores y dominios JMS)
 MIME (Analizador y dominio MIME)
 BLOB (Analizador y dominio BLOB)
 IDOC (Analizador y dominio IDOC)

Analizador y dominio MRM

El dominio MRM se puede utilizar para analizar y escribir una amplia variedad de formatos de
mensajes. Primordialmente está ideado para los formatos de mensajes que no son XML pero
también puede analizar y escribir XML. Para obtener las directrices acerca de cuándo se debe
utilizar el analizador MRM, en lugar de uno de los analizadores XML, para analizar XML,
consulte la sección Qué analizador XML debe utilizar

Las características clave del dominio MRM son:

 Soporte para mensajes de aplicaciones que están escritos en C, COBOL, PL/I y otros lenguajes, utilizando
el formato físico CWF (Formato físico personalizado). Este soporte incluye la posibilidad de crear un
modelo de mensaje directamente desde un archivo de cabecera C o un libro de copias COBOL.
 Soporte para mensajes de texto, quizás con el contenido de campo que está identificado por los códigos,
separado por delimitadores específicos o ambos, utilizando el formato físico TDS (Serie codificada
delimitada). Esto incluye los estándares del sector, por ejemplo, CSV, HL7, SWIFT, EDIFACT y X12.
 Soporte para mensajes XML, incluidos aquellos que utilizan espacios de nombres XML, utilizando el
formato físico XML.
Analizadores y dominios XML

Puede utilizar dominios XML para analizar y grabar mensajes que cumplan el estándar XML de
W3C.

Dominio XMLNSC
El dominio XMLNSC es el dominio preferido para analizar todos los mensajes XML de finalidad general,
incluidos los mensajes que utilizan espacios de nombres XML. Éste es el analizador preferido por los
motivos siguientes:

 El analizador XMLNSC tiene una arquitectura que genera un rendimiento ultra rápido cuando se
analizan todos los tipos de XML.
 El analizador XMLNSC reduce la cantidad de memoria utilizada por el árbol de mensajes lógico
que se crea a partir del mensaje analizado. El comportamiento predeterminado del analizador es
descartar los espacios en blanco no significativos y el contenido mixto, los comentarios, las
instrucciones de proceso y las DTD incorporadas. No obstante, se proporcionan controles para
retener el contenido mixto, los comentarios y las instrucciones de proceso, si es necesario.
 El analizador XMLNSC puede funcionar como un analizador controlado por modelos y puede
validar mensajes XML para Esquemas XML generados desde un conjunto de mensajes, para
asegurarse de que los mensajes XML son correctos.

Dominio XMLNS
Si el dominio XMLNSC no cumple los requisitos, utilice el dominio que reconoce el espacio de nombres y
el analizador alternativos.
Dominio XML
El dominio XML no reconoce el espacio de nombres. Ha quedado obsoleto y no se debe utilizar para
desarrollar nuevos flujos de mensajes

Analizador y dominio SOAP

Puede utilizar el analizador SOAP para crear un formato de árbol lógico basado en WSDL común
para trabajar con los servicios web, independientemente del formato de corriente de bits física.

Analizador y dominio DataObject

Utilice el dominio DataObject para analizar y grabar mensajes para WebSphere Adapters.

El WebSphere Message Broker utiliza el analizador DataObject para leer y escribir mensajes de
Enterprise Information Systems (EIS) como, por ejemplo, PeopleSoft y Siebel. Los mensajes de
este tipo pertenecen al dominio DataObject.
Analizadores y dominios JMS

Los dominios JMSMap y JMSStream pueden utilizarse para modelar mensajes producidos por
las implementaciones del estándar Java Messaging Service.

Utilice el dominio JMSMap al manejar mensajes JMS de tipo MapMessage. Utilice el dominio
JMSStream al manejar mensajes JMS de tipo StreamMessage.

Analizador y dominio MIME

Utilice el dominio MIME si los mensajes utilizan el estándar MIME para mensajes de varias
partes.

El analizador MIME (Multipurpose Internet Mail Extension) no da soporte al estándar MIME

completo aunque sí da soporte a los usos comunes de MIME. Puede enviar los mensajes al
intermediario a través de HTTP o de otros tipos de transporte, como por ejemplo WebSphere
MQ. Utilice el dominio MIME si los mensajes utilizan el estándar MIME para mensajes de varias
partes.

El dominio MIME no da soporte a los valores Content-Type con tipo de soporte de mensaje.

Analizador y dominio BLOB

El dominio de mensajes BLOB incluye todos los mensajes con contenido que no se pueden
interpretar y subdividir en secciones más pequeñas de información.

Los mensajes en este dominio los procesa el analizador BLOB. El analizador BLOB es un
programa que interpreta un árbol de mensaje o una corriente de bits que representa un
mensaje que pertenece al dominio BLOB. El analizador genera el árbol correspondiente a partir
de la corriente de bits en la entrada o la corriente de bits a partir del árbol, en la salida.

Un mensaje BLOB se maneja como una sola serie de bytes y, aunque se puede manipular, no se
pueden identificar secciones específicas de la serie de bytes utilizando ninguna referencia, a
diferencia de otros dominios en los que se pueden modificar los mensajes.

Analizador y dominio BLOB

El dominio de mensajes BLOB incluye todos los mensajes con contenido que no se pueden
interpretar y subdividir en secciones más pequeñas de información.

Los mensajes en este dominio los procesa el analizador BLOB. El analizador BLOB es un
programa que interpreta un árbol de mensaje o una corriente de bits que representa un
mensaje que pertenece al dominio BLOB. El analizador genera el árbol correspondiente a partir
de la corriente de bits en la entrada o la corriente de bits a partir del árbol, en la salida.

Un mensaje BLOB se maneja como una sola serie de bytes y, aunque se puede manipular, no se
pueden identificar secciones específicas de la serie de bytes utilizando ninguna referencia, a
diferencia de otros dominios en los que se pueden modificar los mensajes.

3.2 Create a message model from business requirements

3.3 Create a message model from existing definition (including XSD, Cobol
copybook, C header file)
El asistente puede importar archivos COBOL con extensiones .cbl, .ccp, .cob y .cpy
El asistente puede importar archivos de cabecera C con extensiones .h, .c y .css

3.4 Configure physical properties of data types (including text, binary, XML)
3.5 Create a message model utilizing wildcard elements and attributes
Propiedades lógicas de elemento comodín

Las propiedades lógicas de un elemento comodín incluyen propiedades que especifican el

número de apariciones del elemento comodín.

Propiedad Tipo Significado

Espacio de Serie de Los espacios de nombres son un método simple para calificar nombres de
nombres caracteres elemento y atributo asociándolos con espacios de nombres identificados por
referencias de URI.

Este campo está inicialmente en blanco.

Propiedad Tipo Significado
Procesar Tipo Si un mensaje contiene un elemento que corresponde a un comodín en el modelo
contenido enumerado de mensaje, Procesar contenido define cómo se valida el elemento.
Seleccione una de las siguientes opciones:

 estricto. El analizador sólo puede realizar la comparación con los

elementos declarados en el espacio de nombres especificado.
 flexible. El analizador intenta realizar la comparación con los elementos
declarados en cualquier espacio de nombres accesible. Si el espacio de
nombres especificado no se puede encontrar, no se genera un error.
 omitir. Si selecciona omitir, el analizador no realiza validación en el
elemento.

3.6 Explain the need for and the implementation of multipart MRM messages

Cada archivo de definición de mensajes dentro de un conjunto de mensajes describe la

estructura lógica de los mensajes, así como los formatos físicos que describen el aspecto
preciso de la corriente de bits de mensaje durante la transmisión.

Si está utilizando el dominio MRM o el dominio IDOC, debe proporcionar la información de

formato físico, ya que indica exactamente al analizador cómo debe analizar la corriente de bits
de mensaje.

Puede considerar un mensaje como un paquete de datos que se envía de un lugar a otro. El
emisor y el receptor del mensaje habrán acordado la estructura del mensaje y el significado de
cada campo del mensaje. Esto es la estructura lógica independiente de la plataforma y del
protocolo.

El emisor y el receptor también habrán acordado la representación física del mensaje, el modo
en que se transmiten físicamente los datos. Por ejemplo, si define un mensaje que transmite
información sobre un cargo de una cuenta bancaria de una persona, se puede representar en
formatos físicos diferentes (XML o una estructura fija tal como un libro de copias COBOL por
ejemplo). El significado y los datos son iguales en ambos casos: sólo ha cambiado el diseño
físico.

Si está utilizando el dominio MRM, puede modelar varias representaciones físicas diferentes
utilizando formatos físicos con nombre.

 Utilice el formato físico CWF (Formato físico personalizado) para modelar mensajes de
formato fijo desde aplicaciones escritas en C, COBOL, PL/1 y otros lenguajes. Este
soporte incluye la posibilidad de crear un modelo de mensaje directamente desde un
archivo de cabecera C o un libro de copias COBOL.
 Utilice el formato físico Formato TDS (Tagged Delimited String - Serie de caracteres
codificada delimitada) para modelar mensajes de texto formateados, quizá con el
contenido de campos identificado por códigos y/o separado por delimitadores
específicos. Este soporte es suficientemente potente para modelar estándares de la
industria tales como SWIFT, EDIFACT y X12.
 Utilice el formato físico XML para modelar mensajes XML, incluyendo los que
aprovechan los espacios de nombres XML. Este soporte incluye la posibilidad de crear
un modelo de mensaje directamente desde un archivo de DTD XML o de Esquema XML.

Representaciones físicas diferentes

El ejemplo siguiente muestra cómo un mensaje lógico muy simple puede tener diferentes
representaciones físicas.

El modelo lógico define la estructura y el orden del mensaje. En el ejemplo siguiente, los tres
campos son enteros simples y C sigue a B, que sigue a A:

int A;
int B;
int C;

 Una representación típica de Formato físico personalizado para este mensaje lógico será 12 bytes de
datos, en los que A, B y C ocupan cada uno 4 bytes. Alternativamente, quizá A tiene una longitud de 4
bytes, pero B y C tienen una longitud de sólo 2 bytes. Proporcione la información física precisa para cada
campo del mensaje como propiedades CWF.
 TDS permite modelar varias representaciones diferentes. Cada entero puede ir precedido de un código
para identificarlo y de un delimitador para terminarlo, como se indica a continuación:
{A_código:xxxxxxxx;B_código:xxxxxxxx;C_código:xxxxxxxx}
Una alternativa puede basarse en que se ordenen los datos de forma que sólo sea necesario especificar el
delimitador de terminación, como se muestra a continuación:
[xxxxxxxx;xxxxxxxx;xxxxxxxx]
Proporcione el régimen de identificación preciso en forma de propiedades TDS.
 Una representación XML típica de este modelo es la siguiente:
<Msg><A>xxxxxxxx</A><B>xxxxxxxx</B><C>xxxxxxxx</C></Msg>
donde xxxxxxxx es el valor del entero representado como una serie de caracteres (XML sólo trata con series de
caracteres). Una representación alternativa puede ser:
<Msg A="xxxxxxxx" B="xxxxxxxx" C="xxxxxxxx"/>
donde los valores de los enteros se almacenan como atributos XML en lugar de almacenarse como elementos XML.
Proporcione la información de XML precisa para cada campo del mensaje como propiedades XML.

Esto muestra que el modelo lógico no ha cambiado. Es constante, independientemente de la

representación física sobre la que elija crear el modelo, utilizando el soporte de formato físico
proporcionado por el dominio MRM. El analizador MRM es capaz de transformar el mensaje de
la representación física de entrada en cualquier número de representaciones de salida,
basándose en las capas de formato físico que se hayan definido.

3.7 Create a WSDL document from a message set

Section 4 - Packaging, Deployment and
Migration (11%)
4.1 Migrate WebSphere Message Brokers Toolkit projects from prior versions
(including message flows, message sets, message maps)

Para migrar el espacio de trabajo del Message Broker Toolkit de la Versión 6.0 a la Versión 6.1,
realice los pasos siguientes:

1. Instale WebSphere Message Broker Versión 6.1 en una ubicación distinta de WebSphere Message Broker
Versión 6.0.
2. Cuando inicie el Message Broker Toolkit Versión 6.1 por primera vez, se le solicitará que entre una
ubicación para el espacio de trabajo. Entre el directorio que contiene el espacio de trabajo de Message
Broker Toolkit Versión 6.0 que desea migrar.
o Si los flujos de mensajes incluyen nodos definidos por el usuario, consulte Migración de un nodo
definido por el usuario.
o Si los proyectos de flujo de mensajes contienen definiciones de datos para ESQL y correlaciones,
consulte Migración de un flujo que contiene definiciones de datos.

Ahora, el espacio de trabajo y los recursos están disponibles en el Message Broker Toolkit Versión 6.1.

Para migrar un Message Broker Toolkit Versión 5.0 a la Versión 6.1:

1. Instale WebSphere Message Broker Versión 6.1 en una ubicación distinta de WebSphere Business
Integration Message Broker Versión 5.0.
2. Migre las correlaciones de la Versión 5.0 y las definiciones de datos utilizando el mandato
mqsimigratemfmaps.
3. Cuando inicie el Message Broker Toolkit Versión 6.1 por primera vez, se le solicitará que entre una
ubicación para el espacio de trabajo. Escriba el directorio donde está ubicado el espacio de trabajo del
Message Broker Toolkit Versión 5.0 que desea migrar. En la Versión 5.0, la ubicación predeterminada es
dir_instalación/eclipse/workspace.
o Los flujos de mensajes de la Versión 5.0 se convierten automáticamente al formato de la Versión
6.1 la primera vez que se guardan. El Message Broker Toolkit Versión 5.0 no puede leer flujos de
mensajes que se han guardado en formato de la Versión 6.1.
o Si los flujos de mensajes utilizan nodos WebSphere MQ Everyplace (MQe), siga las instrucciones
de Migración de un flujo de mensajes que contiene nodos WebSphere MQ Everyplace.
o Si sus flujos de mensajes utilizan hojas de estilo XML, siga las instrucciones del tema Migración de
hojas de estilo y archivos XML desde la Versión 5.0.
o Si había activado anteriormente la validación en un flujo de mensajes y ha restablecido la
propiedad Validación del nodo de entrada en Ninguna, debe asegurarse de que la propiedad
Temporización de análisis está establecida en el valor predeterminado A petición antes de migrar
el flujo de mensajes.
 Aunque un intermediario de la Versión 5.0 ignora la propiedad Temporización de
análisis si la Validación se ha establecido en Ninguna, ésta no se ignora en la
Versión 6.1y el flujo de mensajes no se ejecuta correctamente.

Si la Validación se establece en Ninguna y Temporización de análisis no se ha

establecido en el valor predeterminado, restablezca primero Validación con otro
valor. Si La propiedad Temporización de análisis está habilitada y puede volver a
establecerla con el valor predeterminado A petición, a continuación vuelva a
restablecer la propiedad Validación en Ninguna.

Migre el flujo de mensajes con esos valores actualizados; se migra

correctamente y con los valores válidos para Versión 6.1.

o Los conjuntos de mensajes de la Versión 5.0 se convierten automáticamente al formato de la

Versión 6.1 la primera vez que los guarda. El Message Broker Toolkit Versión 5.0 no puede leer
conjuntos de mensajes que se han guardado en formato de la Versión 6.1.
4. Limpie y vuelva a crear el espacio de trabajo.
5. Para migrar nodos definidos por el usuario de la Versión 5.0, importe el proyecto de nodo definido por el
usuario al entorno de trabajo de la Versión 6.1 y vuelva a crear el proyecto. Si está migrando nodos
definidos por el usuario desde la Versión 5.0, realice los siguientes pasos adicionales:
a. Modifique el elemento <requires> del archivo plugin.xml en el directorio raíz del proyecto del
nodo definido por el usuario para que coincida con el ejemplo siguiente. Asegúrese de suprimir
todas las entradas innecesarias del archivo plugin.xml de la Versión 5.0 para que coincida
exactamente con el ejemplo siguiente:
b. <requires>
c. <import match="greaterOrEqual" plugin="com.ibm.etools.mft.api" version="6.0.0"/>
</requires>

d. Modifique la extensión "org.eclipse.help.contexts" en el mismo archivo plugin.xml para que coincida con
el ejemplo siguiente:
e. <extension point="org.eclipse.help.contexts">
f. <contexts file="HelpContexts.xml"/>
</extension>

g. Reinicie el Message Broker Toolkit.

4.2 Create a bar file and configure properties (including runtime versioning)

Esto se realize en el curso creando el .bar de cero e incluyendo los proyectos queriamos desplegar.

Empaquete todos los recursos del flujo de mensajes en un archivo de archivador de

intermediario (BAR) para su despliegue.
 4.3 Explain packaging of Java code in a WebSphere Message Broker solution

SEgun lo leido existen dos formas de tener codigo java en los pryectos de mb, uno que existan nodos definidos por
el usuario, o que exista codigo hecho en java en un javacompute.
Para la primera opción, se tiene que hacer un archivo .par que contiene las clases y las dependencias de estas
clases, este archivo .par se debe colocar en la via de acceso en el LIL, también se pueden empaquetar en un jar y
realizar el mismo procedimiento.
Para la segunda opción el MBT maneja automáticamente eso y los empaqueta como dependencias del proyecto
dentro del archivo .bar

4.4 Deploy a WebSphere Message Broker solution

Hay tres formas de desplegar una aplicacion

1. Mediante el Message Broker Toolkit
2. Comando mqsideploy
3. Utilizando las interfaces o API de CMP.

El primer método es el método que utilizamos en el curso el cuala es darle deploy al .bar y colocarlo en el
manejador deseado.
El segundo método es por línea de comandos y se deben especificar mas parámetros a la hora desplegar hostname
= localhost
queueManager = QMNAME
port = 1414
securityExit = test.myExit

el tercer metodo es controlar el despliegue desde un programa Java utilizando las funciones
descritas por la API de CMP. También puede consultar las respuestas del intermediario y
realizar las acciones adecuadas.

Las aplicaciones Java también pueden utilizar la API de CMP para controlar otros objetos del
dominio, por ejemplo, intermediarios, grupos de ejecución, topologías de
publicación/suscripción, temas, suscripciones y el Gestor de configuración y su registro de
sucesos. Por lo tanto, la API de CMP se puede utilizar para crear y manipular todo un dominio
de forma programada.

Si utiliza el entorno de trabajo o la API de CMP, la solicitud es asíncrona, Una solicitud de despliegue siempre se
completa bien sea porque el intermediario ha enviado una respuesta o porque ha caducado el tiempo de espera
Si utiliza el mandato mqsideploy, el despliegue es síncrono y el mandato espera una respuesta
El que se utiliza en el MBT es asíncrono porque uno despliega y luego llega la respuesta..

4.5 Use version and source control management Commented [s5]: No consegui nada…
Section 5 - Testing and Debugging (13%)
5.1 Test a flow using the facilities of WebSphere Message Brokers Toolkit

5.2 Use the interactive debugger

Puede establecer puntos de interrupción en un flujo y después ejecutar pasos en el flujo.

Durante la ejecución de pasos, puede examinar y modificar las variables del mensaje y las
variables utilizadas en el código ESQL, el código Java y las correlaciones. Puede depurar una
amplia variedad de condiciones de errores en los flujos, incluidas las siguientes:

 Nodos transmitidos incorrectamente (por ejemplo, salidas que están conectadas a

entradas erróneas)
 Bifurcaciones condicionales incorrectas en condiciones de transición
 Bucles infinitos no proyectados en el flujo de mensajes

Desde un solo entorno de trabajo, puede conectar el depurador con uno o más grupos de
ejecución y depurar varios flujos de mensajes en distintos grupos de ejecución (y, por lo tanto,
múltiples mensajes) simultáneamente. Sin embargo, un grupo de ejecución sólo se lo puede
depurar un solo usuario cada vez. Por lo tanto, si conecta el depurador a un grupo de ejecución,
ningún otro usuario podrá conectar el depurador a ese mismo grupo de ejecución hasta que
haya terminado la sesión de depuración.
5.3 Use a Trace node in a message flow

Depuración mediante la adición de nodos de Trace a un flujo de mensajes

Mediante la adición de un nodo de Trace a un flujo de mensajes, puede escribir mensajes de

depuración en un archivo, un rastreo de usuario o en las anotaciones del sistema y revisar estos
mensajes después de que el flujo de mensajes haya procesados datos.

Debe añadir un nodo de Trace cuando se haya designado el flujo de mensajes. El apartado Ver
el árbol lógico de mensaje en la salida de rastreo explica cómo ver la estructura del árbol lógico
de mensaje en cualquier punto del flujo de mensajes y contiene un ejemplo del contenido del
mensaje. Puede desactivar el nodo de Trace cuando flujo de mensajes se promocionen al
entorno de producción para mejorar el rendimiento, pero puede volver a activar el nodo
cuando sea necesario. El rendimiento se puede ver afectado cuando hay nodos de Trace
activos. La magnitud en que el rendimiento se ve afectado depende del destino que se
seleccione para los mensajes de depuración; por ejemplo, grabar en el rastreo de usuario suele
ser más rápido que grabar en un archivo o en las anotaciones del sistema.

Los mensajes de depuración pueden incluir la grabación de parte o de la totalidad del árbol
lógico de mensaje, pero también pueden incluir series codificadas para identificar un
determinado punto del flujo de mensajes (como, por ejemplo, PRINTF en un programa C). Si
graba todo el árbol de mensaje en un nodo de Trace, es posible que el comportamiento del
flujo de mensajes cambie. Normalmente, sólo se analizan las partes del mensaje a las que se
hace referencia en lugar de todo el mensaje.

5.4 Enable and interpret user trace information to diagnose problems

Inicio del rastreo de usuario

Utilice el rastreo de usuario para depurar las aplicaciones; puede efectuar un seguimiento de
intermediarios, grupos de ejecución y flujos de mensajes. Inicie los recursos de rastreo de
usuario utilizando el mandato mqsichangetrace o el entorno de trabajo.

Para iniciar un rastreo de usuario:

1. Inicie los recursos de rastreo de usuario de WebSphere Message Broker mediante el mandato
mqsichangetrace, o, para grupos de ejecución y flujos de mensajes asignados, desde el entorno de
trabajo. Puede seleccionar un solo intermediario en cada invocación del mandato, pero puede activar
rastreos simultáneos para más de un intermediario, invocando el mandato más de una vez.
2. Especifique un grupo de ejecución o un flujo de mensajes individual dentro del intermediario especificado
para limitar el ámbito de un rastreo. Los sucesos que se registran cuando selecciona la opción de flujo de
mensajes incluyen:
o Envío de un mensaje de un nodo de proceso de mensajes al siguiente
o Evaluación de expresiones en un nodo Compute o Filter
3. Inicie el rastreo. Puede iniciar el rastreo en dos niveles:

normal
Efectúa el seguimiento de sucesos que afectan a objetos que ha creado y suprimido, como por ejemplo
nodos.
debug
Efectúa el seguimiento del comienzo y el final de un proceso y supervisa los objetos que se ven afectados
por esos procesos.

Un archivo de anotaciones con formato, como el descrito en Cómo dar formato al rastreo,
contiene una secuencia de mensajes de WebSphere Message Broker. Estos mensajes registran
la actividad que tiene lugar en una parte específica del sistema (la parte que especifique cuando
inicie el rastreo). Puede utilizar esta secuencia para entender lo que está sucediendo y para
comprobar que el comportamiento que se registra es el esperado.
Por ejemplo, el rastreo de flujo de mensajes registra la ruta que toma un mensaje a través del
flujo de mensajes. Puede ver por qué las decisiones dan como resultado esta ruta (cuando
exista la posibilidad).

Si ve un comportamiento inesperado en un flujo de mensajes o un grupo de ejecución, utilice esta información de

rastreo para examinar las acciones que se han realizado e identificar el origen de un error u otra discrepancia.

Los mensajes contienen identificadores para los recursos que se están rastreando, por ejemplo
los grupos de ejecución y los flujos de mensajes. El identificador que aparece es normalmente
la etiqueta (el nombre) que asignó al recurso cuando lo definió.

A continuación se muestra un extracto de un archivo de rastreo de usuario. En el ejemplo, se ha etiquetado cada

columna:
Fecha y hora ID hebra Tipo rastreo Mensaje
2005-07-12 16:17:18.242605 5344 UserTrace BIP2537I: Node 'Reply.MapToRequestor':
Executing statement ''SET I = I + 1;''
at ('.MapToRequestor.CopyMessageHeaders',
'6.4').
2005-07-12 16:17:18.242605 5344 UserTrace BIP2539I: Node 'Reply.MapToRequestor':
Evaluating expression ''I'' at
('.MapToRequestor.CopyMessageHeaders',
'6.12'). This resolved to ''I''. The
result was ''1''.

5.5 Find and analyze the system log