Llegamos a uno de los últimos puntos de la formación de SherpaBots… Una vez hemos llegado hasta aquí podemos realizar prácticamente todo. Ahora, vamos a ver una serie de tablas que son importantes para definir los procesos y cómo éstos se almacenan en tablas.

Estas tablas estarán habitualmente guardadas en la base de datos del core de SherpaBots que son: square, squareexcel, documentacion, uploads.

 

6.1 uploads.uploads_head

Empezamos por el principio, los Uploads. La primera parte de carga de información viene a través de los Uploads. Bien, cuando configuramos una carga gracias al moduform del bloque CREAR UPLOAD. Una de las dos tablas que se rellena es uploads.uploads_head.

Esta tabla tiene esta forma:

Aquí existe una línea por cada hoja de cada upload. Nos indica la fila de inicio (STARTROW) y fila final (ENDROW) la base de datos y tabla vestíbulo. Separador y delimitado en caso de los uploads csv y txt. El nombre y mail de la responsable.

 

6.2 uploads.uploads

Esta segunda tabla define cada campo que se recoge de los Uploads.

Así existen tantas líneas como campos recogidos para cada hoja de cada upload.

Veamos el ejemplo del Upload del Template Penguins of the world.

Vemos que existe un campo ORIGEN que siempre tiene un valor fijo, que es el nombre del Upload.

A continuación vemos, como se relaciona el nombre del campo con la columna, y su respectiva hoja.

También veremos si se ha definido algún valor fijo, fixrow, mandatory o headcheck.

 

6.3 square.apps_responsables_area

Ahora empezamos con una serie de tablas donde se configuran áreas-apps-bloques-campos de los bloques.

Esta primera square.apps_responsables_area es donde se inserta una línea cuando creamos un área.

Tendremos el nombre del área y el responsable que indicamos en el moduform del bloque CREAR ÁREA.

 

6.4 square.apps_list

Esta tabla tendrá las características que definen una app:

Aquí se relaciona el nombre de la app, con el logo, la url, la descripción, el área y si está o no activo. También veremos la orientación de la app (V=Vertical, H=horizontal).

 

6.6 square.sitrees (bloques)

Esta es una de las estrellas de la corona. En square.sitrees se definen los bloques.

Aquí vemos el nombre del bloque y la relación con el área. También se correlaciona el nombre_square con el nombre_area lo que nos da la oportunidad de mapear bloques en función del área. Lo veremos en el punto 6.8

 

6.7 square.sitrees_extended 

Esta tabla define lo que conocemos como atributos de los bloques. De los diversos tipos de bloques (Uploads, Moduforms, Plantilla, etc) necesitamos definir una serie de cosas.

Por ejemplo veamos la definición de un bloque tipo Upload:

Aquí vemos una serie de líneas típicas de la definición de un Bloque “Upload”. 

Vemos el nombre de la app, el nombre que se asigna al bloque en el área de esa app (en este caso app Upload Center tiene de área “UPLOADS”.).

En todos los bloques tenemos los campos:

• MODULOOPER, define el valor (el nombre) del modulooper que ejecuta ese proceso, normalmente tendrá el mismo nombre que el bloque a excepción de aquellos que tengan un modulooper común para todos los bloques; es el caso de las apps standadard con plantilla donde cada bloque ejecuta el modulooper común de la app.
• UPLOAD, define este bloque como de tipo UPLOAD, es decir que el fichero cargado se leerá y se ejecutará el modulooper asociado.
• UPLOADER, define el uploader, que no podemos modificar ni necesitamos saber ahora.
• UPLOADFILE, es el campo tipo fichero que cargará el fichero que necesitamos. 

Además tendremos, normalmente el campo TEXTAREA que nos servirá para introducir un comentario sobre el fichero que estamos cargando.

Ahora miremos cómo se definen los atributos de un bloque independiente que ejecuta un moduform, por ejemplo el de CREAR AREA.

 

Tenemos los tres básicos: MODULOOPER, UPLOADER y TEXTAREA.

Además también tendremos los campos del moduform, que en este caso son solo dos: CAMPO01, CAMPO02, que nos indica lo que pone en la etiqueta, el valor (SELECT/Placeholder) y el tipo. También veremos el orden, si es obligatorio (Required).

Otro ejemplo de bloque sería el bloque de una app standard con plantilla.

Aquí vemos que en una app standard con plantilla como es PENGUINS OF THE WORLD tenemos el campo NOMBRE_AREA vacío ya que los bloques tienen todos la misma definición. Es una definición muy similar a la del bloque “Upload”.

Vemos los campos: UPLOAD, UPLOADFILE, MODULOOPER, TEXTAREA, pero además vemos también una línea extra campo TEMPLATE que nos indica en el valor la url donde se descargará la plantilla desde el botón plantilla. Que es donde se vincula con SquareExcel que es donde se guardan todas las plantillas con el nombre TEMPLATE NombreApp. 

Ahora veamos cómo se define un bloque de SquareExcel:

Aquí vemos la app, con el nombre área, también tendremos VERSION, AREA, TABLASITES y RESPONSABLE. 

De esta manera tenemos el recorrido de cómo se relaciona todo.

• ÁREA se define en square.apps_responsables_area
• APP square.apps_list (que vincula APP y AREA)
• BLOQUE square.sitrees(que vincula ÁREA y BLOQUE)
• ATRIBUTOS DEL BLOQUE square.sitrees_extended (que vincula APP con BLOQUE con campos del moduform)

 

6.8 Relación de nombres de área entre áreas (NOMBRE_AREA, NOMBRE_SQUARE)

 

Ahora veamos cómo se puede vincular un nombre de un área con otro nombre de otro área. 

Lo mejor, un ejemplo práctico.

En SherpaBots ocurre que tenemos áreas que tienen una relación de Bloques que llamamos Unidades de gestión que se llaman diferente en función del área al que pertenezcan a veces un bloque de RRHH tiene otro asociado en OPEX o en FINANZAS.

Por ejemplo, tenemos una unidad de gestion “DHL SAN FERNANDO BRIGHTSTAR” que en cada una de las “grandes” áreas tiene un nombre diferente. 

En el área de RRHH se llama “DHL SAN FERNANDO BRIGHTSTAR”

en el área de FINANZAS “SAN FERNANDO TECNOLOGÍA”

y en el área de OPEX “SAN FERNANDO ALMACEN”

Esto significa que gracias a esta tabla podemos vincular una unidad de gestión a varias áreas cuyos nombres sean diferentes.

Así por ejemplo, puede darse que en una empresa tengamos la gestión de varios departamentos que usan distintas nomenclaturas para las mismas unidades de gestión, como acabamos de ver en el ejemplo. Para distinguir usamos el nombre_square que será común y nos permite mapear con los distintos nombres asignados en las diferentes áreas.

 

6.4 square.listas

Esta tabla ya la hemos visto de pasada a lo largo de la formación, con una copia en la base de datos formacion_ml que simulaba esta tabla.

Aquí vemos un ejemplo muy útil cuando queremos traducir valores de meses a nombres o viceversa.

Esta tabla se alimenta de la carga SQUARE LISTAS de Upload Center:

Donde primero habrá que descargarse la plantilla, luego podremo ver ahí lo que hay y si necesitamos introducir algún listado, rellenarlo al final :

Indicaremos el nombre de la lista, la etiqueta y el valor, a modo de mapeo.

Guardamos el documento y lo volveremos a subir, de esa manera tendremos lo datos en la tabla, para poder utilizarlos como queramos.

 

6.7 square.tracking

Esta tabla tiene el tracking o histórico de todos los bloques de carga y ejecución de square.

Veremos la app desde la que se hace la carga, el usuario y la fecha que realiza la carga. El nombre del archivo, la versión si hay. El centro hace referencia al bloque desde el que se hace, cuando finaliza la carga si hay comentario y luego versiones, adjuntos, tags y actualización del template.

Esta información nos puede servir para rastrear errores y ver actualizaciones de templates en relación a la carga. También si la versión cargada es correcta o recuperar archivos más antiguos que no salen en los históricos.

 

y así acaba la formación de SherpaBots…

Todavía nos quedan muchos conceptos para aprender pero el pack básico ya lo tenemos.

 

Si has llegado hasta aquí…

mi más sincera 

 

ENHORABUENA