Question

I have created a simple order manager wf service (state machine) in WF4.

Order (EF entity) properties: Id, IsExport, NumOfProduct, ProductName, Status (waiting, approved, rejected).

State machine states:
1. OrderReceived (validation -> response activity)
2. Waiting (empty)
– Transitions:
update(update order activity) -> waiting state
approve(assign status field, update order and response activities) -> final state
3. Final state.

Correlation key: Order.Id

The implementation rised a few questions.

1. WF can manage one flow of the order instance, the order flow and the order entity is in one-one relation.
   Question is that where and how should I implement the listing of entityes according to a state filter (eg. approved orders or waiting orders). The list should be accessible via WCF service method.

2. What is the best practise to manage the batch data processing. (eg: Multiple order approval. “Foreach” in the client is not the required sln.)

3. The state of the order is symbolized by the “state activity persisted instances” and the entity’s status field in the db as well.
   What is the best practise to decide the state of the entity, listing the active persisted activity instances in the defined state or select the entities from the db (by an activity) according to a state filter parameter?

Any help would be appreciated.

Answer 1

Good questions!

Taking your first and third questions, there are several possible approaches to this. All require that you write a custom WCF service to enumerate the required orders. This would probably not be a WF service; it might be a REST or OData service. How would you implement the service?

1. You could do it entirely by querying your database through EF. This would have no dependency on WF at all, and is probably the easiest way. Your workflow would update the database record on each state change, and the service would only need to read that value.

2. You could rely on the tracking mechanism provided by WF, and the extensions that Ron Jacobs refers to in his answer to your question. The tracking infrastructure is described here on MSDN. It is possible to use the tracking object in memory to get the state of active workflows. However, this probably won’t work well with IIS/WF services, which are automatically persisted and unloaded when dormant. You would be better off using the tracking facilities to write state records to a database. Your custom service would then just query this tracking database.

Unless you want comprehensive information about the state changes and updates that have occurred through your WF service, suggestion number one should suffice.

As for your second question, that is a little more complicated. Let’s say you write a REST service that lists the orders awaiting approval. You write a Web page that displays those orders, and the user can check the orders he wants to approve. Now, the number of workflows that you need to update is the same as the number of orders he approves.

You could, as you mention, call the Web service multiple times—but for a large number of orders that would be an unnecessary overhead.

What’s the alternative? You would need to write a custom service method on your non-WF service that takes an array of order ids. That service would have to call your WF service multiple times to update each one. Since the WF service is being called from another service on the same machine, you can use the .Net Named Pipe binding instead of one of the HTTP bindings so that the overhead is much less.

It’s worth noting that Entity Framework doesn’t support batched updates either. You’d need to write a stored procedure or custom SQL if you wanted the database update to be batched too.

Is all of this worth the effort? Probably! Using WCF and the named pipes binding is pretty standard with WF. You’ll need to configure Windows Activation Service for named pipes. Also, if you’re not already using AppFabric for Windows Server, have a look into it, because it adds some very good management tools for WF services.