Utilice el nodo HTTPAsyncRequest con el nodo HTTPAsyncResponse para crear un par de flujos de mensajes que interactúen con un servicio web de manera asíncrona.
El nodo HTTPAsyncRequest envía una solicitud de servicio web, pero el nodo no espera a que se reciba la respuesta de servicio web asociada. La respuesta de servicio web la recibe el nodo HTTPAsyncResponse, que puede estar en un flujo de mensajes independiente pero debe estar en el mismo grupo de ejecución. Los nodos se utilizan como un par y correlacionan las respuestas con las solicitudes originales utilizando un identificador exclusivo. El nodo HTTPAsyncRequest pasa el socket de solicitud al nodo HTTPAsyncResponse para que el servidor de fondo lo utilice para la respuesta. Si la latencia del servidor de fondo es alta, es posible que no responda en el tiempo de espera de socket.
Pasar el socket HTTP al nodo HTTPAsyncResponse permite el flujo de mensajes para recuperar el siguiente mensaje de la cola sin esperar a la respuesta y por lo tanto utiliza hebras y almacenamiento de modo más eficaz que un flujo de mensajes síncrono.
En función de la configuración, este nodo construye una solicitud HTTP o HTTP sobre SSL (HTTPS) a partir del contenido especificado del mensaje de entrada, y envía esta solicitud al servicio web. El nodo HTTPAsyncResponse recibe la respuesta del servicio web y analiza la respuesta para incluirla en el árbol de salida. El nodo HTTPAsyncRequest genera cabeceras HTTP si la configuración las necesita.
El nodo HTTPAsyncRequest está contenido en el cajón HTTP de la paleta y se representa en WebSphere Message Broker Toolkit mediante el icono siguiente:
El URL tiene el formato http://<dirección>[:<puerto>]/<función>; por ejemplo, http://localhost:7080/request. Este URL se puede especificar estáticamente en los parámetros de nodo HTTPAsyncRequest como un campo en el propio mensaje o dinámicamente como un campo en el entorno local.
Los datos deben estar en formato CCSID 1208 para la mayoría de las solicitudes. Si la solicitud se realiza satisfactoriamente, se devuelve la HTTPResponse al nodo emparejado HTTPAsyncResponse.
Puede utilizar un proxy HTTP para direccionar una solicitud mediante un sitio intermedio. Puede ejecutar herramientas como un proxy para ver la solicitud y la respuesta y, de este modo, depurar sus flujos. El destino HTTP es tal como lo ve el proxy; si especifica el destino HTTP de localhost y el proxy HTTP se está ejecutando en otro sistema, la solicitud se direcciona al sistema de proxy remoto, no al sistema desde el que se ha emitido la solicitud original.
Puede especificar un intervalo de tiempo de espera, para que si la duración de la operación de solicitud-respuesta es mayor que la duración especificada, la solicitud se propague al terminal de anomalías de uno de los nodos emparejados. El intervalo de tiempo de espera se aplica al intervalo que empieza cuando el nodo HTTPAsyncRequest envía la solicitud y finaliza cuando el nodo HTTPAsyncResponse recibe por completo la respuesta.
Para cada solicitud que el nodo HTTPAsyncRequest procesa, utiliza una conexión para enviar la solicitud y pasa la conexión al nodo HTTPAsyncResponse emparejado. Si se especifica el intervalo de tiempo de espera, el socket se cierra si el intervalo caduca. Este cierre asegura que una solicitud reciba solamente la respuesta correcta y que todos los datos de respuesta para una solicitud que ha excedido el tiempo de espera se descarten.
El proceso de solicitud-respuesta se divide entre el nodo HTTPAsyncRequest y el nodo HTTPAsyncResponse. Si se produce un tiempo de espera excedido durante la fase de solicitud del proceso, la solicitud y una excepción se propagan al terminal de anomalías del nodo HTTPAsyncRequest. De forma similar, si se produce un tiempo de espera durante la fase de respuesta del proceso, se propaga una excepción al terminal de anomalías del nodo HTTPAsyncResponse.
En la mayoría de los casos el tiempo de espera se produce cuando se espera una respuesta de servidor, en cuyo caso se utiliza el terminal de anomalías del nodo HTTPAsyncResponse. En casos excepcionales se puede producir un tiempo de espera cuando el nodo de solicitud envía datos al servidor. En este caso, se utiliza el terminal de anomalías del nodo HTTPAsyncRequest.
El nodo HTTPAsyncRequest se puede utilizar en cualquier flujo de mensajes que deba enviar una solicitud HTTP y recibir una respuesta asíncronamente. El ejemplo más común es un flujo de mensajes que invoca un servicio web.
Para obtener más información sobre cómo trabajar con HTTP, consulte Proceso de mensajes HTTP.
El nodo interactúa directamente con un servicio externo utilizando TCP/IP; por consiguiente, puede experimentar errores generados por TCP/IP. Por ejemplo, no hay vía de acceso al host o conexión rechazada. Si el nodo detecta estos errores, genera una excepción, llena la lista de excepciones con la información de error recibida y dirige el mensaje de entrada sin modificar al terminal de anomalías.
Los terminales del nodo HTTPAsyncRequest están descritos en la siguiente tabla.
Terminal | Descripción |
---|---|
Entrada | El terminal de entrada que acepta un mensaje para que lo procese el nodo. |
Anomalías | El terminal de salida al que se dirige un mensaje si se ha detectado una anomalía durante su proceso en el nodo. |
Salida | El terminal de salida al que se direcciona el mensaje si representa la finalización satisfactoria de la solicitud de servicio web y si se requiere proceso adicional dentro del flujo de mensajes. |
Las tablas siguientes describen las propiedades del nodo. La columna con la cabecera O indica si la propiedad es obligatoria (marcada con un asterisco en el panel si tiene que entrar un valor cuando no hay definido ningún valor predeterminado); la columna con la cabecera C indica si la propiedad es configurable (puede cambiar el valor cuando añade el flujo de mensajes al archivo de intermediario para desplegarlo).
Las propiedades de descripción del nodo HTTPAsyncRequest están descritas en la siguiente tabla.
Propiedad | O | C | Valor predeterminado | Descripción |
---|---|---|---|---|
Nombre de nodo | No | No | El tipo de nodo, HTTPAsyncRequest | El nombre del nodo. |
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. |
Las propiedades básicas del nodo HTTPAsyncRequest se describen en la siguiente tabla.
Propiedad | O | C | Valor predeterminado | Descripción | Propiedad de mandato mqsiapplybaroverride |
---|---|---|---|---|---|
Identificador exclusivo | Sí | No | Esta propiedad es el identificador exclusivo que enlaza un par de nodos HTTPAsyncRequest y HTTPAsyncResponse. | asyncResponseCorrelator | |
URL de servicio web | Sí | Sí | El URL del servicio web. Debe proporcionarlo en el formato
http://nombre_host[:puerto]/[vía_acceso]
donde
El nodo HTTPAsyncRequest determina el URL para el servicio web al que envía una solicitud. Seleccione una de las siguientes tres opciones; el nodo las comprueba en el orden en que se muestran (es decir, la primera siempre prevalece sobre la segunda y ésta sobre la tercera):
Las dos primeras opciones proporcionan métodos dinámicos para establecer un URL para cada mensaje de entrada cuando éste pasa a través del flujo de mensajes. Para usar de estas opciones, incluya un nodo Compute en el flujo de mensajes, antes del nodo HTTPAsyncRequest, para crear e inicializar el valor necesario. La tercera opción proporciona un valor que es fijo para cada mensaje recibido en este nodo. Establezca esta propiedad para que contenga un valor predeterminado que se utilice si los demás campos no se han creado o contienen un valor nulo. Si uno de los campos contiene un valor, se ignora el valor de esta propiedad. La propiedad URL de servicio web debe contener un URL válido o el despliegue falla. Asegúrese de que el valor que establece en X-Original-HTTP-URL o LocalEnvironment.Destination.HTTP.RequestURL es también un URL válido; si no lo es, el nodo utiliza el valor predeterminado de la propiedad URL de servicio web. |
URLSpecifier | |
Tiempo de espera de solicitud (seg) | Sí | Sí | 120 | El valor del tiempo de espera para que el servidor web remoto
envíe una respuesta al nodo HTTPAsyncResponse. El rango válido es de 1 a (231)-1. No se puede entrar un valor
que represente una espera ilimitada. Para obtener más información sobre el comportamiento de tiempo de espera, consulte Tiempos de espera. |
timeoutForServer |
Las propiedades de valores HTTP del nodo HTTPAsyncRequest se describen en la siguiente tabla.
Propiedad | O | C | Valor predeterminado | Descripción | Propiedad de mandato mqsiapplybaroverride |
---|---|---|---|---|---|
Ubicación de proxy HTTP(S) | No | Sí | Servidor proxy al que se envían solicitudes. Este valor debe estar en el formato nombre_host:puerto. | httpProxyLocation | |
Método HTTP | No | No | POST | El método HTTP. Los valores válidos son POST, GET, PUT, DELETE y HEAD. De forma predeterminada, el nodo HTTPAsyncRequest utiliza el método HTTP POST cuando se conecta al servidor web remoto. HEAD se utiliza para determinar si está disponible un servicio; por ejemplo, puede utilizarlo un asignador de red que intenta averiguar qué servidores están activos y disponibles, y envía las cabeceras correctas (incluyendo content-length) pero no datos del cuerpo. | |
Usar compresión | No | Sí | Ninguno | Esta propiedad controla si el contenido de la
solicitud HTTP está comprimido. Puede seleccionar las opciones none, gzip, zlib (deflate) y deflate. Si la solicitud está comprimida, la cabecera
Content-Encoding se establece para indicar que el contenido está
comprimido. zlib (deflate) representa la combinación RFC 1950 + RFC 1951. deflate representa RFC 1951 únicamente. El valor predeterminado es none, lo que significa que el contenido de la solicitud no estará comprimido. |
requestCompressionType |
Las propiedades de SSL del nodo HTTPAsyncRequest se describen en la siguiente tabla.
Propiedad | O | C | Valor predeterminado | Descripción | Propiedad de mandato mqsiapplybaroverride |
---|---|---|---|---|---|
Protocolo | No | Sí | TLS | Especifique la propiedad Protocolo SSL
a utilizar al realizar una solicitud HTTPS. Ambos extremos de una conexión SSL deben coincidir con el protocolo que van a utilizar. Por lo tanto, el protocolo seleccionado debe ser uno que el servidor remoto pueda aceptar. Están disponibles las opciones siguientes:
|
protocol |
Cifrados SSL permitidos | No | Sí | Lista separada por comas de cifrados a utilizar al realizar una solicitud
SSL. Utilice este valor para especificar un solo cifrado (por ejemplo SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) o una lista de cifrados que son los únicos utilizados por la conexión. Este conjunto de cifrados deben incluir uno o varios que el servidor remoto acepte. Se utiliza una coma como separador entre los cifrados. El valor predeterminado es una Serie vacía, que permite al nodo utilizar cualquiera o todos los cifrados disponibles durante el reconocimiento de conexión SSL. Este método proporciona el ámbito más amplio para establecer una conexión SSL satisfactoria. |
allowedCiphers | |
Habilitar comprobación de nombre de host de certificado SSL | No | Sí | Sí | Esta propiedad especifica si el nombre de host del servidor que está recibiendo la solicitud debe coincidir con el nombre de host en el certificado SSL. | hostnameChecking |
Alias de clave de autenticación de cliente SSL | No | Sí | "" (serie vacía) | Esta propiedad especifica un alias de autenticación SSL para el del lado del cliente de una conexión HTTPAsyncRequest. Tomar el valor predeterminado, significa elegir automáticamente la primera clave adecuada. | keyAlias |
Las propiedades Avanzadas del nodo HTTPAsyncRequest se describen en la siguiente tabla.
Propiedad | O | C | Valor predeterminado | Descripción | Propiedad de mandato mqsiapplybaroverride | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Generar cabeceras HTTP predeterminadas desde entrada | No | No | Seleccionado | Si selecciona este recuadro, se genera una HTTPRequestHeader. Si
lo deselecciona, en el mensaje de entrada debe haber una HTTPRequestHeader
válida. Para controlar el contenido de la HTTPRequestHeader que se incluye en el mensaje de solicitud, incluya un nodo Compute que añada una HTTPRequestHeader al mensajes de entrada antes de este nodo HTTPAsyncRequest en el flujo de mensajes, y deseleccione este recuadro de selección.
Si ha seleccionado Usar compresión o
Aceptar respuestas comprimidas por omisión,
los campos de cabecera HTTP Content-Encoding y Accept-Encoding se rellenarán independientemente de si ha seleccionado
Generar cabeceras predeterminadas HTTP a partir de la entrada:
|
|||||||||
Aceptar respuestas comprimidas por omisión | No | Sí | Deseleccionado | Esta propiedad indica si el nodo
HTTPAsyncResponse maneja las respuestas
comprimidas de manera predeterminada. Si la cabecera de solicitud no contiene una cabecera
Accept-Encoding y esta opción está seleccionada, el nodo establece la cabecera
Accept-Encoding en "gzip, deflate" y el nodo de respuesta descomprime
cualquier respuesta comprimida que se recibe.
Si el mensaje propagado al nodo HTTPAsyncResponse incluye una cabecera Accept-Encoding, el flujo de mensaje o la aplicación cliente debe manejar cualquier respuesta comprimida. Por lo tanto, seleccionar esta opción no tiene ningún efecto en este caso. |
acceptCompressedResponses |
Propiedad | O | C | Valor predeterminado | Descripción |
---|---|---|---|---|
Sucesos | No | No | Ninguno | Los sucesos que se han definido para el nodo se visualizan en este separador. De forma predeterminada, no se define ningún suceso de supervisión en ningún nodo en un flujo de mensajes. Utilice Añadir, Editar y
Suprimir para crear, cambiar o suprimir sucesos de supervisión para el nodo; consulte Configuración de orígenes de sucesos de supervisión utilizando propiedades de supervisión para obtener detalles. Puede habilitar e inhabilitar sucesos que se muestran aquí seleccionando o deseleccionando el recuadro Habilitado. |
Valor | Descripción |
---|---|
Compression | Altera temporalmente la propiedad
Usar compresión del nodo. Por ejemplo:
Para establecer un tamaño mínimo (en bytes)
en el que aplicar la compresión, utilice la siguiente alteración temporal:
|
ProxyConnectHeaders | Especifica cabeceras adicionales que se utilizan si la solicitud de salida es una conexión SSL a través de un
proxy. Estas cabeceras adicionales se envían con una solicitud CONNECT inicial al proxy. Por ejemplo, cuando utiliza SSL puede enviar información de autenticación proxy a un servidor proxy. Puede enviar varias cabeceras, pero cada una de ellas debe estar separada por un retorno de carro y un salto de línea (ASCII 0x0D 0x0A), de acuerdo con RFC2616; por ejemplo:
Este valor sólo se utiliza si la solicitud es una solicitud SSL a través de un servidor proxy. Para enviar información de autenticación proxy para una solicitud no SSL, especifique las cabeceras individuales en la carpeta HTTPRequestHeader, tal como se muestra en el siguiente ejemplo:
|
ProxyURL | Altera temporalmente la propiedad
Ubicación de proxy HTTP(S) del
nodo. Por ejemplo:
|
QueryString | Permite los valores de los parámetros de serie de consulta de salida. Cada parámetro se debe establecer de forma individual. Por ejemplo:
Los valores
ESQL anteriores dan como resultado la siguiente serie de consulta que se va a codificar (en función de http://tools.ietf.org/html/rfc3986) y se envían con la solicitud de salida:
Si el
URL de destino ya tiene un parámetro de consulta (o más de uno), los parámetros adicionales que se especifiquen se añadirán a la lista existente. |
QueryStringCCSID | Especifica que, antes de la codificación, los parámetros de serie de consulta se deben convertir en un juego de caracteres que no sea el predeterminado, que es UTF-8. En primer lugar, los parámetros de serie de consulta se convierten en el CCSID especificado antes de que la serie resultante se codifique, según RFC3986.
Por ejemplo:
El ESQL anterior da como resultado que los parámetros QueryString que convierten en la página de códigos 943 antes de codificarlos. Nota: los parámetros de serie de consulta deben contener datos en Unicode. |
RequestLine.RequestURI | Altera temporalmente RequestURI, que es la vía de acceso después del URL y el puerto. Por ejemplo:
|
RequestLine.HTTPVersion | Altera temporalmente la propiedad
Versión de HTTP en el nodo. Por ejemplo:
|
RequestLine.Method | Altera temporalmente la propiedad
Método HTTP en el nodo. Por ejemplo:
|
RequestURL | Altera temporalmente la propiedad URL de servicio web en el nodo. Por ejemplo:
|
SSLProtocol | Altera temporalmente SSLProtocol.
Por ejemplo:
Los valores válidos son: SSL, SSLv3 y TLS. |
SSLCiphers | Altera temporalmente la propiedad
Cifrados SSL permitidos en el nodo. Por ejemplo:
|
UserContext | Puede almacenar datos de contexto BLOB en la
siguiente ubicación en el entorno local. El nodo
HTTPAsyncResponse puede
recuperar estos datos posteriormente.
Los
datos almacenado en UserContext deben estar en formato BLOB. |
WrittenDestination = (
HTTP = (
RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
Compression = (
OriginalSize = 53 (INTEGER)
CompressedSize = 71 (INTEGER)
)
)
)