Thursday, December 1, 2011

You have changes? I have Workflow!

WF4 uses a service oriented architecture and as a result any problem can be decoupled into smaller, easily solvable and testable services. XAF uses MVC architecture which, in a sense, is very similar to that used by WF4. We can compare XAF’s controllers to WF4 services. Moreover XAF’s Application does the same job as the WF4 server. The upshot of all this is that users should be able to get the feel of WF4 in no time at all. The XAF workflow module introduces a new layer that makes the already decoupled services aware of our business classes. After this the sky is the limit and over the next few posts I aim to demonstrate some of what can be achieved. For example the next post will focus on creating an event driven workflow initialization engine.

To get back to today’s post, we will discuss an implementation that is very decoupled and as a result it has very limited dependencies on other modules. It is worth noting that all XAF’s features are decoupled, persistent objects take on the role of domain mappers.

Take these requirements;

  • an end user needs to be able to input an object type (and or) a property name,
  • an object change needs to start the workflow either at client or at sever,
  • workflows need to be aware of the object that has changed, its PropertyName and its property OldValue.

The custom workflow definition

We cannot use the default XAF XpoWorkFlowDefinition class in any way. This is because there are no fields to store the PropertyName and its OldValue. We should not even derive from the default XpoWorkFlowDefinition because we may face difficulties as this class is used by our workflow server. To cope with this issue it is necessary to create a custom ObjectChangedWorkflow definition as shown.


While we are doing this we also need to modify the default xaml of the workflow and add the two more arguments (propertyName, oldValue) as per our requirements.


Below you can see the UI of this custom workflow definition,


Up to here XAF has made things very straightforward for us. We have designed a normal persistent class to store our data and we have used attributes (PropertyEditorType, DataStourceProperty, TypeConverter etc) to configure the UI.

Registration of custom workflow definition

The next step is to register this custom workflow definition. To help with this task, eXpand, provides the WorkflowStartService<T> where T is the type of workflow. Furthermore for ObjectChangeWorkflow definitions the implementation is rather easy since there are no further requirements.

public class ObjectChangedWorkflowStartService : WorkflowStartService<ObjectChangedWorkflow> {

public ObjectChangedWorkflowStartService()

: base(TimeSpan.FromMinutes(1)) {


public ObjectChangedWorkflowStartService(TimeSpan requestsDetectionPeriod) : base(requestsDetectionPeriod) { }

protected override bool NeedToStartWorkflow(IObjectSpace objectSpace, ObjectChangedWorkflow workflow) {

return true;


protected override void AfterWorkFlowStarted(IObjectSpace objectSpace, ObjectChangedWorkflow workflow, Guid startWorkflow) {



Start workflow - Track Object Changes

Now, when I have registered workflows on the server, it's time to return to my task: start a workflow when a property has been changed.
In XAF, I can track changes with the help of the ObjectSpace.Committing and ObjectSpace.ObjectChanged events. However because we need to create only one request per object change, it is advisable to collect the changes in an array.

public class StartWorkflowOnObjectChangeController : ViewController<ObjectView> {

protected override void OnActivated() {


if (TypeHasWorkflows()) {

ObjectSpace.ObjectChanged += PopulateObjectChangedEventArgs;

ObjectSpace.Committing += StartWorkFlows;



void PopulateObjectChangedEventArgs(object sender, ObjectChangedEventArgs objectChangedEventArgs) {

if (!string.IsNullOrEmpty(objectChangedEventArgs.PropertyName)) {

var changedEventArgs = _objectChangedEventArgses.FirstOrDefault(args => args.Object == objectChangedEventArgs.Object && args.PropertyName == objectChangedEventArgs.PropertyName);

if (changedEventArgs != null) {


_objectChangedEventArgses.Add(new ObjectChangedEventArgs(changedEventArgs.Object, changedEventArgs.PropertyName, changedEventArgs.OldValue, objectChangedEventArgs.NewValue));

} else




void StartWorkFlow(ObjectChangedEventArgs objectChangedEventArgs, ObjectChangedWorkflow objectChangedWorkflow) {

var o = objectChangedEventArgs.Object;

ITypeInfo typeInfo = XafTypesInfo.Instance.FindTypeInfo(o.GetType());

object targetObjectKey = typeInfo.KeyMember.GetValue(o);

if (objectChangedWorkflow.ExecutionDomain == ExecutionDomain.Server) {

CreateServerRequest(objectChangedEventArgs, objectChangedWorkflow, targetObjectKey, typeInfo);

} else {

InvokeOnClient(objectChangedEventArgs, objectChangedWorkflow, targetObjectKey);



As you will have noticed we have not used the default VS naming for ObjectSpace event handlers. This is because the names that have chosen give a more specific idea of how each method works.

The ObjectChanged event occurs each time a property is changed and the changes are collected in the objectChangedEventArgses array. The Committing event occurs once changes are ready to be sent to the server and workflows start for each entry. We have introduced two options for starting and executing workflows;

  1. Execute synchronously and locally,
  2. Send a request to the server and execute at the server asynchronously

Execute a workflow synchronously on the client

The next stage is to create activities at the client then on ObjectSpace CommitChanges from appropriate WorkflowDefinition and execute them immediatelly

public class StartWorkflowOnObjectChangeController : ViewController<ObjectView> {

void InvokeOnClient(ObjectChangedEventArgs objectChangedEventArgs, ObjectChangedWorkflow objectChangedWorkflow, object targetObjectKey) {

Activity activity = ActivityXamlServices.Load(new StringReader(objectChangedWorkflow.Xaml));

var dictionary = ObjectChangedStartWorkflowService.Dictionary(targetObjectKey, objectChangedEventArgs.PropertyName, objectChangedEventArgs.OldValue);

WorkflowInvoker.Invoke(activity, dictionary);


This is a simple code which can be found in nearly any WF4 example at

Send a request to start workflow on the server

The second of our two methods involves starting the workflow at the server. Now we need to notify the server of the values of those arguments as well. In the manually starting workflows post we learnt that XAF does this by using XpoStartWorkflowRequest. This class has a different design however, and may create issues since it is used by XAF default services. Therefore instead of deriving from XpoStartWorkflowRequest we need to design a similar custom class.

public class ObjectChangedXpoStartWorkflowRequest : WFBaseObject, IObjectChangedWorkflowRequest {


public Type TargetObjectType {

get { return _targetObjectType; }

set { SetPropertyValue("TargetObjectType", ref _targetObjectType, value); }


#region IDCStartWorkflowRequest Members

public string TargetWorkflowUniqueId {

get { return GetPropertyValue<string>("TargetWorkflowUniqueId"); }

set { SetPropertyValue("TargetWorkflowUniqueId", value); }



public object TargetObjectKey {

get { return GetPropertyValue<object>("TargetObjectKey"); }

set { SetPropertyValue<object>("TargetObjectKey", value); }



#region IObjectChangedWorkflowRequest Members

public string PropertyName {

get { return _propertyName; }

set { SetPropertyValue("PropertyName", ref _propertyName, value); }




public object OldValue {

get { return _oldValue; }

set { SetPropertyValue("OldValue", ref _oldValue, value); }


This is a very simple class, its only role is to store values in the database. Now instead of invoking workflows locally we only need to create ObjectChangedXpoStartWorkflowRequest objects.

public class StartWorkflowOnObjectChangeController : ViewController<ObjectView> {

void CreateServerRequest(ObjectChangedEventArgs objectChangedEventArgs, ObjectChangedWorkflow objectChangedWorkflow, object targetObjectKey, ITypeInfo typeInfo) {

var request = ObjectSpace.CreateObject<ObjectChangedXpoStartWorkflowRequest>();

request.TargetWorkflowUniqueId = objectChangedWorkflow.GetUniqueId();

request.TargetObjectType = typeInfo.Type;

request.TargetObjectKey = targetObjectKey;

request.PropertyName = objectChangedEventArgs.PropertyName;

request.OldValue = GetOldValue(objectChangedEventArgs);


In the next step we are going to create a service to consume these values from the server and start a workflow,

public class StartWorkflowOnObjectChangeService : BaseTimerService {

public override void OnTimer() {

using (var objectSpace = ObjectSpaceProvider.CreateObjectSpace()) {

//get all requests from the database

foreach (var request in objectSpace.GetObjects<ObjectChangedXpoStartWorkflowRequest>()) {

//find workflow

var definition = GetService<IWorkflowDefinitionProvider>().FindDefinition(request.TargetWorkflowUniqueId);

if (definition != null && definition.CanOpenHost) {

//Start the workflow passing in PropertyName && OldValue

if (GetService<ObjectChangedStartWorkflowService>().StartWorkflow(definition.Name,

request.TargetWorkflowUniqueId, request.TargetObjectKey, request.PropertyName, request.OldValue)) {








At this point our server has all the information it needs to start workflows with arguments taken from persistent ObjectChangeXpoStartWorkFlowRequest objects.

I must admit that I have fully enjoyed preparing this post. The decoupled development experienced offered by the WF service oriented model is something that really appeals to me. At the same time XAF’s workflow module implementation made modeling the requirements a simple and enjoyable process. As usual it was possible to work directly on the problem and leave the hard work to non XAF developers.

Subscribe to XAF feed
Subscribe to community feed



Post a Comment