Trabajar con flujos HTTP

Este tema proporciona información que puede ser útil si está utilizando flujos de mensajes HTTP para interactuar con servicios Web. Puede resultarle útil leer este tema conjuntamente con la sección 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 predeterminado es 200, lo que significa que es correcto. Si quiere que se devuelva un código de estado diferente, puede hacer dos cosas:
  • Establezca el código de estado en el campo Destination.HTTP.ReplyStatusCode en el entorno local (nombre de correlación OutputLocalEnvironment). Esto altera temporalmente cualquier código de estado que se haya establecido en una HTTPResponseHeader tal y como se ha descrito anteriormente.
  • Si un nodo HTTPRequest precede al nodo HTTPReply del flujo, entonces se habrá creado una HTTPResponseHeader en el árbol lógico, que representará las cabeceras HTTP en la respuesta de otro servicio Web. Por comodidad, si la propiedad del nodo HTTPReply Generar cabeceras HTTP predeterminadas desde respuesta está seleccionada, los valores de esta cabecera se utilizan como los valores predeterminados al crear el mensaje de respuesta, lo que le permite establecer su código de estado en el campo X-Original-HTTP-Status-Code de la HTTPResponseHeader. También puede definir este campo en una HTTPReplyHeader, pero se recomienda que utilice el entorno local como se ha descrito anteriormente.
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 un par de flujos de mensajes que interactúan con una aplicación de WebSphere MQ existente (como se describe en El intermediario llama a un 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.
Si desea establecer explícitamente cabeceras, créelas en HTTPReplyHeader. Por ejemplo, un nodo Compute que propaga un mensaje en el dominio XMLNS y que desea modificar Content-Type puede hacerlo del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;

En el caso particular de Content-Type, no establezca esta cabecera utilizando la propiedad ContentType a menos que esté trabajando en el dominio MIME. La propiedad ContentType está específicamente destinada a establecer el valor de Content-Type utilizado en MIME.

El conjunto completo de cabeceras HTTP utilizadas en la petición se crea seleccionando las cabeceras con el siguiente algoritmo:
  1. Seleccione las cabeceras en HTTPReplyHeader.
  2. Si hasta ese momento no se ha definido ninguna cabecera Content-Type, cree una utilizando cualquier valor no vacío de la propiedad ContentType.
  3. Seleccione las cabeceras en una HTTPResponseHeader (una HTTPResponsHeader se propaga como devolución de un nodo HTTPRequest).
  4. Si hasta ese momento no se ha definido ninguna cabecera Content-Type, cree una con el valor por omisión text/xml; charset=utf-8
  5. Cree la cabecera Content-Length o escriba encima de la misma.
Atención: El nodo HTTPReply siempre vuelve a escribir la cabecera Content-Length, incluso si ha eliminado la marca del recuadro de selección Generar cabeceras HTTP por omisión desde respuesta. Esto es para asegurarse de que el contenido es correcto.

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.
Si desea establecer explícitamente cabeceras, créelas en HTTPRequestHeader. Por ejemplo, un nodo Compute que propaga un mensaje en el dominio XMLNS y que desea modificar Content-Type puede hacerlo del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
En el caso particular de Content-Type, no establezca esta cabecera utilizando la propiedad ContentType a menos que esté trabajando en el dominio MIME. La propiedad ContentType está específicamente destinada a establecer el valor de Content-Type utilizado en MIME.
El conjunto completo de cabeceras HTTP utilizadas en la petición se crea seleccionando las cabeceras con el siguiente algoritmo:
  1. Establezca la cabecera Host, basándose en el URL de petición o la sección HTTPRequestHeader de entrada del mensaje.
  2. Seleccione las cabeceras en HTTPRequestHeader.
  3. Si hasta ese momento no se ha definido ninguna cabecera Content-Type, cree una utilizando cualquier valor no vacío de la propiedad ContentType.
  4. Seleccione las cabeceras en una HTTPInputHeader (una HTTPInputHeader la crea un nodo HTTPInput automáticamente).
  5. Si hasta ese momento no se ha definido ninguna cabecera Content-Type, cree una con el valor por omisión text/xml; charset=utf-8
  6. Si hasta ese momento no se ha definido ninguna cabecera SOAPAction, cree una con el valor por omisión ''
  7. Cree la cabecera Content-Length o escriba encima de la misma.
Atención: El nodo HTTPRequest siempre vuelve a escribir la cabecera Content-Length, incluso si ha eliminado la marca del recuadro de selección Generar cabeceras HTTP por omisión desde entrada o respuesta. Esto es para asegurarse de que el contenido es correcto.

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

Inicio del cambioRecopilación de los datos de rastreo de HTTPListener si tiene problemas con HTTPFin del cambio
Inicio del cambioSi tiene problemas con HTTP, puede rastrear HTTPListener:
  1. Inicie el rastreo utilizando el mandato mqsichangetrace.
  2. Vea el registro cronológico de anotaciones de rastreo de HTTPListener utilizando el mandato mqsireadlog con el calificador HTTPListener para el parámetro -b.
Fin del cambio
Conceptos relacionados
WebSphere MQ Web Services Transport
Generar WSDL
Tareas relacionadas
Crear 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, 2006 Última actualización: 22/08/2006
ac20450_