Workflows, Modules and executions

Ryax is more than just a tool, it is a complete framework to develop, deploy, and maintain software. To do so, Ryax proposes a paradigm, to fully understand the framework we must go through the concepts of workflows, triggers, actions and runs. All these are explained in details through this section.

Workflow overview

The boxes are called actions, which are unit of computations that from some inputs produces some outputs. Actions linked together are called a workflow.

Workflows:

  • a set of actions all linked together

  • without any loops ; they are Directed Acyclic Graphs

  • links are data streams. An action uses some data from the input stream and adds its output data to the stream. This way, the data that an action outputs is accessible to every downstream actions. In other words, any action has access to the data of upstream actions.

There is 2 types of actions:

  • Triggers. They are the actions that ingest data from the outside world. They are long running processes triggering new workflow runs. For example, a trigger can start a new run every day at 6pm ; or every time that an email arrives in a given mailbox.

  • Actions. These are stateless processes that basically compute things. They ingest data from upstream through their inputs and produce outputs added to the down stream.

An action computing some data is called a run. In Ryax, a run hold everything related to it: the input data, the output data, the logs…

Architecturing a Ryax workflow

To architecture a Ryax workflow, answer to these questions:

  1. What triggers the workflows? Many events in the outside world may trigger a Ryax worflow. It can be a mail, a new file in a file share, a form, a new contact in a CRM or some IoT data, for example.

  2. Who needs the results of the workflows? What are the tools they can access? For instance, a salesperson may need this data to be attached to the company profiles in a CRM, or predictive maintenance results may need to be accessed by managers to plan actions and by workers to perform the recommended actions.

  3. What data do you need to be able to run the required computations? Where do you gather it? In what formats do they come?

  4. Are my computations done in several steps? Are there some steps that I can reuse in other workflows? Can I salvage actions from prior workflows?

The first question, helps define triggers. The second one is for actions. Finally, 3 and 4 help defining re-usable actions to.