Descripción

La etapa CRUD de Onesait de Dataflow realiza operaciones tipo CRUD sobre las ontologías.

Open

Esta etapa permite que, desde un origen que emita registros de cambio (CDC, Change Data Capture), replicar en una ontología o varias los mismos. Tiene la base de operaciones del origen CDC de MySQL (MySQL Binary Log), con lo que, para otros orígenes, es posible que sea necesario adaptar el formato de los registros al mismos. Ten en cuenta que una parte fundamental del proceso de CRUD es el orden de operaciones, con los que no podrás usar hilos de ejecución (o perderías la sincronía) y la única operación que puede agruparse, sería la de insert, con lo que debemos tener en cuenta esto a la hora de trabajar con el componente y entender que su velocidad de trabajo no va a ser tan alta como otros componentes. Si es necesaria más velocidad de proceso, podría dividirse funcionalmente el proceso de traslado de cambios (CDC (origen) - CRUD (destination)) en varios dataflow en el que cada uno actuara sobre un conjunto de tablas funcionalmente independientes y así poder trabajar en paralelo sobre esos conjuntos.

El formato de trabajo tendría las siguientes particularidades:

• El tipo de operación debe de ir en el campo de attributos del header sdc.operation.type que determina lo que se hará con el registro en curso

  Open

  

• Las operaciones permitidas son:

  • 1 → Insert: se toma como registro de inserción el contenido del campo de “/Data". Es requerida la operación del punto anterior y el formato base sería el siguiente. Si hubiera más campos en el registro, serían ignorados.

  • 2 → Delete: se construye y ejecuta una query de borrado en base al contenido del campo “/OldData". Hay dos formas de funcionamiento:

    • Si la entidad destino aparece en la configuración de Entity Key Fields, se usará esa clave indicada usando los valores del registro (contenido del campo “/OldData“) como clave única para el borrado (se construye en base a eso la parte where de la operación delete). Esta clave debe ser única y es recomendable que sea un índice en la entidad destino para acelerar la query.

    • Si la entidad no aparece en la en la configuración de Entity Key Fields, se usará todos los campos del registro (contenido del campo “/OldData“) como clave única para el borrado (se construye en base a eso la parte where de la operación delete). Al igual que el punto anterior, esta clave debe ser única y es recomendable que sea un índice en la entidad destino para acelerar la query.

  • 3 → Update: se construye y ejecuta una query de update en base al contenido del campo “/OldData" (parte where) y del campo “/Data“ (parte set). En la parte set, se usarán todos los campos de “/Data“. Al igual que el delete, hay dos formas de funcionamiento:

    • Si la entidad destino aparece en la configuración de Entity Key Fields, se usará esa clave indicada usando los valores del registro (contenido del campo “/OldData“) como clave única para el campo where del update. Esta clave debe ser única y es recomendable que sea un índice en la entidad destino para acelerar la query.

    • Si la entidad no aparece en la en la configuración de Entity Key Fields, se usará todos los campos del registro (contenido del campo “/OldData“) como clave única para la parte where. Al igual que el punto anterior, esta clave debe ser única y es recomendable que sea un índice en la entidad destino para acelerar la query.

• La entidad destino y el nodo root tienen varias configuraciones:

  • Si el valor de ontology es uno diferente de $$recordheader se aplican las reglas de cualquier otro nodo destination tanto para la ontología/entidad destino como para el nodo root.

  • Si el valor de ontology es $$recordheader, la ontología destino, vendrá dada por el valor del atributo de la cabecera op.ontology, con lo que cada registro puede actuar sobre una entidad distinta y así poder recibir registros de un cdc que genera cambios de múltiples orígenes. Debemos tener en cuenta que es obligatorio que el digital client tenga acceso a todas las ontologías/entidades en modo escritura. Además, habrá que tener en cuenta el valor del nodo root que será:

    • Si el valor es “No root node” o “Custom root node“ todos los campos de las operaciones en destino o no tendrán nodo root o será el valor dado en “Custom root node name“. Esto aplica para insert, update o delete.

    • Si el valor es “Add ontology as root node“ todos los campos de las operaciones tendrán precedido el nombre de la ontología/entidad del campo op.ontology

Cómo usarlo

Importando al pipeline

Para agregarlo al pipeline, busca Onesait en la paleta de etapas así:

Arrastra y suelta en el panel.

Una vez importado, se puede configurar para lograr diferentes comportamientos según el caso.

Pestañas de configuración disponibles

General

Esta pestaña muestra información general y una opción para mostrar el punto generador de eventos en el escenario.

Marcando la opción "Producir Eventos" el escenario muestra otro punto para hacer uso de los eventos.

Los eventos desencadenados son (se añade la entidad/ontología y la operación):

• document-modified

  • Que envía los registros en una lista (datos insertados o modificados).

• document-not-modified

  • Que envía los registros no insertados/modificados en una lista (datos no insertados/modificados).

Por ejemplo, datos modificados:

Y datos no modificados:

Connection

Esta pestaña muestra un formulario para completar con la información del Broker Digital de la plataforma Onesait.

La opción del nodo raíz puede agregar los datos del registro a una propiedad raíz antes de insertarla. Es importante el valor especial del campo ontology $$recordheader en este caso, ya que servirá para indicar el este valor viene del propio registro en el atributo de cabecera “op.ontology“ que nos permitirá tener un destino múltiple.

Configuration

Esta pestaña muestra la configuración principal.

• Root node type: se define si la entidad/ontología tiene nodo root custom, el propio del nombre de la entidad, o no tiene

• Bulk: número de registros por lote (sólo para operaciones de insert).

• Generate error when no records are modified: define si se genera un registro de error cuando la operacion update o delete no ha generado ningún cambio.

• Entity Key fields: se definen a la izquierda las entidades/ontologías y a la derecha los campos clave para las operaciones de update y delete (que vienen en el registro en “/OldData"). Es importante que sean clave e índice en la entidad destino para evitar errores y acelerar las operaciones.

Modo de depuración de operaciones

Para poder depurar las operaciones en detalle, se puede activar el modo debug (sólo para pruebas o desarrollo) añadiendo en la parte del Log Config (configuración Log4J dentro del visor del logs):