Automation
Intro
the ExH services provide a way of running code on demand through tasks. Instead of containing actual code, tasks contain a reference to code that is stored elsewhere, as well as the necessary data to execute it. Because of this, tasks are lightweight and their configuration remains simple.
Aside from tasks, the data service allows for automation by providing configurable logic for the documents that it creates. The document behaviour is configured in a document's schema through statuses and transitions. A document's behaviour can also be configured to trigger tasks, allowing documents to become an active part of applications created with ExH services.
Other Services, such as event service and dispatcher service also work in conjunction with the task service to create even more configurable logic, like event-based code execution.
Tasks
As previously mentioned, ExH services allow the execution of code on demand. This is done by triggering tasks with the task service. Created tasks are added to a task queue, and it is possible to schedule a task to run at a future moment.
Task structure
Tasks consist of three core elements: a function name, execution data and an optional start time. The function name contains a reference to the code to be executed; For example, the name of an AWS Lambda function. Execution data is used as input for the execution of the aforementioned code. The start time, when provided, specifies the time at which the task should be scheduled for execution.
Scheduling tasks
Tasks have two notable features that can be used in conjunction: They can be scheduled to run at a later moment, and they can be used to trigger other tasks.
Tasks can also be scheduled recursively, meaning a task can create another task identical to itself to run at a later time, essentially re-scheduling itself upon being executed. Because of this, it is possible to create a task that infinitely repeats itself at regular intervals.
A task doesn't necessarily need to trigger a single other task, it can trigger a collection of tasks, including itself. Using this functionality, 'scheduler' tasks can be created to automate the execution of a suite of frequently recurring actions.
Data behaviour
Documents provide programmable logic behaviour akin to a finite-state machine. This means a document can exist in one of the statuses configured in it's schema, and change it's status according to the transitions defined in the schema.
Transitions
Depending on it's configuration, a document can change it's status automatically. The data schema allows or an automatic transition to be configured with conditions. This means that a document will automatically transition into the next status when the conditions to do so are fulfilled.
Actions
When a document undergoes a transition, it can also invoke an action. Like conditions, actions are configured within the respective transition, inside the data schema.
Actions invoked by transitioning a document can affect that document directly, such as permitting or denying users and groups read and/or write access to that document. Actions can also trigger tasks, allowing documents to interact with other parts of your application for even more configurable data-driven logic.
Event-based logic
In addition to tasks and data-driven logic, ExH services also provide features for event-based logic. This logic is made possible through the combined functionality of the event service and dispatcher service. These services allow the creation of events and dispatchers, respectively.
Events
Events are simple objects which can be created manually, although they are also created and used by other services. Services use events to alert each other when something happens that another service should be aware of. At such an occurrence, the informing service will create an event of a specific type. The receiving service will be listening for events of the aforementioned type, and then do something based on the event.
Dispatchers
Similar to event-receiving services ,dispatchers wait and listen for an event of a specific type to occur. Upon receiving an event, dispatchers will trigger an action based on that event and it's data. The event type to listen for an the action to perform are configurable through the dispatcher service. The actions a dispatcher can trigger are sending an e-mail and triggering a task.
Related Documents
Last updated
Was this helpful?
