I have been a BizTalk developer sometime back. I used it for one of the large B2B pilots that we did couple of years back. Obviously, I was curious to learn about WWF and figure out when and where to use it.

Yesterday I presented a quick intro on WWF at MUGH User Group Meet here at Hyderabad.

I want to explain this technology the way I understand it. I hope this helps some of you who are confused even after reading some intro articles on MSDN.

Many of us write enterprise applications that has complex business logic. This business logic will obviously have a decent chunk of code that contains some conditional branching.

Think of a scenario where an employee places an internal order for a new notebook computer. The system has to check if the employee is a full time employee before it sends a notification to the manager for his approval.

After the approval process completes, it then goes onto checking the internal inventory for that specific product.If the internal stock is empty, the system goes about generating a PO and calls a Web Service to place an order with the vendor. Then it waits till the Web Service sends an acknowledgment with the order confirmation number and a tentative date of shipping. The process is completed by sending a mail to the employee with the acknowledgment details.

Let’s translate the above scenario into a pseudo code.

public void PlaceOrder(Employee e, Product p)

{

   if(e.FTE)

   {

       if (GetManagerApproval(e,p))

       {

           Inventory i=InventoryServiceProxy.GetInventory(P.ProductID);

          if(!i.InStock)

           {

              PurchaseOrder PO=new PurchaseOrder(p,1);

              OrderAck Ack=OrderServiceProxy.SendPO(PO);

              SendMail(“Placed New Order”,”Order #” + Ack.OrderNo +” Expected on ” + ACK.ShipDate, e.EmailID);

           }

        }      

     }

     // Rest of the code goes here

}

While the above scenario looks very normal and the code looks very familiar, think of some of the possible issues that may crop up over a period of time.

• The company wants to allow even interns to place a new order.
• The approval process now involves a procurement manager’s approval even before the employee’s manager approves it.
• With the vendor providing local ware houses at each city, the company wants to do away with local inventory maintenance and wants to directly check with the vendor’s nearest warehouse.
• For some strange reasons, the acknowledgement also needs to be sent as a SMS or IM alert to the employee.

Unfortunately, our code has no capability to adapt to these requirements and align itself with the changing business requirements. Ideally we should isolate this kind of branching from core business logic.

We should let an analyst or a business manager define and re-define this kind of branching. Actually this perfectly qualifies to be a Workflow. The business logic should have ‘hooks’ to these workflows that run outside of the context of the core business logic. Whenever the workflow needs to be executed, the biz logic should invoke the current workflow definition either synchronously or asynchronously based on the scenario.

WWF efficiently lets a developer convert the decision branching part of the code into an independent and insulated workflow entity from the core business logic.

Using the intuitive designer, any business decision maker can alter the workflow and persist it back into the system. The cool thing about WWF is that the workflow designer can be shipped with your app that runs independent of Visual Studio.  

As I first mentioned in post, this is my initial understanding of WWF. If you feel I am inaccurate in conveying some of the points, drop a comment and I will be glad to go back to do my homework J