Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Disponible desde versión 4.0.0 (Nitroball) de Onesait Platform

Introducción

En esta release se ha creado la base de un Planificador en Plataforma que permite:

  • Definir un flujo de negocio:

    • este flujo puede estar compuesto por DataFlows, Notebooks y/o Entidades KPI

    • Indicar el orden del flujo

    • Indicar qué hacer ante error

  • Planificar la ejecución de un flujo de negocio (desde el FlowEngine)

  • Capturar el resultado de cada ejecución del flujo

  • Visualizar el estado de la ejecución del flujo en un Dashboard de Plataforma

  • Relanzar procesos en el flujo de negocio desde el punto en el que se encuentran

¿Cómo funciona?

Este activo está compuesto por un conjunto de flujos desarrollados en el módulo FlowEngine, y para su funcionamiento se necesitan varias entidades creadas en plataforma que permiten trazar el estado de la ejecución en curso, así como un log de las ejecuciones realizadas.

Estas entidades son las siguientes:

  • processes: entidad en la que se almacenan los procesos a ejecutar.

  • process_log: entidad en la que se va almacenando una traza de log de la ejecución.

  • process_status: entidad en la que se almacena el estado de la ejecución de un proceso para una fecha dada.

  • operation_status: entidad en la que se almacena el estado de la ejecución de una operación para una fecha dada.

  • process_dependencies: entidad en la que se almacenan las dependencias entre procesos (si las hubiera).

Se define proceso como un conjunto de operaciones a ejecutar, en el que las operaciones pueden ser:

  • Flujo en dataflow

  • Notebook

  • Entidad KPI

  • Delete de una entidad

Primero, se definirá la lógica de negocio que se quiera ejecutar, y se guardarán estos datos en la ontología de procesos, teniendo en cuenta que los campos de los que dispone la entidad son:

  • process_id: id de proceso

  • operation_id: id de operación

  • operation_identification: identificador de la operación en plataforma

  • operation_type: tipo de operación (dataflow, notebook, kpi, delete)

  • operation_order*: orden de prioridad de ejecución de la operación

  • previous_delete: boolean que indica si se quiere realizar un borrado previo de la entidad destino

  • delete_condition: condición de borrado de la entidad destino

  • target_entity: entidad destino sobre la que se puede realizar un borrado previo

  • parameters: parámetros necesarios para la ejecución de la operación.

    • kpi o dataflow: 

      "{\"param1\":\"value1\",\"param2\":\"value2\",..}"

    • notebook: 

      "{\"paragraphId\":\"id_parrafo_parametros\",\"params\": {\"param1\":\"value1\",\"param2\":\"value2\",..}}"

    • delete: condición de borrado en SQL o nativo

  • error_continue: boolean que indica si se quiere continuar con la ejecución de las demás operaciones dentro de un proceso ante un fallo.

* Si se quieren hacer ejecuciones de procesos u operaciones en paralelo se debe indicar el mismo número de orden para estos. Además se debe tener en cuenta que el número de orden debe ser consecutivo, es decir, no saltarse ningún número a partir del 1.

Después podrán definir dependencias y/u orden de ejecución de los procesos, informando la entidad de dependencias que tiene estos campos:

  • process_id: id de proceso.

  • previous_processes: array de procesos que debe haberse ejecutado previamente.

  • next_processes: array de procesos siguientes a ejecutar.

Una vez guardada la lógica de ejecución en las entidades de procesos y dependencias, se podrá programar la ejecución ordenada de los procesos en el Flow Engine, bien en el mismo dominio o en otro dominio si se quisiera, para poder aislar así la lógica de orquestación de la planificación.

Para esto se ha apificado toda la lógica de orquestación mediante el Flow Engine en 3 apis:

  • Ejecución completa del orquestador:

    • Endpoint: <host>/api-manager/server/api/v1/orchestrator/execute/

    • Método: POST

    • Body:

{     
  "process_id": "valor_process_id",  # atributo obligatorio - es el primer proceso de la ejecución,
  "date": "yyyy-MM-dd",              # atributo obligatorio - fecha de datos para la ejecución,
  "params": {                        # listado de parámetros que necesita la ejecución (date, parámetros calculados, etc..)
	 "parámetro1": "valor1",		 # se sustituyen dinámicamente en la ejecución
	 "parámetro2": "valor2", 		 # en la ontología processes se informan con nomenclatura ${parámetro}		
  … } 				
}

  • Ejecución de un proceso:

    • Endpoint: /api-manager/server/api/v1/orchestrator/executeProcess/

    • Método: POST

    • Body:

{     
  "process_id": "valor_process_id",  # atributo obligatorio - es el proceso que se ejecuta,
  "date": "yyyy-MM-dd",              # atributo obligatorio - fecha de datos para la ejecución,
  "params": {                        # listado de parámetros que necesita la ejecución (date, parámetros calculados, etc..)
	 "parámetro1": "valor1",		 # se sustituyen dinámicamente en la ejecución
	 "parámetro2": "valor2", 		 # en la ontología processes se informan con nomenclatura ${parámetro}		
  … } 				
}

  • Ejecución de una operación:

    • Endpoint: /api-manager/server/api/v1/orchestrator/executeOperation/

    • Método: POST

    • Body:

{     
  "process_id": "valor_process_id",     # atributo obligatorio - es el proceso que contiene la operación,
  "operation_id": "valor_operation_id", # atributo obligatorio - es la operación que se ejecuta
  "date": "yyyy-MM-dd",                 # atributo obligatorio - fecha de datos para la ejecución,
  "params": {                           # listado de parámetros que necesita la ejecución (date, parámetros calculados, etc..)
	 "parámetro1": "valor1",		 	# se sustituyen dinámicamente en la ejecución
	 "parámetro2": "valor2", 		 	# en la ontología processes se informan con nomenclatura ${parámetro}		
  … } 				
}

* Tanto el process_id como el operation_id que se están pasando en el body del api deben existir en la ontología processes para su correcta ejecución.

Invocando a cada una de estas apis se podrían realizar ejecuciones puntuales de forma manual, o planificada.

En el caso de que se produzca algún error durante la ejecución, esta se detendrá (a no ser que se haya indicado de otra forma en la entidad de procesos), y el usuario podrá revisar manualmente el error que se ha producido, corregirlo y relanzarlo manualmente desde el Flow Engine o desde el api.

En este caso continuará en el primer proceso y/o operación que se encuentre en las entidades de estado (process_status y operation_status) con estado de ERROR. Si el usuario quiere dar como OK la operación que ha fallado para que la ejecución continúe en el siguiente paso, únicamente deberá actualizar el estado de esa operación en la entidad operation_status a OK, y relanzar la ejecución manualmente desde el Flow Engine.

Visualización del estado

Para realizar un seguimiento de las ejecuciones se dispone de un dashboard creado en plataforma en el que dada una fecha se podrá visualizar tanto el log como el estado de la ejecución:

Configuración

El planificador tiene una serie de variables globales que permiten la configuración de las ontologías base, así como el tipo de query que utiliza internamente y el tipo de query de borrado.

Estas variables globales están definidas en el subflujo ‘SF Get Global Properties’, que se invoca cuando se hace la petición al api del orquestador informando las variables si no se han informado previamente.

En este subflujo se pueden configurar las siguientes variables:

  • queryType: tipo de query que utiliza el orquestador (SQL | NATIVE)

  • processes_ontology: nombre de la ontología processes

  • process_dependencies_ontology: nombre de la ontología process_dependencies

  • process_status_ontology: nombre de la ontología process_status

  • operation_status_ontology: nombre de la ontología operation_status

  • process_log_ontology: nombre de ontología process_log

  • deleteQueryType: tipo de query de borrado (SQL | NATIVE)

  • dataflowTimeout: timeout para la ejecución de dataflows

  • notebookTimeout: timeout para la ejecución de noteboks

  • apiKey: api key necesario para la ejecución de las operaciones, esta debe pertenecer a un usuario que tenga permisos sobre las ontologías del orquestador, así como a las operaciones que se vayan a ejecutar.

Consideraciones

Al tratarse de un activo desarrollado sobre plataforma es fácilmente extensible, por lo que se podrían añadir por ejemplo más tipos de operaciones de manera sencilla realizando un pequeño desarrollo en el FlowEngine, o simplemente enriquecer la lógica del planificador según necesidad.

El planificador está desarrollado para ejecutar los procesos y operaciones de forma secuencial y/o en paralelo definiendo el orden en función de la casuística,

Para que funcione correctamente las ontologías deben tener índices únicos creados, que se pueden encontrar en la propia descripción de las mismas.

  • No labels