Custom process state in a Zeebe workflow instance

Question

Is there a way to attach/retrieve a custom state (a string value) to/from a running Zeebe workflow ?

example: Considering a canonical charge credit card workflow in Zeebe.

Start -> ChargeCreditCard (service task) -> End

The ChargeCreditCard task is modelled as an external task that a nodejs worker app is listening on a topic. Assuming this nodejs app takes 1 minute to execute and complete, i'd like to define/attach 2 custom state names to this model.

State # 1. charging-credit-card (before 1 min) State # 2. credit-card-charged-successfully (after 1 min)

so that if someone retrieves the state of a running workflow instance via the zeebe rest api, they get state # 1 before the execution and state # 2 after 1 minute when the nodejs worker is done.

My question is there a native way to do this in Zeebe using the standard BPMN objects. If not, are there any workarounds to achieve the same.

Answer 1

There is no Zeebe REST API. Nor is there any Zeebe gRPC Query API to retrieve the state of a running workflow instance (at least not in any supported for production release - it was removed in 0.18). There is discussion about getting updates on running workflows in this feature request: "Awaitable Workflow Outcomes".

So there is currently no way to query a workflow state. You have to broadcast/message it out from a worker.

You could achieve what you want to do by putting the "Charge Credit Card" Service Task in a sub-process, and put non-interrupting boundary event timers on the sub-process to trigger the state updates via service tasks.

Answer 2

I think the previous answer can be improved by emphasizing that querying workflow state is not supported by design, for the purpose of scalabality. So, you should not even want to query the zeebe broker/engine for its internal state, but let it handle its own state in isolation, while you limit yourself to just dealing with the artifacts the zeebe broker publishes or exports asynchronously about its state.

What I do not agree with is to clutter BPMNs with service workers that have no functional meaning but serve as technical workarounds to achieve some goal you should not even be pursuing in the first place. Because, by definition that defeats the purpose of using BPMN to clarify and orchestrate your process flow.

The solution that I am now working on and will open source in a month or so, is roughly as follows. - A modern Javascript user interface that connects with an API server and a socket server - An API server exposing a RESTful interface for creating workflow instances, putting data into workflow instances, etc. - A zeebe installation with a kafka exporter - A socket server that subscribes to kafka topics related to workflow instance events (using kafkajs in my case), processes kafka messages and emits processed data over a socket back to the JavaScript front-end application

A rudimentary proof-of-concept can be found here https://gitlab.com/werk-en-inkomen/zeebe-kafka-socket . The neater and more elaborate, fully Dockerized solution will follow soon.