Skip to main content

Introduction

Core concepts​

In a backend, every process is a workflow. A workflow is a resilient program triggered by an event (API call, date, database write, etc.), that runs a set of actions on resources and that returns a result (log, HTTP response, etc.).

We placed workflows at the core of OwlGrid because they are the most flexible and robust way to build a backend. They can be used to build any kind of operations, from a simple CRUD to a complex machine learning pipeline.

Properties​

Properties:

  • Id: a unique identifier automatically generated by OwlGrid;
  • Name: a human-readable name, used to trigger the workflow through the API;
  • Metadata: custom metadata of the space (name, description, etc.). Learn more about metadata;
  • Active: a boolean that indicates if the workflow is active or not (callable);
  • Environment: the environment in which the workflow is executed. Learn more about environments;

Trigger​

A workflow is triggered by an event. The event can be:

  • An HTTP Call: every
  • A date

Actions​

An action is a function that is executed on a resource. There is two types of actions: workflow and resource actions.

Workflow actions​

Structural actions (if, for, etc.) or data actions (set variable, etc.). For example, a for loop that iterates over a list of resources.

Examples:

  • Loop over a list of objects;
  • If a condition is true, do something;
  • Set a variable;
  • Log an event;
  • Wait a specific amount of time (ex: one month).

TODO: list actions availables.

Resource actions​

Actions that are executed on a resource. For example, a creates a new objet in a database. These resources can be OwlGrid's resources or external resources triggered by API calls. For example, send a message to a Slack channel.

Examples:

  • Call an HTTP API;
  • Trigger another workflow;
  • Create a new object in a database;
  • Send a message to a Slack channel;
  • Send an email;
  • Etc.

Result​

Logs​

Fault tolerance​

Error handling​

TODO actions:

  • Créer un workflow (id, nom, metadata, active, environnement)
  • Editer un trigger de workflow (id, type: http, date, etc., accès (quel groupe de sécurité))
  • Migrer un workflow dans un autre environnement (id, environnement) -> possible même si le workflow est actif
    • Check que l'utilisateur a les droits
    • Check que le process de changement d'environnement n'est pas violé (ex -> passer de dev à prood interdit => à creuser)
    • Check que les variables ne sont pas nulles dans l'environnement cible
    • Check que les connections d'API sont toujours valides (?)

Modèle de données :

  • Workflow :
    • Id : unique identifier
    • Name : human-readable name
    • Metadata : custom metadata of the space (name, description, etc.)
    • Active : boolean that indicates if the workflow is active or not (callable)
    • Environment : if of the environment in which the workflow is executed
    • versionCurrent: id of the current version
    • versionHistory: list of versions
    • Perimeters: list of perimeters
  • Version:
    • Id : unique identifier
    • date: edition date
    • author: id of the author
    • Trigger :
      • Id : unique identifier
      • Type : http, date, etc.
      • Access : security group
    • Action :
      • Id : unique identifier
      • Type : condition, httpCall, databaseCall, response, etc.
      • ParentAction: id of the parent action
      • Input: parameters
      • Payload: data
      • Output: parameters