bpxe/bpxe

Business Process eXecution Engine

bpxe's Issues

Problem: source code files don't have license references

BSL license stipulates that every source file should have one:

All source files under BSL have a Change Date and the name of an Open Source license in the header. The Change Date specifies when the source file changes from BSL to the specified Open Source license. On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License (i.e., an Open Source license).

Proposed solution: use an automatic header insertion tool and go-header lint (golangci-run includes it)

Problem: reacting to events during activities

BPXE does not currently implement boundary events which are meant for this purpose.

Proposed solution: implement them

Type aliases as used here don't provide value, type safety

https://github.com/bpxe/bpxe/blob/0828554a14ebbdc2c38b7564443c0036b0f05ab0/pkg/bpmn/schema.go#L19-L29

type QName = string
type Id = string

This lets callers intermingle the types freely, removing any benefit of using the types. Should use

type QName string
type Id string

and so on.

https://play.golang.org/p/k8vgBkqdmwr

package main

import (
	"fmt"
)

type Foo = string
type Bar = string

func demo(b Bar) {
	fmt.Printf("i'm happy to have receiver a bar: %v\n", b)
}

func main() {
	var f Foo = "i'm a foo"
	demo(f)
}

Also, ID not Id: https://github.com/golang/go/wiki/CodeReviewComments#initialisms

Finish adding @fire-bot to your repo

Greetings, fire here!

@yrashk recently invited @fire-bot to this repository. Before fire is enabled, @yrashk needs to complete a few steps:

Complete fire setup now

Only @yrashk will be able to enable fire using the above link. If someone added fire by mistake, feel free to remove @fire-bot from your repo's collaborators.

Why Rust package points here? Rust crate doesn't compile due to outdated `rhai` dependency

error[E0425]: cannot find value `args` in this scope
...
error: could not compile `rhai` due to 47 previous errors

Outsiders cannot set issue labels

https://github.com/bpxe/bpxe/blob/master/CODEREVIEWS.md#how-do-i-submit-reviews

Simply open an issue and assign the code review label to it.

Without extra access to the repository, people cannot do that.

Problem: testing different cases

Currently, testing BPXE against different cases / BPMN documents is a bit verbose,
and it's sometimes hard to debug.

Proposed solution (1): extract more primitives to simplify testing

Proposed solution (2): externalize testing by creating a common tracing format
as well as live querying / event injection.

This is a larger undertaking than (1) but it has the following benefits:

1. [Live] trace querying is one of the most important features BPXE will provide, so it needs to be done anyway
2. It will allow to test any BPMN engine that can produce the same tracing format.

I think proposed solutions (1) and (2) aren't exactly mutually exclusive.

Problem: four years is a long time to wait

While the reasoning for conversion to BSL was given in #8, it's still rather unfortunate that one has to wait for four years to get BPXE relicensed.

This is an exploratory discussion as to how this can be improved.

Problem: event-based gateway testing

Currently (as of 0154b48) https://github.com/bpxe/bpxe/blob/0154b48a964c93f02947029be367730974cea4f1/pkg/flow_node/gateway/event_based_gateway/tests/event_based_gateway_test.go#L18-L25 only tests event-based gateway that it'll follow a certain path in presence of
just one event, but it doesn't test what will happen if both events will occur.

Proposed solution: figure out how to improve the test to support this case

Naive implementation like this one below blocks somewhere:

testEventBasedGateway(t, func(reached map[string]int) {
    assert.True(t, reached["task1"] == 1 || reached["task2"] == 1)
    assert.Equal(t, 1, reached["end"])
}, event.NewMessageEvent("Msg1", nil), event.NewSignalEvent("Sig1"))

Not yet sure if this is due to how the test function works or due to a bug in the implementation.

Problem: eventDefinitionRefs support in intermediateCatchEvent

As I've mentioned in #17 (3de353d specifically), due to the bug in schema generator, abstract root element eventDefinition is not expanded into specific types, so we're not able to properly parse BPMN documents that contain these. This prevents us from supporting re-usable event definitions in intermediateCatchEvent.

Impossible clock logic

https://github.com/bpxe/bpxe/blob/0828554a14ebbdc2c38b7564443c0036b0f05ab0/pkg/clock/host_generic.go#L28

				if t1.Before(t1) {

You can be pretty darn sure that t1 is never before itself.

Mock clock leaves lock taken

This pattern repeats:

https://github.com/bpxe/bpxe/blob/0828554a14ebbdc2c38b7564443c0036b0f05ab0/pkg/clock/mock.go#L53-L59

	m.Lock()
	ch := make(chan time.Time, 1)
	if duration.Nanoseconds() <= 0 {
		ch <- m.now
		close(ch)
		return ch
	}

This leaves the lock taken. Should use

m.Lock()
defer m.Unlock()

Problem: can't instantiate process using Receive Task

As mentioned in 460473d, one can't instantiate a process using a Receive Task, simply because Receive Task hasn't been implemented.

Problem: can't instantiate process via event-based gateway

As mentioned in 460473d, one can't instantiate a process using an Event-Based Gateway, simply because it's not a handled use case yet.

Problem: Event-Based Gateway does not support Receive Tasks

As per 10.5.6 of BPMN 2.0, Event-Based Gateways must support Receive Tasks (under certain constraints). Current implementation does not support them.

Proposal: split server and library, means provide flexibility in usage

Hi,

I really appreciate your work in building such a BPMN engine in Go.
I'm quite impressed by your problem statement because it's exactly my thinking.
Really great job done 👍

One sentence caught my attention - the usage one:
"BPXE does not have an executable server of its own and can be only used as a Go library."
Frankly said that's exactly, what I'm looking for, an engine as a library.

Let me explain, why I think splitting BPXE into lib and server as separate projects would be a better idea.
Every point you mentioned about business is interested in transparency and wants to know what is implemented is right.
So the benefits of BPMN having a modeler and thus some "live documentation" is great.
On the other hand, when you want to deploy a (or any) workflow engine into a server,
you're faced with questions about partitioning, consistency, availability (CAP theorem).
What I mean: as the author of this project, you would need to support the most common database,
fiddle with their quirks, ensure multiple server instances can run (high availability), and make this overall very responsive.
That's a lot of work, which not everyone needs.

Think for a moment, bpxe would have no DB persistency implemented and just allows other
developers to load BPMN files, and execute them in memory only - period.
This would lower the barrier to include such a lib instead of developing homebrew state machines or what-not,
with having full documentation and modeling support available.

That said, the bpxe engine would be focused on being a lib without DB support,
one would certainly need two handfuls of callbacks/hooks so that application developers can
react to state changes of the BPMN process state. They would follow their existing paradigms
of putting the state into the DB with their preferred DB technology.

Bare with me, when I share this example from the Javascript space ...
https://github.com/paed01/bpmn-engine/blob/HEAD/docs/Examples.md
This engine is built as lib only.

Considering the lib offering such interfaces, you're not blocked and still be able to develop another project,
which then would/could focus on being a server incl. database support, UI etc.

I hope my thought is not offending, because I really love Open Source and collaboration around it.
And I would be very glad to get some reflections from you and this idea.

Sincerely
Martin