Antes de comenzar
Un nodo de entrada puede recibir datos de cualquier tipo de origen externo, por ejemplo un sistema de archivos o conexiones FTP, a condición de que la salida del nodo esté en el formato correcto. Para conexiones a colas o bases de datos, deberá utilizar el nodos IBM primitivos y las llamadas de API proporcionadas, principalmente porque los nodos primitivos ya están configurados para el manejo de errores. No utilice los mandatos mqget o mqput para el acceso directo a las tablas de base de datos.
{ static char* functionName = (char *)"_Input_run()"; void* buffer; CciTerminal* terminalObject; int buflen = 4096; int rc = CCI_SUCCESS; int rcDispatch = CCI_SUCCESS; char xmlData[] = "<A>data</A>"; buffer = malloc(buflen); memcpy(buffer, &xmlData, sizeof(xmlData)); cniSetInputBuffer(&rc, message, buffer, buflen); } /*propagar etc*/ free(buffer);El ejemplo anterior ilustra un área de memoria que se está asignando (buffer = malloc(buflen);). Si programa en C, siempre que asigne memoria deberá liberarla cuando ya no la necesite. Dado que es posible que el intermediario intente acceder a esta memoria en cualquier momento mientras el mensaje se está propagando través del flujo, sólo deberá liberar la memoria después de invocar cniPropagate en el mismo CciMessage.
Un nodo de entrada tiene la responsabilidad de realizar el proceso apropiado de fin de mensaje cuando se ha propagado un mensaje a través de un flujo de mensajes. Específicamente, el nodo de entrada necesita hacer que se confirmen o se restituyan las transacciones y devolver las hebras a la agrupación de hebras.
Cada hebra de flujo de mensajes se asigna de una agrupación de hebras mantenidas para cada flujo de mensajes e inicia la ejecución en la función cniRun. Determine el comportamiento de una hebra utilizando la función de utilidad cniDispatchThread junto con el valor de retorno apropiado.
El término transacción se utiliza aquí de forma genérica para describir una transacción coordinada globalmente o una transacción controlada por el intermediario. Las transacciones coordinadas globalmente las coordina WebSphere MQ como un gestor de transacciones que se ajusta a las normas de XA o el Servicio de recuperación de recursos (RRS) en z/OS. WebSphere Message Broker controla las transacciones confirmando (o restituyendo) los recursos de base de datos y, a continuación, confirmando las unidades de trabajo de WebSphere MQ; sin embargo, si se utiliza un nodo definido por el usuario, el intermediario no puede confirmar automáticamente las actualizaciones de recursos. El nodo definido por el usuario utiliza valores de retorno para indicar si una transacción se ha ejecutado satisfactoriamente y controlar si las transacciones se han confirmado o restituido. La infraestructura del intermediario captura las excepciones no manejadas y se restituye la transacción.
La tabla siguiente describe cada uno de los valores de retorno soportados, el efecto que tiene cada uno en las transacciones y lo que hace el intermediario con la hebra actual.
Valor de retorno | Efecto en la transacción | Acción de intermediario en la hebra |
---|---|---|
CCI_SUCCESS_CONTINUE | confirmada | Invoca la misma hebra otra vez en la función cniRun. |
CCI_SUCCESS_RETURN | confirmada | Devuelve la hebra a la agrupación de hebras. |
CCI_FAILURE_CONTINUE | restituida | Invoca la misma hebra otra vez en la función cniRun. |
CCI_FAILURE_RETURN | restituida | Devuelve la hebra a la agrupación de hebras. |
CCI_TIMEOUT | No aplicable. La función excede el tiempo de espera periódicamente mientras espera un mensaje de entrada. | Invoca la misma hebra otra vez en la función cniRun. |
{ ... cniDispatchThread(&rcDispatch, ((NODE_CONTEXT_ST *)context)->nodeObject); ... if (rcDispatch == CCI_NO_THREADS_AVAILABLE) return CCI_SUCCESS_CONTINUE; else return CCI_SUCCESS_RETURN; }
Antes de propagar el mensaje, tiene que decidir qué datos de flujo de mensaje desea propagar y qué terminal debe recibir los datos.
El objeto de terminal (terminalObject) se deriva de una lista mantenida por el propio nodo definido por el usuario.
if (terminalObject) { if (cniIsTerminalAttached(&rc, terminalObject)) { if (rc == CCI_SUCCESS) { cniPropagate(&rc, terminalObject, destinationList, exceptionList, message); } }
En el ejemplo anterior, se utiliza la función cniIsTerminalAttached para probar si se puede propagar el mensaje al terminal especificado. Si no utiliza la función cniIsTerminalAttached y el terminal no está conectado a otro nodo por un conector, el mensaje no se propaga. Si utiliza esta función, puede modificar el comportamiento del nodo cuando no hay ningún terminal conectado.