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:
- The workflow itself, and
- An 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:
public interface IAnalyzeNameService
- Give a list of all the events that the workflow would respond to.
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.