Skip to main content

2 posts tagged with "workflows"

View All Tags

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)

Workflows 1.6.0 & ProcessAutomation 0.1.0

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

We have been hard at work on the process automation component, which supersedes the workflow component.

Resources

ResourceVersion
workflow-model-stack 1.6.1
process-automation-component 0.1.2

Workflow model

The first step is moving away from database config into the model. The workflow model allows you to define all workflows statically. It also provides bindings for the workflow component such that it automatically updates the database configuration when changes are made to the model. Having the information in the model also gives the MicroRadiant the ability to visualize your workflows.

We also provide a tool for importing existing database configuration into the model.

Stack Rename

From version 1.6.0 onwards, the stack resource is called net.democritus.workflow:workflow-model-stack.

This previously was net.democritus.workflow:workflows-metamodel-stack.

Process automation component

A preview release is now available for the new process automation component!

note

The version starts with 0.x.x. This is to indicate it is still likely breaking changes are introduced as we move towards a stable 1.0.0 release.

The component is a new approach to workflows, designed with more flexibility in mind. The key distinction is queue based processing, where the previous component could only handle timed polling. This means we can now start supporting a wide range of triggers, such as CRUD events, transitions, cron schedules and even the flow engines you're already familiar with.

Migration

Migration can be quite involved depending on the current state of your application. To ease the difficulty, we provide a migration guide with smaller steps so applications can incrementally adopt the new component.

It is recommended for all applications to at least perform Step 1 (workflow model) and Step 2 (task outcome model). This will already give some advantages like model-based configuration and makes it easier to adopt process automation on a stable release.