You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Workflow Foundation (.Net 4.x System.Activities workflows) over Orleans framework to provide stable, long-running, extremely scalable processes with XAML designer support.
4
+
5
+
__NOTE:__ This project currently is an __experiment__, not production quality! There is no NuGet package for it.
6
+
7
+
~~Help Wanted Issues~~ (soon)
8
+
9
+
~~Documentation~~ (see [HelloWorld](docs/HelloWorld/HelloWorld.md) sample)
10
+
11
+
## Concept
12
+
13
+
14
+
15
+
This is a very high level view:
16
+
17
+
* Each WorkflowGrain is indistinguishable from a normal grain and backed by a WorkflowHost.
18
+
* The WorkflowHost is responsible to handle the lifecycle of the WorkflowInstance, mainly recreate it from a previous persisted state when it aborts.
19
+
* The communication between the WorkflowGrain and the WorkflowHost is based on 2 developer defined interfaces for the incoming and outgoing requests (TAffector and TEffector). These interfaces' methods can be referenced from the workflow activities to accept incoming or to initiate outgoing requests.
20
+
* The methods of the TAffector and TEffector interfaces 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.
21
+
* 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).
22
+
* There are design-, build- and static-run-time checks to keep the interfaces and the workflows in sync.
23
+
24
+
A typical workflow grain manages operations in other grain(s) and handles only the process specific data in it's own state.
25
+
26
+
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.
27
+
28
+
## Functionality
29
+
30
+
Implemented:
31
+
32
+
* Persistence (compatible with legacy workflow extensions), but it can run without any persistence
33
+
* Reminders (redirected from System.Activities Timers, 1 min. is the minimum)
34
+
* Tracking
35
+
* Designer support
36
+
37
+
Extra implemented features:
38
+
39
+
* TAP async API
40
+
* Optionally idempotent request processing for forward recovery
41
+
* Automatic reactivation after failure
42
+
* Workflow can be persisted during processing an incoming request (ReceiveRequestSendResponseScope is __NOT__ an implicit NoPersistScope)
43
+
* Executing code "in the background" after a request returns it's response
44
+
* Workflow is informed whether it is running in a reloaded state after failure (to determine necessary recovery)
45
+
* Notification participant (to notify extensions when the workflow is idle)
46
+
47
+
Not tested, but should work:
48
+
49
+
* CancellationScope
50
+
* CompensableActivity and CompensationExtension
51
+
52
+
Under construction:
53
+
54
+
* Tests (currently semi manual, semi automatic MSTest, don't even look at them)
55
+
* More elaborate sample with
56
+
* DI/Autofac
57
+
* Strategy and Humble Object patterns, to show an arhitecture, where the application logic can be tested independently from Orleans and from Orleans.Activities workflows
58
+
59
+
Not implemented, help wanted (for design and for implementation):
60
+
61
+
* 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
62
+
* TransactionScope activity support (see https://github.com/dotnet/orleans/issues/1090)
63
+
64
+
And there are nearly unlimited issues...
65
+
66
+
## Samples
67
+
68
+
[HelloWorld](docs/HelloWorld/HelloWorld.md)
69
+
70
+
## Details
71
+
72
+
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. See the comments in the source!
Based on Orleans [Hello World](http://dotnet.github.io/orleans/Samples-Overview/Hello-World) sample.
4
+
5
+
## Overview
6
+
7
+
8
+
9
+
## Interface
10
+
11
+
IHello is the same.
12
+
13
+
```c#
14
+
publicinterfaceIHello : IGrainWithGuidKey
15
+
{
16
+
Task<string> SayHello(stringgreeting);
17
+
}
18
+
```
19
+
20
+
## Grain
21
+
22
+
Before the grain, you have to define 3 things: State, Affector and Effector interfaces
23
+
24
+
### State
25
+
26
+
Workflows always have a state. Even if they never persist it. You can use the `WorkflowState` base class or implement the `IWorkflowState` interface.
27
+
28
+
```c#
29
+
publicclassHelloGrainState : WorkflowState
30
+
{ }
31
+
```
32
+
33
+
### Affector interface
34
+
35
+
These are the operations that the grain calls on the workflow, these operations should __NOT__ be the same as the public grain interface methods (see `IHello`)!
36
+
37
+
There are 2 restrictions on the methods:
38
+
39
+
* must have 1 parameter, with type `Func<Task<anything>>` or `Func<Task>` (executed when the workflow accepts the request)
40
+
* the return type must be `Task` or `Task<anything>`
Optionally see what happens during the workflow execution with tracking, this can be left out, there is a default empty implementation in the base class.
A mandatory (boilerplate) implementation of the unhandled exception handler. Because workflows can run in the backround after an incoming call returns the result, we can't propagate back exceptions after this point. Workflow will by default abort in case of unhandled exception, depending on the `Parameters` property.
GetLogger().Error(0, $"OnUnhandledExceptionAsync: the workflow is going to {Parameters.UnhandledExceptionAction}", exception);
98
+
returnTask.CompletedTask;
99
+
}
100
+
```
101
+
102
+
The public grain interface method, that does nothing just calls the workflow's only affector operation. A normal grain can store data from the incoming message in the state, call other grains, closure the necessary data into the parameter delegate. After the await it can build a complex response message based on the value the workflow returned and the grain state, or any other information.
103
+
104
+
The parameter delegate executed when the workflow accepts the incoming call.
105
+
106
+
It also shows how to implement idempotent responses for the incoming calls. In the repeated case, the parameter delegate won't be executed!
107
+
108
+
```c#
109
+
publicasyncTask<string>SayHello(stringgreeting)
110
+
{
111
+
try
112
+
{
113
+
returnawaitWorkflowAffector.GreetClient(() =>
114
+
Task.FromResult(greeting));
115
+
}
116
+
catch (RepeatedOperationException<string>e)
117
+
{
118
+
returne.PreviousResponseParameter;
119
+
}
120
+
}
121
+
```
122
+
123
+
This is the explicit implementation of the effector interface's only method, that does nearly nothing. A normal grain can modify the grain's State, call other grain's operations or do nearly anything a normal grain method can.
124
+
125
+
The return value delegate executed when the workflow accepts the outgoing call's response.
Task.FromResult(string.IsNullOrEmpty(clientSaid) ?"Who are you?":"Hello!"));
131
+
```
132
+
133
+
And see the Workflow. It calls back the grain, and returns the response to the grain at the end.
134
+
135
+
136
+
137
+
That's all. Ctrl+F5, and it works.
138
+
139
+
## Details
140
+
141
+
If you want to dig deep into the source and understand the detailed events in the background, this sequence diagram can help (this is not a completely valid diagram, but displaying every asnyc details, even the AsyncAutoResetEvent idle-queue, this would be 2 times bigger).
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
0 commit comments