Service interfaces

As described in the concepts chapter, Automatiko exposes workflows as services. These services can be directly used by consumers meaning they act as entry points of the API. Depending on the workflow design there might be various ways how to interact with these services:

  • REsT interface

  • GraphQL interface

  • Message based interface (limited to trigger)

REsT interface

REsT interface is the default and always present service interface. That means each public workflow definition will have dedicated endpoint created for it and named based on workflow definition id.

So when there is a workflow definition that processes orders with following

  • workflow definition id - orders

  • workflow definition name - Process incoming orders

  • version - 1.0

Then the REsT service interface will be created with following path /v1_0/orders

It will have number of additional endpoints (under the main path /v1_0/orders) created to expose additional capabilities of the service based on workflow definition. To name some

  • user tasks - each user task will have three endpoints to

    • get task inputs

    • complete task

    • abort task

  • signals - each signal event will have dedicated endpoint

  • subprocesses - each subprocess will have dedicated endpoints based on sub workflow definition

  • workflow definition image and workflow instance image

GraphQL interface

In addition to REsT interface users can enhance their service with GraphQL interface. That is to allow more advanced operation to be performed that take advantage of under-fetching and over-fetching principles promoted by GraphQL.

It follows the same principle as REsT interfaces, each public workflow definition will have dedicated GraphQL operations created, including

  • user tasks

  • signal events

  • subprocesses

To enable GraphQL interface add following dependency to your project


Once that is added, service will be equipped with following capabilities of GraphQL that are based on workflow definition:

  • mutations - each operation that manipulates workflow instance will have dedicated mutation (e.g. start new instance, abort, etc)

  • queries - each operation that allows to retrieve workflow instance information will have dedicated query (e.g. list instances, get instance details, etc)

  • subscription - each workflow definition will have set of subscriptions available to get notifications when:

    • new instance is created

    • instance is completed

    • instance is aborted

    • instance fails (ends with error status)

    • instance is updated

In addition to above subscriptions there is also a generic userTasks subscriptions that allows to get access to user tasks managed by this service.

All subscriptions are security context aware meaning notifications are sent based on access rights of the caller who created subscription

Subscriptions are based on websocket protocol so to create subscription from client side following code can be used

let ws = new WebSocket("ws://localhost:8080/graphql");

ws.onopen = function() {

	ws.send('{ "query" : "subscription {userTasks(user:\\\"john\\\", groups:[]) {id, taskName, state, formLink}}"}');

This will subscribe to userTasks as user john so only user tasks that john is allowed to work on will be delivered.

Message based interface

Last but not least, service can also be equipped with message based interface such as

  • Apache Kafka

  • MQTT

  • Apache Camel components

The main difference for this interface (compared to REsT and GraphQL) is that it is tailored for just one type of workflow constructs - message events

Message based interface is both inbound and outbound so it can consume and produce messages depending on the type of message event used within workflow definition (catching or throwing respectively).

To enable it one (or more) of the messaging providers must be added to your project. The easiest way is to use Automatiko archetypes to bootstrap project with defined dependencies. See Getting started guide for details.