En este tema se proporciona información adicional acerca de cómo configurar los nodos en un flujo de mensajes para manejar situaciones determinadas.
Aunque también puede establecer el estado de la respuesta de la cabecera especial (X-Original-HTTP-Status-Code de la sección HTTPReplyHeader del mensaje de salida que altera temporalmente todos los demás valores) en un nodo Compute, se le recomienda que utilice el contenido de LocalEnvironment para este fin.
Por ejemplo, si diseña un par de flujos de mensajes que interactúen con una aplicación WebSphere MQ existente (como se describe en Trabajo con casos de ejemplo de servicios Web), puede guardar este valor en el flujo de petición y restaurarlo en el flujo de respuesta para garantizar que el cliente correcto recibe la respuesta. Si lo hace, no debe modificar los datos y debe retener los datos como un BLOB.
El nodo HTTPReply extrae este valor de LocalEnvironment y configura la respuesta para que se envíe al cliente específico.
Si diseña un flujo de mensajes que incluya un nodo HTTPInput y un nodo HTTPReply, el valor se establece en LocalEnvironment mediante el nodo HTTPInput pero el nodo HTTPReply no lo utiliza. Por lo tanto, si el flujo de mensajes incluye ambos nodos y un nodo Compute en el mismo flujo, no tiene que incluir el árbol LocalEnvironment cuando especifique qué componentes del árbol de mensajes copia el nodo Compute del mensaje de entrada al mensaje de salida (la propiedad Modalidad de cálculo).
Aunque también puede establecer el URL de la petición en la cabecera especial X-Original-HTTP-URL de la sección HTTPRequestHeader del mensaje de petición (que altera temporalmente todos los demás valores) en un nodo Compute, se le recomienda que utilice el contenido de LocalEnvironment para este fin.
El nodo HTTPReply siempre vuelve a grabar la cabecera Content-Length (incluso si ha borrado el recuadro de selección Generar cabeceras HTTP por omisión desde entrada o respuesta) para asegurarse de que su contenido sea correcto.
Todas las demás cabeceras se copian de HTTPResponseHeader. Después de ello, si no existe ninguna cabecera Content-Type, se añade con un valor de text/xml; charset=utf-8.
Si existe una sección HTTPReplyHeader en el mensaje que ha recibido el nodo HTTPReply y se conecta el terminal de salida del nodo HTTPReply, la sección HTTPReplyHeader se actualiza con cualquier valor que haya modificado o añadido.
El nodo HTTPRequest siempre vuelve a grabar la cabecera Content-Length (incluso si ha borrado el recuadro de selección Generar cabeceras HTTP por omisión desde entrada) para garantizar que su contenido sea correcto.
Todas las cabeceras se copian desde 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 esté presente en HTTPRequestHeader en el mensaje que reciba el nodo, altera temporalmente una cabecera con el mismo nombre que también está presente en HTTPInputHeader del mismo mensaje. Si existe una HTTPRequestHeader en el mensaje recibido, HTTPRequestHeader se actualiza con cualquier valor modificado o añadido.
Conceptos relacionados
WebSphere MQ Web Services Transport
Generación del lenguaje de descripción de servicios web (WSDL)
Tareas relacionadas
Creación de un flujo de mensajes
Trabajo con casos de ejemplo de servicios Web
Difusión de aplicaciones de flujos de mensajes
Comprobación de los resultados de la difusión
Referencia relacionada
Nodo HTTPInput
Nodo HTTPReply
Nodo HTTPRequest
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
ac20450_ |