Ibm Integration Bus - Ejercicios.docx

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 Smith Jack

staffmsg2: <Staff> <StaffNumber>2 Doe Jane

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 o

JMSREQUESTQ 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="..." 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: AVAILABLE 50 <partNo>Some Part <partQuantity>1

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 SOAPInput

Nombre de nodo 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: Message Broker <Street>IBM IBM IBM <PartNumber>Some Part 1

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: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: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"/>

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 o

JMSREQUESTQ 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. 2. 3. 4.

Crear el flujo de mensajes y el conjunto de mensajes de servicio web Crear el conjunto de mensajes de controlador de cliente Crear el flujo de cliente de servicios web 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: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: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"/>

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:

   

<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:

       

<Envelope> <MessageIdentity> <Username>IdInMsg <Password>PwdInMsg InMsgIssuer





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:

    

<Envelope> <MapIdentity>true

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. 2. 3. 4. 5.

Crear el subflujo de mensajes Crear el flujo de mensajes de Informe de identidad Flujo de mensajes principal Crear las colas 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: "[email protected]" Contraseña: "p_" + <nombre_usuario> + 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 <SufijoVíaAccesoURL> [ ]

Donde los argumentos son:    

 

- Nombre de host al que enviar la solicitud HTTP; se establece en localhost. - 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. - 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. - ID de usuario en texto sin formato a enviar en la cabecera de solicitud HTTP. - 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.