Orleans.Activities

Workflow Foundation (.Net 4.x System.Activities workflows) over Microsoft Orleans framework to provide stable, long-running, extremely scalable processes with XAML designer support.

Stable:

Master: AppVeyor project feed (NuGet source)

Guidelines

• Branching Guidelines
• CI Guidelines
• Coding Guidelines
• Design Guidelines

This project is licensed under the Apache License.

Important

Only in case of projects with designed XAML workflows!!!

• Don’t use Microsoft.NET.Sdk, use old project format (Sdk has no XamlAppDef BuildAction)

• Use at least VS 15.6 (older VS 15.x Activity designer crashes when Microsoft.Orleans.Core.Abstractions is installed via NuGet 4.x PackageReference tag)

Documentation

• see the Samples below, they come with tutorial level, detailed descriptions
• or see my Presentations repo

Concept

Why?

The key concepts behind Workflow Foundation and Microsoft Orleans are very similar, but Microsoft Orleans solves the pain points of Workflow Foundation (WCF and SQL oriented, non-scalable).

How?

We kept only the the "good parts" of Workflow Foundation, the WorkflowInstance (a mini Virtual Machine executing the Activities) and replaced everything else with Microsoft Orleans, ie. we replaced WorkflowServiceHost with Microsoft Orleans Grains (stateful actors).

Integrated:

• Persistence (compatible with legacy workflow extensions)
• Reminders (compatible with legacy Delay activities)
• Tracking
• Designer & Debugger support
• Nearly all legacy activities are supported (except TransactionScope and WCF messaging activities)

Result?

A typical workflow grain ("domain service" grain) manages operations in other normal grains ("aggregate root" grains) and handles only the process specific data in it's own state.

• Normal grains typically have long life, they can have event sourced states or can use short-lived Orleans transactions on their interfaces.
• Workflow grains have a one-shot lifetime, the long-lived transaction they implement.

Implementation

This is a very high level view:

• Each WorkflowGrain is indistinguishable from a normal grain and backed by a WorkflowHost.
• The WorkflowHost is responsible to handle the lifecycle of the WorkflowInstance, mainly recreate it from a previous persisted state when it aborts.
• The communication between the WorkflowGrain and the WorkflowHost is based on 2 developer defined interfaces for the incoming and outgoing requests (TWorkflowInterface and TWorkflowCallbackInterface).
  • These interfaces provide the type safe communication with the workflow.
  • Their methods can be referenced from the workflow activities to accept incoming or to initiate outgoing requests.
• The methods of the TWorkflowInterface and TWorkflowCallbackInterface are independent from the grain's external public interface, you can merge different public requests into one method or vice versa. Or a reentrant grain even can execute (read-only) public interface methods independently from the current running workflow operations.
• The method's signatures are restricted, their parameters and return values are lazy, async delegates with 1 optional parameter/return value. The delegates executed by the workflow activities if/when they accept them (command pattern).
• There are design-, build- and static-run-time checks to keep the interfaces and the workflows in sync.
• Though you can execute complete workflows as methods also.

The goal, is to keep the C# code in the grain, and use the workflow only to decide what to do next. This way we can avoid a steep learning curve to use workflows: the developer doesn't need to write or to understand anything about activities, he/she can build workflows with the provided activities in a designer.

Functionality

Integrated:

• Persistence (compatible with legacy workflow extensions)
• Reminders (compatible with legacy Delay activities)
• Tracking
• Designer & Debugger support
• Nearly all legacy activities are supported (except TransactionScope and WCF messaging activities)

Extra implemented features:

• TAP async API
• Optionally idempotent request processing for forward recovery
• Automatic reactivation after failure
• Workflow can be persisted during processing an incoming request (ReceiveRequestSendResponseScope is not an implicit NoPersistScope)
• Executing code "in the background" on the tail of the request after the request returns it's response
• Workflow is informed whether it is running in a reloaded state after failure (to determine necessary recovery)
• Notification participant extensions (to get notified when the workflow is idle)

Under construction:

• Tests (currently semi manual, semi automatic MSTest, don't even look at them)
• More elaborate sample with
  • DI/Autofac
  • Strategy and Humble Object patterns, to show an architecture, where the application logic can be tested independently from Orleans and from Orleans.Activities workflows

Not implemented, help wanted (for design and for implementation):

• DynamicUpdateMap support (updating loaded workflows to a newer definition version), though the separation of the application logic (the plain C# delegates) and the process (the diagram) results in a very simple workflow diagram, that has a big chance you won't need to update when it runs
• See all Help Wanted issues

Samples

With tutorial level, detailed descriptions!

HelloWorld - How to communicate with the workflow through custom interfaces.

Arithmetical - How to execute the complete workflow like a method.

Details

You don't need to understand this to use the project! This is for those who want to dig in to the source!

This is still an overview, all the details of the classes are hidden. The goal is to give a map to understand the relations between the classes.

The 2 generated proxies translate the calls between the TWorkflowInterface and TWorkflowCallbackInterface interfaces and the workflow's API, where the methods are identified by their names.

For more details see the detailed comments in the source!