AgileWorks

Today I am going to spend a dew minutus talking about AgileWorks.
What is an AgileWork?
An AgileWork is made, basically, by 2 classes, one for runtime(the class that inherit from AgileWork) and one for design time, the class that inherits from WFAgileWorkDescriptor.

If you create an AgileWork project in Visula Studio you will see this two classes.

Once you have them you can start creating your AgileWork :-).

The design time time class has similar funtionalities to the corresponding AgilePart descriptor but the runtiome class has much more functionalities.

The main purpose of an AgileWork is to be used in manual task, that is,when the process has human interaction, but in theory you should use an AgileWork when you want to subscribe to events at runtime.

There is a list of events you can subscribe to:

• Enter activity instance.
• Leave Activity Instance.
• Assign WorkItem
• Complete WorkItem
• ...

Let's say that we want to get the user assigned to a task at runtime.

This can be easily achieved by siubscribing to EnterActivityInstance and changing the value of the participants field.

I will provide sample code in next entries.

For me, the best idea behind AgileWorks is the fact that you can have several WorkItems in one activity. You can assign multiple tasks and the process drawing has only one shape for this step.

That is what Parallel Approval (and others) shape does, it creates several workitems(one for each user) when the engine arrives to this activity. With this approach the drawing is easier to understand.

The same idea is applied when you assign a task to several users, when you configure a manuall task to be assigned to "user1;user2;user3" three workitems are created.

This is the first entry where I talk about events inside AgilePoint, but this issue will need a monographic :-), there are many places in AgilePoint where you can handel engine events. AgileWorks, AgileStub, AgileConnector,...

You can have complete control over the behavior of the engine. You just need coding.