WorkflowDefinition vs WorkflowModel (vs WorkflowBlueprint)

[jdevillard]

Hello,

first of all, thanks you for you amazing work, I'm really interested by Elsa Core and Designer capability. I would like to include this in a more large application and for this I need to understand the serialization of the different element.

Using the Serialization Sample, I've understand that :

• A WorkflowDefinition can be (de)serialize in(from) JSON and using WorkflowBluePrint you can start instance of the Workflow.

My idea was to start from a Code Workflow (IWorkflow) and try to serialize it to be sure that the WorkflowDefinition is correct but I've seen that there is no (simple?) way to go from a code Workflow to WorkflowDefinition. I've not seen the way. (from WorkflowBluePrint to WorkflowDefinition).

After Looking at the Rest API , and WorkflowDefinitionService, I've seen that there is a other class WorkflowModel which seems to be used to go to the Workflow Definition (use by the designer?).

Am I wrong? Am I missing something?

What is the good way to go From CodeWorkfow to WorkflowDefinition? (and so after I can go back to instanciate a Workflow Instance, because I understand that the CodeWorkflow representation is "readonly" and I don't search to recreate a C# CodeWorkflow from serialization).

Thanks a lot

[sfmskywalker]

Thanks for the kind words!

I'll try and explain the object model and relationships. It's pretty simple actually:

• The workflow engine itself deals with Workflow Blueprints only by instantiating new Workflow Instances, that then get executed (using the blueprint as a "map" to determine what activities to execute next).
• To construct a blueprint, Elsa relies on IWorkflowProvider implementations, of which there are currently 3 that come with the box:
  1. DatabaseWorkflowProvider
  2. StorageWorkflowProvider
  3. ProgrammaticWorkflowProvider

The responsibility of these providers are simply to return a list of IWorkflowBlueprint implementations which are then stored (in a memory cache) for the workflow engine to lookup.

Each provider has its own means of providing a workflow blueprint. I'll briefly describe each one of them:

DatabaseWorkflowProvider

This provider loads WorkflowDefinition objects from the database. These workflow definitions are typically created by the visual designer. More specifically, the designer communicates with a REST API exposed from the workflow server, which stores workflow definitions.

StorageWorkflowProvider

This provider is similar to the DatabaseWorkflowProvider, except for the fact that this provider loads WorkflowDefinition objects from an abstraction called IBlobStorage (which comes from the Storage library), which allows you to host workflow definitions as JSON files on local disk, cloud blob storage, and anywhere else for which there is an implementation of IBlobStorage.

ProgrammaticWorkflowProvider

This provider is the one that relies on IWorkflow implementations, which in turn is part of the workflow builder API. This provider takes all IWorkflow implementations and basically runs the Build method on each one of them, which returns a fresh new workflow blueprint.

I'm considering to rename this to WorkflowBuilderApiWorkflowProvider since it relies on the Workflow Builder API.

** What is the good way to go From CodeWorkfow to WorkflowDefinition **

Short answer: there is no good way. Not out of the box at least.

All of the providers mentioned are unidirectional: you can go from any source to a workflow blueprint, but there is no support to go the other way around.

The reason for that is simple: programmatic/code workflows can run inline C# code. Imagine you want to convert such a workflow to a workflow definition that can be stored in the database or on disk. How would you do it in such a way that when you convert that workflow definition back to a blueprint (in order for the workflow engine to run a workflow instance of it), that inline C# code can still run?

I'm not saying it's not possible, but I imagine it would require quite a bit of work to somehow extract the C# code to be persisted as part of its inline activity somehow, and when being deserialized, be parsed into actual C# code, or at least in compiled form so that it can be executed.

Now, I haven't spent much time investigating this, so it's completely possible that there are simple ways to achieve this that I'm unaware of. I would love to hear about it if this is the case.