Trabajar con flujos HTTP

Lea esta información si utiliza flujos de mensajes HTTP para interactuar con servicios web. Puede resultarle útil leer este tema conjuntamente con la sección Escenarios de servicios web siguiente.

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, 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 LocalEnvironment (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 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 (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 de identificador del árbol LocalEnvironment y configura la respuesta para que se envíe al cliente específico. Sin embargo, si utiliza un nodo HTTPReply en un flujo que no tiene un nodo HTTPInput y este campo se ha suprimido o se ha establecido incorrectamente, se emite el mensaje BIP3143S.

Si diseña un flujo de mensajes que incluye 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 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 predeterminado en el nodo HTTPRequest para determinar el URL de destino para una petición de servicio web. Puede configurar un nodo Compute antes del nodo HTTPRequest en el flujo de mensajes para alterar temporalmente el valor establecido en la propiedad. Escriba código ESQL que almacene una serie de caracteres de URL en LocalEnvironment.Destination.HTTP.RequestURL; el nodo HTTPRequest recupera y utiliza la serie de URL en lugar del valor de la propiedad del 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 para ello el contenido del árbol LocalEnvironment 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 XMLNS y modifica Content-Type del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;

No utilice la propiedad ContentType para establecer Content-Type a menos que esté trabajando en el dominio MIME. La propiedad ContentType está diseñada específicamente 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. Seleccione las cabeceras en una cabecera HTTPReplyHeader.
  2. Si todavía no se ha definido ninguna cabecera Content-Type, cree una utilizando cualquier 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=utf-8.
  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 los valores cambiados o añadidos.

Establecimiento de Generar cabeceras HTTP predeterminadas desde entrada para el nodo HTTPRequest
Si selecciona Generar cabeceras HTTP predeterminadas desde entrada en las propiedades del nodo HTTPRequest, el nodo incluye un conjunto mínimo de cabeceras en la petición 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 XMLNS puede modificar Content-Type del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
No utilice la propiedad ContentType para establecer Content-Type a menos que esté trabajando en el dominio MIME. La propiedad ContentType está diseñada específicamente 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 que se define 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 cualquier 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=utf-8
  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 siempre reescribe la cabecera Content-Length, incluso si ha deseleccionado Generar cabeceras HTTP predeterminadas desde entrada. Esta acción asegura que el contenido es correcto.

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

Recopilación de los datos de rastreo de HTTPListener si tiene problemas con HTTP
Si tiene problemas con HTTP, puede rastrear HTTPListener:
  1. Utilice el mandato mqsichangetrace para iniciar el rastreo con las opciones siguientes:
    mqsichangetrace componente -t -b
    donde componente es el nombre de intermediario.
  2. Recupere el registro de rastreo de HTTPListener utilizando el mandato mqsireadlog con el calificador HTTPListener para el parámetro -b.
  3. Formatee el registro cronológico de rastreo utilizando el mandato mqsiformatlog de forma que pueda ver su contenido.
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, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:54:00

ac20450_