Blueprint processing platform should support Imperative workflow modeling and process those models.

Imperative workflows are user defined and can define any really specific constraints and ordering of activities. They are really flexible and powerful and can be used for any complex use-case that cannot be solved in declarative workflows. However, they provide less reusability as they are defined for a specific topology rather than being dynamically generated based on the topology content.

Imperative workflow grammar defines two ways to define the sequence of operations in an imperative workflow:

• Leverage the on_success definition to define the next steps that will be executed in parallel.
• Leverage a sequence of activity in a step.

The graph of workflow steps is build based on the values of on_success elements of the various defined steps. The graph is built based on the following rules:

• All steps that defines an on_success operation must be executed before the next step can be executed. So if A and C defines an on_success operation to B, then B will be executed only when both A and C have been successfully executed.
• The multiple nodes defined by an on_success construct can be executed in parallel.
• Every step that doesn’t have any predecessor is considered as an initial step and can run in parallel.
• Every step that doesn’t define any successor is considered as final. When all the final nodes executions are completed then the workflow is considered as completed.