WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Nodo HTTPRequest

Utilice el nodo HTTPRequest para interactuar con un servicio web.

Este tema contiene las secciones siguientes:

Finalidad

El nodo HTTPRequest interactúa con un servicio web utilizando todo o parte del mensaje de entrada como la solicitud que se envía a ese servicio. También puede configurar el nodo para crear un mensaje de salida a partir del contenido del mensaje de entrada, aumentado por el contenido de la respuesta del servicio web, antes de propagar el mensaje a los siguientes nodos del flujo de mensajes.

En función de la configuración, este nodo construye una solicitud HTTP o HTTP sobre SSL (HTTPS) a partir del contenido especificado del mensaje de entrada, y envía esta solicitud al servicio web. El nodo recibe la respuesta del servicio web y analiza la respuesta para incluirla en el árbol de salida. El nodo genera cabeceras HTTP si su configuración las necesita.

Puede utilizar este nodo en un flujo de mensajes que contenga o no un nodo HTTPInput o HTTPReply.

El nodo HTTPRequest maneja los mensajes en los siguientes dominios de mensaje:

  • DFDL
  • XMLNSC
  • JSON
  • BLOB
  • MIME
  • MRM
  • XMLNS

El nodo HTTPRequest se encuentra en el cajón HTTP de la paleta y está representado en WebSphere Message Broker Toolkit mediante el siguiente icono:

Icono de nodo HTTPRequest

Utilización del nodo HTTPRequest para emitir una solicitud a un servicio web

Una solicitud HTTP consta de dos partes:
  1. El URL de un servicio.
  2. Una corriente de datos que el servidor remoto procesa, y a la que luego devuelve una respuesta, que a menudo es un mensaje SOAP u otro mensaje de servicio web en XML.

El URL tiene el formato http://<dirección>[:<puerto>]/<función>; por ejemplo, http://localhost:7080/request. Este URL se puede especificar estáticamente en los parámetros del nodo HTTPRequest como un campo en el propio mensaje, o como un campo en el entorno local. Los datos que se envían al servicio web pueden ser el árbol de mensaje completo, o una parte del mismo, según se especifique en las propiedades del nodo HTTPRequest.

Los datos deben estar en formato CCSID 1208 para la mayoría de las solicitudes. La respuesta puede sustituir al mensaje de entrada, o se puede insertar en el árbol de mensajes; la ubicación se especifica en los parámetros del nodo HTTPRequest. El dominio para la respuesta es XMLNS. Si la solicitud se realiza satisfactoriamente, la HTTPResponse se inserta al principio del árbol de mensajes, la respuesta se coloca en la ubicación especificada del árbol, y la solicitud se propaga al terminal Out (de salida). Si el nodo HTTPRequest no puede emitir la solicitud, se inserta una Lista de excepciones en el árbol de mensajes y el árbol se propaga al terminal Failure (de anomalías).

Si el nodo HTTPRequest envía satisfactoriamente la solicitud, pero el servicio web no se realiza satisfactoriamente, la HTTPResponse se inserta en el árbol de mensajes y se propaga al terminal Error (de errores). El parámetro Ubicación del mensaje de error en el nodo HTTPRequest especifica en qué lugar del árbol se coloca la respuesta, por ejemplo OutputRoot.XMLNS.error. Es posible que tenga que utilizar un nodo Compute para convertir esta respuesta a una página de códigos adecuada para poder visualizar los datos, por ejemplo:
Set OutputRoot.XMLNS.error850 = CAST(InputRoot.XMLNS.error.BLOB as CHAR CCSID 850);
Para obtener información sobre HTTP, consulte Protocolo de transferencia de hipertexto - HTTP/1.1. Para obtener más información sobre los códigos de retorno HTTP, consulte Códigos de respuesta HTTP.

Puede especificar un intervalo de tiempo de espera, de modo que si la solicitud tarda más qie la duración especificada, la solicitud se propaga al terminal Anomalías con un mensaje apropiado. Para cada solicitud que el nodo HTTPRequest procesa, éste abre una conexión y luego la cierra cuando se devuelve la respuesta. Si se especifica el tiempo de espera, el socket se cierra una vez transcurrido el intervalo. Este cierre asegura que una solicitud reciba solamente la respuesta correcta y que todos los datos de respuesta para una solicitud que ha excedido el tiempo de espera se descarten.

Puede utilizar el proxy HTTP para direccionar una solicitud a través de un sitio intermedio. Puede ejecutar herramientas como un proxy para ver la solicitud y la respuesta, y por consiguiente depurar sus flujos. El destino HTTP es tal como lo ve el proxy; si especifica el destino HTTP de localhost, y el proxy HTTP se está ejecutando en otro sistema, la solicitud se direcciona al sistema de proxy remoto, no al sistema desde el que se emitió la solicitud original.

Utilización del nodo HTTPRequest en un flujo de mensajes

El nodo HTTPRequest se puede utilizar en cualquier flujo de mensajes que tenga que enviar una solicitud HTTP. El ejemplo más común es un flujo de mensajes que invoca un servicio web.

Para obtener más información sobre servicios web, consulte Proceso de mensajes de servicio web.

Manejo de errores

El nodo interactúa directamente con un servicio externo utilizando TCP/IP; por consiguiente, puede experimentar los tipos de error siguientes:

  • Errores generados por TCP/IP, por ejemplo no route to host (sin ruta al host) o connection refused (conexión rechazada).

    Si el nodo detecta estos errores, genera una excepción, llena la lista de excepciones con la información de error recibida y dirige el mensaje de entrada sin modificar al terminal de anomalías.

  • Errores devueltos por el servidor web. Estos errores se representan mediante códigos de estado HTTP que están fuera del rango 100 a 299. Si el nodo detecta estos errores, direcciona la respuesta al terminal de errores mientras sigue las propiedades especificas en el separador Error.

    La respuesta se produce como un mensaje BLOB porque el nodo no puede determinar en qué formato estará la respuesta. Si no ha configurado este nodo para que maneje la redirección, los mensajes con un código de estado de redirección (3xx) también se manejan del mismo modo.

Códigos de respuesta HTTP

El nodo HTTPRequest trata los códigos de estado de la serie 100 como una respuesta 'continuar', descarta la respuesta actual y espera otra respuesta del servidor web.

Los códigos de estado de la serie 200 se tratan como solicitud correcta, los valores de los diversos separadores del nodo determinan el formato del mensaje de salida que se genera y la respuesta se direcciona al terminal de salida del nodo.

Los códigos de estado de la serie 300 son para redirección. Si se selecciona la propiedad Seguir la redirección HTTP(s), el nodo reenvía la solicitud al nuevo destino especificado en la respuesta que se recibe. Si la propiedad Seguir la redirección HTTP(s) no está seleccionada, los códigos se tratan como un error, tal como se describe en Utilización del nodo HTTPRequest para emitir una solicitud a un servicio web. Para obtener más información sobre los códigos de retorno HTTP, consulte Códigos de respuesta HTTP.

Los códigos de estado de las series 400 y 500 son errores y se tratan como se describe en Utilización del nodo HTTPRequest para emitir una solicitud a un servicio web. Para obtener más información sobre los códigos de retorno HTTP, consulte Códigos de respuesta HTTP.

Manipulación de cabeceras

Si selecciona el mensaje de entrada Sustituir mensaje de entrada por respuesta de servicio web o Sustituir entrada con error, la cabecera del mensaje de entrada (la cabecera que pertenece al mensaje cuando llega al terminal In (de entrada) del nodo HTTPRequest) no se propaga con el mensaje que sale del nodo HTTPRequest. Sin embargo, si se especifica una de las propiedades que especifica una ubicación en el árbol de mensajes, las cabeceras del mensaje de entrada se propagan.

La cabecera HTTPResponse, que contiene las cabeceras que devuelve el servicio web remoto, es la primera cabecera del mensaje (después de Propiedades) que se propaga desde el nodo. Esta acción se adopta independientemente de las opciones que se seleccionen. Por lo tanto, para que la respuesta del nodo HTTPRequest se transfiera a una cola WebSphere MQ, manipule las cabeceras de forma que un MQMD sea la primera cabecera (después de Propiedades).

Si está sustituyendo el mensaje de entrada por una respuesta, puede copiar el MQMD del mensaje de entrada en el árbol de entorno antes del nodo HTTPRequest y, a continuación, volver a copiarlo en el árbol de mensajes después del nodo HTTPRequest. Si está especificando una ubicación para la respuesta, con el fin de mantener cabeceras de mensajes de entrada existentes, deberá mover o eliminar la cabecera de respuesta HTTP para que el MQMD sea la primera cabecera.

El ejemplo siguiente contiene ESQL que elimina la HTTPHeader:
SET OutputRoot = InputRoot;
SET OutputRoot.HTTPResponseHeader = NULL; 
El ejemplo siguiente contiene ESQL para mover la HTTPHeader y, por consiguiente, conservar la información que proporciona:
SET OutputRoot = InputRoot;
DECLARE HTTPHeaderRef REFERENCE TO OutputRoot.HTTPResponseHeader;
DETACH HTTPHeaderRef;
ATTACH HTTPHeaderRef TO OutputRoot.MQMD AS NEXTSIBLING;

Configuración del nodo HTTPRequest

Cuando haya colocado una instancia del nodo HTTPRequest en un flujo de mensajes, podrá configurar el nodo; consulte el apartado Configurar un nodo de flujo de mensajes. Las propiedades del nodo se visualizan en la vista Propiedades.

Todas las propiedades obligatorias, para las que se debe entrar un valor, están marcadas con un asterisco.

Configure el nodo HTTPRequest:

  1. Opcional: En el separador Descripción, especifique una Descripción corta, una Descripción larga, o ambas. En este separador también puede renombrar el nodo.
  2. En el separador Básicas:
    1. El nodo HTTPRequest determina el URL para el servicio web al que envía una solicitud. Seleccione una de las tres opciones siguientes; el nodo las comprueba en el orden mostrado (es decir, la primera siempre prevalece sobre la segunda y ésta sobre la tercera):
      1. X-Original-HTTP-URL en la cabecera HTTPRequest del mensaje de entrada
      2. LocalEnvironment.Destination.HTTP.RequestURL en el mensaje de entrada
      3. La propiedad URL de servicio web

      Las dos primeras opciones proporcionan métodos dinámicos para establecer un URL para cada mensaje de entrada cuando éste pasa a través del flujo de mensajes. Para usar de estas opciones, incluya un nodo Compute en el flujo de mensajes, antes del nodo HTTPRequest, para crear e inicializar el valor necesario.

      La tercera opción proporciona un valor que es fijo para cada mensaje recibido en este nodo. Establezca esta propiedad para que contenga un valor predeterminado que se utilice si los demás campos no se han creado o contienen un valor nulo. Si uno de los campos contiene un valor, se ignora el valor de esta propiedad. La propiedad URL de servicio web debe contener un URL válido o el despliegue falla. Asegúrese de que el valor que establece en X-Original-HTTP-URL o LocalEnvironment.Destination.HTTP.RequestURL es también un URL válido; si no lo es, el nodo utiliza el valor predeterminado de la propiedad URL de servicio web.

      Si un URL empieza con http://, el nodo de solicitud realiza una solicitud HTTP al URL especificado. Si el URL empieza con https://, el nodo de solicitud realiza una solicitud HTTP sobre SSL (HTTPS) al URL especificado, utilizando los parámetros especificados en el separador SSL del nodo.

    2. Establezca el valor de la propiedad Tiempo de espera de solicitud (seg), que es el período de tiempo, en segundos, que el nodo espera para obtener una respuesta del servicio web. Si la respuesta se recibe dentro de este periodo de tiempo, se propaga a través del terminal de salida al resto del flujo de mensajes. Si no se recibe una respuesta dentro de este periodo de tiempo, el mensaje de entrada se propaga a través del terminal de anomalías, si está conectado. Si el terminal de anomalías no está conectado y no se recibe una respuesta dentro del tiempo especificado, se genera una excepción.
  3. En el separador Valores de HTTP:
    1. En Ubicación de proxy HTTP(S), establezca la ubicación del servidor proxy al que se envían las solicitudes.
    2. Seleccione Seguir la redirección HTTP(S) para especificar cómo maneja el nodo las respuestas de servicio web que contienen un código de estado HTTP de 300 a 399:
      • Si selecciona el recuadro, el nodo sigue la redirección que se proporciona en la respuesta, y vuelve a emitir la solicitud de servicio web al nuevo URL (incluido en el contenido del mensaje).
      • Si deselecciona el recuadro, el nodo no sigue la redirección proporcionada. El mensaje de respuesta se propaga al terminal de errores.
    3. Seleccione una de las opciones para la propiedad Versión HTTP. Los valores válidos son: 1.0 o 1.1.

      Si, como valor de la propiedad Versión HTTP, selecciona 1.1, también podrá seleccionar Habilitar el mantenimiento de activado de HTTP/1.1.

    4. Seleccione una de las opciones para la propiedad Método HTTP. Los valores válidos son: POST, GET, PUT, DELETE y HEAD.
    5. Seleccione una de las opciones para la propiedad Usar compresión para especificar la compresión del contenido de la solicitud HTTP. Puede seleccionar gzip, zlib (deflate), deflate o ninguno. El valor zlib (deflate) representa la RFC 1950 y la RFC 1951 combinadas y deflate representa únicamente la RFC 1951. El valor predeterminado es none, lo que significa que el contenido de la solicitud no estará comprimido.
  4. En el separador SSL, si desea utilizar solicitudes HTTP sobre SSL (HTTPS), establezca los valores para solicitudes HTTPS:
    1. Especifique la propiedad Protocolo que desee utilizar para realizar la solicitud. Ambos extremos de una conexión SSL deben coincidir en el protocolo que van a utilizar. Por lo tanto, el protocolo seleccionado debe ser uno que el servidor remoto pueda aceptar. Están disponibles las opciones siguientes:
      • SSL. Esta opción es el valor predeterminado. Esta opción intenta establecer conexión utilizando primero el protocolo SSLv3, pero permite al reconocimiento recurrir al protocolo SSLv2 cuando el proveedor JSSE subyacente soporta el protocolo SSLv2.
      • SSLv3. Esta opción intenta establecer conexión sólo con el protocolo SSLv3. No es posible retroceder a SSLv2.
      • TLS. Esta opción intenta establecer conexión sólo con el protocolo TLS. No es posible retroceder a SSLv3 o SSLv2.
    2. Establezca la propiedad Cifrados SSL permitidos. Utilice este valor para especificar un solo cifrado (por ejemplo SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) o una lista de cifrados que son los únicos utilizados por la conexión. Este conjunto de cifrados debe incluir uno o varios que el servidor remoto acepte. Se utiliza una coma como separador entre los cifrados. El valor predeterminado es una Serie vacía, que permite al nodo utilizar cualquiera o todos los cifrados disponibles durante el reconocimiento de conexión SSL. Este método proporciona el ámbito más amplio para establecer una conexión SSL satisfactoria.
    3. Utilice la propiedad SSLKeyAlias para especificar un alias de autenticación SSL para el lado del cliente de una conexión HTTP. El servidor comprueba una lista de control de accesos para esta clave del lado del cliente. El alias de clave que identifica la clave en el almacén de claves del intermediario o del grupo de ejecución que se va a utilizar para la conexión SSL. Establezca esta propiedad opcional si el almacén de claves contiene más de una clave. El valor predeterminado "" (o ninguno), significa que no se utiliza un alias de clave SSL. Cualquier otro valor de serie identifica el alias.
  5. En el separador Análisis de mensajes de respuesta, establezca valores para las propiedades que describen el dominio de mensajes, el conjunto de mensajes, el tipo de mensaje y el formato de mensaje que el nodo utiliza, para determinar cómo analizar el mensaje de respuesta devuelto por el servicio web. Si el servicio web devuelve un mensaje de error, se ignoran los valores de estas propiedades y el analizador BLOB analiza el mensaje.
    1. En Dominio de mensajes, seleccione en la lista el nombre del analizador que utiliza. Si el campo está en blanco, el valor predeterminado es BLOB. Elija una de las siguientes opciones:
      • DFDL
      • XMLNSC
      • JSON
      • BLOB
      • MIME
      • MRM
      • XMLNS

      También puede especificar un analizador definido por el usuario, si es adecuado.

    2. Si utiliza el analizador DFDL, el analizador MRM o el analizador XMLNSC en modalidad de validación, seleccione el Modelo de mensaje relevante en la lista. Esta lista se llena con conjuntos de mensajes disponibles cuando se selecciona MRM o XMLNSC como Dominio de mensajes, o con archivos de esquema DFDL disponibles al seleccionar DFDL como Dominio de mensajes.
    3. Si utiliza los analizadores DFDL o MRM, seleccione el mensaje correcto en la lista de Mensaje. Esta lista se llena con los mensajes definidos en el Modelo de mensaje que se ha seleccionado.
    4. Si está utilizando el analizador MRM, seleccione el formato del mensaje en la lista de Formato físico. Esta lista incluye todos los formatos físicos que se han definido para este Modelo de mensaje.
  6. En el subseparador Opciones de análisis:
    1. De forma predeterminada, Temporización de análisis está establecido en A petición con lo cual el análisis del mensaje se retrasa. Para que el mensaje se analice de forma inmediata, consulte Análisis a petición.
    2. Si está usando el analizador XMLNSC, establezca valores para las propiedades que determinan el funcionamiento del analizador XMLNSC. Para obtener más información, consulte Manipular mensajes en el dominio XMLNSC.
  7. En el separador >Manejo de errores, establezca valores para las propiedades que determinan cómo se maneja un mensaje de error devuelto por el servicio web:
    1. Para que todo el mensaje de error del servicio web se propague como mensaje de salida, deje Sustituir entrada con error seleccionado (el valor predeterminado).

      Para que el mensaje de error del servicio web se incluya en el mensaje de salida con parte del contenido del mensaje de entrada, deseleccione Sustituir entrada con error y establezca la propiedad Ubicación del mensaje de error. Si deselecciona esta propiedad, el nodo copia el mensaje de entrada en el mensaje de salida y escribe el mensaje de error del servicio web encima del contenido del mensaje de salida en la ubicación especificada (el mensaje de entrada mismo no se modifica).

    2. En el campo Ubicación del mensaje de error, entre la ubicación de inicio (dentro del árbol de mensajes de salida) en la que se almacenan los elementos analizados de la corriente de bits del mensaje de error del servicio web. Esta propiedad sólo es obligatoria si ha deseleccionado Sustituir entrada con error.

      Puede entrar cualquier referencia de campo ESQL válida, incluyendo expresiones dentro de la referencia, y nuevas referencias de campo (para crear un nodo en el árbol de mensajes para la respuesta). Por ejemplo, entre:

      OutputRoot.XMLNSC.ABC.DEF
      o
      Environment.WSError

      Si selecciona Sustituir entrada con error, se ignora esta propiedad.

  8. En el separador Avanzadas, establezca valores para las propiedades avanzadas que describen la estructura y el contenido de la solicitud y la respuesta del servicio web:
    1. Especifique el contenido del mensaje de solicitud que se envía al servicio web:
      • Para que el mensaje de solicitud sea el cuerpo entero del mensaje de entrada, deje seleccionado Utilizar todo el mensaje de entrada como solicitud (el valor predeterminado).

        Para que el mensaje de solicitud contenga un subconjunto del mensaje de entrada, deseleccione Utilizar todo el mensaje de entrada como solicitud y establezca la propiedad Ubicación del mensaje de solicitud en el árbol.

      • En el campo Ubicación del mensaje de solicitud en el árbol, entre la ubicación inicial desde la que se copia el contenido del árbol de mensajes de entrada al mensaje de solicitud. Esta propiedad sólo es obligatoria si ha deseleccionado Utilizar todo el mensaje de entrada como solicitud. El nodo crea un mensaje de solicitud y copia las partes especificadas del mensaje de entrada (el mensaje de entrada mismo no se modifica).

        Puede entrar cualquier referencia de campo ESQL válida, incluidas expresiones dentro de la referencia. Por ejemplo, entre:

        InputRoot.XMLNSC.ABC

        Si selecciona Utilizar todo el mensaje de entrada como solicitud, esta propiedad se ignora.

      Cuando se analiza el contenido del árbol de mensajes adecuado para crear una corriente de bits, se utilizan las propiedades de mensaje (Dominio del mensaje, Conjunto de mensajes, Tipo de mensaje y Formato del mensaje) asociadas al texto del mensaje de entrada y almacenadas en la carpeta Propiedades.

    2. Especifique el contenido del mensaje de salida que se propaga al siguiente nodo en el flujo de mensajes:
      • Para que el mensaje de respuesta del servicio web entero se propague como mensaje de salida Sustituir mensaje de entrada por respuesta de servicio web seleccionado (el valor predeterminado).

        Para que el mensaje de respuesta del servicio web se incluya en el mensaje de salida con parte del contenido del mensaje de entrada, deseleccione Sustituir mensaje de entrada por respuesta de servicio web y establezca la propiedad Ubicación del mensaje de respuesta en el árbol. Si deselecciona esta propiedad, el nodo copia el mensaje de entrada en el mensaje de salida y escribe el mensaje de respuesta del servicio web encima del contenido del mensaje de salida en la ubicación especificada (el mensaje de entrada mismo no se modifica).

      • En el campo Ubicación del mensaje de respuesta en el árbol, entre la ubicación de inicio (dentro del árbol de mensajes de salida) en la que se almacenan los elementos analizados de la corriente de bits del mensaje de respuesta del servicio web. Esta propiedad sólo es obligatoria si ha deseleccionado Sustituir mensaje de entrada por respuesta de servicio web.

        Puede entrar cualquier referencia de campo ESQL válida, incluyendo expresiones dentro de la referencia, y nuevas referencias de campo (para crear un nodo en el árbol de mensajes para la respuesta). Por ejemplo, entre:

        OutputRoot.XMLNSC.ABC.DEF
        o
        Environment.WSReply

        Si selecciona Sustituir mensaje de entrada por respuesta de servicio web, se ignora esta propiedad.

      Cuando se analiza la corriente de bits de respuesta para crear el contenido del árbol de mensajes, se utilizan las propiedades de mensaje (Dominio del mensaje, Conjunto de mensajes, Tipo de mensaje y Formato del mensaje) que ha especificado en las propiedades de Análisis de mensajes de respuesta del nodo.

    3. Para que el nodo genere una HTTPRequestHeader para el mensaje de solicitud, deje Generar cabeceras HTTP predeterminadas desde entrada (el valor predeterminado).

      Si no desea que el nodo genere una HTTPRequestHeader para el mensaje de solicitud, deseleccione Generar cabeceras HTTP predeterminadas. Para controlar el contenido de la HTTPRequestHeader que se incluye en el mensaje de solicitud, incluya un nodo Compute que añada una HTTPRequestHeader al mensajes de entrada antes de este nodo HTTPRequest en el flujo de mensajes, y deseleccione este recuadro de selección.

      • Si ha seleccionado Generar cabeceras HTTP predeterminadas desde entrada y el mensaje de entrada incluye una cabecera HTTPRequestHeader, el nodo HTTPRequest extraerá cabeceras de servicio web de la HTTPRequestHeader de entrada y añadirá cualquier cabecera de servicio web que sea exclusiva, excepto Host (vea la tabla siguiente), que se encuentre en una HTTPInputHeader, si hay alguna en el mensaje de entrada. (Puede haber una HTTPInputHeader si el mensaje de entrada lo ha recibido el nodo HTTPInput procedente de un servicio web.)

        El nodo HTTPRequest también añade las cabeceras de servicio web que aparecen en la tabla siguiente, con los valores predeterminados, si éstos no están ya en la HTTPRequestHeader o la HTTPInputHeader.

        Cabecera Valor predeterminado
        SOAPAction "" (serie vacía)
        Content-Type text/xml; charset=ccsid del cuerpo de mensaje

        A no ser que el mensaje de entrada esté en el dominio JSON, en el que el valor predeterminado es:

        application/json; charset=ccsid del cuerpo de mensaje

        Host El nombre de host al que se envía la solicitud.

        El nodo HTTPRequest también añade la cabecera opcional Content-Length con el valor calculado correcto, aunque este valor no esté presente en la HTTPRequestHeader o la HTTPInputHeader.

      • Si ha seleccionado Generar cabeceras HTTP predeterminadas desde entrada y el mensaje de entrada no incluye una HTTPRequestHeader, el nodo HTTPRequest extrae las cabeceras de servicio web, excepto Host, de la HTTPInputHeader(si está presente en el mensaje de entrada). El nodo HTTPRequest añade las cabeceras de servicio web necesarias con valores predeterminados, si estos valores no están presentes en la HTTPInputHeader.
      • Si ha deseleccionado Generar cabeceras HTTP predeterminadas desde entrada y el mensaje de entrada incluye una HTTPRequestHeader, el nodo extrae todas las cabeceras de servicio web que se encuentran en la HTTPRequestHeader de entrada. El nodo no comprueba la presencia de una HTTPInputHeader en el mensaje de entrada y no añade las cabeceras de servicio web necesarias si no las proporciona la HTTPRequestHeader de entrada.
      • Si ha deseleccionado Generar cabeceras HTTP predeterminadas desde entrada y el mensaje de entrada no incluye una HTTPRequestHeader, no se genera ninguna cabecera de servicio web. El nodo HTTPRequest no comprueba la presencia de una HTTPInputHeader en el mensaje de entrada y no añade ninguna cabecera de servicio web necesaria. El mensaje de solicitud se propaga al servicio web sin una HTTPRequestHeader. Normalmente, esta acción hace que el servicio web genere un error, a menos que dicho servicio esté configurado para manejar el contenido de los mensajes.
      Si ha seleccionado Usar compresión o Aceptar respuestas comprimidas por omisión, los campos de cabecera HTTP Content-Encoding y Accept-Encoding se rellenarán independientemente de si ha seleccionado Generar cabeceras predeterminadas HTTP a partir de la entrada:
      • Si el valor de Usar compresión no es el valor predeterminado None, la cabecera HTTP Content-Encoding se rellenará con este valor y la corriente de bits se comprimirá. Si la cabecera Content-Encoding ya está presente en una cabecera HTTP existente, este campo se actualiza con el valor de la propiedad Usar compresión. Si la cabecera Content-Encoding existente ya se inicia con la función de compresión indicada, no se realizará ninguna compresión adicional. Si la cabecera Content-Encoding se inicia con la cabecera deflate, no se realiza ninguna compresión, aunque se haya seleccionado ZLIB (deflate) o deflate.
      • Si ha seleccionado Aceptar respuestas comprimidas, el campo Accept-Encoding se rellenará. Si este campo ya está presente en una cabecera HTTP existente, el valor existente prevalecerá sobre la propiedad del nodo. No obstante, si se recibe un cabecera comprimida, no se descomprimirá.
    4. Seleccione la propiedad Aceptar respuestas comprimidas por omisión para indicar si la solicitud acepta solicitudes comprimidas. Si selecciona esta opción, la solicitud puede recibir respuestas con un Content-Encoding que sea gzip o deflate. Si se recibe una respuesta de este tipo, el contenido se decodifica y la cabecera Content-Encoding se elimina. Si la cabecera de solicitud no contiene una cabecera Accept-Encoding, al seleccionar esta opción se establece la cabecera Accept-Encoding en "gzip, deflate".
  9. En el separador Validación, establezca las propiedades de validación si desea que el analizador valide el texto de los mensajes de respuesta a partir del Conjunto de mensajes. (Si un mensaje se propaga al terminal de anomalías del nodo, no se valida.) Estas propiedades no hacen que se valide el mensaje de entrada. Se espera que, si se necesita dicha validación, el nodo de entrada o un nodo de validación anterior ya habrá realizado la validación.

    Si desea ver información más detallada, consulte Validar mensajes y Propiedades de validación.

Conexión de los terminales de salida a otro nodo

Conecte el terminal Out (de salida), Error (de errores) o Failure (de anomalías) de este nodo a otro nodo de este flujo de mensajes para procesar posteriormente el mensaje, procesar errores o enviar el mensaje a un destino adicional. Si no conecta el terminal de errores, el mensaje se elimina. Si no conecta el terminal de anomalías, el intermediario proporcionará un proceso de errores predeterminado, consulte Manejar errores en flujos de mensajes.

Terminales y propiedades

Los terminales del nodo HTTPRequest están descritos en la siguiente tabla.

Terminal Descripción
In (de entrada) El terminal de entrada que acepta un mensaje para que lo procese el nodo.
Failure (de anomalías) El terminal de salida al que se dirige un mensaje si se ha detectado una anomalía durante su proceso en el nodo.
Out (de salida) El terminal de salida al que se direcciona el mensaje si representa la finalización satisfactoria de la solicitud de servicio web y si se requiere proceso adicional dentro del flujo de mensajes.
Error El terminal de salida al que se dirigen los mensajes que incluyen un código de estado HTTP que no está entre 200 y 299, incluidos los códigos de redirección (3xx) si no ha establecido la propiedad Seguir la redirección de HTTP(s).

Las tablas siguientes describen las propiedades del nodo. La columna con la cabecera O indica si la propiedad es obligatoria (marcada con un asterisco en el panel si tiene que entrar un valor cuando no hay definido ningún valor predeterminado); la columna con la cabecera C indica si la propiedad es configurable (puede cambiar el valor cuando añade el flujo de mensajes al archivo de intermediario para desplegarlo).

Las propiedades de Descripción del nodo HTTPRequest están descritas en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción
Nombre de nodo No No El tipo de nodo, HTTPRequest El nombre del nodo.
Descripción corta No No   Descripción breve del nodo.
Descripción larga No No   Texto que describe la finalidad del nodo en el flujo de mensajes.

Las propiedades básicas del nodo HTTPRequest se describen en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción Propiedad de mandato mqsiapplybaroverride
URL de servicio web   El URL del servicio web. Debe proporcionarlo en el formato http://nombre_host[:puerto]/[vía_acceso] donde
  • http://nombre_host debe especificarse.
  • puerto tiene 80 como valor predeterminado. Si especifica un valor, debe incluir los dos puntos : antes del número de puerto.
  • vía_acceso toma de forma predeterminada el valor /. Si especifica un valor, debe incluir la barra inclinada / antes de la vía de acceso.
URLSpecifier
Tiempo de espera de solicitud (seg) 120 Tiempo, en segundos, que un nodo espera la respuesta del servicio web. El rango válido es de 1 a (231)-1. No se puede entrar un valor que represente una espera ilimitada. El tiempo de espera puede tardar un segundo más que el valor especificado. timeoutForServer

Las propiedades de valores HTTP del nodo HTTPRequest se describen en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción Propiedad de mandato mqsiapplybaroverride
Ubicación de proxy HTTP(S) No   Servidor proxy al que se envían solicitudes. Este valor debe estar en el formato nombre_host:puerto. httpProxyLocation
Seguir la redirección HTTP(S) No No No seleccionado Si selecciona el recuadro, se siguen las redirecciones. Si lo deselecciona, no se siguen las redirecciones.  
Versión de HTTP No 1.0 Versión de HTTP a utilizar para las solicitudes. Los valores válidos son 1.0 y 1.1. httpVersion
Habilitar el mantenimiento de activado de HTTP/1.1 No Seleccionado (si Versión HTTP es 1.1) Utilice el mantenimiento de activado de HTTP/1.1 enableKeepAlive
Método HTTP No No POST El método HTTP. Los valores válidos son POST, GET, PUT, DELETE y HEAD. De forma predeterminada, el nodo HTTPRequest utiliza el método HTTP POST cuando se conecta al servidor web remoto. HEAD se utiliza para determinar si está disponible un servicio; por ejemplo, puede utilizarlo un asignador de red que intenta averiguar qué servidores están activos y disponibles, y envía las cabeceras correctas (incluyendo content-length) pero no datos del cuerpo.  
Usar compresión No None Esta propiedad controla si el contenido de la solicitud HTTP está comprimido. Puede seleccionar las opciones none, gzip, zlib (deflate) y deflate. Si la solicitud está comprimida, la cabecera Content-Encoding se establece para indicar que el contenido está comprimido.

zlib (deflate) representa la combinación RFC 1950 + RFC 1951.

deflate representa RFC 1951 únicamente.

requestCompressionType

Las propiedades de SSL del nodo HTTPRequest se describen en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción Propiedad de mandato mqsiapplybaroverride
Protocolo No SSL Protocolo SSL a utilizar al realizar una solicitud HTTPS. protocolo
Cifrados SSL permitidos No   Lista separada por comas de cifrados a utilizar al realizar una solicitud SSL. El valor predeterminado de una Serie vacía significa que hay que utilizar todos los cifrados disponibles. allowedCiphers
Habilitar comprobación de nombre de host de certificado SSL No No Esta propiedad especifica si el nombre de host del servidor que está recibiendo la solicitud debe coincidir con el nombre de host en el certificado SSL. hostnameChecking
Alias de clave de autenticación de cliente SSL No "" (serie vacía) Esta propiedad especifica un alias de autenticación SSL para el lado del cliente de una conexión HTTP. Tomar el valor predeterminado, significa elegir automáticamente la primera clave adecuada. keyAlias

En la tabla siguiente se describen las propiedades de Análisis de mensajes de respuesta del nodo HTTPRequest.

Propiedad O C Valor predeterminado Descripción
Dominio de mensajes No No BLOB Dominio que se utiliza para analizar el mensaje. Si el campo está en blanco, el valor predeterminado es BLOB.
Modelo de mensaje No No Deseleccionado Nombre o ubicación del archivo de esquemas de modelos de mensaje en el que se define el mensaje. Esta lista se llena con todos los archivos de esquemas de modelos de mensajes disponibles para el Dominio de mensajes que ha seleccionado.
Mensaje No No Deseleccionado Nombre o ubicación de la raíz de mensaje dentro del archivo de esquemas de modelos de mensaje. Esta lista se llena con todos los mensajes disponibles que se han definido en el Modelo de mensaje que ha seleccionado.
Formato físico No No Deseleccionado Nombre del formato físico del mensaje. Si está utilizando el analizador MRM o IDOC, seleccione el formato físico del mensaje de entrada de la lista. Esta lista incluye todos los formatos físicos que ha definido para este modelo de mensaje seleccionado. Si establece la propiedad Dominio de mensajes en DataObject, puede establecer esta propiedad en XML o IDoc ALE de SAP. Establezca esta propiedad en IDoc ALE de SAP cuando tenga que analizar una corriente de bits desde un origen externo y generar un árbol de mensajes.

Las propiedades de Opciones de análisis del nodo HTTPRequest están descritas en la tabla siguiente.

Propiedad O C Valor predeterminado Descripción
Temporización del análisis No No A petición Esta propiedad controla cuándo se analiza un mensaje de respuesta. Los valores válidos son A petición, Inmediato y Completo.

Para obtener una descripción completa de esta propiedad, consulte Análisis a petición.

Crear árbol utilizando los tipos de datos de esquema XML No No No seleccionado Esta propiedad controla si el analizador XMLNSC crea elementos de sintaxis en el árbol de mensajes con tipos tipos de datos tomados del esquema XML. Esta propiedad sólo se puede seleccionar si se establece la propiedad Validar del separador Validación en Contenido o Contenido y valor.
Utilizar analizador compacto XMLNSC para dominio XMLNS No No No seleccionado Esta propiedad controla si el analizador compacto XMLNSC se utiliza para mensajes en el dominio XMLNS. Si establece esta propiedad, los datos del mensaje de respuesta aparecerán bajo XMLNSC en los nodos que estén conectados al terminal de salida cuando la cabecera MQRFH2 de entrada o el Dominio de las propiedades de Análisis de mensajes de respuesta sea XMLNS.
Retener el contenido mixto No No No seleccionado Esta propiedad controla si el analizador XMLNSC crea elementos en el árbol de mensaje cuando encuentra texto mixto en un mensaje de respuesta. Si selecciona el recuadro, se crean elementos para el texto mixto. Si deselecciona el recuadro, el texto mixto se ignora y no se crea ningún elemento.
Retener comentarios No No No seleccionado Esta propiedad controla si el analizador XMLNSC crea elementos en el árbol de mensaje cuando encuentra comentarios en un mensaje de respuesta. Si selecciona el recuadro, se crean elementos para los comentarios. Si deselecciona el recuadro, los comentarios se ignoran y no se crea ningún elemento.
Retener instrucciones de proceso No No No seleccionado Esta propiedad controla si el analizador XMLNSC crea elementos en el árbol de mensaje cuando encuentra instrucciones de proceso en un mensaje de respuesta. Si selecciona el recuadro, se crean elementos para las instrucciones de proceso. Si deselecciona el recuadro, las instrucciones de proceso se ignoran y no se crea ningún elemento.
Elementos opacos No No Espacio en blanco Esta propiedad se utiliza para especificar una lista de elementos en el mensaje de respuesta que se analizan opacamente por el analizador XMLNSC. El análisis opaco sólo se realiza si la validación no está habilitada (es decir, si la propiedad Validar está establecida en Ninguno); las entradas que se especifiquen en Elementos opacos se omiten si la validación está habilitada.

Las propiedades de Manejo de errores del nodo HTTPRequest se describen en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción
Sustituir entrada con error No No Seleccionado Si selecciona este recuadro, el contenido del mensaje de entrada se sustituye por el contenido del mensaje de error. Si lo deselecciona, debe especificar Ubicación del mensaje de error.
Ubicación del mensaje de error No OutputRoot La ubicación de inicio en la que se almacenan los elementos analizados de la corriente de bits de error del servicio web. Esta propiedad toma la forma de una referencia de campo ESQL.

Las propiedades Avanzadas del nodo HTTPRequest están descritas en la siguiente tabla.

Propiedad O C Valor predeterminado Descripción Propiedad de mandato mqsiapplybaroverride
Utilizar todo el mensaje de entrada como solicitud No No Seleccionado Si selecciona este recuadro, todo el cuerpo del mensaje de entrada se pasará al servicio web. Si deselecciona este recuadro, debe seleccionar Ubicación del mensaje de solicitud en el árbol.  
Ubicación del mensaje de solicitud en el árbol No InputRoot La ubicación de inicio desde la que se crea la corriente de bits para enviar al servicio web. Esta propiedad toma la forma de una referencia de campo ESQL.  
Sustituir mensaje de entrada por respuesta de servicio web No No Seleccionado Si selecciona este recuadro, el mensaje de respuesta del servicio web sustituye la copia del mensaje de entrada como el contenido del mensaje de salida que se crea. Si deselecciona este recuadro, debe seleccionar Ubicación del mensaje de respuesta en el árbol.  
Ubicación del mensaje de respuesta en el árbol No OutputRoot La ubicación de inicio en la que se almacenan los elementos analizados de la corriente de bits de respuesta del servicio web. Esta propiedad toma la forma de una referencia de campo ESQL.  
Generar cabeceras HTTP predeterminadas desde entrada No No Seleccionado Si selecciona este recuadro, se genera una HTTPRequestHeader. Si lo deselecciona, en el mensaje de entrada debe haber una HTTPRequestHeader válida.  
Aceptar respuestas comprimidas por omisión No No seleccionado Esta propiedad indica si el nodo de solicitud maneja respuestas comprimidas de manera predeterminada. Si la cabecera de la solicitud no acepta una cabecera Accept-Encoding y esta opción está seleccionada, el nodo establecerá la cabecera Accept-Encoding en "gzip, deflate" y descomprimirá todas las respuestas comprimidas que se reciban.

Si el mensaje propagado al nodo Request incluye un cabecera Accept-Encoding, el flujo de mensajes o la aplicación cliente debe manejar las respuestas comprimidas. Por lo tanto, seleccionar esta opción no tiene ningún efecto en este caso.

acceptCompressedResponses

Las propiedades de validación del nodo HTTPRequest se describen en la siguiente tabla.

Para ver una descripción completa de estas propiedades, consulte Propiedades de validación.

Propiedad O C Valor predeterminado Descripción Propiedad de mandato mqsiapplybaroverride
Validar No Ninguna Esta propiedad controla si tiene lugar la validación. Los valores válidos son Ninguno, Contenido y valor, Contenido y Heredar. validateMaster
Acción para anomalía No No Excepción Esta propiedad controla qué sucede si falla la validación. Sólo puede establecer esta propiedad si establece Validar en Contenido o Contenido y valor. Los valores válidos son Rastreo de usuario, Anotaciones de error locales, Excepción y Lista de excepciones.  
Las propiedades de supervisión del nodo se describen en la siguiente tabla.
Propiedad O C Valor predeterminado Descripción
Sucesos No No Ninguno Los sucesos que se han definido para el nodo se visualizan en este separador. De forma predeterminada, no se define ningún suceso de supervisión en ningún nodo en un flujo de mensajes. Utilice Añadir, Editar y Suprimir para crear, cambiar o suprimir sucesos de supervisión para el nodo; consulte Configuración de orígenes de sucesos de supervisión utilizando propiedades de supervisión para obtener detalles.

Puede habilitar e inhabilitar sucesos que se muestran aquí seleccionando o deseleccionando el recuadro Habilitado.

Alteraciones temporales del entorno local

Puede alterar dinámicamente los valores establecidos en el entorno local del mismo modo que se establecen valores en otros elementos de un mensaje. Puede establecer los valores siguientes bajo LocalEnvironment.Destination.HTTP.
Valor Descripción
RequestURL Altera temporalmente la propiedad URL de servicio web en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://ibm.com/abc/';
Timeout Altera temporalmente la propiedad Tiempo de espera de solicitud (segundos) en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.Timeout = 42;
TimeoutMillis Altera temporalmente la propiedad Tiempo de espera de solicitud (segundos) en el nodo. Por ejemplo: se escribe
SET OutputLocalEnvironment.Destination.HTTP.TimeoutMillis = 5000;
Esta propiedad define el tiempo de espera en milisegundos. El valor de TimeoutMillis altera temporalmente el valor de Timeout si se han establecido los dos valores.
ProxyURL Altera temporalmente la propiedad Ubicación de proxy HTTP(S) del nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.ProxyURL = 'my.proxy';
RequestLine.RequestURI Altera temporalmente RequestURI, que es la vía de acceso después del URL y el puerto. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.RequestURI = '/abc/def';
RequestLine.HTTPVersion Altera temporalmente la propiedad Versión de HTTP en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.HTTPVersion = 'HTTP/1.1';
KeepAlive Altera temporalmente la propiedad Habilitar el mantenimiento de activado de HTTP/1.1 en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.KeepAlive = TRUE;
RequestLine.Method Altera temporalmente la propiedad Método HTTP en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.RequestLine.Method = 'GET';
SSLProtocol Altera temporalmente SSLProtocol. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.SSLProtocol = 'TLS';

Los valores válidos son: SSL, SSLv3 y TLS.

SSLCiphers Altera temporalmente la propiedad Cifrados SSL permitidos en el nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.SSLCiphers =
 'SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA';
ProxyConnectHeaders Especifica cabeceras adicionales que se utilizan si la solicitud de salida es una conexión SSL a través de un proxy. Estas cabeceras adicionales se envían con una solicitud CONNECT inicial al proxy. Por ejemplo, cuando utiliza SSL puede enviar información de autenticación proxy a un servidor proxy. Puede enviar varias cabeceras, pero cada una de ellas debe estar separada por un retorno de carro y un salto de línea (ASCII 0x0D 0x0A), de acuerdo con RFC2616; por ejemplo:
DECLARE CRLF CHAR CAST(X'0D0A' AS CHAR CCSID 1208);
SET OutputLocalEnvironment.Destination.HTTP.ProxyConnectHeaders =
'Proxy-Authorization: Basic Zm5lcmJsZTpwYXNzd29yZA==' || CRLF || 
'Proxy-Connection: Keep-Alive' || CRLF;
Este valor sólo se utiliza si la solicitud es una solicitud SSL a través de un servidor proxy. Para enviar información de autenticación proxy para una solicitud no SSL, especifique las cabeceras individuales en la carpeta HTTPRequestHeader, tal como se muestra en el siguiente ejemplo:
SET OutputRoot.HTTPRequestHeader."Proxy-Authorization" =
 'Basic Zm5lcmJsZTpwYXNzd29yZA==';
SET OutputRoot.HTTPRequestHeader."Proxy-Connection" = 'Keep-Alive';
UseFolderMode Establece UseFolderMode. Se utiliza para la generación de corriente de bits; para ciertos analizadores, esto cambia la corriente de bits de salida. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.UseFolderMode = TRUE;
QueryString Permite los valores de los parámetros de serie de consulta de salida. Cada parámetro se debe establecer de forma individual. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.QueryString.param1 = 'my"Value"1';
SET OutputLocalEnvironment.Destination.HTTP.QueryString.param2 = 'my"Value"2';
Los valores ESQL anteriores dan como resultado la siguiente serie de consulta que se va a codificar (en función de http://tools.ietf.org/html/rfc3986) y se envían con la solicitud de salida:
?param1=my%22Value%221&param2= my%22Value%222
Si el URL de destino ya tiene un parámetro de consulta (o más de uno), los parámetros adicionales que se especifiquen se añadirán a la lista existente.
QueryStringCCSID Especifica que, antes de la codificación, los parámetros de serie de consulta se deben convertir en un juego de caracteres que no sea el predeterminado, que es UTF-8. En primer lugar, los parámetros de serie de consulta se convierten en el CCSID especificado antes de que la serie resultante se codifique, según RFC3986. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.QueryStringCCSID = 943;
El ESQL anterior da como resultado que los parámetros QueryString que convierten en la página de códigos 943 antes de codificarlos. Nota: los parámetros de serie de consulta deben contener datos en Unicode.
Compression Altera temporalmente la propiedad Usar compresión del nodo. Por ejemplo:
SET OutputLocalEnvironment.Destination.HTTP.Compression =
 'gzip';
Para establecer un tamaño mínimo (en bytes) en el que aplicar la compresión, utilice la siguiente alteración temporal:
SET OutputLocalEnvironment.Destination.HTTP.MinimumCompressionSize = 1048576;

Cómo trabajar con datos WrittenDestination

Después de realizar la solicitud, se actualiza la carpeta WrittenDestination del entorno local con el URI al cual se ha enviado la solicitud y los detalles de compresión (si se utiliza). WrittenDestination en un nodo HTTPRequest tiene el formato siguiente, con Compression sólo presente si se utiliza compresión:
WrittenDestination = (
   HTTP  = (
      RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
      Compression = (
        OriginalSize = 53 (INTEGER)
        CompressedSize = 71 (INTEGER)
      )
   )
)
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:19


Tema de referenciaTema de referencia | Versión 8.0.0.5 | ac04595_