Antes de empezar
WebSphere Message Broker proporciona el origen de dos nodos de ejemplo definidos por el usuario denominados SwitchNode y TransformNode. Puede utilizar estos nodos en su estado actual o puede modificarlos. Además, puede ver el ejemplo de extensión definida por el usuario que muestra el uso de nodos definidos por el usuario, incluido un nodo de proceso de mensajes escrito en C.
Una biblioteca de implementación cargable, o LIL, es el módulo de implementación para un nodo (o analizador) C. Una LIL se implementa como una biblioteca de enlaces dinámicos (DLL). Tiene la extensión de archivo .lil, no .dll.
Las funciones de implementación que el desarrollador tiene que escribir se listan en el apartado Funciones de implementación de nodo en C. Las funciones de programa de utilidad que WebSphere Message Broker proporciona para ayudar en este proceso se listan en el apartado Funciones de programa de utilidad de nodo en C.
WebSphere Message Broker proporciona el origen de dos nodos de ejemplo definidos por el usuario denominados SwitchNode y TransformNode. Puede utilizar estos nodos en su estado actual o puede modificarlos. También puede utilizar el ejemplo Ejemplo de extensión definida por el usuario.
Conceptualmente, un nodo de proceso de mensajes se utiliza para procesar un mensaje de algún modo y un nodo de salida se utiliza para producir un mensaje como una corriente de bits. Sin embargo, cuando se codifica un nodo de proceso de mensajes o un nodo de salida, éstos son esencialmente lo mismo. Puede realizar el proceso de mensajes en un nodo de salida y, del mismo modo, puede producir un mensaje en una corriente de bits utilizando un nodo de proceso de mensajes. Aunque, para una mayor sencillez, este tema hace referencia principalmente al nodo como nodo de proceso de mensajes, describe la funcionalidad de ambos tipos de nodo.
Para declarar y definir un nodo definido por el usuario en el intermediario, debe incluir una función de inicialización bipGetMessageflowNodeFactory, en su LIL. Los pasos siguientes tienen lugar en la hebra de configuración e indican cómo llama el intermediario a su función de inicialización y cómo esa función declara y define el nodo definido por el usuario:
El procedimiento siguiente muestra cómo crear instancias del nodo:
Se establecen atributos siempre que se inicia el intermediario o cuando se vuelve a desplegar un flujo de mensajes con valores nuevos. El intermediario establece atributos invocando el código de usuario en la hebra de configuración. El código de usuario necesita almacenar estos atributos en el área de contexto de nodo, para utilizarlos posteriormente al procesar mensajes.
{ const CciChar* ucsAttr = CciString("nodeTraceSetting", BIP_DEF_COMP_CCSID) ; insAttrTblEntry(p, (CciChar*)ucsAttr, CNI_TYPE_INTEGER); _setAttribute(p, (CciChar*)ucsAttr, (CciChar*)constZero); free((void *)ucsAttr) ; } { const CciChar* ucsAttr = CciString("nodeTraceOutfile", BIP_DEF_COMP_CCSID) ; insAttrTblEntry(p, (CciChar*)ucsAttr, CNI_TYPE_STRING); _setAttribute(p, (CciChar*)ucsAttr, (CciChar*)constSwitchTraceLocation); free((void *)ucsAttr) ; }
Cuando el intermediario recupera un mensaje de la cola y dicho mensaje llega al terminal de entrada del nodo de salida o de proceso de mensajes definido por el usuario, el intermediario invoca la función de implementación cniEvaluate. Esta función se invoca en la hebra de proceso de mensajes y debe decidir qué se debe hacer con el mensaje. Es posible que esta función se invoque en varias hebras, específicamente si se utilizan instancias adicionales.
En el caso de que se suprima un nodo, el intermediario llama a la función cniDeleteNodeContext. Esta función debe liberar todos los recursos utilizados por el nodo definido por el usuario. Por ejemplo:
void _deleteNodeContext(
CciContext* context
){
static char* functionName = (char *)"_deleteNodeContext()";
free ((void*) context); return;
}