La información de este tema se aplica tanto a los nodos de salida como a los nodos de proceso de mensajes. Ambos tipos de nodo pueden considerarse como un solo nodo porque, aunque un nodo de proceso de mensajes se utiliza normalmente para procesar un mensaje y un nodo de salida se utiliza para proporcionar una salida de mensaje (en forma de corriente de bits), puede utilizarse cualquiera de los dos tipos de nodo para realizar cualquiera de las dos funciones.
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 se inicia cuando el intermediario recibe la tabla de punteros de función e invoca la función cniCreateNodeContext para cada creación de instancia del nodo definido por el usuario. La función cniCreateNodeContext se invoca para cada flujo de mensajes que utiliza el nodo de proceso de mensajes definido por el usuario. Esta función debe asignar memoria a dicha instancia del nodo definido por el usuario para que retenga los valores de los atributos configurados.
En cniCreateContext, el intermediario invoca las dos funciones cniCreateInputTerminal y cniCreateOutputTerminal para establecer qué terminales de entrada y salida tiene el nodo de proceso de mensajes.
Un nodo de proceso de mensajes definido por el usuario se registra con el intermediario cuando el sistema operativo ha cargado e inicializado la LIL (biblioteca de implementación cargable) que contiene el nodo.
El intermediario invoca bipGetMessageflowNodeFactory para establecer la función de la LIL y la manera en que debe invocarse.
La función bipGetMessageflowNodeFactory, a su vez, invoca la función cniCreateNodeFactory, que devuelve una fábrica o nombre de grupo para todos los nodos a los que la LIL da soporte.
A continuación, la LIL debe invocar la función de programa de utilidad cniDefineNodeClass para pasar el nombre de cada nodo y una tabla de funciones virtuales de las direcciones de las funciones de implementación.
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 tiene lugar una operación de proceso determinada 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 invoca la función de implementación cniEvaluate. Esta función se utiliza para decidir qué hacer con el mensaje.
Puede utilizar un rango de funciones de programa de utilidad de nodo en su nodo de proceso de mensajes definido por el usuario para realizar un rango de funciones de proceso de mensajes, como acceder a los datos de mensaje, acceder a ESQL, transformar un objeto de mensaje y propagar un mensaje. Debe incluir las funciones de programa de utilidad de nodo que vaya a utilizar para procesar el mensaje en la función cniEvaluate.
Esta interfaz no genera automáticamente un subárbol de propiedades para un mensaje. No es un requisito para un mensaje tener un subárbol de propiedades, aunque puede resultarle útil crear uno para proporcionar una estructura de árbol de mensajes consistente independientemente de un nodo de entrada. Si desea que se cree un subárbol de propiedades en un mensaje, y también utiliza un nodo de entrada definido por el usuario, deberá hacerlo usted mismo.
Cuando un nodo de proceso de mensajes definido por el usuario haya procesado un mensaje, debe asegurarse de que éste se destruya a fin de liberar los recursos de sistema que utilizaba, así como las áreas de datos específicas de la instancia de nodo, como el contexto, que se adquirieron al crearse o procesarse el mensaje.
Una instancia de un nodo de proceso de mensajes definido por el usuario se destruye cuando el intermediario invoca la función cniDeleteNodeContext. El intermediario invoca cniDeleteNodeContext cuando
La fase de registro tiene lugar cuando un nodo de proceso de mensajes definido por el usuario y escrito en Java se da a conocer al intermediario, o se registra con el mismo.
Siempre que un intermediario se inicia, carga todas las lils y clases Java relevantes. Para asegurarse de que un nodo de proceso de mensajes está registrado con el intermediario, debe proporcionar al intermediario una clase que implemente la interfaz MbNodeInterface y que se encuentre en la vía de acceso de clase del intermediario.
Se crean instancias para un nodo de proceso de mensajes definido por el usuario cuando un intermediario difunde un flujo de mensajes que contiene el nodo de proceso de mensajes definido por el usuario. Al crearse instancias del nodo, se invoca el constructor de la clase de nodo de proceso de mensajes.
Cuando se crean instancias de un nodo, se crean los terminales que se hayan especificado utilizando los métodos relevantes. Un nodo de proceso de mensajes puede tener cualquier número de terminales de entrada y salida asociados. Debe incluir los métodos createInputTerminal y createOutputTerminal en el constructor de nodos para declarar estos terminales.
Entre los terminales de salida se incluyen los terminales de salida (out), los terminales de anomalía y los de captación. Utilice la clase createOutputTerminal del constructor de clases de nodos para crear todos los terminales de salida que necesite.
Como mínimo, sólo debe crear estos terminales de salida utilizando la clase de constructor. No obstante, si necesita inicializar valores de atributo, también debe incluir ahora ese código en el nodo de proceso de mensajes.
Si desea manejar las excepciones que se hayan vuelto a pasar al nodo de proceso de mensajes, es aconsejable hacerlo mediante la creación de un terminal de anomalías para el nodo de proceso de mensajes definido por el usuario y utilizando el método createOutputTerminal. Es prudente utilizar el terminal de anomalías para realizar este proceso porque ahí es donde WebSphere Business Integration Message Broker propaga errores.
Debe asegurarse de que las excepciones que reciba el nodo de proceso de mensajes se gestionen correctamente. Si no incluye un terminal de anomalías, el nodo de proceso de mensajes no intentará manejar la excepción. Si el flujo de mensajes no contiene ningún método de manejo de excepciones, las excepciones emitidas volverán a pasarse al nodo de entrada, en donde serán gestionadas.
Si recibe excepciones, debe asegurarse de volver a emitir aquéllas que el nodo de proceso de mensajes no pueda gestionar por sí solo, de manera que la excepción se entrega al nodo de entrada para su manejo, por ejemplo para restituir una transacción.
Durante la fase de proceso del ciclo de vida de un nodo de proceso de mensajes definido por el usuario, el nodo de proceso de mensajes toma la jerarquía lógica del mensaje y lo procesa de una manera concreta.
Un nodo de proceso de mensajes Java definido por el usuario se destruye al suprimirse el nodo o cerrarse el intermediario. No es necesario que incluya en el código información que especifique que el nodo debe suprimirse físicamente, ya que de esto se encarga el recopilador de basura.
No obstante, si desea que se le notifique de la supresión de algún nodo, puede utilizar el método onDelete. Es posible que desee utilizarlo si hay otros recursos aparte de los que se recopilarán como basura una vez suprimidos. Por ejemplo, si ha abierto un zócalo, éste no volverá a cerrarse correctamente cuando se suprima el nodo automáticamente. Puede incluir esta instrucción en el método onDelete para asegurarse de que el zócalo esté cerrado correctamente.
Conceptos relacionados
Nodos del flujo de mensajes
Nodos de proceso de mensajes definidos por el usuario
Planificación de nodos de proceso de mensajes definidos por el usuario
Tareas relacionadas
Creación de un nodo de proceso de mensajes en C
Creación de un nodo de proceso de mensajes o un nodo de salida en Java
Referencia relacionada
cniCreateInputTerminal
cniCreateNodeFactory
cniDeleteNodeContext
cniDefineNodeClass
cniEvaluate
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
as01394_ |