Workflow instance creation by Event State seems strange

[globalflea]

The specs for Event State states "... If defined as the workflow starting state, the event state definition controls when the workflow instances should be created".

My understanding is that States (e.g. Operation, Switch, etc) are own by a Workflow Instance. So i don't understand how an Event State can trigger the creation of the Workflow Instance that it belongs to? i.e. in order to have an Event State, shouldn't there be a Workflow (as a sort of parent) first? If so, the workflow instance already exists ...

am i missing something?

[tsurdilo]

Good point. Will work on clarifying this section.

To give you an idea, it is really up to the runtime how to do this, and the spec doc should not make this assumption (will fix asap!).

There are really two ways a runtime can handle this:

1. Like you mentioned, create instance of a workflow and then send the event that triggers the starting event state. Some runtimes provide like a "eventWithStart" functionality which creates workflow instance and then immediately sends the event to it that triggers exec.
2. Have an event-consumer that triggers workflow instance creating when the appropriate event arrives. This means that runtime keeps track of deployed workflow definitions and knows to map incoming events to creation of workflow instances that have a starting event state

Either way, the spec should not, as you mention, favor one or the other, or in that matter any possible implementation decision.

[globalflea]

I'll need time to digest your answer. I sort of thought of each workflow as an independent process registered with a registry (so others can locate it - eg K8S mDNS service). The idea that an event starting a workflow or the concept of a runtime that listens to all events inorder to be able to trigger a workflow does not sound scaleable to me. Especially if there are hundreds or thousands of workflow definitions ... Wouldn't that runtime become a bottleneck? I mean that runtime would need to listen to each and every message, check if it's a cloud event, check if the event ought to start an workflow from the hundreds defined workflows who may also have hundreds of Event States defined? Or am I missing/misunderstood something?

[tsurdilo]

Can you please elaborate? A workflow definition (json/yaml) is a definition of your business requirements. From a workflow definition you can create many workflow instances. Those can be triggered by users pressing a button on a website, or events coming into your event broker system.
Runtimes can also control this by limiting a single creation of a workflow instance from a workflow definition.
From the DSL perspective, it has "keepActive" property that you can use to explicitly do that (single instance)

[tsurdilo]

There are always going to be some scaling concerns, with any runtime existing or new. The typical bottleneck ends up always being a DB storage. Some runtimes scale per single workflow instance, others per number of workflow instances.
So yeah it really depends how you want to use it and for us then to make sure that you have the proper functionality in the DSL to express that.

[tsurdilo]

Good point, a "runtime" at least for sw is an interpreter and executor of the instructions defined in the DSL.
I guess it may also be historical as to name it a "workflow runtime" as that is widely used.
Definitely open to suggestions on the wording tho