WorkFlow-Engine: a Flowable based Java workflow suite with its own form and item designers

Three products in one repository, not a library you embed

The repository layout explains the shape of this project better than any description. There are four Maven modules plus a separate frontend project, and the naming makes the division of labour clear:

y9-module-flowableui
y9-module-itemadmin
y9-module-jodconverter
y9-module-processadmin
vue

The flowableui module is the workflow module and carries a webapp submodule. The itemadmin module is the item management module and it is the largest of the four, splitting into a Feign client wrapper for the API, the API interface itself, a JPA repository persistence layer, a control and business layer, and a webapp. The processadmin module follows the same shape with its own Feign client, interface, business layer and webapp. The jodconverter module is separate and small, and it exists only to preview documents. The vue directory holds two frontend projects, one for item management and one for the workflow interface.

This is an application suite, not a library. You deploy it, you configure it, you extend it through its own modules. If you wanted to add workflow to an existing Java application, this is the wrong shape of tool. If you wanted to run an approval system for an organisation that already thinks in terms of forms, positions and pending items, it is the right shape.

The badges at the top of the page give the version numbers: v9.6.9, Spring Boot 2.7, Vue 3.3, JDK 11, a GPL3 licence and a claimed total of 301k lines. The repository also carries a CHANGELOG.md, a lombok.config and a pom.xml at the root, and both .gitee and .github directories, which suggests the project is developed with Gitee as its primary home and mirrored to GitHub.

The three modules correspond to three different users

The functional architecture divides the system into a configuration side and an operating side. The workflow engine is split into item configuration and the workbench. Item configuration is aimed at operations staff who set up the workflow, and the workbench is aimed at the people who actually use it. The workbench features and interface are what item management produces once it is configured.

Within item management there are three categories of configuration: process items, form items and configuration items. Form management maps database table structures and is backed by a drag and drop form engine. Process management covers the design, deployment and monitoring of processes, backed by a drag and drop process engine. Interface management supports plugging third-party interfaces into process nodes and process paths. Link management binds entries to third-party applications by position.

Two consequences follow from that split. First, the workbench is not a fixed product: what a user sees on screen is the sum of what operations staff configured, so a deployment that skips item configuration produces an empty or broken workbench. Second, the body template and the red-header template features both need third-party plugins, which the documentation states plainly, so those two features are not available out of the box.

The process designer itself is more than a drawing tool. It covers graphical modelling and full lifecycle management, with drag and drop of start events, approval nodes and end events, plus node permissions, transition conditions and handling rules. Instance monitoring lets you see the state of a running process and act on it, deleting, suspending or activating it, and you can read the approval history and the variables. There is process simulation to catch design mistakes early, and support for migrating running instances from a lower version to a higher one so that redeploying a changed process does not strand in-flight work.

The form designer is where most of the daily work happens

The form designer is described as a visual tool for creating and configuring forms, where the structure is built by dragging. Beyond the drag and drop itself, the documented capabilities are worth naming because they set the boundary of what you can do without writing code.

You can associate data sources, set field binding rules and validation logic, and customise the style and layout so the form adapts to different terminals. It supports arrays and table style data structures for entry and display, which is what makes it usable for line item forms rather than only flat records. Actions can be configured to trigger rules that interact with backend data. Standardised templates can be imported, which removes the repetition of building the same approval form over and over.

The item management module adds the surrounding administrative detail: configuring form style, approval rules, the comment box, attachments and numbering rules for a process node, and it provides both interface configuration and link configuration so that third-party systems can participate in a flow. All pending items are gathered into a single interface, filterable by position and by instance status, and message notifications push approval requests and results.

For anyone used to plain JPA entity modelling, this is the part of the suite that will take the longest to learn, because the form definition, the approval rule and the pending list are three separate configuration surfaces rather than one.

The deployment depends on the platform around it

The deployment notes are the most important section for an evaluator, because this engine is not standalone. It supports deployment as microservices, in a distributed way, and containerised, and it can be scaled along those lines. It also needs an extra server for file preview, which is what the jodconverter module exists for, and it depends on the digital base platform and on that platform's single sign-on service.

The logical architecture adds a second dependency that is easy to miss. The workflow engine cannot run without the digital base having job and role configuration, because the whole approval model is built around positions rather than around users. In other words, the system is a component of a larger platform, and standing it up in isolation means standing up the role configuration too.

The scale claim is specific and worth reading carefully. The documentation states that a single instance in a domestic-computing environment on a 4 core, 8GB memory virtual machine can easily handle 500 users, with a caveat that historical data has to be carried over by year. That is a number for the single instance case only, and the annual rollover is a maintenance task you have to schedule rather than an invisible detail.

The topic tags name the surrounding stack, which is a useful hint about what is expected in the field: bpmn, flowable, springboot2, springcloud, nacos, redis, kafka, elasticsearch, docker and vue3.

A fixed dependency set on Flowable 6.8.0

The backend dependency table pins a specific set of versions, and that set tells you what era of the ecosystem this targets. Spring Boot, Spring Data JPA and Spring Data Redis are all at 2.7.10, Spring Kafka is at 2.8.11, Nacos is at 2.2.1, Druid is at 1.2.16, Jackson at 2.13.5, Javers at 6.13.0, Lombok at 1.18.26, Logback at 1.2.11, and Flowable at 6.8.0.

The interesting entry is Flowable, because Flowable is the actual process engine and everything else is the surrounding application. Blaze-Persistence style extensions are not involved; this is a straight deployment of Flowable 6.8.0 with an administration UI, a form layer and an item layer on top. Javers is there for auditing, which is a natural fit for a system that tracks approval history.

The frontend table is similarly pinned: Vue at 3.3.2, vite2 at 2.9.13, vue-router at 4.0.13, pinia at 2.0.11, axios at 0.24.0, typescript at 4.5.4, element-plus at 2.2.29, sass at 1.58.0, vxe-table at 4.3.5 and echarts at 5.3.2. The presence of vxe-table tells you the item lists are grid oriented, which matches the description of a workbench that filters pending instances by position and status.

These are the versions the project ships against, and because the whole suite is pinned together rather than being a set of libraries you mix yourself, you inherit them. A team on a newer Spring Boot line has to either accept the pinned versions or rebuild the modules against a newer Flowable.

Where this engine is the wrong choice

The documentation language is the first obstacle and it is a hard one. The README is written in Chinese, the architecture and deployment sections rely on diagrams hosted on a separate site, and the item management, form and template features use concepts specific to Chinese enterprise administration, including numbered rules, red-header templates and body templates for official documents. There is no English documentation in the repository.

The second obstacle is the coupling. An engine that cannot run without a digital base platform supplying job and role configuration, a single sign-on service, Nacos for discovery and configuration, Redis, Kafka, Elasticsearch and a separate document preview server is a large operational commitment for a team that wanted a workflow library.

The third is the licensing question, and it should be checked rather than assumed. The licence field on the repository says GPL-3.0, and the README links to a licence file hosted on Gitee rather than in this tree, while the repository itself carries a LICENSE file. The project is described as a domestic and open source replacement for commercial workflow products, so its position on commercial use is worth reading directly.

The comparison with plain Flowable is the honest one. If you need BPMN execution and can live with the Flowable modeler, going straight to Flowable gives you the same engine with far less to run, and you build the form and approval experience yourself. WorkFlow-Engine earns its place only when the packaged form designer, item management and third-party interface integration are the parts you would otherwise write.

Editorial conclusion

WorkFlow-Engine fits a Chinese enterprise team that already runs the Risesoft digital base platform with job and role configuration and single sign-on, and that wants approval flows, form rendering and third-party interface calls delivered as one deployable suite rather than assembled from parts. It does not fit a developer who needs English documentation, a standalone workflow library to embed in an existing application, or a deployment without Nacos, Redis, Kafka and a separate file preview server. Before adopting it, confirm the version badge, which reads v9.6.9, against the Flowable 6.8.0 and Spring Boot 2.7.10 dependencies it ships with, check that the position and role configuration it requires from the digital base is available, and read the GPL3 licence file yourself before using it commercially.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. risesoft-y9/WorkFlow-Engine on GitHub