Im trying this library follow guide https://nitram509.github.io/lib-bpmn-engine/getting-started, it gave:

./main.go:18:13: bpmnEngine.NewTaskHandler undefined (type bpmn_engine.BpmnEngineState has no field or method NewTaskHandler)

Do we have any plan to support backwards ?

Problem: Assume that we allow user to repay the order instead of creating a new order when user choose to refund before confirm-receipt, it can handle confirm-recepit event and go to send-bill again.
But it can't handle the next flow becasue of some event had already trigged. I can't clear or reset the processInfo either.

The order repay flow may sound weird, but it's common for me to desigin flows like that.

I'm trying to design a workflow that user can handle an event then supervisor recheck it.
If the event handled before has some wrong, the supervisor can turn the flow to previous flow again. so that the previous user can handle it again until the supervisor recheck pass.

At now, I can't archive this goal graceful without backwards support.
Do you have some suggestions?

motivation

currently, task handlers only can be registered for single Ids, which means just one element.
it would be a great extension, to allow a single task handler to be used for multiple types.
This would also increase compatibility with Zeebe.

acceptance criteria

• task handler can be defined for ID
• task handler can be defined for Type (as in extension taskDefinition)
• in case of overlapping task handler (id and type would match), the more specific one has precedence == ID first
• in case of overlapping task handler (id and/or type would match), only the first matching one is executed
• documentation describes details of how multiple task handlers are treated/executed

links

• was inspired by #57

create message event capabilities, so that workflows can be paused, until an event arives.

as in zeebe client, jobs workers should be able to signal done or fail

Note:

func ha(client worker.JobClient, job entities.Job) {
	client.NewCompleteJobCommand()
	client.NewFailJobCommand()
}

motivation

Internal data structures (slices, maps, etc) do grow over time and occupy memory.
Hence, all objects shall be removed, once no more needed.

Implementing a Github action, which triggers a go test run for every PR,
would support the quality of this lib.

motivation

To be compatible with other BPMN runtimes, we need to introduce different scopes for variable mapping which means input mapping should be defined in the local scope, while the output mapping may be merged into the parent scope.

Doc: https://docs.camunda.io/docs/components/concepts/variables/#inputoutput-variable-mappings

business background

Considering sending msg in different situations, the send_notice service task will face variable conflict or overwrite if input mapping does not define in local scope.

If we change and introduce a local scope for input mapping, it will help a lot.

it would be awesome for use cases where long-running processes and are implemented in short living microservices,
if lib-bpmn-engine would be able to export and import+resume it's internal state.

• must: the data must be represented as ASCII-save string, to allow maximum compatibility and avoid codepage/unicode issues
• could: the data format should be human readable, e.g. JSON
• optional: data compression
• optional: base64 encoding
• must: the feature must be agnostic to library upgrades and for example allowing schema changes (optional: split this into another feature)
  • e.g. version info in the serialized file
• documentation is up to date

motivation

lib-bpmn-engine is meant to be an embedded engine.
The architectural guidelines focus on core BPMN execution capability.
There is no support for databases or other external IO.
Also, due to Go's compact and powerful syntax, the code base is just a few hundred lines of code
and so very attractive to be transpiled into WASM.
This would enable a broud range of

This is an experiment as well, to learn if there's a need/demand for such a piece of technology.

Admitting, this is kind of an extra playground :)

acceptance criteria

• the engine is available as wasm artifact (likely a .JS file)
• Github actions are in place, to build wasm artifacts on every release automatically
• npm package registry is considered/evaluated to be used as release hub -- vs. a Github one
• an example implementation is available at the GH pages documentation
• some marketing is made: e.g. is there some special site, listing "interesting" WASM projects? (like e.g. npm is the number one for JS based projects ... if there's some similar go-to place for WASM, this lib should be listed there)

motivation

As documented, https://docs.camunda.io/docs/components/modeler/bpmn/message-events/
when publishing a message, variables shall be possible to be added

acceptance criteria

• documentation exists & examples are updated
• variables can be passed with message publishing
• exciter: "variable mapping", as defined in Camunda's documentation works as well

hint: "exciter" means this is not required to complete/finish this issue, but would be really awesome, if present/included
all other criteria are mandatory

motivation

• don't allow altering process instance state, when job's are in-flight
• align with zeebe go client

motivation

internal errors should be categorized and bubble up to the application developer.

acceptance criteria

• error "classes" shall be defined - e.g. "BpmnValidationError" (as shown in #36)
• documentation shows how to filter/log/react on BPMN validation errors
• errors in 'createNewTimer()' do bubble up so they can be tested with assertions
• process instance status is set to not-active, but "FAILED"

Issue: currently, IDs for instances etc are generated from system clock - which has not always full nano-seconds resolution and thus collides.
The 'TestLoadingTheSameProcessWithModificationWillCreateNewVersion'
does run well on Linux, but fails on Windows.

currently, only one workflow can be registered in the engine
it would be super helpful if multiple could be registered.

estimated <4h of work incl. tests

Thx. 😊

I found that lib-bpmn-engine currently only supports service tasks. Does lib-bpmn-engine plan to support user tasks?

It's not a good idea to painc, use an error to indicate create timer error maybe better than panic.

• provide example code to create background ticker/timer
• explain architectural idea
• optional: provide simple worker code in standard package?

At now the timer is only checked while the engine is running.

If I want to check whether the timer was trigger, I need to write a cron job or a timer to run the engine.

It's awkward , I want a timer event but I still have to use another timer to check timer event.

Maybe the engine could do this work by using a gorontine ito check timers every seconds or some other periods?

motivation

Implementing FEEL (Friendly Enough Expression Language; one part of the DMN specification)
would be a great step towards compatibility with other BPMN runtimes.
The current 'expr' language has known differences (see also #18).

The FEEL language is designed to write expressions for decision tables and literal expressions in a way that is easily understood by business professionals and developers.

Ideally, this FEEL implementation is not part of the engine, but rather an individual project.

Hi,

I am interested to take a challenge persisting the Process to DB. What's the best approach that should I take?

1. Persisting in JSON
2. Persisting in Binary using Gob
3. Others

Also mentioned in:

• #32 (comment)

And what is the storage preferences?
I can do the persistence in Redis / SQLite for starter, later can be MySQL / Postgres, etc

Thank you.

There are some technical checks about the consistency of the BPMN/XML file.
They are commented out because no tests cover these scenarios.
Tests should be created and code can be re-activated.

See

initially, I thought to implement FEEL (from DMN) as Camunda does - I still believe it's a good idea -
but in order to speed up delivery and focus on BPMN, I will use https://github.com/antonmedv/expr language.
This one seems to cover most of my use cases and might be compatible to FEEL to a great extent.

Acceptance Criteria

• lib is included and works for conditions (exclusive gateways)
• documentation exists, to show usage and outline differences/compatibility
• exclusive gateways and defaults can be handled
• #28

motivation

the documentation should make the difference between user tasks and services tasks explicit.
moreover, the difference as introduced in #49 must be documented

acceptance criteria

• the difference between user task and service task is documented
• the handling of user tasks is given by example (code)

• [/] add simple example
• add complex example

the git workflows should also test, if the code example still compile (which are not covered by unit tests)

motivation

supporting assignee and candidateGroups enriches not only the integration option for lib-bpmn-engine users,
but also increases compatibility with Zeebe

acceptance criteria

• task handler can be set to assignee or group
• documentation is there describing the details

bpmn service tasks can be configured with input and output parameters.
currently, the engine can't handle such.
thus, it would be cool to have this feature implemented

The current engine directly calls each handler.
that has some disadvantages when it comes to error handling.

so the idea is ... as described in the title

motivation

being more compatible with BPMN standard

acceptance criteria

• published messages are 'global' on the engine (not on the instance)
• method is renamed
• documentation is extended, minimum mentioned, that IDs of messages must be unique in order to match the right process
  • tbc. what's the matching order? first come first served?
  • tbc. how to deal with different versions of a process

Compared to Zeebe == the BPMN spec, these test events do not behave as expected...

• completion state is not always correct
• wrong path is chosen on event-based gateway

see also #23

add the feature of BPMN timer elements to be supported.
thus workflow instances could be paused, until a given timer event happens.

Hi,

Passing heavy object passing during service task execution ActivatedJob is caught by Go Critic linter https://go-critic.com/overview.html#hugeParam-ref

This suggests performance will degrade over time. I don't have benchmark yet how degraded. Maybe if we have 10,000 service tasks in one flow, this will start to degrade.

Can we consider passing function interface or pointer? My suggestion is to change the existing struct copying with function interface passing. We can do better mocking as well when function interface is passed.

Propagate errors, so that users/developers can detect/handle errors.

See todo:

motivation

the name of the engine should be optional

hint: engine instances are supposed to have a name, to differentiate multiple instances - e.g. during logging.

acceptance criteria

• the name for the bpmn engine is optional, means an engine can be created straight, without providing a name
• a default name per engine is created, when no explicit name is provided

see

// TODO: set to failed in case of panic

motivation

It would be cool to have a Gopher like art/logo for this library,
to strengthen the community :)

• a logo, similar like (google for images, with keyword: ) golang gopher
• SVG preferred
• PNG files in various common logo/thumbnail sizes would be cool to have
• an additional banner would be awesome

the engine is meant to be embedded.
that said, there's a need/appetite to bring transparency into the engine, by allowing users to have a "view" on their processes and states.

One of the initial ideas/goals of this project is to emit the same events, as the popular Camunda Cloud a.k.a. Zeebe BPMN Engine.
Zeebe uses a protobuf based exporter protocol.

The idea for this library is, to provide an optional module so that developers can opt-in to emit events like Zeebe does with the ultimate goal to use their Simple Monitor.

Acceptance Criteria

• can send events to Hazelcast, so that Zeebe Simple Monitor will display them
• basic support for Start, End, ServiceTask, and Flow events required
• ability to configure Hazelcast client
• documentation for setup and how to use

findIntermediateCatchEventsForContinuation seems can't handle mulit events, it alwasy catch the last events when iterating over process.definitions.Process.IntermediateCatchEvent.

code line:

I'd like to push a pull requet if possible.

This project look interesting, tried in production use case?

motivation

the bullet items of supported elements is quite compact and not easy to digest for beginners.
so, the main idea is to improve documentation for beginners

acceptance criteria

• pictures/symbols for each elements are shown
• short element description is available
• relevant caveats (compared to other engines) are described

currently, each workflow instance cant have any variables in its context.
a context would be something simple like a hashmap and would allow each task to read/write variables into.

by BPMN definition, a workflow can have multiple instances.
currently, that's not implemented but is required.

is considered a relatively small task, should be possible <4h

I'm exploring user task function, there is example at https://github.com/nitram509/lib-bpmn-engine/blob/main/docs/examples/pause_user_tasks/pause_user_tasks.go
however, I can't understand how to implement it, support the workflow shall pause user task step, waiting further instruction right? Is there any better example?