Acerca del ejemplo de Nodo DatabaseInput

Mediante un nodo DatabaseInput, puede crear flujos de mensajes que reaccionen rápidamente a los cambios en los datos de la aplicación contenidos en las bases de datos. El nodo recupera los datos actualizados directamente de la base de datos.

El diagrama siguiente muestra la secuencia de sucesos. Cuando se introduce un cambio en la tabla de datos de la aplicación, se activa un desencadenante y la tabla de sucesos se rellena con suficiente información para determinar qué filas han cambiado.

Estructura de un despliegue de nodo DatabaseInput

La estructura de las tablas de datos de aplicación que se utiliza en este ejemplo se muestra en el diagrama siguiente:

Tablas de datos de aplicación de ejemplo con registros de clientes y direcciones

Por ejemplo, si una entrada se inserta en una tabla de clientes, las filas insertadas en las tablas de clientes y de sucesos se parecen a la siguiente tabla.

PKEY FIRSTNAME LASTNAME CCODE
cust1 Joe Bloggs sales

Tabla de sucesos

La tabla de sucesos es una tabla de base de datos creada por el usuario, generalmente dentro del mismo esquema que la tabla o tablas de aplicación para las que se almacenan sucesos. La tabla de sucesos describe el tipo de cambio realizado en una tabla de aplicaciones y un identificador para la fila cambiada. En la tabla siguiente se muestran algunas columnas típicas de una tabla de sucesos y las razones para incluirla.

Nombre de columna Función de columna Valor de ejemplo
EVENT_ID Necesario. La clave primaria, que identifica el suceso que se está procesando en cualquier momento dado. 1
OBJECT_KEY Necesario. El elemento de identificación de la fila cambiada en la tabla de aplicación, normalmente el elemento de la fila de la columna de clave primaria. cust1
OBJECT_VERB Opcional. El cambio realizado, normalmente CREATE, UPDATE o DELETE. Este suceso se utiliza para distinguir un suceso DELETE, porque en este caso la tabla de aplicación no contiene ninguna fila que recuperar cuando se crea el mensaje para el flujo. CREATE
OBJECT_NAME Opcional. El nombre de la tabla de aplicación que ha cambiado. Esta columna es necesaria si el nodo DatabaseInput se utiliza para dar soporte a las actualizaciones de más de una tabla de aplicación. customer
EVENT_PRIORITY Opcional. La prioridad del suceso, por ejemplo, si se puede utilizar para garantizar que las transacciones de prioridad alta se calculen antes del valor inferior. 1
EVENT_TIME Opcional. Hora a la que se realizó la operación. Se utiliza generalmente para el registro o la supervisión del rendimiento del flujo. 2010-10-19T17:10:00
EVENT_STATUS Opcional. Se utiliza para determinar si el suceso ya se ha procesado. Es necesaria si los sucesos no se van a suprimir o archivar después del proceso. 0
EVENT_COMMENT Opcional. Campo de formato libre, por ejemplo, se puede utilizar para almacenar el resultado del proceso de mensajes si el suceso no se ha suprimido después del proceso. Procesado con excepciones

Nota:

En el ejemplo siguiente, la tabla de sucesos es muy básica, con sólo tres columnas. Una adición a la tabla de aplicación da como resultado la siguiente nueva fila en la tabla de sucesos:

EVENT_ID OBJECT_KEY OBJECT_VERB
1 cust1 Create

Se ha creado un cliente nuevo con la clave primaria cust1. El nodo DatabaseInput responde al cambio y procesa la nueva fila en un flujo de mensajes.

Opciones de proceso al finalizar

Cuando el flujo ha finalizado el proceso de un suceso, se utiliza uno de estos tres procedimientos para completar el proceso:

  1. Suprimir el suceso. Utilice esta opción si no desea almacenar el suceso para referencia futura.
  2. Actualizar la columna de estado. Utilice esta opción si desea mantener un registro de sucesos procesados y su tabla de sucesos tiene una columna de estado (EVENT_STATUS).
  3. Archivar el suceso en una tabla de sucesos independiente. Utilice esta opción si desea conservar un registro de sucesos y quiere mantener la tabla de sucesos con un tamaño mínimo.

En este ejemplo se utiliza la primera opción y se suprimen los sucesos tras una finalización satisfactoria.

Los detalles del flujo de mensajes y el proceso que realiza aparecen en la siguiente sección.

Flujo de mensajes DatabaseInput

El flujo de mensajes DatabaseInput toma los cambios efectuados en la base de datos, los correlaciona con un formato de mensaje de salida y los coloca en una cola de WebSphere MQ:

Una captura de pantalla del flujo de mensajes DatabaseInput.

Tenga en cuenta que el flujo incluye un segundo nodo MQOutput para capturar las excepciones que se pueden haber producido. Esta acción evita reintentos innecesarios y procesos repetitivos de ESQL con formato incorrecto o una base de datos o tabla configurada incorrectamente.

Scripts de prueba

Se utilizan tres scripts de SQL en este ejemplo:

Script para insertar una fila en la base de datos

INSERT INTO DBINPUT_CUSTOMER
      VALUES ('cust1', 'Fred', 'Flintstone', 'Dev');

Script para actualizar una fila en la base de datos

UPDATE DBINPUT_CUSTOMER SET FIRSTNAME = 'Barney', LASTNAME = 'Rubble' WHERE PKEY='cust1';

Script para suprimir una fila en la base de datos

DELETE FROM DBINPUT_CUSTOMER WHERE PKEY='cust1';

Volver a la página inicial del ejemplo