Iniciación a SherpaBots

Iniciación a SherpaBots

2. Ejemplo Representativo

Primero comencemos por un ejemplo global, tal y como vimos en el tema 1 donde explicamos someramente el proceso de un Upload. Ahora, vamos a ver los detalles de alguno de esos Uploads para ver, poco a poco, como hacerlo nosotras mismas.

Veamos a continuación el Modulooper del Upload QUIRON PREVENCIÓN SLU, que es la carga de facturas de un proveedor. Veremos las consultas hasta la 12, puesto que las siguientes forman parte de otro tema y, por el momento, no nos interesan.

 

2.1 QUIRON PREVENCION SLU:

2.1.1 Consultas SQL vacías

En estas consultas vacías  vemos cómo se realizan modificaciones sobre los datos subidos. En la primera, cambiamos un carácter no aceptado por el sistema donde se va a integrar la información; en la segunda, modificamos la fecha para tener el formato requerido.

 

2.1.2 Stops:

Estas son consultas SQL con acción Stop (pararán la carga si el Select da algún resultado)

 

Vemos que en cada una se verifican ciertas cosas: que no haya DNIs duplicados, que las fechas tengan un formato correcto, que uno de los campos (SITE) sea correcto, que los totales, cuadren y que todos los empleados existan en otra tabla (listado de imputaciones).

 

Aquí vemos cómo usamos el alias “ELEMENTOS” con ciertos campos así como la fórmula CONCAT(GROUP_CONCAT(A.SQ_FILA)) AS FILAS —— HAVING FILAS IS NOT NULL. Esto nos servirá para utilizar esos datos en los mails que se envían a los usuarios cuando salta el stop (la consulta da algún resultado) para dar información sobre las filas y los datos que se están detectando como erróneos.

Lo veremos con más detalle más adelante cuando veamos cómo configurar el mail que se envía.

 

2.1.3 Otras consultas

Estas consultas 8 y 9 son consultas SQL de acción vacía (se ejecutarán si o si).
La 8 vacía la tabla destino, utiliza un DELETE para borrar las cargas anteriores del mismo bloque. Esto sirve en muchas ocasiones para no duplicar datos en la tabla destino que provienen de un mismo bloque que por las razones que sea, no interesa duplicar.

 

La 9, hace un INSERT en la tabla destino donde se guarda la información acumulada de este bloque y otros que tienen un proceso común de gestionar las facturas.

 

La consulta 10 es de tipo trigger, esto es, que incluye consultas comunes a varios procesos. Este tipo lo veremos más adelante, y para lo que ahora nos ocupa no es relevante.

 

Cabe resaltar en este ejemplo que estas tres consultas podrían ser de acción OK, puesto que son las consultas “finales”, y podrían ejecutarse una vez se ha comprobado que los datos son correctos. El hecho de que en este ejemplo estas consultas no sean de acción OK es debido a que en el trigger, que veremos más adelante, pero que básicamente implica la inclusión de otro proceso de modulooper común, contiene, a su vez, otro tipo de consultas se ejecute sí o sí. No te preocupes si este párrafo te causa confusión, posteriormente, en temas más específicos, lo veremos en detalle.

2.1.4 Error:

Finalmente tenemos las consultas con acción Error (son las que se ejecutan si ha saltado alguno de los stops). Vemos que son dos DELETES que borran tanto la tabla vestíbulo como la tabla de destino. Así, si existe algún error se borran todos los datos.

 

2.2 Recapitulamos:

En un Upload “típico” encontramos, como hemos visto, tendremos tres fases de consultas:

  • SQL vacías (UPDATE, DELETE): se ejecutan siempre, modificaremos y completaremos datos.
  • SQL acción Stop (SELECT): se ejecutan siempre, verifican datos, si dan resultados “saltan” – existe la opción de mandar un mail con errores.

NO salta ningún Stop:

  • SQL acción OK (INSERT, UPDATE): Se ejecutan si no ha saltado ningún Stop, podremos realizar diferentes acciones con los datos correctos.
  • SQL acción Alarma (SELECT): se ejecutan si no ha saltado ningún Stop, alertan de incoherencias no muy graves que no requieran parar la carga. si dan resultados “saltan” – existe la opción de mandar un mail con las alertas para informar al usuario

SÍ que salta algún Stop:

  • SQL acción Error (DELETE): se ejecutan si ha saltado algún Stop, normalmente sirven para borrar datos cargados, que por saltar el Stop se consideran incorrectos.

 

A continuación mostramos un ejemplo modélico, que no es funcional pero sirve para ver la estructura básica de lo que sería un Modulooper de una carga de Facturas o de otro tipo, que incluye todos los tipos de eventos SQL con acciones: Vacías, Stops, OK, Alarmas, Errores.

Deja una respuesta