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

Ciclo de vida de nodos de proceso de mensajes definidos por el usuario en C

Un nodo de proceso de mensajes definidos por el usuario para el lenguaje de programación C pasa a través de varias etapas.

Este tema trata los objetos que se crean y destruyen, y las funciones y clases de implementación a las que se llama en las siguientes fases:

La información de este tema se aplica a los nodos de salida y a los nodos de proceso de mensajes. Estos dos tipos de nodos se pueden considerar juntos porque aunque un nodo de proceso de mensajes se utiliza generalmente para procesar un mensaje y un nodo de salida se utiliza para proporcionar una salida, con formato de corriente de bits, puede utilizar cualquiera de estos dos tipos de nodos para realizar cualquiera de estas funciones.

Registro

Un nodo de proceso de mensajes definido por el usuario se registra con el intermediario cuando el sistema operativo carga e inicializa el LIL que contiene el nodo.

El intermediario llama a bipGetMessageflowNodeFactory para establecer la función del LIL y cómo debe llamarse a la misma.

La función bipGetMessageflowNodeFactory a su vez llama a la función cniCreateNodeFactory, la cual devuelve un nombre de fábrica o de grupo para todos los nodos a los que da soporte el LIL.

A continuación, el LIL debe llamar a la función de utilidad cniDefineNodeClass para pasar el nombre de cada nodo y una tabla de funciones virtuales de los punteros de función, de las funciones implementadas.

Creación de una instancia

Durante la fase de creación de instancias, se crea una instancia de un nodo de proceso de mensajes definido por el usuario. La fase comienza cuando el intermediario crea un flujo de mensajes y llama a la función cniCreateNodeContext para cada creación de una instancia del nodo definido por el usuario en ese flujo de mensajes. La función cniCreateNodeContext es la que se especifica en el campo iFpCreateNodeContext de la estructura CNI_VFT que se pasa a cniDefineNodeClass para ese tipo de nodo. Esta función debe asignar los recursos requeridos para ese nodo, incluida la memoria suficiente para que la creación de instancia del nodo definido por el usuario pueda contener los valores de los atributos configurados.

El intermediario creará una instancia del nodo y llamará a cniCreateNodeContext en las siguientes ocasiones:
  • Se crea el flujo de mensajes:
    • Se está iniciando el intermediario (el usuario ha ejecutado mqsistart). Los flujos de mensajes desplegados anteriormente se vuelven a crear cuando se inicia el intermediario.
    • Se vuelve a cargar el grupo de ejecución (el usuario ha ejecutado mqsireload). Los flujos de mensajes que se han desplegado anteriormente se vuelven a crear cuando se carga de nuevo el grupo de ejecución.
    • Se ha producido un error grave dentro del grupo de ejecución, por lo que el grupo de ejecución se ha reiniciado.
  • Se vuelve a desplegar el flujo de mensajes. Cuando se modifica un flujo de mensajes y se vuelve a desplegar, el intermediario procesa este nuevo despliegue suprimiendo todos los nodos del flujo y volviendo a crearlos con la nueva configuración.
Nota: No se crea un flujo de mensajes al iniciar un grupo de ejecución. Al detener un grupo de ejecución simplemente se detienen todos los flujos, pero no se suprime ningún flujo ni se desactiva el proceso. Al reiniciar un grupo de ejecución, se inician los flujos de mensajes pero no se vuelven a crear.

Dentro de cniCreateContext, la extensión definida por el usuario llama a las dos funciones cniCreateInputTerminal y cniCreateOutputTerminal para establecer qué terminales de entrada y de salida tiene el nodo de proceso de mensajes.

Proceso

Durante la fase de proceso del ciclo de vida de un nodo de proceso de mensajes definido por el usuario, el mensaje se transforma de algún modo cuando se lleva a cabo algún tipo de proceso en el mensaje de entrada.

Cuando el intermediario recupera un mensaje de la cola y dicho mensaje llega al terminal de entrada del nodo definido por el usuario, el intermediario llama a la función de implementación cniEvaluate. Esta función se utiliza para decidir lo que se hace con el mensaje.

Puede utilizar una serie de funciones de utilidad de nodo en su nodo de proceso de mensajes definido por el usuario para realizar una serie de funciones de proceso de mensajes, como por ejemplo acceder a los datos del mensaje, acceder a ESQL, transformar un objeto de mensajes y propagar un mensaje. Debe incluir las funciones de utilidad de nodo que va a utilizar para procesar el mensaje dentro de la función cniEvaluate.

Esta interfaz no genera automáticamente un subárbol de propiedades para un mensaje. No es un requisito que un mensaje tenga un subárbol de propiedades, aunque puede resultarle útil crear uno que proporcione una subestructura de árbol de mensaje independientemente del nodo de entrada. Si desea que se cree un subárbol de propiedades en un mensaje y además está utilizando un nodo de entrada definido por el usuario, deberá hacerlo usted mismo.

Destrucción

Cuando un nodo de proceso de mensajes definido por el usuario ha procesado un mensaje, debe asegurarse de que se ha destruido para liberar cualquier recurso del sistema que se utilice y para liberar las áreas de datos específicas a la instancia del nodo como, por ejemplo, el contexto, que se han adquirido cuando se ha creado o procesado el mensaje.

Se destruye una instancia de un nodo de proceso de mensajes definido por el usuario cuando el intermediario llama a la función cniDeleteNodeContext.

El intermediario llama a cniDeleteNodeContext cuando se suprime la instancia del nodo. Los siguientes sucesos pueden provocar la supresión de un nodo:
  • Finalización controlada del proceso de grupo de ejecución:
    • Se está deteniendo el intermediario (el usuario ha ejecutado mqsistop).
    • Se vuelve a cargar el grupo de ejecución (el usuario ha ejecutado mqsireload)
    • Se ha producido un error grave dentro del grupo de ejecución, por lo que el grupo de ejecución se ha reiniciado.
    Nota: Esto NO incluye detener un grupo de ejecución. Al detener un grupo de ejecución simplemente se detienen todos los flujos, pero no se suprime ningún flujo ni se desactiva el proceso.
  • Se ha suprimido un flujo de mensajes.
  • Se vuelve a desplegar el flujo de mensajes. Cuando se modifica un flujo de mensajes y se vuelve a desplegar, el intermediario procesa este nuevo despliegue suprimiendo todos los nodos del flujo y volviendo a crearlos con la nueva configuración.
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 17:00:19


Tema de conceptoTema de concepto | Versión 8.0.0.5 | as01394_