Lea esta información si
utiliza flujos de mensajes HTTP para interactuar con aplicaciones
HTTP, incluyendo servicios web y servicios RESTful.
Puede resultarle útil leer esta información
conjuntamente con la sección Escenarios de servicios web.
Debe decidir qué escucha desea que se utilice en los nodos HTTP:
- El escucha del intermediario (el componente httplistener) tiene un conector
HTTPConnector para gestionar mensajes HTTP, y un conector HTTPSConnector para
gestionar mensajes HTTPS (HTTP a través de SSL). Cada conector tiene su
propio puerto asignado.
De forma predeterminada, todos los nodos
HTTPInput y
HTTPReply utilizan el escucha del
intermediario,que establece interfaz con los nodos HTTP utilizando una cola
WebSphere MQ.
- Cada grupo de ejecución contiene un escucha incluido. El escucha incluido
tiene un conector HTTPConnector y un conector HTTPSConnector, cada uno con su
propio puerto asignado.
Puede configurar uno o más grupos de ejecución, de modo que
todos los nodos HTTPInput y
HTTPReply que despliegue a dicho grupo
utilicen el escucha incluido.
Para obtener información sobre las
ventajas de cada escucha, consulte
Escuchas HTTP.
ProxyConnectHeaders sólo puede utilizarse con conexiones HTTPS (SSL);
estas cabeceras no funcionan con conexiones HTTP.
- Utilización de conexiones seguras con HTTPS
- Para obtener información sobre la configuración de conexiones HTTPS,
consulte Implementación de autenticación SSL.
- Utilización de consulta-respuesta asíncrona HTTP
- Para realizar una solicitud HTTP y recibir una respuesta asíncronamente,
utilice los nodos HTTPAsyncRequest y
HTTPAsyncResponse en el flujo de mensajes. El nodo HTTPAsyncRequest procesa el
mensaje siguiente sin esperar a la respuesta, recibida por el nodo
HTTPAsyncResponse en una hebra diferente
y en una nueva transacción. Esto significa que se pueden procesar muchas
más solicitudes utilizando menos hebras.
Para obtener más información, consulte
Utilización de consulta-respuesta asíncrona HTTP.
- 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 de entorno local (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 solicitud de entrada, establece el campo de entorno local
Destination.HTTP.RequestIdentifier 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 identificador del árbol de entorno local y configura la respuesta de forma que se envía al cliente específico. Sin embargo, si utiliza un nodo HTTPReply en un flujo que no tenga ningún nodo
HTTPInput y se ha suprimido el campo o se ha establecido de forma incorrecta, se emitirá el mensaje
BIP3143S.
Si diseña un flujo de mensajes que incluya 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 HTTP y un nodo
Compute en el mismo flujo, no tiene
que incluir el árbol de entorno local 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 dinámico del URL de solicitud HTTP
- Puede establecer la propiedad URL de servicio web
predeterminado en el nodo
HTTPRequest o
HTTPAsyncRequest para determinar
el URL de destino para una solicitud de servicio web. Puede configurar un nodo
Compute antes que el nodo
HTTPRequest o
HTTPAsyncRequest
en el flujo de mensajes para alterar temporalmente el valor establecido en la propiedad.
Escriba código ESQL que almacene una serie URL en LocalEnvironment.Destination.HTTP.RequestURL;
el nodo recupera y utiliza la serie URL en lugar del valor de propiedad de 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 el contenido del árbol de entorno local 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 XMLNSC y modifica Content-Type del modo siguiente:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
No utilice la
propiedad ContentType para establecer Content-Type a menos que esté
trabajando en el dominio MIME. La propiedad ContentType está diseñada
para establecer el valor de Content-Type utilizado en MIME.
Para
crear el conjunto completo de cabeceras HTTP que se utilizan en la
respuesta, 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 un 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=ccsid del cuerpo del
mensaje.
- 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 todos los valores cambiados o
añadidos.
- Establecimiento de Generar cabeceras HTTP predeterminadas
desde entrada para el nodo
HTTPRequest o
HTTPAsyncRequest
- Si selecciona Generar cabeceras
HTTP predeterminadas desde entrada en las propiedades de nodo
HTTPRequest o
HTTPAsyncRequest, el nodo incluye
un conjunto mínimo de cabeceras en la solicitud
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 XMLNSC puede modificar Content-Type del siguiente modo:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
No utilice la
propiedad ContentType para establecer Content-Type a menos que esté
trabajando en el dominio MIME. La propiedad ContentType está diseñada
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:
- 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 un 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=ccsid del cuerpo del
mensaje
- 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 o
HTTPAsyncRequest siempre vuelve a grabar
la cabecera Content-Length, incluso si ha deseleccionado
Generar cabeceras HTTP predeterminadas desde entrada
o solicitud. Esta acción asegura que el
contenido es correcto.
Si existe una cabecera HTTPRequestHeader en el mensaje recibido, la
cabecera HTTPRequestHeader se actualiza con todos los valores cambiados o añadidos.