Workflow as a Service

The first and foremost idea behind Automatiko is to allow use of workflows as a means of describing complete business logic of an IT solution. With that you, as a developer would use BPMN notation as sort of programming language. Further it will be compiled into a fully featured service that can be accessed over the network.

Workflow as a service

Workflow as a service means there will be a service that will be built based on workflow definition(s). This takes into account various aspects of the workflow such as

• entry point of the workflow
• type of activities used
• data object defined
• custom attributes defined on workflow, activities and data objects

Depending on the workflow definition the service built from it will have different characteristics but overall it aims at delivering fully functional service that is also selfdescribing.

Self describing service

The selfdescribing aspect is extremely important as it allows consumers of the service to quickly understand the intention behind the service and how to make use of it.

This characteristic is relaized by building OpenAPI definition of the service that can be either consumed directly (e.g. to create client applications) or published to service repositories that can be later on discovered and managed by API management tools.

OpenAPI definition visualized with swagger UI.

What is important is that all of the descriptions can be directly defined in the workflow definition making it not just the definition of you business logic but also your documentation.

Entry points of the service

Entry point of the service are built based on so called stard events of the workflow definition. That can be one of following

• none start event - it will be a dedicated POST endpoint
• message start event - it will rely on integration components to subscribe for messages
• timer start event - it will start based on time intervals

This enables service to react to various types of events that can initiate instances of the workflow.

Expose data to the outside world

Since data is effectively the most important part of the service, exposing them to outside world is crucial. In many cases this will lead to defining the intention behind given data object of the workflow.

Common scenarios invole data object classification such as

• inputs of the service - data that are expected to be given when starting new instances
• outputs of the service - data that will be considered as results of the instance
• internal data - data objects that are not to be shown to the consumers of the service

This again contributes to the description of the service, so consumers can directly interact with the service in the way that was intended.

Secured from the beginning

Security should never be an afterthought, that's why Automatiko comes with simple yet powerful option to secure your service. Service can be secured on the API level but also on the instance level. Instance level security enables use cases that bring the context of the instance into the mix. Instance level security enforces security on operation level such as

• read - checks if given identity can access the instance
• create - checks if given identity can create new instance
• update - checks if given identity can update the data of the instance
• delete - checks if given identity can delete the instance
• signal - checks if given identity can trigger activities in the instance

Various access policies can be implemented taking into account different aspects e.g. actors involved in given instance, geolocation of the actors and so on.

Know what's happening

Building and deploying service is one thing but knowing how it operates is another. Automatiko comes with built in mechanism for delivering metrics about the execution state. That is directly exposed as service endpoint that can be integrated with monitoring tools like Prometheus and Grafana to build dashboards on top of collected data.

In addition to that, Automatiko comes with an addon that can be added to the service to provide extra details around workflows being used in the service.

Process management addon UI.

Conclusion

Workflow as a service is meant to build services backed by workflow, taking their definition as the source of the logic to be exposed. Making best use of the what workflows are good at (visibility, isolation, tracability and more) to deliver efficient runtime environment to host your business logic.

At the same time it is not that different from the regular way ... build it from scratch. It does rely on modern architectures, frameworks and ways of building services which greatly simplifies maintenance of the delivered service.

Photographs by Unsplash.

---