Utilización de flujos HTTP

Este tema proporciona información que puede ser útil si está utilizando flujos de mensajes HTTP para interactuar con servicios Web. Puede encontrar útil leer este tema conjuntamente con el apartado Escenarios de servicios Web subsiguiente.

HTTPS
Para obtener ayuda con la utilización de HTTPS, consulte Implementación de autenticación SSL.
Establecimiento del código de estado HTTP para una respuesta
El código de estado HTTP por omisión es 200, lo que significa que es correcto. Esto se puede modificar de varios modos:
  • Si se selecciona la propiedad Generar cabeceras HTTP por omisión desde entrada o respuesta, el nodo HTTPReply explora las cabeceras de respuesta HTTP en busca de un código de estado para pasarlo. El nodo HTTPRequest crea las cabeceras de respuesta y éstas representan las cabeceras HTTP proporcionadas como parte de la respuesta del servicio Web. El nodo HTTPReply encuentra el código de estado y establece su propio código de estado en este valor.
  • Puede establecer el código de estado en el campo Destination.HTTP.ReplyStatusCode de LocalEnvironment. Si lo hace, el valor que establezca prevalecerá sobre cualquier valor recuperado de las cabeceras de respuesta.

Aunque también puede establecer el estado de respuesta en la cabecera especial (X-Original-HTTP-Status-Code de la sección HTTPReplyHeader del mensaje de salida que prevalece sobre todos los demás valores) de un nodo Compute, se le recomienda que para ello utilice el contenido de LocalEnvironment.

Utilización de LocalEnvironment.Destination.HTTP.RequestIdentifier
Cuando el nodo HTTPInput recibe un mensaje de petición de entrada, establece el campo Destination.HTTP.RequestIdentifier de LocalEnvironment 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 una pareja de flujos de mensajes que interactúan con una aplicación de WebSphere MQ existente (como se describe en el apartado El intermediario llama al servicio Web existente), puede guardar este valor en el flujo de peticiones y restaurarlo en el flujo de respuestas para asegurarse de que el cliente correcto recibe la respuesta. Si realiza esta acción, no debe cambiar los datos y debe conservarlos en forma de BLOB.

El nodo HTTPReply extrae este valor del entorno local (LocalEnvironment) y configura la respuesta para que se envíe al cliente específico.

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

Establecimiento dinámico del URL de nodo HTTPRequest
Puede establecer la propiedad URL de servicio Web por omisión en el nodo HTTPRequest para determinar el URL de destino para una petición de servicio web. Puede configurar un nodo Compute antes que el nodo HTTPRequest en el flujo de mensajes para alterar temporalmente el valor establecido en la propiedad. Codifique el ESQL que almacene una serie de caracteres de URL en LocalEnvironment.Destination.HTTP.RequestURL; el nodo HTTPRequest recuperará dicha serie y ésta se utilizará en lugar del valor de propiedad de nodo.

Aunque también puede establecer el URL de petición de la cabecera especial X-Original-HTTP-URL de la sección HTTPRequestHeader del mensaje de petición (que prevalece sobre todos los demás valores) de un nodo Compute, se le recomienda que para ello utilice el contenido de LocalEnvironment.

Establecimiento de Generar cabeceras HTTP por omisión desde respuesta para el nodo HTTPReply
Si selecciona el recuadro de selección Generar cabeceras HTTP por omisión desde respuesta en el diálogo de propiedades de nodo HTTPReply, el nodo incluye un conjunto mínimo de cabeceras en la respuesta que se envía al cliente de servicio Web. También incluye las cabeceras que existen en la cabecera de respuesta HTTP (HTTPResponseHeader) del mensaje que recibe como entrada.

El nodo HTTPReply vuelve a escribir siempre la cabecera Content-Length (aunque haya eliminado la marca de selección del recuadro Generar cabeceras HTTP por omisión desde entrada o respuesta) para asegurarse de que el contenido es correcto.

Todas las demás cabeceras se copian de HTTPResponseHeader. Después de esto, si no existe ninguna cabecera Content-Type, se añade con un valor de text/xml; charset=utf-8.

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

Establecimiento de Generar cabeceras HTTP por omisión desde entrada para el nodo HTTPRequest
Si selecciona el recuadro de selección Generar cabeceras HTTP por omisión desde entrada del diálogo de propiedades del nodo HTTPRequest, el nodo incluye un conjunto mínimo de cabeceras en la petición que se envía al servidor. El nodo también incluye las cabeceras existentes en HTTPInputHeader en el mensaje que recibe como entrada.

El nodo HTTPRequest vuelve a escribir siempre la cabecera Content-Length (aunque haya eliminado la marca de selección del recuadro Generar cabeceras HTTP por omisión desde entrada), para asegurarse de que el contenido es correcto.

Todas las cabeceras se copian de HTTPInputHeader, excepto:

  • La cabecera Host, que se establece basándose en el URL de petición o la sección HTTPRequestHeader de entrada del mensaje
  • La cabecera Content-Length, que se vuelve a escribir en todos los casos

Se generan varias cabeceras con valores por omisión si no se encuentran en las cabeceras HTTPRequest o HTTPInput de entrada:

  • SOAPAction, que se establece en ""
  • Host, que se establece basándose en el URL de petición que se debe utilizar para este mensaje. Éste puede ser el valor
  • Content-Type, que se establece en text/xml; charset=utf-8

Cualquier cabecera que exista en una HTTPRequestHeader del mensaje recibido por el nodo prevalece sobre una cabecera con el mismo nombre que también esté presente en una HTTPInputHeader del mismo mensaje. Si existe una HTTPRequestHeader en el mensaje recibido, HTTPRequestHeader se actualiza con los valores cambiados o añadidos.

Conceptos relacionados
WebSphere MQ Web Services Transport
WSDL
Tareas relacionadas
Creación de un flujo de mensajes
Despliegue
Comprobación de los resultados del despliegue
Referencia relacionada
Nodo HTTPInput
Nodo HTTPReply
Nodo HTTPRequest
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2005 Última actualización: 11/11/2005
ac20450_