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.
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.
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.
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.
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.
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:
Se generan varias cabeceras con valores por omisión si no se encuentran en las cabeceras HTTPRequest o HTTPInput de entrada:
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.