WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Trabajar con flujos HTTP

Lea esta información si utiliza flujos de mensajes HTTP para interactuar con aplicaciones HTTP, incluyendo servicios web y servicios RESTful.

Puede resultarle útil leer esta información conjuntamente con la sección Escenarios de servicios web.

Debe decidir qué escucha desea que se utilice en los nodos HTTP:
  • El escucha del intermediario (el componente httplistener) tiene un conector HTTPConnector para gestionar mensajes HTTP, y un conector HTTPSConnector para gestionar mensajes HTTPS (HTTP a través de SSL). Cada conector tiene su propio puerto asignado.

    De forma predeterminada, todos los nodos HTTPInput y HTTPReply utilizan el escucha del intermediario,que establece interfaz con los nodos HTTP utilizando una cola WebSphere MQ.

  • Cada grupo de ejecución contiene un escucha incluido. El escucha incluido tiene un conector HTTPConnector y un conector HTTPSConnector, cada uno con su propio puerto asignado.

    Puede configurar uno o más grupos de ejecución, de modo que todos los nodos HTTPInput y HTTPReply que despliegue a dicho grupo utilicen el escucha incluido.

Para obtener información sobre las ventajas de cada escucha, consulte Escuchas HTTP.

ProxyConnectHeaders sólo puede utilizarse con conexiones HTTPS (SSL); estas cabeceras no funcionan con conexiones HTTP.

Utilización de conexiones seguras con HTTPS
Para obtener información sobre la configuración de conexiones HTTPS, consulte Implementación de autenticación SSL.
Utilización de consulta-respuesta asíncrona HTTP
Para realizar una solicitud HTTP y recibir una respuesta asíncronamente, utilice los nodos HTTPAsyncRequest y HTTPAsyncResponse en el flujo de mensajes. El nodo HTTPAsyncRequest procesa el mensaje siguiente sin esperar a la respuesta, recibida por el nodo HTTPAsyncResponse en una hebra diferente y en una nueva transacción. Esto significa que se pueden procesar muchas más solicitudes utilizando menos hebras.

Para obtener más información, consulte Utilización de consulta-respuesta asíncrona HTTP.

Establecimiento del código de estado HTTP para una respuesta
El código de estado HTTP predeterminado es 200, que indica un resultado satisfactorio. Si quiere que se devuelva un código de estado diferente, realice una de las acciones siguientes:
  • Establezca el código de estado en el campo Destination.HTTP.ReplyStatusCode del árbol de entorno local (nombre de correlación OutputLocalEnvironment). Este campo altera temporalmente cualquier código de estado que esté establecido en una cabecera HTTPResponseHeader. Esta acción es la opción preferida porque proporciona la mayor flexibilidad.
  • Establezca el código de estado en el campo X-Original-HTTP-Status-Code de la cabecera HTTPReplyHeader.
  • Establezca el código de estado en el campo X-Original-HTTP-Status-Code de la cabecera HTTPResponseHeader. Esta opción suele ser útil si incluye un nodo HTTPRequest antes del nodo HTTPReply en el flujo, porque la cabecera HTTPResponseHeader se crea automáticamente. En este escenario, se ha creado una cabecera HTTPResponseHeader en el árbol lógico, que representa las cabeceras HTTP en la respuesta de otro servicio web. Si ha seleccionado la propiedad Generar cabeceras HTTP predeterminadas desde respuesta en el nodo HTTPReply, los valores para la cabecera de la respuesta se establecen como valores predeterminados cuando se crea el mensaje de respuesta.
Utilización de LocalEnvironment.Destination.HTTP.RequestIdentifier
Cuando el nodo HTTPInput recibe un mensaje de solicitud de entrada, establece el campo de entorno local Destination.HTTP.RequestIdentifier en un valor exclusivo que identifica el cliente de servicio web que ha enviado la petición. Puede hacer referencia a este valor y puede guardarlo en otra ubicación si es apropiado.

Por ejemplo, si diseña un par de flujos de mensajes que interactúan con una aplicación de WebSphere MQ existente (tal como se describe en El intermediario llama a un servicio web existente), puede guardar el valor de identificador en el flujo de peticiones y restaurarlo en el flujo de respuestas, para asegurar que la respuesta la reciba el cliente correcto. Si utiliza esta técnica, no debe cambiar los datos y debe conservarlos en forma de BLOB.

El nodo HTTPReply extrae el valor identificador del árbol de entorno local y configura la respuesta de forma que se envía al cliente específico. Sin embargo, si utiliza un nodo HTTPReply en un flujo que no tenga ningún nodo HTTPInput y se ha suprimido el campo o se ha establecido de forma incorrecta, se emitirá el mensaje BIP3143S.

Si diseña un flujo de mensajes que incluya un nodo HTTPInput y un nodo HTTPReply, el nodo HTTPInput establece el valor de identificador en el entorno local pero el nodo HTTPReply no lo utiliza. Por consiguiente, si el flujo de mensajes incluye ambos nodos HTTP y un nodo Compute en el mismo flujo, no tiene que incluir el árbol de entorno local cuando especifique qué componentes del árbol de mensajes copia el nodo Compute del mensaje de entrada al mensaje de salida (la propiedad Modalidad de cálculo).

Establecimiento dinámico del URL de solicitud HTTP
Puede establecer la propiedad URL de servicio web predeterminado en el nodo HTTPRequest o HTTPAsyncRequest para determinar el URL de destino para una solicitud de servicio web. Puede configurar un nodo Compute antes que el nodo HTTPRequest o HTTPAsyncRequest en el flujo de mensajes para alterar temporalmente el valor establecido en la propiedad. Escriba código ESQL que almacene una serie URL en LocalEnvironment.Destination.HTTP.RequestURL; el nodo recupera y utiliza la serie URL en lugar del valor de propiedad de nodo.

Aunque también puede establecer el URL de petición en la cabecera especial X-Original-HTTP-URL de la sección de cabecera HTTPRequestHeader del mensaje de petición (que prevalece sobre todos los demás valores) de un nodo Compute, utilice el contenido del árbol de entorno local para obtener una mayor flexibilidad.

Establecimiento de Generar cabeceras HTTP predeterminadas desde respuesta para el nodo HTTPReply
Si selecciona Generar cabeceras HTTP predeterminadas desde respuesta en las propiedades del nodo HTTPReply, el nodo incluye un conjunto mínimo de cabeceras en la respuesta que se envía al cliente de servicio web.
Para establecer cabeceras explícitamente, créelas en una cabecera HTTPReplyHeader. Por ejemplo, un nodo Compute propaga un mensaje en el dominio XMLNSC y modifica Content-Type del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;

No utilice la propiedad ContentType para establecer Content-Type a menos que esté trabajando en el dominio MIME. La propiedad ContentType está diseñada para establecer el valor de Content-Type utilizado en MIME.

Para crear el conjunto completo de cabeceras HTTP que se utilizan en la respuesta, se seleccionan las cabeceras utilizando el algoritmo definido en los pasos, siguientes:
  1. Seleccione las cabeceras en una cabecera HTTPReplyHeader.
  2. Si todavía no se ha definido ninguna cabecera Content-Type, cree una utilizando un valor no vacío en la propiedad ContentType.
  3. Seleccione las cabeceras en una cabecera HTTPResponseHeader (una cabecera HTTPResponseHeader se propaga cuando se devuelve de un nodo HTTPRequest).
  4. Si todavía no se ha definido ninguna cabecera Content-Type, cree una con el valor predeterminado text/xml; charset=ccsid del cuerpo del mensaje.
  5. Cree o sobrescriba la cabecera Content-Length.
Atención: El nodo HTTPReply siempre reescribe la cabecera Content-Length, incluso si ha deseleccionado Generar cabeceras HTTP predeterminadas desde respuesta. Esta acción asegura que el contenido es correcto.

Si existía una sección de cabecera HTTPReplyHeader en el mensaje recibido por el nodo HTTPReply, y el terminal de salida del nodo HTTPReply está conectado, la sección de cabecera HTTPReplyHeader se actualiza con todos los valores cambiados o añadidos.

Establecimiento de Generar cabeceras HTTP predeterminadas desde entrada para el nodo HTTPRequest o HTTPAsyncRequest
Si selecciona Generar cabeceras HTTP predeterminadas desde entrada en las propiedades de nodo HTTPRequest o HTTPAsyncRequest, el nodo incluye un conjunto mínimo de cabeceras en la solicitud que se envía al servidor.
Para establecer cabeceras explícitamente, créelas en una cabecera HTTPRequestHeader. Por ejemplo, un nodo Compute que propaga un mensaje en el dominio XMLNSC puede modificar Content-Type del siguiente modo:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
No utilice la propiedad ContentType para establecer Content-Type a menos que esté trabajando en el dominio MIME. La propiedad ContentType está diseñada para establecer el valor de Content-Type utilizado en MIME.
Para crear el conjunto completo de cabeceras HTTP que se utilizan en la petición, se seleccionan las cabeceras utilizando el algoritmo definido en los pasos siguientes:
  1. Establezca la cabecera Host, basándose en el URL de petición o la sección de cabecera HTTPRequestHeader de entrada del mensaje.
  2. Seleccione las cabeceras en una cabecera HTTPRequestHeader.
  3. Si todavía no se ha definido ninguna cabecera Content-Type, cree una utilizando un valor no vacío en la propiedad ContentType.
  4. Seleccione las cabeceras en una cabecera HTTPInputHeader (una cabecera HTTPInputHeader la crea automáticamente un nodo HTTPInput).
  5. Si todavía no se ha definido ninguna cabecera Content-Type, cree una con el valor predeterminado text/xml; charset=ccsid del cuerpo del mensaje
  6. Si todavía no se ha definido ninguna cabecera SOAPAction, cree una con el valor predeterminado ''.
  7. Cree o sobrescriba la cabecera Content-Length.
Atención: El nodo HTTPRequest o HTTPAsyncRequest siempre vuelve a grabar la cabecera Content-Length, incluso si ha deseleccionado Generar cabeceras HTTP predeterminadas desde entrada o solicitud. Esta acción asegura que el contenido es correcto.

Si existe una cabecera HTTPRequestHeader en el mensaje recibido, la cabecera HTTPRequestHeader se actualiza con todos los valores cambiados o añadidos.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:29


Tema de tareaTema de tarea | Versión 8.0.0.5 | ac20450_