Creating an Automated Purchase Order Workflow Using BizTalk Server 2004

• Download source files - 25.4 KB

Introduction

This article shows how BizTalk can be used to automate workflows which do not require human intervention. A message can be routed to various users based just on business logic. This is similar to a state machine wherein a system moves through several states/stages based on external inputs/stimuli. For user oriented workflows, BizTalk Human Workflow Services (HWS) can be used.

Purchase Order (PO) - Workflow

Consider a scenario where a Purchase Order (PO) request needs to be approved by various people in an organization before it can be sent to the procurement department. Let's consider three roles in an organization where the PO Workflow happens: a Clerk, Supervisor, and a Manager.

• Clerk - Processes a PO request and sends it to the Supervisor for approval.
• Supervisor - If a Supervisor does not have enough rights to approve a PO, the PO is sent to the Manager. A Supervisor may also send back a PO to the Clerk for corrections.
• Manager - The Manager approves or rejects a PO based on certain rules. He may also send back a PO to the Clerk.

Various <STATES> in the PO Workflow

The Purchase Order (PO) - Schema

The PO schema has the following elements:

• PONum - This field is used to set the Purchase Order number.
• POAmount - This field is used to set the Purchase Order value.
• POStatus - This field is used to set the Status of the PO.
• PODate - This field is used to set the date on which the PO was created.
• POQty - This field is used to set the total quantity in the PO request.
• POAuthorize - The role (Clerk, Supervisor, or Manager) of the person who authorized the PO request.
• POComments - This field is used to set the comments by various parties in the workflow.

The Purchase Order Workflow - Orchestrations

"CREATE" message - Business Process

This Orchestration sets the status of the incoming message from "CREATE" to "LEVEL_0". The Send Port is bound directly to the message box and hence it automatically triggers a Clerk Orchestration which is filtered on "LEVEL_0" status messages.

Clerk - Business Process

This Orchestration sets the POStatus of the incoming message from "LEVEL_0" to "LEVEL_1". It checks the POAuthorize field of the message, and if it is "SUPERVISOR", it fills in the POComments property.

POOut = POIn;
POOut(POWorkflow.PropertySchema.POStatus) = "LEVEL_1";
POOut(POWorkflow.PropertySchema.POAuthorize) = "CLERK";
POOut(POWorkflow.PropertySchema.POComments) = "Supervisor! Please approve this PO.";

If the POAuthorize field contains "MANAGER", then the POQty field is set to "99". The reason being, a manager will not approve a PO with a POQty value of "100".

POOut = POIn;
POOut(POWorkflow.PropertySchema.POStatus) = "LEVEL_1";
POOut(POWorkflow.PropertySchema.POAuthorize) = "CLERK";
// The quantity is set 99, so as to get Approval from Manager.
POOut(POWorkflow.PropertySchema.POQty) = 99;
POOut(POWorkflow.PropertySchema.POComments) = 
      "The quantity is set 99, so as to get Approval from Manager";

The Receive Port and Send Port are bound directly to the message box, and hence automatically triggers a Supervisor orchestration which is filtered on "LEVEL_1" status messages.

Supervisor - Business Process

This Orchestration sets the POStatus of the incoming message from "LEVEL_1" to "LEVEL_2", or "APPROVED", or "REJECTED". The Supervisor checks several conditions and updates the POStatus property accordingly.

POOut = POIn;
// Send the message to Manager for Approval.
POOut(POWorkflow.PropertySchema.POStatus) = "LEVEL_2";
POOut(POWorkflow.PropertySchema.POAuthorize) = "SUPERVISOR";
POOut(POWorkflow.PropertySchema.POComments) = "Manager, please approve this PO.";

The Receive Port and Send Port are bound directly to the message box and hence automatically triggers a Manager/Clerk Orchestration.

Manager - Business Process

This Orchestration sets the POStatus of the incoming message from "LEVEL_2" to "LEVEL_0", or "APPROVED", or "REJECTED". The manager checks several conditions and updates the POStatus property accordingly. If the POAmount value exceeds $5000, POStatus is set to "REJECTED".

POOut = POIn;
POOut(POWorkflow.PropertySchema.POStatus) = "REJECTED";
POOut(POWorkflow.PropertySchema.POAuthorize) = "MANAGER";
POOut(POWorkflow.PropertySchema.POComments) = "Rejected due to cost overrun.";

The Filter Expression

The "Filter Expression" property in the "Receive" shape in every orchestration ensures that only messages which are intended to be processed arrive in the orchestration.

Clerk Orchestration - Filter Expression:

(POWorkflow.PropertySchema.POStatus == "LEVEL_0")

Supervisor Orchestration - Filter Expression:

(POWorkflow.PropertySchema.POStatus == "LEVEL_1")

Manager Orchestration - Filter Expression:

(POWorkflow.PropertySchema.POStatus == "LEVEL_2")

Executing the Demo

Input File

Notice the input file data. POComments is left as blank so as to route the message back to the Clerk from the Supervisor. The value of POAmount is more than $1000, which enables the message to flow into the Manager Orchestration. The POQty value is greater than 100. This will again send the message back to the "Clerk", and then to "Supervisor", and finally get it approved by the "Manager". This data in the input file covers most of the flows.

Event Viewer

The Event Viewer shows the various logged messages during the routing of the POMessage for the scenario just described.

BizTalk Explorer

Notice the Send and Receive Ports in the BizTalk Explorer.

Output File

The final approved output file is generated after the "Manager" approves the POMessage.

About the Downloadable Code

• Unzip the file with the folder names in the C:\ drive.
• The folder KeyAndBindings contains the Bindings.xml file, which can be imported after the solution is built and deployed.
• Place the POMessage in the In folder and observe the event log to find out where the message is getting routed to.

Some Takeaways

1. Using BizTalk workflows can be automated extensively. The example shown can be extended and customized. All the business rules can be placed in a separate DLL and placed in the GAC. This DLL can be updated independently of the Orchestration.
2. This article has demonstrated how a workflow can be automated using Message Routing. More complex scenarios can be implemented using BizTalk.
3. The PO approval logic of the Manager, Supervisor, and the Clerk can be moved into a .NET component which can include several processing rules instead of just simple ones. This example can act as a Proof-Of-Concept for complex scenarios; it also demonstrates the power of "DIRECT" message box binding.
4. In the case of a decision to be made by Human, InfoPath can be used to display the XML documents, and messages would need to be placed in a shared folder.