Este tema contiene los apartados siguientes:
Utilice el nodo HTTPInput para recibir peticiones de servicios web para que las procese un flujo de mensajes. Al utilizar el nodo HTTPInput con los nodos HTTPReply y HTTPRequest, el intermediario puede actuar como un intermediario para servicios web, y las peticiones de servicios web se pueden transformar y direccionar del mismo modo que los demás formatos de mensaje para los que ofrece soporte WebSphere Business Integration Message Broker.
Si incluye un nodo HTTPInput en un flujo de mensajes, debe incluir un nodo HTTPReply en el mismo flujo, o bien, pasar el mensaje a otro flujo que incluya un nodo HTTPReply (por ejemplo, a través de un nodo MQOutput a un segundo flujo que se inicie con un nodo MQInput). En este último caso, el identificador de peticiones almacenado en el entorno local coordina la petición y la respuesta del cliente (se describe más abajo).
El nodo HTTPInput maneja mensajes de los dominios de mensajes siguientes:
Cuando el nodo HTTPInput recibe un mensaje de un cliente de servicios web, invoca a los analizadores adecuados para que interpreten las cabeceras y el cuerpo del mensaje y para que creen el árbol de mensajes que utiliza el flujo de mensajes internamente. El nodo crea un identificador exclusivo para el mensaje de entrada y lo almacena en una matriz binaria de 24 bytes en el árbol LocalEnvironment de LocalEnvironment.Destination.HTTP.RequestIdentifer. El nodo HTTPReply utiliza este valor y no se debe modificar en modo alguno.
Los mensajes HTTP siempre son no permanentes y no tienen ningún orden asociado.
Los mensajes HTTP son no transaccionales. Sin embargo, si el flujo de mensajes interactúa con una base de datos u otro recurso externo como, por ejemplo, una cola WebSphere MQ, estas interacciones se llevan a cabo transaccionalmente. El nodo HTTPInput proporciona confirmación o restitución, en función de cómo finaliza el flujo de mensajes y cómo se ha configurado para el manejo de errores (cómo se han conectado los terminales de anomalías, por ejemplo). Si este nodo restituye el flujo de mensajes, se genera un mensaje de error SOAP y se devuelve al cliente de servicios web.
Si se produce una excepción en sentido descendente en este flujo de mensajes, y no se captura pero se devuelve a este nodo, el nodo construye una respuesta de error para el cliente invocador. Esta respuesta es un mensaje de error SOAP derivada de la excepción en sí.
Si incluye un nodo de salida en un flujo de mensajes que empieza con un nodo HTTPInput, puede ser cualquiera de los nodos de salida para los que se ofrece soporte (incluidos los nodos de salida definidos por el usuario). Puede crear un flujo de mensajes que reciba mensajes de clientes de servicios web y genere mensajes para clientes que utilicen todos los transportes para los que se ofrece soporte para conectar al intermediario, puesto que puede configurar el flujo de mensajes de modo que solicite al intermediario que facilite las conversiones necesarias.
Si crea un flujo de mensajes para utilizarlo como un subflujo, no puede utilizar un nodo de entrada estándar; debe utilizar una instancia del nodo Input como primer nodo para crear un terminal de entrada para el subflujo.
Si el flujo de mensajes no recibe peticiones de servicios web, puede elegir uno de los nodos de entrada que se indican a continuación:
El nodo HTTPInput se representa en el área de trabajo mediante el icono siguiente:
Puede utilizar este nodo en dos escenarios diferentes:
El cliente de servicios web genera una petición de servicios web que, a continuación, se dirige al nodo HTTPInput de un flujo de mensajes que se ejecuta en el intermediario. El flujo de mensajes se debe diseñar para que procese el mensaje utilizando el mismo procedimiento y genere una respuesta que tenga el formato de una respuesta de servicio web. El intermediario envía la respuesta al cliente de servicios web a través del nodo HTTPReply del flujo de mensajes.
Por ejemplo, tiene clientes de servicios web que interactúan con un servicio web que proporciona información específica sobre un tema determinado (precios de valores o tipos de cambio, por ejemplo). Sustituye este servicio por una solución de búsqueda de base de datos interna, pero no desea realizar cambios en las aplicaciones cliente. Diseña un flujo de mensajes que incluye un nodo HTTPInput que recibe peticiones de sus clientes. Este nodo conecta a un nodo Compute que recupera la información necesaria de la base de datos y genera un nuevo mensaje de salida, con el formato de una respuesta de servicio web y que incluye los nuevos datos. El nodo Compute pasa el mensaje al nodo HTTPReply, lo que genera la respuesta para el cliente de servicios web.
El cliente de servicios web genera una petición de servicio web que, a continuación, se dirige al nodo HTTPInput de un flujo de mensajes que se ejecuta en el intermediario. El flujo de mensajes se debe diseñar para que procese el mensaje utilizando el mismo procedimiento y para que interactúe con el servicio web al que la aplicación cliente considera que está conectado. Debe incluir un nodo HTTPRequest en el flujo de mensajes para que envíe una petición al servicio web y recupere la respuesta. El flujo de mensajes también genera una respuesta para el cliente, basada en toda o en parte de la respuesta que se ha recibido en el nodo HTTPRequest, con el formato de una respuesta de servicio web. El intermediario envía la respuesta al cliente de servicios web a través del nodo HTTPReply del flujo de mensajes.
Por ejemplo, dispone de una aplicación cliente que interactúa con un servicio web que envía información a otra aplicación que solicita la información en otro formato. Diseña un nuevo flujo de mensajes que incluye un nodo HTTPInput, un nodo HTTPRequest y un nodo HTTPReply. El nodo HTTPInput recibe la entrada del cliente de servicios web y pasa el mensaje al nodo HTTPRequest, que interactúa con el servicio web.
Cuando se recibe la respuesta, el nodo HTTPRequest propaga el mensaje a un nodo Compute, que crea un mensaje de salida en formato existente a partir del contenido de la respuesta del servicio web. El flujo de mensajes finaliza con un nodo MQOutput, que entrega el mensaje transformado a la aplicación existente, seguida de un nodo HTTPReply que proporciona la respuesta adecuada para el cliente de servicios web.
En un segundo ejemplo, los clientes interactúan con un servicio web y desea conservar información sobre las peticiones al servicio web por motivos de auditoría. Diseña un flujo de mensajes que incluye un nodo HTTPInput conectado a un nodo Warehouse. El mensaje de entrada que se recibe del cliente de servicios web se almacena en la base de datos y el nodo Warehouse pasa el mensaje a un nodo HTTPRequest, que interactúa con el servicio web. Cuando se recibe la respuesta, el nodo HTTPRequest la propaga al nodo HTTPReply, que genera la respuesta para el cliente de servicios web.
Se puede configurar al transferir una instancia del nodo HTTPInput a un flujo de mensajes. Pulse el botón derecho del ratón en la vista del editor y, a continuación, pulse en Propiedades. En el diálogo de propiedades se muestran las propiedades básicas del nodo.
Todas las propiedades obligatorias para las que debe entrar un valor (las que no tienen un valor por omisión definido) se muestran marcadas con un asterisco en el diálogo de propiedades.
Configure el nodo HTTPInput tal como se indica a continuación:
Deje el campo Conjunto de mensajes en blanco para los analizadores XML, XMLNS, JMS y BLOB.
Deje el campo Tipo de mensaje en blanco para los analizadores XML, XMLNS, JMS y BLOB.
Deje el campo Formato del mensaje en blanco para los analizadores XML, XMLNS, JMS y BLOB.
Los destinos de las anomalías se comportan igual que en el caso de la salida del nodo Trace. Así, si, por ejemplo, se selecciona Rastreo de usuario, las entradas de rastreo se escriben sin tener en cuenta el valor del distintivo del rastreo de usuario para el flujo de mensajes.
Pulse el botón en Cancelar para cerrar el diálogo y descartar todos los cambios que ha realizado en las propiedades.
HTTPInput direcciona cada mensaje que recupera correctamente al terminal de salida. Si la validación del mensaje da error, el mensaje se direcciona al terminal de anomalías; puede conectar nodos a este terminal para manejar esta condición. Si no ha conectado el terminal de anomalías, el mensaje se descarta, el Tiempo máximo de espera de cliente finaliza y el escucha TCP/IP devuelve un error al cliente. No existen otras situaciones en las que el mensaje se direccione al terminal de anomalías.
Si el nodo capta el mensaje después de emitirse una excepción más adelante en el flujo de mensajes, el mensaje se direcciona al terminal de captación. Si no se ha conectado el terminal de captación, el mensaje se descarta, el Tiempo máximo de espera de cliente finaliza y el escucha TCP/IP devuelve un error al cliente.
Los terminales del nodo HTTPInput se describen en la tabla siguiente:
Terminal | Descripción |
---|---|
Terminal de anomalías | Terminal de salida al que se direcciona el mensaje si se produce un error. |
Terminal de salida | Terminal de salida al que se direcciona el mensaje si se recupera correctamente. |
Terminal de captación | Terminal de salida al que se direcciona el mensaje si se emite una excepción en sentido descendente y la captura este nodo. |
En las tablas siguientes se describen las propiedades del nodo; la columna que tiene el encabezamiento M indica si se trata de una propiedad obligatoria (marcada con un asterisco en el diálogo de propiedades si se debe especificar un valor cuando no se ha definido ningún valor por omisión), la columna que tiene el encabezamiento C indica que se trata de una propiedad configurable (se puede cambiar el valor cuando se añade el flujo de mensajes al archivo bar para su difusión).
Las propiedades básicas del nodo HTTPInput se describen en la tabla siguiente:
Propiedad | M | C | Valor por omisión | Descripción |
---|---|---|---|---|
Selector de URL | Sí | Sí | Ubicación de la que se recuperan las peticiones de servicios web. Debe proporcionarlo en uno de los formatos siguientes:http://<nombreSistema>[:<puerta>]/[<víaAcceso>]o bien /<fragmento vía de acceso>/*donde * es un carácter comodín que se puede utilizar para cualquier coincidencia. |
|
Tiempo máximo de espera de cliente | Sí | No | 180 | Tiempo que espera el escucha, en segundos, antes de enviar un mensaje de error al cliente. El rango válido es de cero (lo que significa una espera indefinida) a (231)-1. |
Las propiedades por omisión del nodo HTTPInput se describen en la tabla siguiente:
Propiedad | M | C | Valor por omisión | Descripción |
---|---|---|---|---|
Dominio del mensaje | No | No | Dominio del mensaje entrante. | |
Conjunto de mensajes | No | No | Conjunto de mensajes del mensaje entrante. | |
Tipo de mensaje | No | No | Tipo del mensaje entrante. | |
Formato del mensaje | No | No | Formato del mensaje entrante. |
Las propiedades de validación del nodo HTTPInput se describen en la tabla siguiente:
Propiedad | M | C | Valor por omisión | Descripción |
---|---|---|---|---|
Validar | Sí | No | Ninguna | Si debe llevarse a cabo la validación. Los valores válidos son Ninguna y Contenido y valor. |
Acción por anomalía | Sí | No | Rastreo de usuario | Lo que sucede si la validación da error. Sólo puede establecer esta propiedad si ha establecido Validar en Contenido y valor. Los valores válidos son Rastreo de usuario, Anotaciones de error locales y Excepción. |
Cronometraje | Sí | No | Diferido | Cuando se produce la validación. Sólo puede establecer esta propiedad si ha establecido Validar en Contenido y valor. Los valores válidos son Diferido, Inmediato y Completo. |
Incluir todas las limitaciones de valores | Sí | No | Seleccionado | Esta propiedad no se puede cambiar. |
Arreglo | Sí | No | Ninguno | Esta propiedad no se puede cambiar. |
Las propiedades de descripción del nodo HTTPInput se describen en la tabla siguiente:
Propiedad | M | C | Valor por omisión | Descripción |
---|---|---|---|---|
Descripción corta | No | No | Descripción breve del nodo. | |
Descripción larga | No | No | Texto que describe la finalidad del nodo en el flujo de mensajes. |
Conceptos relacionados
WebSphere MQ Web Services Transport
Flujos de mensajes
Extensiones definidas por el usuario
Tareas relacionadas
Cómo decidir los nodos que utilizar
Utilización de más de un nodo de entrada
Manejo de errores en flujos de mensajes
Edición de propiedades configurables
Referencia relacionada
Nodo Compute
Nodo HTTPReply
Nodo HTTPRequest
Nodo Input
Nodo MQeInput
Nodo MQInput
Nodo MQOutput
Nodo Real-timeInput
Nodo SCADAInput
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
ac04565_ |