Nodo HTTPInput

Este tema contiene los apartados siguientes:

Finalidad

Utilice el nodo HTTPInput para recibir peticiones de servicios web para que las procese un flujo de mensajes. Al utilizar el nodo HTTPInput con los nodos HTTPReply y HTTPRequest, el intermediario puede actuar como un intermediario para servicios web, y las peticiones de servicios web se pueden transformar y direccionar del mismo modo que los demás formatos de mensaje para los que ofrece soporte WebSphere Business Integration Message Broker.

Si incluye un nodo HTTPInput en un flujo de mensajes, debe incluir un nodo HTTPReply en el mismo flujo, o bien, pasar el mensaje a otro flujo que incluya un nodo HTTPReply (por ejemplo, a través de un nodo MQOutput a un segundo flujo que se inicie con un nodo MQInput). En este último caso, el identificador de peticiones almacenado en el entorno local coordina la petición y la respuesta del cliente (se describe más abajo).

El nodo HTTPInput maneja mensajes de los dominios de mensajes siguientes:

  • MRM
  • XML
  • XMLNS
  • JMS
  • BLOB

Cuando el nodo HTTPInput recibe un mensaje de un cliente de servicios web, invoca a los analizadores adecuados para que interpreten las cabeceras y el cuerpo del mensaje y para que creen el árbol de mensajes que utiliza el flujo de mensajes internamente. El nodo crea un identificador exclusivo para el mensaje de entrada y lo almacena en una matriz binaria de 24 bytes en el árbol LocalEnvironment de LocalEnvironment.Destination.HTTP.RequestIdentifer. El nodo HTTPReply utiliza este valor y no se debe modificar en modo alguno.

Los mensajes HTTP siempre son no permanentes y no tienen ningún orden asociado.

Los mensajes HTTP son no transaccionales. Sin embargo, si el flujo de mensajes interactúa con una base de datos u otro recurso externo como, por ejemplo, una cola WebSphere MQ, estas interacciones se llevan a cabo transaccionalmente. El nodo HTTPInput proporciona confirmación o restitución, en función de cómo finaliza el flujo de mensajes y cómo se ha configurado para el manejo de errores (cómo se han conectado los terminales de anomalías, por ejemplo). Si este nodo restituye el flujo de mensajes, se genera un mensaje de error SOAP y se devuelve al cliente de servicios web.

Si se produce una excepción en sentido descendente en este flujo de mensajes, y no se captura pero se devuelve a este nodo, el nodo construye una respuesta de error para el cliente invocador. Esta respuesta es un mensaje de error SOAP derivada de la excepción en sí.

Si incluye un nodo de salida en un flujo de mensajes que empieza con un nodo HTTPInput, puede ser cualquiera de los nodos de salida para los que se ofrece soporte (incluidos los nodos de salida definidos por el usuario). Puede crear un flujo de mensajes que reciba mensajes de clientes de servicios web y genere mensajes para clientes que utilicen todos los transportes para los que se ofrece soporte para conectar al intermediario, puesto que puede configurar el flujo de mensajes de modo que solicite al intermediario que facilite las conversiones necesarias.

Si crea un flujo de mensajes para utilizarlo como un subflujo, no puede utilizar un nodo de entrada estándar; debe utilizar una instancia del nodo Input como primer nodo para crear un terminal de entrada para el subflujo.

Si el flujo de mensajes no recibe peticiones de servicios web, puede elegir uno de los nodos de entrada que se indican a continuación:

  • MQeInput
  • MQInput
  • Real-timeInput
  • SCADAInput
  • Un nodo de entrada definido por el usuario

El nodo HTTPInput se representa en el área de trabajo mediante el icono siguiente:

icono del nodo HTTPInput

Utilización de este nodo en un flujo de mensajes

Puede utilizar este nodo en dos escenarios diferentes:

  1. El intermediario actúa como servicio web.

    El cliente de servicios web genera una petición de servicios web que, a continuación, se dirige al nodo HTTPInput de un flujo de mensajes que se ejecuta en el intermediario. El flujo de mensajes se debe diseñar para que procese el mensaje utilizando el mismo procedimiento y genere una respuesta que tenga el formato de una respuesta de servicio web. El intermediario envía la respuesta al cliente de servicios web a través del nodo HTTPReply del flujo de mensajes.

    Por ejemplo, tiene clientes de servicios web que interactúan con un servicio web que proporciona información específica sobre un tema determinado (precios de valores o tipos de cambio, por ejemplo). Sustituye este servicio por una solución de búsqueda de base de datos interna, pero no desea realizar cambios en las aplicaciones cliente. Diseña un flujo de mensajes que incluye un nodo HTTPInput que recibe peticiones de sus clientes. Este nodo conecta a un nodo Compute que recupera la información necesaria de la base de datos y genera un nuevo mensaje de salida, con el formato de una respuesta de servicio web y que incluye los nuevos datos. El nodo Compute pasa el mensaje al nodo HTTPReply, lo que genera la respuesta para el cliente de servicios web.

  2. El intermediario actúa como un intermediario del servicio web.

    El cliente de servicios web genera una petición de servicio web que, a continuación, se dirige al nodo HTTPInput de un flujo de mensajes que se ejecuta en el intermediario. El flujo de mensajes se debe diseñar para que procese el mensaje utilizando el mismo procedimiento y para que interactúe con el servicio web al que la aplicación cliente considera que está conectado. Debe incluir un nodo HTTPRequest en el flujo de mensajes para que envíe una petición al servicio web y recupere la respuesta. El flujo de mensajes también genera una respuesta para el cliente, basada en toda o en parte de la respuesta que se ha recibido en el nodo HTTPRequest, con el formato de una respuesta de servicio web. El intermediario envía la respuesta al cliente de servicios web a través del nodo HTTPReply del flujo de mensajes.

    Por ejemplo, dispone de una aplicación cliente que interactúa con un servicio web que envía información a otra aplicación que solicita la información en otro formato. Diseña un nuevo flujo de mensajes que incluye un nodo HTTPInput, un nodo HTTPRequest y un nodo HTTPReply. El nodo HTTPInput recibe la entrada del cliente de servicios web y pasa el mensaje al nodo HTTPRequest, que interactúa con el servicio web.

    Cuando se recibe la respuesta, el nodo HTTPRequest propaga el mensaje a un nodo Compute, que crea un mensaje de salida en formato existente a partir del contenido de la respuesta del servicio web. El flujo de mensajes finaliza con un nodo MQOutput, que entrega el mensaje transformado a la aplicación existente, seguida de un nodo HTTPReply que proporciona la respuesta adecuada para el cliente de servicios web.

    En un segundo ejemplo, los clientes interactúan con un servicio web y desea conservar información sobre las peticiones al servicio web por motivos de auditoría. Diseña un flujo de mensajes que incluye un nodo HTTPInput conectado a un nodo Warehouse. El mensaje de entrada que se recibe del cliente de servicios web se almacena en la base de datos y el nodo Warehouse pasa el mensaje a un nodo HTTPRequest, que interactúa con el servicio web. Cuando se recibe la respuesta, el nodo HTTPRequest la propaga al nodo HTTPReply, que genera la respuesta para el cliente de servicios web.

Configuración del nodo HTTPInput

Se puede configurar al transferir una instancia del nodo HTTPInput a un flujo de mensajes. Pulse el botón derecho del ratón en la vista del editor y, a continuación, pulse en Propiedades. En el diálogo de propiedades se muestran las propiedades básicas del nodo.

Todas las propiedades obligatorias para las que debe entrar un valor (las que no tienen un valor por omisión definido) se muestran marcadas con un asterisco en el diálogo de propiedades.

Configure el nodo HTTPInput tal como se indica a continuación:

  1. En Selector de URL, entre el URL del que este nodo recibe las peticiones de servicios web.
  2. Entre el intervalo de tiempo de espera de Tiempo máximo de espera de cliente como un número de segundos. Es el tiempo que el escucha TCP/IP que recibe el mensaje de entrada del cliente de servicios web espera una respuesta del nodo HTTPReply del flujo de mensajes. Si, durante este tiempo, se recibe una respuesta, el escucha propaga la respuesta al cliente. Si, por el contrario, no se recibe ninguna respuesta, el escucha envía un mensaje de error SOAP al cliente que indica que el tiempo de espera ha finalizado.
  3. Seleccione Valor por omisión en el navegador del diálogo de propiedades y establezca valores para las propiedades que describen el dominio del mensaje, el conjunto de mensajes, el tipo de mensaje y el formato del mensaje que utiliza el nodo para determinar el modo de analizar el mensaje entrante.
    • En el campo Dominio del mensaje, seleccione el nombre del analizador que está utilizando de la lista desplegable. Puede elegir entre:
      • MRM
      • XML
      • XMLNS
      • JMSMap
      • JMSStream
      • BLOB
    • Si utiliza el analizador MRM, seleccione el conjunto de mensajes correcto de la lista desplegable del campo Conjunto de mensajes. Esta lista se llena con los conjuntos de mensajes disponibles cuando se selecciona MRM como dominio.

      Deje el campo Conjunto de mensajes en blanco para los analizadores XML, XMLNS, JMS y BLOB.

    • Si utiliza el analizador MRM, seleccione el mensaje correcto de la lista desplegable del campo Tipo de mensaje. Esta lista se llena con los mensajes que se definen en el conjunto de mensajes que se ha seleccionado.

      Deje el campo Tipo de mensaje en blanco para los analizadores XML, XMLNS, JMS y BLOB.

    • Seleccione el formato del mensaje de la lista desplegable del campo Formato del mensaje. Esta lista incluye todos los formatos físicos que se han definido para este conjunto de mensajes. Si ha utilizado los nombres por omisión para los formatos físicos, la lista contiene:
      • CWF1 (el ID del formato físico personalizado por omisión)
      • XML1
      • TDS1
      Si ha especificado nombres diferentes (que no son por omisión) para cualquiera de estos formatos, los nombres aparecen en la lista.

      Deje el campo Formato del mensaje en blanco para los analizadores XML, XMLNS, JMS y BLOB.

  4. Seleccione Validación en el navegador del diálogo de propiedades si desea que el analizador MRM valide el cuerpo de los mensajes frente al diccionario que se genera del conjunto de mensajes. (Si se propaga un mensaje al terminal de anomalías del nodo, no se valida).
    • Inicialmente, Validar está establecido en Ninguna. Cámbielo por Contenido y valor de modo que se solicite tanto la validación del contenido (comprobaciones de la composición y el contenido de tipo) como la validación de valor (comprobaciones de tipo de datos de valor, comprobaciones de nulo permitido, comprobaciones de longitud, comprobaciones de rango y comprobaciones de enumeración, entre otras).
    • Para determinar lo que sucede si la validación da error, seleccione una de las opciones siguientes para Acción para anomalía:
      • Rastreo de usuario: escribe todas las anomalías de validación en el rastreo de usuario y el proceso continúa.
      • Anotaciones de error locales: escribe todas las anomalías de validación en las anotaciones de sucesos y el proceso continúa.
      • Excepción: emite una excepción a la primera anomalía de validación. Éste es el funcionamiento por omisión.
      Las dos primeras opciones son útiles cuando se invoca la validación por primera vez, puesto que se pueden ver todas las anomalías de validación, no sólo la primera que se encuentra. Una vez que se han analizado las anomalías, generalmente, se selecciona Excepción para su uso futuro.

      Los destinos de las anomalías se comportan igual que en el caso de la salida del nodo Trace. Así, si, por ejemplo, se selecciona Rastreo de usuario, las entradas de rastreo se escriben sin tener en cuenta el valor del distintivo del rastreo de usuario para el flujo de mensajes.

    • Establezca un valor para Cronometraje:
      • Diferido: valida el mensaje a medida que se analiza cada campo. Éste es el funcionamiento por omisión.
      • Inmediato: el mensaje se valida inmediatamente, pero se permite que haya subconjuntos sin resolver (de este modo, se ofrece soporte para los valores Elección y Mensaje de Composición en los que el elemento aún no se ha resuelto).
      • Completo: valida todo el mensaje inmediatamente.
      Las opciones disponibles para esta propiedad aprovechan la posibilidad de análisis parcial de los analizadores, puesto que puede elegir validar sólo los campos a los que se accede (Diferido), o bien, validar todo el mensaje (Inmediato y Completo). Lo primero mejora el rendimiento y lo último ofrece mayor seguridad.
    • La propiedad del recuadro de selección Incluir todas las limitaciones de valores está seleccionada y no se puede cambiar de su valor por omisión. Este valor significa que se llevan a cabo comprobaciones completas de los tipos de datos y de los valores.
    • La propiedad Arreglo no se puede cambiar de su valor por omisión, Ninguno. Si Acción por anomalía no se establece en Excepción, se toma una acción reparadora limitada cuando se producen anomalías de validación. Si establece Acción por anomalía en Excepción, no se lleva a cabo ninguna acción reparadora y se emite una excepción a la primera anomalía de validación.
  5. Seleccione Descripción en el navegador del diálogo de propiedades para especificar una descripción corta, una descripción larga, o ambas.
  6. Pulse el botón en Aplicar para realizar los cambios en el nodo HTTPInput sin cerrar el diálogo de propiedades. Pulse el botón en Aceptar para aplicar los cambios y cerrar el diálogo de propiedades.

    Pulse el botón en Cancelar para cerrar el diálogo y descartar todos los cambios que ha realizado en las propiedades.

Conexión de terminales

HTTPInput direcciona cada mensaje que recupera correctamente al terminal de salida. Si la validación del mensaje da error, el mensaje se direcciona al terminal de anomalías; puede conectar nodos a este terminal para manejar esta condición. Si no ha conectado el terminal de anomalías, el mensaje se descarta, el Tiempo máximo de espera de cliente finaliza y el escucha TCP/IP devuelve un error al cliente. No existen otras situaciones en las que el mensaje se direccione al terminal de anomalías.

Si el nodo capta el mensaje después de emitirse una excepción más adelante en el flujo de mensajes, el mensaje se direcciona al terminal de captación. Si no se ha conectado el terminal de captación, el mensaje se descarta, el Tiempo máximo de espera de cliente finaliza y el escucha TCP/IP devuelve un error al cliente.

Terminales y propiedades

Los terminales del nodo HTTPInput se describen en la tabla siguiente:

Terminal Descripción
Terminal de anomalías Terminal de salida al que se direcciona el mensaje si se produce un error.
Terminal de salida Terminal de salida al que se direcciona el mensaje si se recupera correctamente.
Terminal de captación Terminal de salida al que se direcciona el mensaje si se emite una excepción en sentido descendente y la captura este nodo.

En las tablas siguientes se describen las propiedades del nodo; la columna que tiene el encabezamiento M indica si se trata de una propiedad obligatoria (marcada con un asterisco en el diálogo de propiedades si se debe especificar un valor cuando no se ha definido ningún valor por omisión), la columna que tiene el encabezamiento C indica que se trata de una propiedad configurable (se puede cambiar el valor cuando se añade el flujo de mensajes al archivo bar para su difusión).

Las propiedades básicas del nodo HTTPInput se describen en la tabla siguiente:

Propiedad M C Valor por omisión Descripción
Selector de URL   Ubicación de la que se recuperan las peticiones de servicios web. Debe proporcionarlo en uno de los formatos siguientes:
http://<nombreSistema>[:<puerta>]/[<víaAcceso>]
o bien
/<fragmento vía de acceso>/*
donde * es un carácter comodín que se puede utilizar para cualquier coincidencia.
Tiempo máximo de espera de cliente No 180 Tiempo que espera el escucha, en segundos, antes de enviar un mensaje de error al cliente. El rango válido es de cero (lo que significa una espera indefinida) a (231)-1.

Las propiedades por omisión del nodo HTTPInput se describen en la tabla siguiente:

Propiedad M C Valor por omisión Descripción
Dominio del mensaje No No   Dominio del mensaje entrante.
Conjunto de mensajes No No   Conjunto de mensajes del mensaje entrante.
Tipo de mensaje No No   Tipo del mensaje entrante.
Formato del mensaje No No   Formato del mensaje entrante.

Las propiedades de validación del nodo HTTPInput se describen en la tabla siguiente:

Propiedad M C Valor por omisión Descripción
Validar No Ninguna Si debe llevarse a cabo la validación. Los valores válidos son Ninguna y Contenido y valor.
Acción por anomalía No Rastreo de usuario Lo que sucede si la validación da error. Sólo puede establecer esta propiedad si ha establecido Validar en Contenido y valor. Los valores válidos son Rastreo de usuario, Anotaciones de error locales y Excepción.
Cronometraje No Diferido Cuando se produce la validación. Sólo puede establecer esta propiedad si ha establecido Validar en Contenido y valor. Los valores válidos son Diferido, Inmediato y Completo.
Incluir todas las limitaciones de valores No Seleccionado Esta propiedad no se puede cambiar.
Arreglo No Ninguno Esta propiedad no se puede cambiar.

Las propiedades de descripción del nodo HTTPInput se describen en la tabla siguiente:

Propiedad M C Valor por omisión Descripción
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.

Conceptos relacionados
WebSphere MQ Web Services Transport
Flujos de mensajes
Extensiones definidas por el usuario

Tareas relacionadas
Cómo decidir los nodos que utilizar
Utilización de más de un nodo de entrada
Manejo de errores en flujos de mensajes
Edición de propiedades configurables

Referencia relacionada
Nodo Compute
Nodo HTTPReply
Nodo HTTPRequest
Nodo Input
Nodo MQeInput
Nodo MQInput
Nodo MQOutput
Nodo Real-timeInput
Nodo SCADAInput