Extra Horizon
GitHub
  • Extra Horizon Documentation
  • Getting Started
    • Start familiarizing yourself
  • Tutorials
    • Medical Device Tutorial
      • Preparation
      • Build your first prototype
        • Define a data model
        • Configure your workflows
          • Workflow 1: Analyze a measurement
          • Workflow 2: Create & store a PDF report
          • Workflow 3: Send an e-mail
        • Define your permissions
          • Update your schema with user permissions
          • Update your schema with group permissions
        • Build the Front-End
          • Set up oAuth in your backend
          • Demo login page
      • Summary & Wrap up
    • Polysomnography (PSG) Tutorial
    • Retool - Building dashboards Tutorial
  • FAQ
    • General
  • Services
    • Identity and Access Management
      • User service
        • Users
        • Groups
        • Global roles
        • Configuration
      • Auth Service
        • Applications
        • OAuth2
        • OAuth1
        • MFA
        • OpenID Connect
          • Google Cloud
          • Azure ADFS
    • Data Management
      • File Service
      • Data Service
        • Schemas
        • Documents
        • FAQ Data Service
    • Automation
      • Task Service
        • Functions
        • Tasks
        • API Functions
        • Examples
          • Hello world (JS)
          • Hello world (Py)
          • Hello world (Docker)
        • FAQ
      • Dispatchers Service
      • Event Service
        • System Events
    • Communication
      • Notification Service
        • Notifications
        • Settings
      • Mail Service
    • Other
      • Localization Service
        • Language Codes
      • Template Service
        • Localizations
      • Payments Service
        • Subscriptions
        • Stripe
        • iOS App Store
      • Configurations Service
  • API Reference
    • OpenAPI Specifications
    • 📦Changelog
      • Per-service Changelog
    • Postman Reference Collection
  • Tools
    • SDK
    • CLI
    • Control Center
  • Additional Resources
    • Resource Query Language (RQL)
    • Handling Errors
    • GitHub
    • API interaction (Python)
    • Migration guide: Enabling verification request limiting
  • ExH Platform
    • 🙋Support
    • ⏱️Usage and Performance
    • 🗺️Regions
    • ⚖️Cloud Subscription Agreement
    • Security, Privacy & Quality
      • 🔓Security
      • 🇺🇸CFR 21 Part 11
      • ExH as OTS Software
Powered by GitBook
On this page
  • Intro
  • Tasks
  • Data behaviour
  • Event-based logic
  • Related Documents

Was this helpful?

  1. Services

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

PreviousFAQ Data ServiceNextTask Service

Last updated 2 months ago

Was this helpful?

Data Management
Tasks Service guide
Data Service guide
Events Service guide
Dispatchers Service guide
event_flowchart