What’s the difference between a Workflow tool and a BPM tool? or what´s the difference between a train and a car?

I’ve heard this  question (the first ) many times, and sometimes I have not heard the question but it looks like if the people who I am talking to would know the answer to this question other questions will not arise. Samples of this questions are:

• What’s the difference between Windows Workflow Foundation and AgilePoint?.
• What’s the difference between AgilePoint and X (replace X with the name of a whatever product developed before 2003 that now has been renamed to BPM and many products developed after this year that want to be in the BPM wave).

So let’s say what’s the difference in a few words:

Workflow->static->automation->developers->system to system

BPM->Process->flexible->Management->business users->user to user and user to system.

Workflow tools

Workflow tools were developed in 90’s (maybe the 80’s too) and were focused on task automation, used mainly by developers and usually manage interactions between systems.

The behavior of the workflow in runtime was predictable, that is, there is a defined path and you cannot change it, the workflow behavior is static at runtime.

This is usually associated to code, maybe automatic code generation, compilation and traditional development methodologies.

What happens when something must be changed because the business has changed? and what happens when the requirements change because processes are not well defined in the requirement phase?

We all know what happens… problems and more problems, the business users need a car and they get a train. Sometimes the train is really beautiful and really fast but unfortunately a train only runs on rails.

BPM Tools

Technically it was almost impossible to develop a BPM tool before the beginning of the XXI century, so I can not believe that a tool developed before is able to provide BPM functionalities, call me skeptic if you want.

In a BPM tool you do not run workflows you run PROCESSES, Business Processes, that is, processes that are understandable from the point of view of business and that meet the needs of business.

The behavior of a process sometimes is not predictable, sometimes people do not make their work, sometimes the applicant of a grant is the cousin of the CEO and no approval is required…

A BPM tool must manage this situations, when you travel by car, sometimes you want to lunch in a beautiful village near the motorway and go to see that incredible castle made in the XII century…, when you travel by train maybe you can see the village in the distance (if you are not in a tunnel).

Some people call it flexibility, other agility.

Agility must be available

Design time

Requirements change. Many times (in my experience, always) requirements change, new requirements are discovered when users see their processes running, the world changes, your competitor change,…

A BPM tool must allow t change processes easily and this changes must be welcome.

Run Time

Users make mistakes, cousins have uncles that are CEO’s and some people do not make their work, so the BPM tool must allow to manage this scenarios.

Process owners must be able to change the flow if they need to, they should be able to move a process forward or backward, they should be able to change the fure behavior of a process by migrating it to a new version…

Epilogue

If someone tries to sell you a car with iron wheels… think it twice before buying it.

Plaese, take a look at AgileXRM channel in Youtube, there are several incredible videos about integration between AgilePoint and Microsoft Dynamics CRM.

This integration is the best sample of what you can achieve with AgilePoint in terms of injecting BPM in an aplication.

AgilePoint extensions unit tests

Hi again,
After a few months resting I am here again with a new interesting blog entry :-).
I am going to spend a few entries to talk about unit testing your AgilePoint extensions (AgileParts and AgileWorks basically).
When I started developing AgileParts one of the things I realise, is how much time I wasted testing my code.
I had to create a process to test the AgilePart in Envision, deploy the process, attach to corresponding w3wp process, and then, I can debug.
Too much time wasted getting the AgilePart in context for debugging, there must be a better way to do this.

In the next entries I am going to show the process I followed to create a Unit Testing Framework for AgilePoint that have saved me much time.

This is a summary of what I considere that is needed to get this framework:

• Base test clasess for AgilePart and AgileWork tests.
• IWFApi implementation to be used as a mock class.
• IWFAdmin implementation (used in very specific implementations).
• An easy mechanism to set context process variables and AgileParts/Works parametrization to allow testing multiple scenarios.
• An extension of WFProcessInstance to be used as mock class in tests.
• Several code snippets to increase the speed of coding even more :-)

Once I have this, I can create a new Unit Test in Visual Studio for my AgileParts in a few seconds.

The basic idea is to provide a mechanism to run AgileParts and AgileWorks without running processes in AgilePoint Engine, creating mock classes that simulate the behavior of the engine.

This is the code I need to test an AgileWork using my framework:

[TestMethod]
public void TestAgileWork()

{

WFAdmMock myMock = new WFAdmMock();

api.RunAgileWork(CreateDescriptor(CreateDescriptorWork), typeof(DynamicParallelActivity), GetWFManualActivity, GetWFProcessInstance, GetManualWorkItems, WFEvent.ASSIGN_WORKITEM, myMock);

}

protected Ascentn.Workflow.Base.WFAgileWorkDescriptor CreateDescriptorWork()

{

DynamicParallelActivityDescriptor desc = new DynamicParallelActivityDescriptor();

desc.Participant = "xxx";

desc.Name = "name";

desc.ID = "Test";

desc.DisplayName = "TestDisplay";

NameValue[] nvs = new NameValue[2];

nvs[0] = new NameValue("Task1", "user1");

nvs[1] = new NameValue("Task2", "user2");

desc.WorkItems = nvs;

return desc;

}

As you can see, I do not work much to create a test.

If you are interested in this ... comments are welcome.

ClientData: How to configure UI behavior

Maybe yo have seen ClientData property in WFManualWorkItem class and you wonder what this property is for.

Well, let's take a look at WebForm AgileShape(AgileWork).

If you configure it it Envision, you can configure a URL (with context parameters), and you can configure the controls behavior, you can set if you want a control to be readonly, hidden,...

If you do that in a template and run the process, you can get the instance of the WFManualWorkItem in runtime and you will see that the content of ClientData property is the configuration that you have set in Envision.

Using the AgilePoint wep application template in Visual Studio you will see that controls behavior is applied automatically by the WFWorkSheetPage class.

So, what's the idea behind this?

Te idea is provide a mechanism to pass UI configuration from design time to UI runtime, this is the information flow:

• Designer sets UI configuration in Envision.
• This configuration is saved as AgileWork descriptor configuration.
• At runtime AgileWork takes configuration and (in an event where the WFManualWorkItem already exists, for example AssignWorkItem) the AgileWork writes the content of ClientData for each workitem.
• When the UI (in our sample the aspx page) is presented, the UI code retrieves the WFManualWorkItem(using the WorktemID) and applies the configuration that has been set at design time and written at runtime in AgilePoint server.

I think this is a powerful approach, don't you think so?

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.

Here again :-)
I was thinking about writing abou asynchronus AgileParts but I have found this AgilePoint blog where you can find a description of this functionality so I will write about another funtionality.

AgilePoint extensibility

First we are going to talk about AgilePoint extensions:

• AgilePart
• AgileWork
• AgileStub
• AgileConnector

Extensibility is the main advantage of AgilePoint so this is going to be the main issue in this blog, so if you are interested in out of the box functionalities do not waste your time her :-).

AgileParts

This is the first extension point that we are to talk about.

What is an AgilePart? is a method that the engine is going to call at runtime passing the parameters that you have gathered using the WFAgilePartDescriptor that you have created in the AgilePart project template in Visual Studio.

Easy :-), but what does it mean?

When you create an AgilePart project, you have 2 main classes, AgilePart and AgilePart descriptor.

Every method that you decorate with an WFAgilePartDescriptor is going to be exposed as an AgilePart in Envision and the WFAgilePartDescriptor is going to be exposed by Envision in the right side property grid to gather configuration from Business User .

When the engine arrives to the AgilePart at runtime, the method is called and you get the actual values of the configuration and you can do whatever you want with them.

So what is the approach AgilePoint have?

AgilePoint provides a mechanism to gather information from business users at design time and this configuration is used at run time to make technical stuff that AgileParts(and AgileWorks) isolate.

Stop reading for 10 miuntes and thik about it...

This is really powerful, you can use a standard and extensible interface, Visio and .Net, to get all configuration that you need for your runtime, and this configuration can be as user friendly as you can imagine, and you can use .Net platform at runtime to connect to other systems and run your technical stuff.

The key point here is expose your technical needs translatig them to user friendly language, for example if youare going to call to your ERP using whatever protocol and parameters,... that you need(as you can see I am not an expert in ERP systems :-)), the Business User's should not care about this technical needs, he should care about where to get the amount of his invoice, the name of the client,...

So your work as IT guy is provide the interface to configure this call to the ERP and the user at design time should not care if your ERP is SAP,Axapta a database or csv file, this is your responsability.