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:
- Seleccione las cabeceras en una cabecera HTTPReplyHeader.
- Si todavía no se ha definido ninguna cabecera Content-Type, cree una
utilizando cualquier valor no vacío en la propiedad ContentType.
- Seleccione las cabeceras en una cabecera HTTPResponseHeader (una cabecera
HTTPResponseHeader se propaga cuando se devuelve de un nodo HTTPRequest).
- Si todavía no se ha definido ninguna cabecera Content-Type, cree una
con el valor predeterminado text/xml; charset=utf-8.
- 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:
- Establezca la cabecera Host, basándose en el URL de petición o la
sección de cabecera HTTPRequestHeader de entrada del mensaje.
- Seleccione las cabeceras en una cabecera HTTPRequestHeader.
- Si todavía no se ha definido ninguna cabecera Content-Type, cree una
utilizando cualquier valor no vacío en la propiedad ContentType.
- Seleccione las cabeceras en una cabecera HTTPInputHeader (una cabecera
HTTPInputHeader la crea automáticamente un nodo HTTPInput).
- Si todavía no se ha definido ninguna cabecera Content-Type, cree una
con el valor predeterminado text/xml; charset=utf-8
- Si todavía no se ha definido ninguna cabecera SOAPAction, cree una con
el valor predeterminado ''.
- 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:
- Utilice el mandato mqsichangetrace
para iniciar el rastreo con las opciones siguientes:
mqsichangetrace componente -t -b
donde
componente es el nombre de intermediario.
- Recupere el registro de rastreo de HTTPListener
utilizando el mandato mqsireadlog con el
calificador HTTPListener para el parámetro -b.
- Formatee el registro cronológico de rastreo utilizando el mandato
mqsiformatlog de forma que pueda ver su contenido.