Configuración de nodos para casos de servicios Web determinados

En este tema se proporciona información adicional acerca de cómo configurar los nodos en un flujo de mensajes para manejar situaciones determinadas.

Establecimiento del código de estado HTTP para una respuesta
El código de estado HTTP por omisión es 200, el cual es aceptable. Se puede modificar de varios modos:
  • Si se selecciona la propiedad Generar cabeceras HTTP por omisión desde entrada o respuesta, el nodo HTTPReply explora las cabeceras de la respuesta HTTP para pasar un código de estado. Las cabeceras de la respuesta las crea el nodo HTTPRequest y representan las cabeceras HTTP que se proporcionan como parte de la respuesta del servicio Web. El nodo HTTPReply busca el código de estado y establece su propio código de estado en este valor.
  • Puede establecer el código de estado en el campo Destination.HTTP.ReplyStatusCode de LocalEnvironment. Si lo hace, el valor que establezca altera temporalmente cualquier valor que haya recuperado de las cabeceras de la respuesta.

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.

Utilización de LocalEnvironment.Destination.HTTP.RequestIdentifier
Cuando el nodo HTTPInput recibe un mensaje de petición de entrada, establece el valor de Destination.HTTP.RequestIdentifier del campo LocalEnvironment en un valor exclusivo que identifica el cliente del servicio Web que ha enviado la petición. Puede hacer referencia a este valor y puede guardarlo en otra ubicación, si corresponde.

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).

Establecimiento del URL de nodo HTTPRequest dinámicamente
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 del nodo HTTPRequest en el flujo de mensajes para alterar temporalmente el conjunto de valores de la propiedad. Codifique ESQL que almacene una serie de caracteres en LocalEnvironment.Destination.HTTP.RequestURL; esta la recupera el nodo HTTPRequest y se utiliza en lugar del valor de la propiedad del nodo.

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.

Establecimiento de Generar cabeceras HTTP por omisión desde entrada o respuesta para el nodo HTTPReply
Si selecciona el recuadro de selección Generar cabeceras HTTP por omisión desde entrada o respuesta en el diálogo de propiedades del nodo HTTPReply, el nodo incluye un conjunto mínimo de cabeceras en la respuesta que se envía al cliente del servicio Web. También incluye cualquier cabecera que esté presente en HTTPResponseHeader en el mensaje que recibe como entrada.

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.

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 en el 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. El nodo también incluye cualquier cabecera que esté presente en HTTPInputHeader en el mensaje que recibe como entrada.

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:

  • La cabecera Host que se establece basándose en el URL de la petición o en la sección HTTPRequestHeader de entrada del mensaje
  • La cabecera Content-Length que se vuelve a grabar en todos los casos

Se generan varias cabeceras con valores por omisión si no se encuentran en las cabeceras HTTPRequest o HTTPInput de entrada:

  • SOAPAction, que se establece en ""
  • Host, que se establece basándose en el URL de la petición que va a utilizar para este mensaje. Este puede ser el valor
  • Content-Type, que se establece en text/xml; charset=utf-8

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