Skip to main content

ProcessAutomation 1.0.0

· 3 min read
Jorren Hendriks
Jorren Hendriks
R&D Engineer

In the past six months we've seen adoption of the process-automation component. Feedback has been great and people seem to be happy with the changes we made. We felt the current feature set came to a point where it warrants a first stable release. This of course does not mean development will stop here, as there are many features we still plan to add.

Resources

ResourceVersion
process-automation-component 1.0.0

Feature set summary

The list below should give you a good idea of the features we currently support through process-automation:

  • Fully supports the workflow model.
    • Integrates all defined transitions, including branching transitions.
    • Respects configuration on TaskElements, such as transactionType and TaskOutcomes.
    • Supports configuring WorkflowImplementation through defining QueuedProcessors.
  • Multi-node or multi-instance configurations are supported.
    • Internal state-machine to perform leader-election in the presence of multiple nodes.
    • Ensures smooth execution of transitions, with no conflicting state.
    • Improved scalability by providing extensible queue configurations.
  • Event-based execution model, backed by a queue.
    • CRUD triggers: transition an element on create or modify.
    • Transition trigger: immediately queue the next transition after another completes.
    • DataCommand trigger: transition an element when a command is performed.
    • Schedule trigger: Cron-like configuration for time-based transitions.
    • FlowEngine trigger: behaves similar to the classic Flow implementation.
  • Modular design, ships with standard configurations and can be extended easily.
    • Provided queue implementations: ApplicationPersistence (DB) and InMemory.
    • Provided processing implementations: Asynchronous and ExecutorService.
note

There is no full feature-parity with the Workflow component yet, so consider this when planning to migrate. Reaching this point however is a goal of the following release, as the primary omission is support for TimeWindow/TimeWindowGroup.

Migration guide available in full post... (Read more)

Migration

This guide assumes you will be migrating from process-automation 0.x.x. If your current application is using the workflow component, please use the dedicated guide for migrating from the workflow component.

Version 1.0.0 introduces changes to the datamodel. Depending on the stage of your project you will need to migrate the database to support this change. This can be achieved in two ways:

  1. Create an incremental change, only applying the difference in fields. For example in PostgreSQL, you would write the following:
    -- WorkerNode gets created on startup, remove old instances to prevent any issues.
    DELETE FROM PROCESS_AUTOMATION.WorkerNodeService;
    DELETE FROM PROCESS_AUTOMATION.WorkerNode;
    -- WorkerNode no longer defines 'address', and added columns 'isLeader' and 'request'.
    ALTER TABLE PROCESS_AUTOMATION.WorkerNode
    DROP COLUMN address,
    ADD COLUMN isLeader BOOL,
    ADD COLUMN request VARCHAR(255);
  2. Drop the database/schema, and provision it again with the expanded schema definition.

Finally, there have been changes to the artifacts used at runtime. If your expansion folder contains artifacts from a previous version, make sure to clean it when expanding.

mvn expanders:expand -Dexpansion.clean=true