Automatiko 0.6.0 released

Asynchronous execution, ready to use services and more

Posted by Automatiko team on August 01, 2021 · 5 mins read

We are pleased to announce a new release of Automatiko - 0.6.0

Highlights

  • Async execution of service endpoints
  • Addon services ready for use (Archive and Send Email)
  • End of instance strategies
  • Google PubSub sink for Workflow as a Function Flow
  • Support for Apache Camel connector headers
  • Imporved error handling for Business Rule task

Async execution of service endpoints

In many situation awaiting response when interacting with workflow instances might not be desired behaviour. It might be due to various reasons such as

  • long running service invocation
  • poor network that can cause dropped connections
  • there is no need to wait for the response at all .e.g fire and forget kind of use cases
With Automatiko you can take advantage of async execution very easily by deciding on the mode on request basis. That means workflow definition is not really aware of it and the responsibility how the invocation should happen is on consumer side.

Async execution is provided by an HTTP header and can also request a callback to post data once execution is completed.

Have a look at Automatiko documentation for more information about async execution.

Addon services ready for use (Archive and Send Email)

In many cases there are needs to simply do basic operations - like sending email to notify about created incident. Such operations are usually reusable and as such should be easily configured within workflow tasks. This is what has been started in 0.6.0 release of Automatiko - an addon services. With this version following services are delivered

  • Archive - to build archives (zip files) based on given set of files
  • Send email - to send email message either with templates or without them

Have a look at Automatiko documentation for more information about addon services provided out of the box.

End of instance strategies

When workflow instance reaches its end (either by completing successfully or by being aborted) there might be situations that requires it to be handled in one way or another. For this exact purpose, end of instance strategies are provided. These allow to have different behavior depending on your needs. For example due to legal requirements instances must be kept for given amount of time, or they should be archived to another location for reference. Automatiko provides three out of the box strategies:

  • remove
  • keep
  • archive
Process management UI has also been improved to support various strategies and by that you can look up instances based on the status including completed and aborted.

User task form image Process management UI with filter by instance status.

Have a look at Automatiko documentation for more information about end of instance strategies.

Google PubSub sink for Workflow as a Function Flow

Workflow as a Function Flow is a very powerful concept that allows high scalability based on KNative Eventing but allowing developers to focus on complete business use case rather just individual functions. Automatiko 0.6.0 brings support for Google PubSub as event sink instead of default http based one. The main advantage of this sink is to be able to take advantage of managed KNative environment that is Google CloudRun. With the support of this component users can run workflow as a function flow directly on managed service and rely on higly scalable messaging infrastructure - Google PubSub.

A complete blog post dedicated to this topic is in the works and will be published within few days!

Support for Apache Camel connector headers

Apache Camel connector has been supported for quite some time. It allows to take advantage of any of the supported Apache Camel connector as implementation behind message events (both sending and receiving). Until now, it had a missing feature - to be able to specify headers (headers are frequently used by Apache Camel components to provide configuration). Since Automatiko 0.6.0 you can specify any of the headers as part of custom attributes of the message event. All entries that starts with Camel will be considered headers.

Imporved error handling for Business Rule task

When working with business rule tasks that invoke decision you can now take advantage of error handling. That can be either

  • boundary error event
  • event subprocess with error start event
When defining errors to handle decision evaluation problems error code should be set to DecisionEvaluationFailure. In addition, error information can be mapped to workflow instance variable that will be of type Map with following entries:
  • error - string representation of all error messages returned from the evaluation
  • results - data returned from the evaluation (might be partial)

Photographs by Unsplash.

← Previous Post Next Post →