Ejercicio: Configuración de nodos de integración y personalización

Conexión con IBM MQ

Ejecutar el ejemplo con un mensaje que contiene un

número de empleado que no es igual a 2
Para ejecutar el ejemplo con el mensaje que contiene un número de empleado que no es
igual a 2:

1. En la vista Desarrollo de aplicaciones, expanda el proyecto Browsing Websphere

MQ Queues Message Flows y efectúe una doble pulsación en staffmsg1.mbtest. El
archivo staffmsg1.mbtest se abre en el Cliente de prueba.
2. En el Cliente de prueba, pulse Colocar en cola.
3. Pulse Enviar mensaje. Un mensaje que contiene un número de empleado igual a 1
se coloca en la cola MQBROWSE_IN.
4. Vea la cola MQBROWSE_IN utilizando WebSphere MQ Explorer. El mensaje se
ha leído pero sigue estando en la cola de entrada. Observe que el nodo MQInput no
intenta procesar el mensaje más de una vez, aunque éste permanece en la cola.

Ejecutar el ejemplo con un mensaje que contiene un

número de empleado igual a 2
Para ejecutar el ejemplo con el mensaje que contiene un número de empleado igual a 2:

1. En la vista Desarrollo de aplicaciones, expanda el proyecto Browsing Websphere

MQ Queues Message Flows, abra staffmsg2.mbtest en el Cliente de prueba y pulse
Colocar en cola.
2. Pulse Enviar mensaje.
3. Vea la cola MQBROWSE_IN utilizando WebSphere MQ Explorer. El mensaje ya
no está en esta cola. Si ha colocado este mensaje de prueba después de utilizar
staffmsg1.mbtest, observe que el mensaje con un número de empleado igual a 1
sigue estando en la cola. Esto es debido a que el nodo MQGet obtiene el mensaje
buscando una coincidencia con el ID de mensaje, en vez de eliminar el primer
mensaje de la cola.
4. En el Cliente de prueba, pulse Extraer de la cola.
5. Pulse Obtener mensaje para obtener el mensaje de la cola MQBROWSE_OUT.
El ejemplo contiene un único flujo de mensajes llamado BrowseGet. El flujo de mensajes
examina un mensaje en la cola de entrada y luego lo direcciona basándose en el valor del
campo StaffNumber. A continuación, el flujo de mensajes elimina el mensaje de la cola y
lo coloca en una segunda cola.

Flujo de mensajes BrowseGet

El flujo de mensajes BrowseGet muestra las siguientes tareas:

 Examina el mensaje de WebSphere MQ que contiene una carga útil XML.

 Examina el campo StaffNumber para determinar si el proceso debe continuar.
 Elimina el mensaje de la cola.
 Coloca el mensaje en una segunda cola de WebSphere MQ.

La siguiente figura muestra el flujo de mensajes BrowseGet:

El nodo MQInput llamado MQBROWSE_IN lee el mensaje XML de la cola

MQBROWSE_IN. Puesto que la opción Sólo examinar está especificada en este nodo, el
mensaje no se elimina de la cola de entrada.

El nodo Route llamado StaffNumber=2 ejecuta la expresión XPath:

$Body/Staff/StaffNumber="2"|Match

Si el mensaje no contiene un valor de 2 para StaffNumber, el proceso del flujo de mensajes

se detiene, y el mensaje permanece en la cola de entrada. Si el mensaje contiene un valor de
2 para StaffNumber, el proceso del flujo de mensajes continúa en el siguiente nodo.

El nodo MQGet llamado MQBROWSE_GET obtiene el mensaje de la cola de entrada. La

propiedad Obtener por ID de mensaje del nodo está seleccionada para asegurarse de que es
el mensaje actual el que se elimina de la cola de entrada.

El nodo MQOutput llamado MQBROWSE_OUT coloca el mensaje en la cola

MQBROWSE_OUT.

Mensajes de prueba
Los mensajes de prueba que se utilizan en el ejemplo de Examen de colas de WebSphere
MQ son mensajes XML sencillos que contienen detalles sobre el personal de una empresa.
staffmsg1:

<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>

staffmsg2:

<Staff>
<StaffNumber>2</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>

Acerca del ejemplo Nodos SOAP

IBM Integration Toolkit

Conceptos básicos de administración

La ejecución del ejemplo Nodos SOAP consiste en pasar un mensaje a través del flujo de
mensajes de consumidor. Para ejecutar este ejemplo, puede utilizar el Cliente de prueba
para colocar mensajes de entrada en el flujo de mensajes.

Antes de ejecutar el ejemplo, compruebe que su consumidor de servicios web está

configurado correctamente para flujos HTTP y de que los objetos administrados JNDI están
configurados para flujos JMS, consulte Configurar la parte JMS del ejemplo Nodos SOAP.

Si encuentra algún problema al ejecutar el ejemplo, consulte Resolver problemas al ejecutar

ejemplos en la documentación de IBM Integration Bus.

Verificar que el consumidor tiene las propiedades

correctas para el proveedor
 SOAP sobre HTTP:
 Si desea verificar que el consumidor de servicios web está configurado
correctamente, realice todos los pasos siguientes. Si ha configurado un supervisor
TCP/IP, entonces ya ha comprobado qué puerto está utilizando el proveedor de
servicios Web, pero debe configurar de todas formas el consumidor para enviar los
mensajes al supervisor TCP/IP y, a continuación, crear y volver a desplegar el
archivo de archivador de intermediario (BAR).

El puerto predeterminado que utilizan los servicios web es el 7800 y el nodo

SOAPRequest está configurado para utilizar este puerto. Sin embargo, si este puerto
ya se está utilizando, el número de puerto se incrementa en uno.

Para comprobar qué puerto está utilizando el grupo de ejecución del proveedor,
emita el siguiente mensaje mqsireportproperties:

mqsireportproperties IB9NODE -e grupoEjecuciónEjemplo -o

HTTPConnector -n port

Donde grupoEjecuciónEjemplo es el grupo de ejecución de su ejemplo.

Para verificar que el puerto que el nodo SOAPRequest está utilizando es el puerto
correcto para llamar al flujo de proveedor, cambie el puerto del nodo SOAPRequest
por el puerto que el grupo de ejecución de proveedor está utilizando realizando los
pasos siguientes:

1. Abra el flujo de mensajes que se encuentra en el proyecto de integración.

2. Abra el separador Transporte HTTP en la vista Propiedades. Si el puerto ya es
correcto, ha terminado de configurar el ejemplo. Si el puerto no es correcto,
cámbielo en la propiedad URL de servicio web por el puerto correcto por el
proveedor de servicios web o por su supervisor TCP/IP.
3. Guarde el flujo de mensajes. Ahora debe volver a crear y volver a desplegar el
archivo BAR.

 SOAP sobre JMS:

Asegúrese de que los objetos administrados JNDI se han creado como se describe
en Configurar el ejemplo Nodos SOAP para que utilice transporte JMS. Asegúrese
también de que se han establecido las propiedades JNDI en los nodos SOAPInput y
SOAPRequest. Verifique que se han creado las siguientes colas de WebSphere MQ
bien a través de WebSphere MQ Explorer o de la Consola de mandatos de
WebSphere MQ.

o JMSREQUESTQ
o JMSREPLYQ
  En el ejemplo, el recuadro de selección Habilitar soporte para ?wsdl del nodo SOAPInput
está seleccionado; de forma predeterminada no está seleccionado. No se devuelve
información de WSDL si el recuadro de selección no está seleccionado. Este recuadro de
selección está en el separador Transporte HTTP.
 Para verificar que el flujo se ha configurado utilizando el WSDL esperado, envíe una
solicitud HTTP GET al punto final expuesto por el flujo, con el sufijo ?wsdl. Por ejemplo,
puede especificar un URL con la forma siguiente en la barra de direcciones de un
navegador:

http://brokerHost:brokerPort/pathSuffixFromNode?wsdl

El WSDL devuelto incluye elementos import o include como se muestra a continuación:

<xsd:import namespace="..."</xsd:import>
schemaLocation="http://brokerHost:brokerPort/pathSuffixFromNode?xsd
=xsd0" />

Estas referencias se pueden especificar a su vez en la barra de direcciones del navegador

para recuperar las partes subsiguientes de la definición. Algunos proveedores
proporcionan herramientas que siguen automáticamente una cadena de referencias como
ésta para crear la definición WSDL completa.

Ejecutar el ejemplo
1. En la vista Desarrollo de aplicaciones, expanda el proyecto SOAPNodesSampleFlows.
2. Bajo Pruebas de flujo, efectúe una doble pulsación en
SOAPNodesSampleConsumerFlow.mbtest para abrir el archivo en el Cliente de prueba.
3. Pulse Enviar mensaje.
4. Seleccione Extraer de la cola en el panel Sucesos de prueba de flujo de mensaje y luego
pulse Obtener mensaje.

Si el ejemplo se ha ejecutado satisfactoriamente, se recupera el siguiente mensaje de

la cola SOAPSAMPLE_OUT:

<NS1:submitPOResponse
xmlns:NS1="http://www.acmeOrders.com/OrderService">
<orderStatus>AVAILABLE</orderStatus>
<orderAmt>50</orderAmt>
<partNo>Some Part</partNo>
<partQuantity>1</partQuantity>
</NS1:submitPOResponse>
El ejemplo Nodos SOAP muestra cómo se pueden utilizar los nodos SOAPInput,
SOAPReply y SOAPRequest para proporcionar y consumir un servicio web a través de un
transporte HTTP o JMS.

El punto de partida del ejemplo es un archivo WSDL (lenguaje de descripción de servicios

web) que define un servicio de pedidos simplificado, consulte el Archivo WSDL. El
archivo WSDL, que contiene enlaces HTTP y JMS, apunta a las operaciones que hay
definidas en el WSDL. El servicio web devuelve siempre una respuesta que indica que la
pieza solicitada está disponible; una opción para ampliar el servicio web puede ser utilizar
un nodo Database para consultar una base de datos de existencias.

El asistente "Empezar a partir de archivos WSDL y/o XSD" se utiliza con el archivo
WSDL para crear el conjunto de mensajes y los dos flujos de mensajes que componen este
ejemplo.

El ejemplo Nodos SOAP muestra las siguientes tareas:

 Cómo proporcionar un servicio web utilizando nodos SOAPInput y SOAPReply mediante un

transporte HTTP o JMS.
 Cómo consumir un servicio web utilizando un nodo SOAPRequest mediante un transporte
HTTP o JMS.
 Cómo consultar el WSDL utilizado para configurar un flujo de proveedor de servicios web.

Los flujos de mensajes

El ejemplo utiliza dos flujos de mensajes. Un flujo de mensajes proporciona un servicio
web y el otro consume un servicio web. El mensaje de solicitud y de respuesta es el mismo
en el caso de servicios web HTTP y JMS. Los flujos de mensajes se describen más adelante
en esta sección.

El diagrama siguiente muestra el flujo de mensajes de Proveedor de servicios web:

La tabla siguiente muestra los nodos del flujo de mensajes de Proveedor de servicios web:

Tipo de nodo Nombre de nodo

SOAPInput Input
Subflow OrderService_Extract

Compute Compute Response

SOAPReply Reply

El nodo SOAPInput recibe mensajes SOAP de entrada y, si son válidos, los pasa por el
flujo de mensajes al subflujo OrderService_Extract. El subflujo OrderService_Extract lo
crea el asistente "Empezar a partir de archivos WSDL y/o XSD". El siguiente diagrama
muestra el subflujo de Proveedor de servicios web:

La tabla siguiente muestra los nodos del subflujo de Proveedor de servicios web:

Tipo de nodo Nombre de nodo

Input Terminal in

SOAPExtract Extract

Output Terminal failure

Label ws_submitPORequest

Output Terminal submitPORequest

El nodo SOAPExtract toma un mensaje SOAP y elimina el sobre SOAP. En este ejemplo,
al eliminar el sobre SOAP se deja un mensaje XML en el dominio XMLNSC, que se puede
utilizar en nodos como el nodo Mapping o el nodo Compute. El nodo SOAPExtract
direcciona a continuación el mensaje a una etiqueta basándose en la operación de servicio
web que se está invocando. En este ejemplo se utiliza una sola operación. Si el WSDL que
se utiliza como punto de partida tiene varias operaciones, el asistente "Empezar a partir de
archivos WSDL y/o XSD" ofrece la opción de implementar más de una operación. Si se
seleccionan varias operaciones, el subflujo tiene varias etiquetas, lo que produce varios
terminales de salida en el flujo de mensajes padre.
Cuando el mensaje XMLNSC deja el subflujo y vuelve al flujo de mensajes del proveedor
principal, entra en un nodo Compute. Utilizando el nodo Compute, puede hacer referencia
al cuerpo SOAP original como XML, y realizar operaciones ESQL en los datos en el
mensaje. En el ejemplo, se hace caso omiso de los datos del mensaje y se crean datos XML
válidos partiendo de cero. Estos datos se envían luego al nodo SOAPReply, que construye
un mensaje SOAP para devolver al consumidor de servicio web que inició la llamada de
servicio web.

El siguiente diagrama muestra el flujo de mensajes de Consumidor de servicios web:

La tabla siguiente muestra los nodos del flujo de mensajes de Consumidor de servicios
web:

Tipo de nodo Nombre de nodo

MQInput SOAPSample_IN

Compute Compute Request

Subflow Invoke_submitPO

Compute Compute Response

MQOutput SOAPSample_OUT

MQOutput SOAPSample_FAULT

El flujo de consumidor de servicios web lo inicia un mensaje de WebSphere MQ que llega

a la cola supervisada por el nodo MQInput. El mensaje es un mensaje XML en el dominio
XMLNSC. El mensaje entra en un nodo Compute donde los datos de entrada se utilizan
para crear los datos XML que se van a enviar al servicio web. El mensaje se pasa luego por
el flujo al subflujo Invoke_submitPO. El subflujo Invoke_submitPO lo crea el asistente
"Empezar a partir de archivos WSDL y/o XSD".
El siguiente diagrama muestra el subflujo de Consumidor de servicios web:

La tabla siguiente muestra los nodos del subflujo de Consumidor de servicios web:

Tipo de nodo Nombre de nodo

Input Terminal in

SOAPRequest Request

Output Terminal fault

SOAPExtract Extract

Output Terminal failure

Label ws_submitPOResponse

Output Terminal submitPOResponse

El nodo SOAPRequest toma los datos XML de entrada y los utiliza para construir un
mensaje SOAP válido que va a enviar al servicio web definido por las propiedades del
nodo. Si la respuesta que se recibe es válida, se pasa a un nodo SOAPExtract, que elimina
el sobre SOAP de la respuesta y devuelve el mensaje al dominio XMLNSC. El mensaje se
direcciona entonces a la Etiqueta ws_submitPOResponse y sale del subflujo.

En el flujo de consumidor principal, el mensaje de salida se envía a un nodo MQOutput que

graba los datos XML en la cola de WebSphere MQ especificada. El mensaje de error se
envía a un nodo MQOutput que graba los datos de error SOAP en la cola de WebSphere
MQ especificada.
Los mensajes
El flujo de mensajes de cliente web está controlado por un mensaje WebSphere MQ. Se
proporciona un archivo de cliente de prueba para ejecutar el ejemplo utilizando el siguiente
mensaje XML:

<OrderMessage>
<localElement>
<FirstName>Message</FirstName>
<LastName>Broker</LastName>
<Street>IBM</Street>
<City>IBM</City>
<ZipCode>IBM</ZipCode>
<PartNumber>Some Part</PartNumber>
<Quantity>1</Quantity>
</localElement>
</OrderMessage>

En el siguiente extracto de esquema editado se muestra el formato válido para un mensaje

de solicitud de servicio web y el mensaje de respuesta:

<xsd:element name="submitPORequest">

...
<xsd:complexType>
<xsd:sequence>
<xsd:element name="partNo" type="xsd:string"/>
<xsd:element name="partQuantity" type="xsd:int"/>
<xsd:element name="personName">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="firstName" type="xsd:string"/>
<xsd:element name="lastName" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="address">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="zipCode" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="submitPOResponse">
...
<xsd:complexType>
<xsd:sequence>
<xsd:element name="orderStatus" type="xsd:string"/>
<xsd:element name="orderAmt" type="xsd:int"/>
 <xsd:element name="partNo" type="xsd:string"/>
<xsd:element name="partQuantity" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

Ejecutar el ejemplo Consumidor asíncrono

La ejecución del ejemplo Consumidor asíncrono consiste en poner mensajes a través del
flujo de mensajes. Para ejecutar este ejemplo, puede utilizar el Cliente de prueba para
colocar mensajes de entrada en el flujo de mensajes. Para obtener más información sobre el
Cliente de prueba, consulte Comprobación de los flujos de mensajes utilizando el Cliente
de prueba en la documentación de IBM Integration Bus.

Si encuentra algún problema al ejecutar el ejemplo, consulte Resolver problemas al ejecutar

ejemplos en la documentación de IBM Integration Bus.

Verificar que el proveedor tiene las propiedades

correctas para el consumidor
 SOAP sobre HTTP:

Si desea verificar que el consumidor de servicios web está configurado

correctamente, realice todos los pasos siguientes. Si ha configurado un supervisor
TCP/IP, entonces ya ha comprobado qué puerto está utilizando el proveedor de
servicios web, pero debe configurar de todas formas el consumidor para enviar los
mensajes al supervisor TCP/IP y, a continuación, crear y volver a desplegar el
archivo de archivador de intermediario (BAR).

El puerto predeterminado que utilizan los servicios web es el 7800 y el nodo

SOAPRequest está configurado para utilizar este puerto. Sin embargo, si este puerto
ya se está utilizando, el número de puerto se incrementa en uno.

Para comprobar qué puerto está utilizando el servidor del proveedor, emita el
siguiente mandato mqsireportproperties:

mqsireportproperties IB9NODE -e grupoEjecuciónEjemplo -o

HTTPConnector -n port

Donde grupoEjecuciónEjemplo es el servidor de su ejemplo.

Para verificar que el puerto que el nodo SOAPRequest está utilizando es el puerto
correcto para llamar al flujo de proveedor, cambie el puerto del nodo SOAPRequest
 por el puerto que el servidor del proveedor está utilizando realizando los pasos
siguientes:

1. Abra el flujo de mensajes que se encuentra en el proyecto de Nodo de integración.

2. Abra el separador Transporte HTTP en la vista Propiedades. Si el puerto ya es
correcto, ha terminado de configurar el ejemplo. Si el puerto no es correcto,
cámbielo en la propiedad URL de servicio web por el puerto correcto por el
proveedor de servicios web o por su supervisor TCP/IP.
3. Guarde el flujo de mensajes. Ahora debe volver a crear y volver a desplegar el
archivo BAR.
 SOAP sobre JMS:

Asegúrese de que los objetos administrados por JNDI se crean según se indica en
Configuración del ejemplo Consumidor asíncrono para utilizar un transporte JMS.
Asegúrese también de que se han establecido las propiedades JNDI en los nodos
SOAPInput y SOAPRequest. Verifique que se han creado las siguientes colas de
WebSphere MQ bien a través de WebSphere MQ Explorer o de la Consola de
mandatos de WebSphere MQ.

o JMSREQUESTQ
o JMSREPLYQ

Ejecutar el ejemplo
1. En la vista Desarrollo de aplicaciones, expanda el proyecto AsyncWebServiceFlows.
2. Efectúe una doble pulsación en WebServicesTest.mbtest para que se abra el archivo en el
Cliente de prueba. Si no tiene una carpeta Pruebas de flujo o un archivo
WebServicesTest.mbtest, debe crear uno. Consulte Crear un archivo de prueba de flujo de
mensajes.
3. Pulse Enviar mensaje.
4. En la ventana Ubicación de despliegue, asegúrese de seleccionar la ubicación de
despliegue correcta, pulse Finalizar. Un mensaje se coloca en la cola
WEBSERVICECLIENTIN.

Si el ejemplo se ha ejecutado satisfactoriamente, el mensaje de salida se visualiza en la

vista Propiedades.
Se proporcionan todos los archivos que necesita para ejecutar el ejemplo Consumidor
asíncrono, pero si prefiere crear el ejemplo usted mismo, utilice las siguientes
instrucciones:

Estas instrucciones crean flujos que utilizan un transporte HTTP, no obstante, una vez que
haya completado el ejemplo con HTTP, puede modificarlo para utilizar JMS; consulte
Configuración del ejemplo Consumidor asíncrono para utilizar un transporte JMS.

Para crear el ejemplo Consumidor asíncrono, utilice las instrucciones de los enlaces
siguientes para crear los recursos necesarios:

1. Crear el flujo de mensajes y el conjunto de mensajes de servicio web

2. Crear el conjunto de mensajes de controlador de cliente
3. Crear el flujo de cliente de servicios web
4. Crear las colas de WebSphere MQ

Cuando haya creado los recursos necesarios utilizando las instrucciones proporcionadas,
debe añadir el flujo de servicio web y el flujo de cliente a un archivo de archivador de
intermediario (BAR), junto con los conjuntos de mensajes asociados. La captura de pantalla
siguiente muestra los recursos que se deben añadir en el archivo de archivador de
intermediario:
Cuando haya realizado estos pasos, estará preparado para ejecutar el ejemplo. Consulte
Ejecutar el ejemplo Consumidor asíncrono.

El ejemplo Consumidor asíncrono muestra cómo se pueden utilizar nodos asíncronos para
llamar a un servicio web. El lenguaje WSDL (Web Services Definition Language) del
servicio web se importa en las herramientas y se utiliza para configurar el nodo
SOAPAsyncRequest para invocar operaciones expuestas por el servicio web. Este ejemplo
también muestra cómo se pueden ampliar las interfaces de WebSphere MQ existentes para
realizar solicitudes de servicio web.

El ejemplo utiliza inicialmente un transporte HTTP, pero puede modificarse para utilizar
JMS, consulte Configuración del ejemplo Consumidor asíncrono para que utilice un
transporte JMS.

En el ejemplo, el servicio web es un servicio de pedidos simplificado que expone una

operación. El servicio web se proporciona como un flujo de mensajes en el ejemplo. El
servicio web devuelve siempre una respuesta que indica que la pieza solicitada está
disponible; una opción para ampliar el servicio web puede ser utilizar un nodo Database
para consultar una base de datos de existencias.

El ejemplo Consumidor asíncrono muestra las siguientes tareas:

 Cómo llamar a un servicio web de forma asíncrona

 Cómo ampliar una interfaz WebSphere MQ

Los flujos de mensajes

El siguiente diagrama muestra el flujo de mensajes de cliente web:

Tipo de nodo Nombre de nodo

MQInput MQWSInput

MQOutput MQWSOutput

Compute Compute Request, Format Response

SOAPAsyncRequest SOAP Asynchronous Request

SOAPAsyncResponse SOAP Asynchronous Response

Se construye una solicitud de servicio web a partir de un mensaje WebSphere MQ

utilizando el nodo Compute Request en el dominio SOAP. La operación de servicio web se
invoca utilizando el nodo SOAP Asynchronous Request y el nodo SOAP Asynchronous
Response emparejado recibe la respuesta. Finalmente, el nodo Format Response formatea
la respuesta como un mensaje WebSphere MQ.

El diagrama siguiente muestra el flujo de mensajes de servicio web:

 Tipo de nodo Nombre de nodo

SOAPInput SOAP Input

RouteToLabel Route WS Operation

Label submitPO

Compute Compute Response

SOAPReply SOAP Reply

Un mensaje SOAP entrante se direcciona al nodo submitPO utilizando el nodo Route WS

Operation. En este ejemplo, el servicio web de ejemplo expone sólo una operación. Puede
utilizar varios nodos Label para manejar las diferentes operaciones cuando el servicio web
exponga más de una operación. La respuesta SOAP se genera en el nodo Compute
Response, antes de que la respuesta se devuelva al cliente web.

Los mensajes
El flujo de mensajes de cliente web está controlado por un mensaje WebSphere MQ. Se
proporciona un archivo de Cliente de prueba para ejecutar el ejemplo; el archivo utiliza el
formato de mensaje mostrado en la captura de pantalla siguiente:
En el siguiente extracto de esquema editado se muestra el formato válido para un mensaje
de solicitud de servicio web y el mensaje de respuesta:

<xsd:element name="submitPORequest">
...
<xsd:complexType>
<xsd:sequence>
<xsd:element name="partNo" type="xsd:string"/>
<xsd:element name="partQuantity" type="xsd:int"/>
<xsd:element name="personName">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="firstName" type="xsd:string"/>
<xsd:element name="lastName" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="address">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="zipCode" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="submitPOResponse">
...
<xsd:complexType>
<xsd:sequence>
<xsd:element name="orderStatus" type="xsd:string"/>
<xsd:element name="orderAmt" type="xsd:int"/>
<xsd:element name="partNo" type="xsd:string"/>
<xsd:element name="partQuantity" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

Después de ejecutar el ejemplo, tal vez desee ampliarlo para enviar un mensaje de solicitud
que no sea válido. Para enviar un mensaje de solicitud que no es válido, debe editar el nodo
Compute Request para añadir elementos incorrectos en el cuerpo del mensaje SOAP. El
terminal de anomalías del nodo SOAPAsyncRequest debe estar conectado porque el
servicio web genera un mensaje de error SOAP. Para obtener más detalles sobre los errores
SOAP, consulte El error SOAP en la documentación de IBM Integration Bus.
ejemplo Propagación de identidad de seguridad

El ejemplo Propagación de identidad de seguridad muestra cómo utilizar algunas de las

características de Seguridad de identidad que se proporcionan en IBM Integration Bus.

Puesto que una implementación de seguridad real depende de un proveedor de seguridad

externo centralizado para definir las identidades y las autorizaciones, este ejemplo no
implementa la aplicación de seguridad. El ejemplo creado previamente muestra cómo
extraer las credenciales de seguridad de mensajes en nodos MQInput y HTTPInput, cómo
manipular las credenciales de seguridad utilizando ESQL y cómo informar sobre ellas y,
opcionalmente, correlacionarlas. Asimismo, el ejemplo muestra cómo propagar la identidad
utilizando los nodos MQOutput y HTTPRequest.

La sección "Ampliar el ejemplo" proporciona información detallada sobre cómo incluir un

proveedor de seguridad externo en el ejemplo.

El ejemplo Propagación de identidad de seguridad muestra las siguientes tareas:

 Cómo utilizar una Identidad por mensaje por motivos de seguridad.

 Cómo configurar la extracción automática de una Identidad de las cabeceras de mensajes
WebSphere MQ y HTTP, o la extracción de una Identidad de los campos del cuerpo de un
mensaje.
 Cómo implementar un proceso basado en Identidad personalizado utilizando la Identidad
extraída, independientemente de los transportes subyacentes.
 Cómo implementar una correlación de Identidad personalizada para correlacionar una
Identidad entrante con una Identidad que se utiliza en las solicitudes salientes de un flujo
de mensajes.
 Cómo configurar los flujos de mensajes para propagar la identidad por mensaje, al realizar
solicitudes de salida.

Para obtener información detallada de los conceptos relacionados con la seguridad de flujo de
mensajes, consulte Seguridad de flujo de mensajes en la documentación de IBM Integration Bus.

Los flujos de mensajes

El siguiente diagrama muestra el flujo de mensajes principal del ejemplo Propagación de
seguridad, que es SecurityIdentitySampleFlow.msgflow en el proyecto de Integración
SecurityIdentitySampleFlowProject. El flujo de mensajes consta de un nodo HTTPInput y
dos nodos MQInput que invocan un subflujo común.
El nodo HTTPInput, llamado HTTP_ID, extrae la Identidad que se pasa en la cabecera de
Autenticación básica HTTP, que codifica una señal de nombre de usuario y contraseña de
las solicitudes entrantes. El nodo HTTPInput está configurado en el archivo BAR que se
proporciona, SecurityIdentityPropagation.bar, para que tenga un valor de perfil de
seguridad de Propagación predeterminada.

El nodo MQ_ID MQInput extrae la Identidad, sólo con un nombre de usuario, que se pasa a
la cabecera de mensaje MQMD de WebSphere MQ del mensaje entrante. El nodo MQ_ID
está configurado en el archivo BAR que se proporciona, SecurityIdentityPropagation.bar,
para que tenga un valor de perfil de seguridad de Propagación predeterminada.

El nodo MSG_ID MQInput extrae un conjunto de credenciales de identidad que constan de

un nombre de usuario y una contraseña. Las propiedades de seguridad del nodo MSG_ID se
configuran de forma que las credenciales de identidad pasen al cuerpo del mensaje
WebSphere MQ. El nodo MSG_ID está configurado en el archivo BAR que se
proporciona, SecurityIdentityPropagation.bar, para que tenga un valor de perfil de
seguridad de Propagación predeterminada.

El diagrama siguiente muestra el subflujo de Propagación de identidad de seguridad,

SecurityIdentitySubFlow.msgflow, invocado por todos los nodos de entrada.

El subflujo contiene un nodo Compute, denominado MapIdentity, que puede establecer la

Identidad correlacionada en la carpeta de propiedades del mensaje, si el contenido del
mensaje de entrada solicita que se establezca la identidad correlacionada. El nodo
HTTPRequest, denominado HTTP_ReqAsID, utiliza la identidad de origen o la identidad
correlacionada de la carpeta de propiedades para emitir una solicitud al flujo de mensajes
SecurityIdentityReportFlow. Este nodo sustituye el árbol de mensaje por la respuesta de ese
flujo. HTTPRequestNode propaga el origen de la identidad correlacionada porque está
configurado en el archivo BAR que se proporciona, SecurityIdentityPropagation.bar, para
que tenga un perfil de seguridad de Propagación predeterminada. El nodo final Compute,
denominado ClearHdrs, se proporciona para borrar la cabecera de solicitud HTTP en el
caso que el flujo principal envíe un mensaje de respuesta a través de WebSphere MQ.

El diagrama siguiente muestra el flujo de mensajes Identidad del informe del ejemplo
Propagación de seguridad, denominado SecurityIdentityReportFlow.msgflow, que invoca
el subflujo. Este flujo de mensajes propaga la identidad pertinente.

El nodo Report Identity Compute del flujo de mensajes Informe de identidad de

propagación de seguridad informa de la identidad recibida en los campos de elementos del
cuerpo del mensaje, si está presenta la carpeta body.

Los mensajes
Se proporcionan tres mensajes de entrada para ejecutar el ejemplo Propagación de identidad
de seguridad:

 Simple Message es un mensaje XML pequeño que contiene la estructura a la cual se

informa de la identidad del mensaje entrante:
 <?xml version="1.0" encoding="UTF-8"?>
 <Envelope>
 <Body>
 </Body>
</Envelope>

Consulte Simple.xml, Security_Identity_MQ_ID.mbtest

 Identity Message es un mensaje XML que se utiliza para mostrar cómo se pasa un
conjunto de credenciales de identidad dentro del cuerpo del mensaje:
 <?xml version="1.0" encoding="UTF-8"?>
 <Envelope>
 <Body>
 <MessageIdentity>
 <Username>IdInMsg</Username>
 <Password>PwdInMsg</Password>
 <IssuedBy>InMsgIssuer</IssuedBy>
 </MessageIdentity>
  </Body>
</Envelope>

Consulte Security_Identity_MSG_ID.mbtest

 Map To Identity es un mensaje XML que se utiliza para mostrar cómo pasar una Identidad
en la cabecera de WebSphere MQ. La Identidad se establece luego en la Identidad
correlacionada utilizando un nodo Compute, y se utiliza cuando el flujo realiza una
solicitud de salida a través de HTTP:
 <?xml version="1.0" encoding="UTF-8"?>
 <Envelope>
 <Body>
 <MapIdentity>true</MapIdentity>
 </Body>
</Envelope>

Consulte Security_Identity_Mapped.mbtest

Crear el ejemplo Propagación de identidad de seguridad

Se proporcionan todos los archivos necesarios para ejecutar el ejemplo Propagación de
identidad de seguridad. Si prefiere crear el ejemplo usted mismo, utilice las siguientes
instrucciones:

Para crear el ejemplo Propagación de identidad de seguridad, cree los recursos necesarios
llevando a cabo las tareas siguientes, en este orden:

1. Crear el subflujo de mensajes

2. Crear el flujo de mensajes de Informe de identidad
3. Flujo de mensajes principal
4. Crear las colas
5. Cree un nuevo archivo BAR y añada SecurityIdentitySampleFlow.msgflow y
SecurityIdentityReportFlow.msgflow. Establezca la propiedad a nivel de flujo Perfil
de seguridad en Propagación predeterminada, para que los nodos Input y Output
extraigan y propaguen la Identidad.

Para ejecutar el ejemplo Propagación de identidad de seguridad, pase cada uno de los
mensajes de ejemplo a través del nodo de entrada de transporte adecuado del flujo de
mensajes principal de Propagación de identidad de seguridad. Puede ejecutar el ejemplo
para saber qué sucede en las siguientes situaciones:

 El mensaje de entrada de WebSphere MQ contiene una señal de identidad de usuario en

la cabecera MQMD del mensaje.
 El mensaje de entrada de WebSphere MQ contiene un conjunto de credenciales de
identidad de usuario en el cuerpo del mensaje.
 El mensaje de entrada de WebSphere MQ contiene un elemento Request que el nodo
Compute del flujo principal utiliza para establecer las credenciales de identidad
correlacionada. Las credenciales de identidad correlacionada se basan en la señal de
identidad de usuario, presente en la cabecera MQMD del mensaje de entrada.
 El mensaje de solicitud de entrada de HTTP contiene una señal de identidad de usuario y
contraseña. La señal de identidad de usuario y contraseña está presente en la cabecera de
Autenticación básica HTTP.

Para obtener más información, consulte Acerca del ejemplo Propagación de identidad de
seguridad.

Si encuentra algún problema al ejecutar el ejemplo, consulte Resolver problemas al ejecutar

ejemplos en la documentación de IBM Integration Bus.
Ejecutar el ejemplo con un mensaje WebSphere MQ que
contiene una señal de identidad de usuario en la cabecera
MQMD del mensaje
La cabecera de mensaje MQMD de los mensajes de WebSphere MQ proporciona la
siguiente información al sistema de seguridad del nodo de integración:

 La serie "nombre de usuario" del campo ID de usuario.

 La serie "emitida por" del campo Nombre de aplicación de transferencia.

Para ejecutar el ejemplo con el mensaje WebSphere MQ que contiene una señal de
identidad de usuario en la cabecera MQMD:

1. En la vista Desarrollo de aplicaciones, expanda el proyecto

SecurityIdentitySampleFlowProject. Expanda el directorio Pruebas de flujo y efectúe una
doble pulsación en Security_Identity_MQ_ID.mbtest para abrir el archivo en el Cliente de
prueba.
2. Pulse Colocar en cola en la barra de herramientas de sucesos de prueba de flujo de
mensajes. Observe que el mensaje XML no contiene ningún elemento en el cuerpo del
mensaje.
3. Expanda Cabecera en la sección Propiedades detalladas. Observe que la Cabecera de
mensaje seleccionada es Enviar identidad. Si cambia al separador Configuración del Cliente
de prueba y selecciona Cabecera de mensaje MQ "Enviar identidad", puede ver los
detalles de la cabecera. Estos detalles incluyen mqmdUID como ID de usuario y cliente de
prueba como Nombre de aplicación de transferencia.
4. En el separador Sucesos, pulse Enviar mensaje. El mensaje se coloca en la cola
SECURITYIDFROMMQIN.
5. Fíjese en los resultados:
o Obtenga el mensaje resultante de la cola SECURITYIDFROMMQOUT.
1. En el Cliente de prueba, pulse Extraer de la cola.
2. Pulse Obtener mensaje. El mensaje de salida se visualiza en Mensaje.
o Puede ver nuevos elementos bajo PropagatedIdentityReport, que informan de los
detalles de identidad propagados que se pasaron al flujo de mensajes
SecurityIdentityReportFlow desde el mensaje de entrada.
o Observe que la identidad presentada en el mensaje de salida es el nombre de
usuario mqmdUID. Puesto que no hay ningún campo para la contraseña en el
MQMD, el campo Contraseña está en blanco en el mensaje.
El Emisor se establece en el valor arbitrario HTTP porque el nodo de integración
no establece la propiedad de cabecera UserAgent de HTTP.

Ejecutar el ejemplo con un mensaje WebSphere MQ que

contiene credenciales de identidad en el cuerpo del
mensaje
Para superar la restricción de que el MQMD de WebSphere MQ sólo puede proporcionar el
emisor y la señal de identidad de usuario, se ha proporcionado un nodo MQInput adicional.
Este nodo está configurado para extraer un conjunto completo de credenciales de seguridad
de campos del cuerpo del mensaje.

Para ejecutar el ejemplo con el mensaje WebSphere MQ que contiene una señal de
identidad de usuario en el cuerpo del mensaje:

1. En la vista Desarrollo de aplicaciones, expanda el proyecto

SecurityIdentitySampleFlowProject. Expanda el directorio Pruebas de flujo y efectúe una
doble pulsación en Security_Identity_MSG_ID.mbtest para abrir el archivo en el Cliente de
prueba.
2. Pulse Colocar en cola. Observe que el mensaje contiene elementos en la carpeta
Body.MessageIdentity, que define las siguientes credenciales de identidad:
o Username: IdInMsg
o Password: PwdInMsg
o IssuedBy: InMsgIssuer
3. Expanda Cabecera en la sección Propiedades detalladas. Observe que la Cabecera de
mensaje seleccionada es Cabecera predeterminada. Si cambia al separador Configuración
en el Cliente de prueba y selecciona Cabeceras de mensajes MQ"Cabecera
predeterminada", puede ver los detalles de la cabecera. El ID de usuario y el Nombre de
aplicación de transferencia están en blanco.
4. En el separador Sucesos, pulse Enviar mensaje. El mensaje se coloca en la cola
SECURITYIDFROMMSGIN.
5. Fíjese en los resultados:
o Obtenga el mensaje resultante de la cola SECURITYIDFROMMSGOUT.
1. En el Cliente de prueba, pulse Extraer de la cola.
2. Pulse Obtener mensaje. El mensaje de salida se visualiza en Mensaje.
o Puede ver los elementos body que se han creado en el flujo de mensajes
SecurityIdentityReportFlow a partir del mensaje de entrada.
o Observe que la identidad presentada en el mensaje de salida coincide con los
detalles de los elementos MessageIdentity del mensaje de entrada. El emisor está
establecido en el valor arbitrario HTTP porque el emisor no se propaga.

Ejecutar el ejemplo con un mensaje WebSphere MQ que

solicita que esté establecida una identidad correlacionada
Al trabajar con mensajes de WebSphere MQ que sólo contienen el nombre de usuario y el
emisor, a menudo es necesario invocar una correlación de identidad federada en las
credenciales. Las credenciales pueden correlacionarse luego en un formato que sea
adecuado para invocar una solicitud de servicio, por ejemplo, que requiere un nombre de
usuario y contraseña. Normalmente se invoca un gestor de identidad federada externo para
realizar esta operación. Este ejemplo ofrece una solución sencilla en la que se utiliza un
nodo Compute para correlacionar la identidad entrante, para que se creen las credenciales
de seguridad siguientes:
  El tipo de señal es nombre de usuario y contraseña.
 El nombre de usuario se crea como "minúsculas(id recibido)" + "@company.com".
 La contraseña se crea como "p_" + "minúsculas(id recibido)" + "año(indicación de fecha y
hora actual)".

Para ejecutar el ejemplo con el mensaje de entrada de WebSphere MQ que contiene una
solicitud para establecer la identidad correlacionada basándose en el nombre de usuario que
se pasa en el MQMD del mensaje:

1. En la vista Desarrollo de aplicaciones, expanda el proyecto

SecurityIdentitySampleFlowProject. Expanda el directorio Pruebas de flujo y efectúe una
doble pulsación en Security_Identity_Mapped.mbtest para abrir el archivo en el Cliente de
prueba.
2. Pulse Colocar en cola. Observe que el mensaje contiene el elemento Body.MapIdentity. La
presencia de este elemento en el mensaje hace que el ESQL del flujo de mensajes
SecurityIdentitySampleFlow establezca las credenciales de identidad correlacionada tal
como se ha descrito antes.
3. Expanda Cabecera en la sección Propiedades detalladas. Observe que la Cabecera de
mensaje seleccionada es Enviar identidad. Si cambia al separador Configuración del Cliente
de prueba y selecciona Cabecera de mensaje MQ "Enviar identidad", puede ver los
detalles de la cabecera. Estos detalles incluyen TESTUSER como ID de usuario y
BRKTSTCLNT como Nombre de aplicación de transferencia.
4. En el separador Sucesos, pulse Enviar mensaje. El mensaje se coloca en la cola
SECURITYIDFROMMQIN.
5. Fíjese en los resultados:
o Obtenga el mensaje resultante de la cola SECURITYIDFROMMQOUT:
1. En el Cliente de prueba, pulse Extraer de la cola
2. Pulse Obtener mensaje. El mensaje de salida se visualiza en Mensaje.

Puede ver los elementos body que se han creado en el flujo de

mensajes SecurityIdentityReportFlow a partir del mensaje de
entrada.

Observe que la identidad presentada en el mensaje de salida se ha

creado a partir de la correlación del nombre de usuario enviado en el
MQMD del mensaje de entrada:

 Señal: "testuser@company.com"
 Contraseña: "p_" + <nombre_usuario> + <año_actual> Por
ejemplo, "p_testuser2013"

El emisor está establecido en el valor arbitrario HTTP porque el

emisor no se propaga.

Ejecutar el ejemplo con un mensaje de solicitud HTTP

El transporte HTTP permite pasar credenciales de seguridad, tales como nombre de usuario
y contraseña, en la cabecera HTTP. Se ha proporcionado una aplicación Java para ejecutar
el ejemplo con un mensaje de solicitud HTTP que contiene una señal de identidad y
contraseña de usuario en la cabecera de autenticación básica HTTP. La aplicación Java le
permite someter el contenido de un archivo de texto, que incluye un nombre de usuario y
contraseña, al nodo HTTPInput del flujo de mensajes de ejemplo.

El programa de ejemplo tiene los siguientes argumentos:

java BasicAuthHttpPost
<HostURL> <PuertoURL> <SufijoVíaAccesoURL> <Archivo XML>
[<IdUsuario> <Contraseña> ]

Donde los argumentos son:

 <HostURL> - Nombre de host al que enviar la solicitud HTTP; se establece en localhost.

 <PuertoURL> - Puerto de servicio HTTP; es el valor predeterminado del nodo de
integración de 7080.
 <SufijoVíaAccesoURL> - Sufijo de URL de HTTP; es /Security/IdentityFromHttp.
 <Archivo XML> - Vía de acceso al archivo que contiene los datos a enviar como el cuerpo
de la solicitud HTTP. Este archivo es Messages\Simple.xml porque el archivo de datos del
mensaje de ejemplo Simple.xml está situado en el mismo proyecto que el código fuente
Java en el paquete Message.
 <IdUsuario> - ID de usuario en texto sin formato a enviar en la cabecera de solicitud HTTP.
 <Contraseña> - Contraseña en texto sin formato a enviar en la cabecera de solicitud HTTP.

Para ejecutar el ejemplo con un mensaje de solicitud HTTP:

1. En IBM Integration Toolkit, vaya a la perspectiva Java.

2. En la vista Explorador de paquetes, expanda el paquete com.ibm.wmb.sample.httpClient
expandiendo el proyecto SecurityIdentitySampleApplicationProject.
3. Pulse con el botón derecho del ratón HttpPostFileWithBAuth.java en
com.ibm.wmb.sample.httpClient y seleccione Ejecutar como > Ejecutar configuraciones
para que se abra el asistente Ejecutar configuraciones.
4. Efectúe una doble pulsación en Aplicación Java en la vista de árbol de la izquierda y
seleccione la configuración denominada HttpPostFileWithBAuth.
5. En el separador Principal, asegúrese de que Proyecto esté establecido en
SecurityIdentitySampleApplicationProject.
6. Asegúrese de que Clase principal esté establecida en
com.ibm.wmb.sample.httpClient.HttpPostFileWithBAuth.
7. Cambie al separador Argumentos del asistente Ejecutar y entre lo siguiente en
Argumentos del programa:

En Windows:

localhost 7080 /Security/IdentityFromHttp

Messages\Simple.xml HttpUserName HttpPassword
 En Linux o Unix:

localhost 7080 /Security/IdentityFromHttp

Messages/Simple.xml HttpUserName HttpPassword

8. Ha creado la configuración de ejecución.

Inicie la aplicación para enviar la solicitud HTTP al ejemplo pulsando Ejecutar. Fíjese en los
resultados:
o La salida de la aplicación Java HttpPostFileWithBAuth se muestra en la vista
Consola. La vista Consola muestra la respuesta HTTP recibida o detalla los errores
de la acción de enviar o recibir.
o El mensaje de respuesta HTTP que se visualiza tiene elementos en la carpeta Body
que se crearon en el flujo de mensajes SecurityIdentityReportFlow.
o La identidad presentada en el mensaje de salida es HttpUserName y
HttpPassword. Estos son los valores que se pasaron como argumentos a la
aplicación de prueba y se enviaron en la cabecera de mensaje de solicitud HTTP.
La presencia de estos valores demuestra que la identidad se ha propagado a
través de la solicitud HTTP desde el nodo de integración.
Acerca del ejemplo Pasarela de servicios web

El ejemplo Pasarela de servicios web muestra cómo utilizar nodos SOAP, en modalidad de
pasarela, para invocar y proporcionar un servicio web. Este ejemplo se basa en dos ejemplos
existentes (Nodos SOAP y Libreta de direcciones) y modifica el URL en los nodos SOAPRequest de
modo que todas las solicitudes se direccionen a través de un nuevo flujo de pasarela que reenvía
la solicitud al proveedor de servicios web apropiado.

En el ejemplo, la operación se extrae del mensaje de solicitud SOAP y se utiliza un servicio

configurable definido por el usuario para recuperar el URL del proveedor de servicio web.

El asistente del ejemplo sustituye el URL en los nodos SOAPRequest en los archivos de
archivador de intermediario (bar) de flujo de consumidor. Si opta por volver a crear los
archivos bar, es posible que estos valores se borren y que el flujo de pasarela no se invoque.

El ejemplo Pasarela de servicios web muestra las siguientes tareas:

 Cómo crear una pasarela de servicio web.

 Cómo utilizar los servicios configurables definidos por el usuario.

Antes de empezar
Antes de empezar, debe familiarizarse con los ejemplos existentes sobre los que se basa
este ejemplo:

 Ejemplo Libreta de direcciones

 Ejemplo Nodos SOAP
El Flujo de mensajes
El siguiente diagrama muestra el flujo de mensajes Pasarela de servicios web:

La tabla siguiente muestra los nodos en el flujo de mensajes:

Tipo de nodo Nombre de nodo

SOAPInput GatewayInput

JavaCompute ComputeURL

SOAPRequest SOAP Request

SOAPReply GatewayReply

El nodo SOAPInput opera en la modalidad de pasarela y acepta solicitudes de los flujos de

consumidor del ejemplo Libreta de direcciones o del ejemplo Nodo SOAP.

El nodo JavaCompute obtiene el nombre de operación del mensaje de solicitud entrante y lo

almacena en csName. El asistentes de configuración del ejemplo crea un servicio
configurable definido por el usuario denominado Gateway, y una propiedad que coincide
con los nombres de operación para dos flujos de consumidor de los ejemplos existentes. El
proxy de intermediario (BrokerProxy) se utiliza para obtener el valor del servicio
configurable y establecer el URL para la solicitud en el entorno local.

List nodeset =
(List)message.getRootElement().evaluateXPath("SOAP/Body/*[1]");
String csName=((MbElement)(nodeset.get(0))).getName();

String URL = null;

try {
//Obtener el proxy de intermediario
BrokerProxy bp = BrokerProxy.getLocalInstance();
//Buscar el URL de un servicio configurable
URL =
bp.getConfigurableServiceProperty("UserDefined/Gateway/"+csName);
} catch (Exception e) {
URL="/";
}
//Establecer el URL de servicio web (WebServiceURL) creando la vía de
acceso si no existe
le.getRootElement().evaluateXPath("?Destination/?SOAP/?Request/?Transport
/?HTTP/?WebServiceURL[set-value('"+URL+"')]");

El nodo SOAPRequest envía la solicitud al flujo de proveedor apropiado.

El nodo SOAPReply devuelve la respuesta al flujo de consumidor que llama.

Los mensajes
Los mensajes SOAP se generan a través de los flujos de cliente y proveedor existentes. El
flujo de pasarela utiliza el nombre de operación para direccionarlo al proveedor correcto.

Ampliar el ejemplo
Una vez que haya ejecutado el ejemplo, es posible que desee ampliarlo añadiendo otro
proveedor de servicios web. Dado que el servicio configurable se utiliza para almacenar el
URL para el proveedor, todo los que debe hacer es añadir una propiedad con el nombre de
una operación de servicio existente y el valor establecido en el URL.

Ejecutar el ejemplo Pasarela de servicios web

La ejecución del ejemplo Pasarela de servicios web consiste en poner mensajes a través de
los flujos de mensajes. Para ejecutar este ejemplo, puede utilizar el Cliente de prueba para
colocar mensajes de entrada en cualquiera de los flujos de mensajes de consumidor. Para
obtener más información sobre el Cliente de prueba, consulte Comprobación de los flujos
de mensajes utilizando el Cliente de prueba en la documentación de IBM Integration Bus.

Si encuentra algún problema al ejecutar el ejemplo, consulte Resolver problemas al ejecutar

ejemplos en la documentación de IBM Integration Bus. Al volver a crear los archivos de
archivador de intermediario también puede aparecer un error en el que se notifique que en
el proyecto WebServiceGatewayJava falta una biblioteca necesaria. Consulte el tema
Añadir dependencias de código Java y compruebe que las ubicaciones de instalación son
correctas.

Verificar que el proveedor tiene las propiedades

correctas para el consumidor
Si desea verificar que el consumidor de servicios web está bien configurado, siga las
instrucciones que se indican a continuación. Si ha configurado un supervisor TCP/IP,
entonces ya ha comprobado qué puerto está utilizando el proveedor de servicios web, pero
debe configurar de todas formas el consumidor para enviar los mensajes al supervisor
TCP/IP y, a continuación, crear y volver a desplegar el archivo de archivador de
intermediario (BAR).

El puerto predeterminado que utilizan los servicios web es el 7800, y las solicitudes SOAP
están configuradas para utilizar este puerto. Sin embargo, si este puerto ya se está
utilizando, el número de puerto se incrementa en uno.

Para comprobar qué puerto está utilizando el servidor del proveedor, emita el siguiente
mandato mqsireportproperties:

mqsireportproperties IB9NODE -e WebServiceGatewaySample -o HTTPConnector

-n port

Siga los pasos que se indican a continuación para verificar que los nodos SOAPRequest
utilizan el puerto correcto, y para sustituir el puerto del nodo SOAPRequest en los archivos
de archivador de intermediario (BAR) por el puerto utilizado por el servidor del proveedor:

1. Abra el archivo de archivador de intermediario en cada uno de los proyectos de ejemplo

(Libreta de direcciones y Nodo SOAP).
2. Seleccione el separador Gestionar.
3. Cambie el puerto en el URL para los nodos SOAPRequest.
4. Guarde el archivo BAR.

Para verificar que el puerto es correcto en el servicio configurable, siga estos pasos:

1. Abra MQ Explorer.
2. Pulse el botón derecho del ratón y seleccione las propiedades del Servicio configurable
definido por el usuario llamado Gateway.
3. Cambie el puerto de cada propiedad y pulse Finalizar.