Available since version 4.0.0 (Nitroball) of Onesait Platform

Introduction

In this release we have created the basis of a Platform Planner that allows:

• Define a business flow:

  • this flow can be composed of DataFlows, Notebooks and/or KPI Entities.

  • Indicate the order of the flow

  • Indicate what to do in case of error

• Plan the execution of a business flow (from the FlowEngine)

• Capture the result of each flow execution

• Visualize the status of the flow execution in a Platform Dashboard

• Relaunch processes in the business flow from where they are now

How does it work?

This asset is composed of a set of flows developed in the FlowEngine module, and its operation requires several entities created in the platform that allow tracing the status of the execution in progress, as well as a log of the executions carried out.

These entities are the following:

• processes: entity where the processes to be executed are stored.

• process_log: entity in which a log trace of the execution is stored.

• process_status: entity in which the execution status of a process for a given date is stored.

• operation_status: entity in which the execution status of an operation for a given date is stored.

• process_dependencies: entity where the dependencies between processes (if any) are stored..

Process is defined as a set of operations to be executed, in which operations can be:

• Flow in dataflow

• Notebook

• KPI entity

• Delete of an entity

First, the business logic to be executed will be defined, and this data will be stored in the process ontology, taking into account that the fields available to the entity are:

• 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:

• Ejecución de un proceso:

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

  • Método: POST

  • Body:

• Ejecución de una operación:

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

  • Método: POST

  • Body:

* 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:

Open

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.

Open

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.