Working with XAF CRUD activities–Introduction

In this post we are going to explore the built in XAF CRUD activities beginning with how a workflow execution takes place.

The workflow server acts as a host for WorkflowServiceHost objects and a number of services. Services will perform every action needed in a very decoupled way. For example, there is a service that will read WorkFlowDefinitions, another that creates and starts a WorkflowServiceHost for each definition, another that will search for objects that match the WorkflowDefintions’ criteria and so on. Every 15 seconds the later service runs and if objects found it calls the service that can start the corresponding workflow. Note that only one workflow instance can be started for each found object. The following image is an Issue workflow definition taken from our Workflow demo. It will run for all Issues whose Active property is true.


However in the above image we see that Object Fits Criteria is not checked meaning that  this WorkFlowDefintion doesn’t provide StartWorkFlowConditions therefore this workflow will not start. In addition we can check Object Is Created and force the workflow to run instantly when a new Issue is created rather than after 15 sec. Moreover if a WorkFlowDefintion is not active will not start. You can activate a WorkFlowDefintion by executing the Activate action (next to refresh).

When working with workflows and persistent objects it is better to keep transactions short. For example, when reading data from a database, checking values, modifying, creating, deleting, committing changes and completing transactions. It is better to avoid continuous operations in the ObjectSpaceTransactionScope, because we are inside an XPO transaction. Since this is an atomic operation, workflow can not be persisted while workflow is inside the ObjectSpaceTransactionScope. If there is a need to use delays, especially within loops, consider placing them outside XAF’s container activities (NoPersistScope,ObjectSpaceTransactionScope).

Next we are going to examine how to create a workflow from scratch using the demo . The scenario is, creating a new Task when an active Issue is found and setting its subject by concatenating a fixed string with the issue subject.


Since we are going to create a new persistent object (Task) we have to use an ObjectSpaceTransactionScope as a container for our activities. After we create a new WorkflowDefinition a new 'targetObjectId' argument will automatically be created for it. We need to manage arguments only when we are creating a reused workflow definition and planning to call it manually. We have to leave the 'targetObjectId' argument unchanged if WorkflowDefinition instances will be started by the WorkflowServer.


The next step is to find the active Issue using the targetObjectId value and assign it as  Key to a GetObjectByKey activity.


However the Issue is being queried because we need to assign its subject to a Task object that will be create later. For this reason we need to define a variable that can hold it.


Variables in workflows are very much like the variables we are used to in imperative languages. They describe a named location for data to be stored and they follow certain scoping rules. Since we need the issue variable to be accessible from all activities inside the ObjectSpaceTransactionScope, we use this value in the Scope column.

The next step is to create the new Task object. Later the resultant Task will be used by other activities so we also need to create a variable to hold it.


In the final step we are going to use both ObjectSpaceTransactionScope variables - issue and task as defined in previous steps. A native WF Assign activity is dropped into the designer and uses to set the Task’s subject to an expression.


There is no need to commit the XPO transaction because by default, the ObjectSpaceTransactionScope activity commits all the changes at the end. However it is possible to control this behaviour by setting the AutoCommit attribute to false.



In the next post we are going to talk about “short transactions” inside a long running workflow and how to debug it.

Please free to ask any questions you might have and as always happy XAFing!

6 comment(s)
Thomas Wieser


found the "xaf workflow service" in the new menu. Think thats the better way for multiple (concurent) users.

Tried the Demo-Service (one service per user, like in the feature-center) in a Live enviorment and caught some Threading Exceptions... but i don't know why :(

1 June, 2011
Dan (DevExpress)


Thank you for the feedback!

Could you please contact our support team to elaborate on "Threading Exceptions" issues?

3 June, 2011
Willem de Vries

I don't understand this blog. Neither the title, nor the content. What background do you require from your readers? Do we have to open an example to be able to follow you?

I'm a newbie on the WF level, and this article does not bring me any further.

3 June, 2011
Apostolis Bekiaris (DevExpress)

@Willem de Vries

This post explains how and when the server will start a workflow. Additional you can see how to design a simple workflow and learn about internal classes and terminology. It is based on our WorkFlow demo so you can follow it easier. What parts you  do not understand?

5 June, 2011

While it comment is long too-late: what William refers to is that you place "CRUD" in the title, you don't explain the term, nor do you actually refer to it in the article in the context of the content you are attempting to explain.

Writing tech is difficult. De-evolving from a level of tech understanding to that place where explanations are created to help those not at the same level is a hard task.  

This is a great example of this in that there is no higher-level explanation as to WHY we are using WF, no real explanations unless you already understand the concepts.

I have stayed away from the WF arena until now, so i get what William was referring to. This comment is meant constructively btw  ;)

13 April, 2013
Warren Connors 4

I would echo the previous post. Writing tech is difficult. And writing DIFFICULT tech is even MORE difficult.

Drew hits the nail on the head when he states, "De-evolving from a level of tech understanding to that place where explanations are created to help those not at the same level is a hard task."

Stated another way, and drawing from my experience as a classroom computer science instructor teaching beginning programming classes at both community college and university level, an experienced software developer simply MUST be able to "time warp," or run their minds back in time to when they knew nothing about a particular subject, in order to be able to explain it in a way that absolute beginners who know nothing about that topic can understand it. Yes, there will always be one or two geniuses in any classroom (or group of developers) that just pick up on anything without much instruction or help and fly with it, but they are the exception. Most beginners to ANYthing, whether it is comp sci 101 or a particular topic that even an experienced software developer needs to learn from scratch, such as, oh, XAF workflow programming, need for the information to be presented from that perspective, rather than the way that I have observed DevExpress seems to, more often than not, try to explain things. In a way, unfortunately, that either seems to assume knowledge that the beginner does not have, or by referring them to generic documentation that, again, a genius might be able to use to figure something out, but MOST average developers (and I readily admit that I belong to that crowd) are NOT able to.

Now these comments are not a knock on this article in particular, as after already learning quite a bit about XAF workflow myself, I completely understand what Apostolis was trying to achieve in this post and it makes sense to me IN THAT CONTEXT (and as he stated).

However, to have the reaction to William of "what parts do you not understand" I found a little funny, because I can easily "time warp" myself back to about 5 months ago when I knew absolutely nothing about XAF workflow and my reaction to this blog would have been exactly like William's - complete non-understanding by virtue of the fact that what is discussed in this blog are a few selected topics in isolation from the very large overall topic that XAF workflow programming consists of.

Over decades as a software engineer/developer/architect and as a part-time comp sci instructor, it has become obvious to me that the most effective way to impart knowledge is to present the information from the beginning, in chronological sequence, leaving no details out. This is a process that naturally occurs in an actual instructor-led classroom when teaching something, but outside of that context, what is really needed (especially with software development / coding) is a video that shows exactly what someone is doing, step-by-step, in detail. Anything short of that, even fairly detailed written documentation, or even canned demo code solutions, can be lacking for many people (including, as I readily admit, me). And thus I have had much frustration with DevExpress documentation and support.

If you have a very complex subject, whether it is something like XAF workflow, or broader XAF application development in general, the MOST helpful learning tool for MOST beginners is always going to be a step-by-step, detailed video on the topic. Not some static documentation that may be useful as reference material but not very useful as learning material. And not tech support that just points you to that kind of documentation.

Now DevExpress has a bunch of videos on youtube, but in my experience most of those videos are either outdated or weren't that well done in the first place. What a software tools vendor needs to do, after having made available a very large and complex software tool product, is very simple. They just need to spend a few weeks with a group of people in a room, "time warping" themselves back in time to pretend that they know NOTHING about their product (or better yet, have a couple of software developer guinea pigs who DO actually know nothing about their tool, in the room), and come up with a "hit list" of the, say, 100 most commonly-asked questions or sources of befuddlement or most-commonly required techniques that a complete beginner to their product is going to come up with or not know how to do.

Then, make VIDEOS answering those questions and/or explaining EXACTLY how to accomplish those techniques. Clearly, concisely and plain as day, in a step-by-step, hyper-detailed fashion, right in the videos. As I've pointed out to DevExpress numerous times, if they only had a collection of videos like this, then they would be able to answer 80% of their support questions simply by referring to THOSE videos, rather than having all of those support questions a) make their own support personnel's lives miserable by having to continuously, until the end of time, muddle through trying to provide a not-so-great answer to most of those questions, and b) having customers get frustrated by being presented with those not-so-great answers (i.e., just being pointed to some general documentation rather than a specific answer to their specific question).

But hey, it's never too late, right? On an ongoing basis, an initiative could also be started at DevExpress such that when questions of that nature - recurring "befuddlement" type questions, many of which are on what are essentially (once you KNOW the answer, of course) very simple things - are asked, someone at DevExpress takes the time to make such a video on the topic and put it up on youtube.

One can dream :)

1 July, 2015

Please login or register to post comments.