State-Machine Workflow Part II

We have the following on the host app:

1. A service class that implements communication-service interface
2. The workflow runtime and its services which are instantiated and added respectively in the host app.

Service Class
The service class basically implements the communication-service interface, promising the interface that it understands which events the workflow would support and that it will raise them. For each of the events that is supported the service class just raises them. That's it!

Workflow Runtime
We come to the centre of the pizza! Workflow runtime is the actual component that hosts the workflow. In effect, it's the translator between the workflow and the rest of the world.

Many services can be registered while instantiating the runtime. Services for External Data Exchange, tracking etc (the list of services can be easily googled) are provided to add extra functionality to the bare-bone runtime. But it's very important to choose the services judiciously as a service without purpose brings down the performance.

State-Machine Workflow Part I

State-machine WorkflowThis dia helps me very nicely in understanding how to implement a state-machine workflow (which relies on external events). Let me see if I understand each of the components in the dia :)

Let us start with the workflow part and then move to the host application part (prob in the next post if this one becomes too long):

The workflow part has only a couple of things:

1. The workflow itself, and
   
2. An interface

The Interface
The interface, also sometimes called as communication-service interface, is used to tell the outer world as to what events the workflow would respond to. To elaborate on this, the workflow is expected to handle events that are generated from the host application. Hence the host app needs to know which events the workflow is prepared to handle or, in other words, what functionality is the workflow capable of handling. The same is exposed through a set of events. Essentially, it (the interface) is nothing more than a communication contract, which helps the host app to understand what events it can raise. The interface, at the minimum, is supposed to do two things:

• Is marked with ExternalDataExchange attribute: This attribute tells the WF that this interface should be used as a contract. A simple example would be:

[ExternalDataExchange]
public interface IAnalyzeNameService
{
event EventHandler AnalyzeName;
}

• Give a list of all the events that the workflow would respond to.

That's it on the interface end! Quite simple!

The Workflow
On the workflow end, in addition to the actual workflow that it would contain, it should also define the custom EventArgs that has been used while defining the event in the service interface. (One can consider this activity to be outside of workflow also. ) But there are few things that should be taken care of:

• It should inherit from ExternalDataEventArgs: Unless this is done the custom event args is not accepted. The obvious reason is that this pre-defined type has some information, like the instaced id, that needs to be propogated to the WF infrastructure to raise the event on the appropriate workflow instance.
• This class should be marked as serilizable: If this is not done, an EventDeliveryFailedException is thrown.
• InstanceID of the workflow instance should be passed (in addition to any custom info that would be required to be passed), for reasons mentioned already.
  

That does the job on the workflow side. There are a couple of things that should be done on the host app side and we are ready with a state-machine workflow running with the host app and the workflow communication in full flow.

Error loading workflow: Runtime capabilities are not available with this type

I just started-off with coding on workflows and the first error that I see:

I did quite a bit of googling but couldn't find any answer. Usually in these kind of errors, the error (written in blue) is given with link which would take the dev to the error line. But here the link doesn't work i.e. you don't go anywhere :)

So the resolution?
Well, just rebuild the whole application. And it works like magic. Now, what's going on here: The scenario was that we were two guys working on same code using TFS. He had checked-in code which was not properly building (he was infact in the middle of making some changes). Once he checked-in properly building code things started working properly.

Going Forward...

Long time that I've updated my blog. I was actually busy with a personal work and couldn't concentrate on this.

Well, as Shakespeare said, All is well that ends well, I'm now going to resume my blog. But going forward the posts would be relating to Windows Workflow Foundation (WF), Windows Communication Foudnation (WCF) and Windows Presentation Foundation (WPF) rather than just C#. Though the theme of the posts would be same, "Not So Obvious..."