Tareas DataK 2.0 Migración

Al actualizar KPlatform a la versión 4.0.0, se migrarán las Tareas presentes en DataK para alinearlas con la nueva metodología de creación de Tareas que contempla la composición de Operaciones elementales.

Al final de la migración, todas las Tareas se actualizarán y se realizará una sincronización automática con Airflow para propagar los cambios también dentro de él.

Las tareas para las que se produjo un error durante la migración aún se guardan y se marcan con un mensaje de error, como se muestra a continuación.

Las Tareas que presenten la señal de error, si se ejecutan dentro de un flujo, lanzarán un error que lo hará fallar. Para estas tareas es necesario actuar manualmente configurando nuevamente la Tarea según las especificaciones deseadas. Es recomendable modificar la Tarea ya existente en lugar de crear una nueva para no tener que modificar también los Flujos que contienen la Tarea en cuestión.

Los errores ocurridos durante la fase de migración se pueden consultar en la sección de Errores en la página de Administración de KPlatform, donde además del mensaje de error también se reportan los parámetros de configuración de la Tarea migrada para poder configurar fácilmente una nueva tarea.

Importación de proyectos antiguos

Los proyectos de DataK exportados desde las versiones de KPlatform entre 3.6.0 y 4.0.0 aún se pueden importar, durante la fase de importación se realizará la migración para actualizar la estructura de tareas. Cualquier error se informará al final del procedimiento de importación y será necesario seguir las indicaciones válidas para actualizar KPlatform anteriores.

Puntos de atención

Esta sección enumera algunos cambios que ocurrieron durante la migración a los que debe prestar especial atención, como las funciones que no se migraron y para las cuales debe intervenir manualmente.

Parámetros de entrada

En la nueva versión se ha eliminado el uso de Input Params por lo que es necesario modificar manualmente las Tareas que los utilizaban. Es recomendable hacer un levantamiento de estas Tareas y los Flujos en los que están contenidas y llevar un registro de cómo están configurados los Parámetros de Entrada para poder modificarlos fácilmente, ya que una vez actualizada la versión de KPlatform ya no será posible ver su configuración.

A continuación se muestran algunos ejemplos del uso de los parámetros de entrada y cómo actuar para actualizar la tarea y el flujo de la manera correcta.

Token de autenticación para la tarea Http

Para ejecutar una tarea Http que realiza una llamada API utilizando un token generado dinámicamente, es necesario usar Input Params para anular el token de autenticación de conexión en tiempo de ejecución.

Esta situación se puede solucionar fácilmente:

Al actualizar la función de mapa de flecha auth_token para devolver solo el token de autenticación.
En la Tarea Http Call cree una variable y configúrela de acuerdo a la estructura:
```
{
'token': 'resource_token', 
'extra':{
    'auth_type':'Token', 
    'token':${auth_token}
}
}
```
Donde resource_token debe ser reemplazado por el token de la conexión utilizada en la operación Http.
Vincule la variable recién creada con el recurso en la pestaña de configuración de la operación Http.

Cambiar dinámicamente la base de datos utilizada

Para ejecutar una tarea Db a Db donde la base de datos de origen se determina durante la ejecución por una tarea anterior, es necesario usar los parámetros de entrada para sobrescribir la base de datos que se usará en el tiempo de ejecución.

También en este caso es necesario actuar de manera similar a lo que se hizo para el ejemplo anterior:

En el Transferir valores de indicadores a MariaDB crea una variable y configurala de acuerdo a la estructura:
```
{
'token': 'resource_token',
'conf': {
    'database':${database}
}
}
```
Donde resource_token debe ser reemplazado por el token de la conexión utilizada en la operación Read Db.

Vincule la variable recién creada con el recurso en la pestaña de configuración de la operación Read Db.

Gestión general de parámetros de entrada

Los ejemplos anteriores informan algunos casos en los que los parámetros de entrada se usan para anular algunos parámetros de recursos, pero en general se pueden usar para anular cualquier parámetro de configuración de tareas.

En este último escenario es posible actuar de diferentes formas dependiendo del tipo de parámetro (string, integer, boolean…):

Parámetro de tipo cadena : en estos casos, el uso de Input Params se puede reemplazar con el uso de la sintaxis ${name_input} dentro del campo de texto de la tarea.
Parámetro de tipo no cadena : en estos casos, deberá seguir el procedimiento que se describe a continuación.
Se debe definir un parámetro de entrada para cada flecha de datos (flecha azul en el editor de flujo) que ingresa a la Tarea. (imagen1)
Reemplace la entrada definida anteriormente donde sea necesario. (imagen2)
Una vez que se han especificado todas las entradas de la Tarea, a partir del editor de flujo, es necesario conectar las flechas de datos entrantes (flecha azul en el editor de flujo) con la entrada respectiva definida dentro de la Tarea. (imagen3)Imagen1: Creación de las entradas de una Tarea.
Imagen 2: Uso de entradas de tareas.
Imagen 3: conexión de las entradas de una Tarea con las entradas definidas en el Flujo.

ATENCIÓN

Si solo se define una entrada de la Tarea, será necesario definir una entrada para cada flecha de datos que ingrese a la Tarea y conectarla con ella. Si no hace esto, cualquier uso de la sintaxis ${input_name} no funcionará.

Por lo tanto, si es necesario definir una entrada para manejar los casos mencionados anteriormente, es recomendable:

Defina una entrada para cada flecha de datos que ingrese a la tarea especificando el tipo correcto o Tiempo de ejecución y posiblemente un valor predeterminado y dando a la entrada el mismo nombre que la flecha entrante.
A partir del editor de Flujos, conecte las flechas de datos que ingresan a la Tarea con las entradas recién definidas.

gestion de tareas sql

Las tareas de tipo Sql durante la migración se pueden transformar de 2 formas diferentes:

Debe buscar para recuperar el resultado de la consulta. En este caso la Task Sql se transforma en una secuencia de operaciones del tipo Read DB , una por cada consulta presente en la Task original. Luego, el resultado se combina a través de una operación Variable para devolver el mismo resultado que la tarea original.
No necesita buscar (las consultas son operaciones de actualización o DDL, por ejemplo). La tarea Sql se transforma en una secuencia de operaciones Sql que no devuelve ningún dato.Ejemplo de aplicación de la Transformación 2
Ejemplo de aplicación de la Transformación 2

Durante la migración, la transformación en una Tarea en lugar de otra se realiza automáticamente, analizando cómo se utilizan las Tareas Sql originales dentro de los flujos.

Si en algún flujo se usa la salida de Task Sql (en al menos un flujo hay al menos una flecha azul que sale de la tarea), se aplica la primera transformación. Por el contrario, si la salida de Task Sql no se usa en ningún flujo (en ningún flujo hay una flecha azul que sale de la tarea), se aplica la segunda transformación.

Este aspecto debe tenerse en cuenta al importar un proyecto antiguo a la nueva versión. De hecho, si solo se importan las Tareas sin los Flujos, no es posible establecer qué transformación aplicar, por lo tanto, la transformación 2 se aplica por defecto , todas las Tareas Sql se transforman en una secuencia de operaciones Sql que no produce ningún resultado. , en consecuencia también la Tarea original no producirá ningún valor.