BizTalk 2004
Automate Your Business Processes with Human Workflow Services and Visual Studio
Chris Whytock
This article discusses:
- The new knowledge worker features in BizTalk Server 2004
- Human Workflow Services (HWS)
- Developing and customizing actions
- Creating and executing a business process in HWS
|
This article uses the following technologies:
BizTalk Server, Visual Studio, C#
|
Code download available at:
HumanWorkflowServices.exe
(1,118 KB)
Browse the Code Online
Contents
In February of this year, Microsoft released the latest version of its BizTalk® server software, BizTalk Server 2004. BizTalk is the Enterprise Application Integration (EAI) tool that enables businesses to connect their diverse applications and graphically define processes that use the services provided by those applications. This enables a business to automate processes that involve multiple software applications and gain all the benefits that process automation provides, such as consistent processing, audit trails and speed and efficiency improvements.
The latest version of BizTalk adds features such as user-configurable business rule support, Business Activity Monitoring to provide increased insight into processes, and Business Activity Services to help manage interactions with trading partners.
BizTalk Server is an excellent platform for automating B2B and EAI workflows. Process-driven workflows send messages between machines and access data. It's the process, not a person, that decides what happens next. Until now, such processes were very difficult to automate using BizTalk Server. Now, with the introduction of Human Workflow Services (HWS) in BizTalk Server 2004, this class of workflow automation is a very real possibility.
Workflow Problem: The Interview Process
Every company has some type of interview process. This procedure usually requires coordination and communication of information between many people, some of whom are not privy to the overall process. Using HWS to model this process, participants are guided by the system to perform the correct steps in the correct order. This predefined process may be dynamically modified at run time to account for any of the one-off irregularities that typically occur in any human-driven process. Every time the process is run, all information relating to that run of the process will be stored for later retrieval for statistical analysis or legal documentation.
Create a Process Model
Let's explore the steps needed to automate this process. First you need to model your process—break it down into steps and then figure out what type of activities are involved in each step and which users or user types will be involved in each. A typical interview process probably starts with a recruiter choosing a candidate, deciding which job in the company the candidate fits, and assigning the candidate to an assistant. The assistant would then contact the candidate to verify his interest in the position, after which the hiring manager would be notified that a candidate is in the pipeline. Next, the candidate would be screened by a phone interviewer. Following the screening, the assistant would schedule an interview with the candidate and set up a set of interviewers to participate. Feedback from each of the regular interviewers will be collected at some point, and if the candidate passes those interviews, the applicant proceeds to the final interview with the hiring manager. Figure 1 shows a diagram representing the workflow of the interview process.
.gif)
Figure 1 The Interview Process
Basic Concepts of Human Workflow Services
As the interview example reveals, business processes are simply an ordering of disparate activities. The two main HWS objects used to create business processes are activity flows, which are individual instances of one business process or another, and actions, which are the disparate activities added to activity flows in order to perform one of the disparate activities in the process. In HWS, to indicate the next step in a process, actions are added to activity flows by human participants. The result is a workflow that represents a human-driven process.
In addition to actions and activity flows, HWS introduces the concept of a task. A task is a message sent from an action to a human participant in the process. The message can be anything, such as a notification that a certain activity has occurred or an instruction telling the person to perform the next step in the process. Once a person receives a task, the person can either respond to the task, add a new action to the activity flow after the task, or both. HWS does not restrict the form a task message takes; it could be e-mail, a Windows® SharePoint® Services task, or even an instant message through MSN® Messenger.
Here's how business processes in HWS work. First, an activity flow is created by starting an action. Second, that action sends out one or more task messages to users of the system. Third, those users can either respond to those task messages or add new actions to the activity flow, after which the business process continues as more and more of these actions are activated in the process over time.
Creating the Actions
Since an activity flow is created by instantiating one or more actions, you must first populate your system with the set of actions required to complete your business process before you can create the activity flow for that process. At first glance, you might think that since the interview process described earlier has a dozen steps, you'll need to write twelve actions. You could certainly do that, but then each process you want to automate would come at a relatively high price.
Actually, a number of the steps involve the same basic activity performed in slightly different ways. For example, the actions of assigning the candidate to an assistant and notifying a phone interviewer that they must conduct an interview are both simply communicating a message to a single user. In fact, there are only three different types of generic actions required to perform the interview process: a Communicate action, which notifies one or more users about something (in Figure 1 those are the steps in purple); an Approval action, which will poll one or more users for a positive or negative answer to a question and collect feedback (red steps in Figure 1); and a Routing action, which will automatically make a branch decision based on what happened in the past (orange steps in Figure 1). Notice that the "Does the candidate fit?" question is not actually a step. This is a human decision which will have to be made by the recruiting assistant after the phone interview feedback since many factors that are not easily quantified (such as how badly the company needs the position filled and the estimation of the phone interviewer) will affect the decision.
Assuming this is the first Human Workflow Services procedure developed for the company, you will have to create each of these particular actions from the beginning. By developing generic rather than specific actions, the more processes you end up automating using Human Workflow Services, the more you'll find that you already have actions defined that will perform most of the activities in the new process.
Developing the Approval Action
The first thing you need to do when developing an action is design the message schemas that the action will use to both send and receive task messages. HWS has defined three extensible schemas for the three types of messages that actions will use: the Activate schema, which defines the message that will start the action; the Task schema, which defines the form of the task messages sent to the user; and the Synchronize schema, which defines how one action talks to the next action in the workflow. Looking at the interview process, you can see that the Approval action will require two different tasks: one task to communicate the issue to the users evaluating the issue and another task to notify a user of the end result of the Approval action.
To create the Approval action through Visual Studio®, you need to create a new BizTalk project using the Human Workflow Project template. Since you need two different task schemas, you need to replicate the original task schema. The easiest way to do this is to make a copy of the file in the file system and then add the copy file as an existing item to your project. This is easier than the manual approach since each HWS schema contains a number of required HWS fields that would need to be replicated.
Now you need to edit the ActionSection of each of the schemas. The ActionSection is the user-defined section of each HWS message type, which is where the designer can add any elements that are required for the action. Since the Approval action needs to send the text of an issue for approval to multiple users, in the activate schema you add four items: a string element for the issue to be evaluated; an unbounded element for the users who will be evaluating the issue; an integer field for the percentage of approvers who must approve the issue; and an element to identify the user who receives the final answer. Your ActionSection will then look like Figure 2. For the task messages, in the first type that communicates the issue, you add an element for the issue text, the user who will approve the issue, an approval field, and a comments field. In the summary task message, you add the issue field, a summary target field, a field for all comments submitted by the approvers, and finally a field for the final approval answer. One important requirement of task messages is that they carry data to and from the user. This is why you have the approval field built into the first task message schema—so that the user can send their approval decision back to the action.
.gif)
Figure 2 ActionSection
Now you need to add the logic to the action orchestration. Every action created from the HWS action project template contains a scope named ScopeAllActionSpecificLogic. All action-specific logic should be inserted within this scope. The Approval action should next perform three stages: send out all the messages to request approval decisions, wait until it receives completed responses for each message, then compose a summary message and send that out. If you examine the ApprovalAction.odx file, you can see these stages occur in the Send_Approval_Requests scope, the Collect_Responses_Loop while loop, and the Send_Summary_Task scope.
Once the action logic has been developed, three more steps are required to access the action in HWS. First, like all orchestrations, the action must be deployed, enlisted, and started in BizTalk. Next, you will need to register the action with HWS using the HWS admin console. Finally, you must add a constraint to the HWS system to allow your users to activate the action. The final two steps are explained in detail in the BizTalk Server 2004 help files, under the "Enabling an Action for Use in Human Workflow Services" topic, and the first step is covered under the "Managing Orchestrations" topic.
Developing the Communicate and Routing Actions
If you examine the CommunicateAction project in the sample code, you'll see that the messages and action logic of the communicate action is similar to Approval. The code and schemas should be mostly self-explanatory. The routing action, though, is very different. Due to the complex nature of the behavior that the action needs to implement, there would be no easy way to implement the logic using orchestration shapes. The only option left was to write code to implement the action logic and have the orchestration call out into the code to perform its logic. You can see the code in the RouteActionLogic project (specifically the RouteActionLogic.cs file), which at a high level reads a specific value from the sync message received and performs one of the actions encoded in the activate message based on the value. Either method of implementing action logic can be used; however, orchestration shapes are usually much easier for other developers to understand.
Customizing Actions for Your Environment
You may notice that all the actions in the sample code send out rather generic XML messages through their ports. How do these messages make it to the users? The answer is by using the BizTalk pipeline system. Pipelines are designed to shape and transmit the XML messages from an orchestration into meaningful data for the user. This allows for an elegant separation of delivery logic from orchestration logic, making the action orchestration even more reusable. For more detail see the "Processing Messages: Pipelines" topic in the BizTalk documentation. A sample customized pipeline is included in the code download for this article. You can find custom pipelines in both the ApprovalAction and CommunicateAction projects (the .btp files). The bulk of the work these pipelines perform is done by the custom pipeline component created in the SMTPPipelineComponent project. This is a highly configurable component that will process a message, translate the usernames of the targets in Active Directory®, and send out e-mail versions of the message via the .NET SMTP library.
Another benefit of generically designed actions is that by simply writing a new pipeline component, I can change the way I communicate tasks to users from the current AD/e-mail-based notification medium to Windows SharePoint Services tasks or even a Word document on a public share.
Dynamically Creating the Interview Workflow
Now that the actions required for our interview process have been created and added to the system, it is possible to execute the process using what HWS calls ad hoc composition. In HWS, the simplest way to execute a business process is to have the participants in the process dynamically build the process. For the interview process, the recruiter starts a new process and initiates a communication action that directs the assistant to contact the candidate; then the assistant would initiate an approval action to instruct the phone screener to conduct an interview and submit feedback, and so on.
Ad hoc processes are composed in HWS through the HWS Web service. At each stage in the process, the user would call the Web service to retrieve the list of possible actions he or she could initiate, then format the activation message for the desired action and add a new instance of that action to the activity flow. The code for initiating the first step of the interview process this way is shown in the C# sample in Figure 3.
Figure 3 Initiating the Ad Hoc Interview Process
Hws.HwsService hws = new Hws.HwsService();
hws.Credentials = CredentialCache.DefaultCredentials;
Guid interviewProcessId = Guid.Empty;
interviewProcessId = hws.GetNewActivityFlowID();
Hws.Activity[] activities = hws.GetActivityList(interviewProcessId,
Guid.Empty, Guid.Empty, "", null);
Hws.Activity communicateAction = null;
foreach( Hws.Activity activity in activities )
{
if( activity.Name == "Communicate" )
communicateAction = activity;
}
Hws.ActionParameters parameters = hws.GetActionParameters(
communicateAction.ActionTypeID, null);
XmlDocument activateMsg = new XmlDocument();
activateMsg.Load(new FileStream("CommunicateAction_Activate.xml",
FileMode.Open));
activateMsg.SelectSingleNode("//ActionSection/MessageBody").InnerText =
"Please contact Bob Smith (bsmith@hotmail.com) regarding job# 1145";
activateMsg.SelectSingleNode("//ActionSection/Subject").InnerText =
"Contact Candidate";
activateMsg.SelectSingleNode("//ActionSection/Target").InnerText =
@"Domain\username";
activateMsg.SelectSingleNode("//ActionSection/ExpectResponse").InnerText
= "false";
parameters.ParametersDoc = activateMsg.OuterXml;
hws.AddActionToActivityFlow(interviewProcessId, Guid.Empty,
Guid.Empty, false, parameters, null);
The benefit of ad hoc workflows is that you can get them up and running quickly and easily after developing the requisite actions. This can shorten the development time required for automating a given process, and it can also be used for trying various process configurations. The caveat is that the process is completely defined by the participants. In some processes, this may be a benefit or even a requirement. Certain processes demand a more rigid structure that the participants should not be able to alter. HWS also supports such predefined workflows.
Creating a Predefined Interview Workflow
In HWS, a predefined workflow is referred to as an activity model. Activity models provide a way to structure a workflow prior to execution, and serve up other features such as default parameters and advanced transitions not available in an ad hoc workflow. The basic building blocks of an activity model are steps and transitions, each of which is a class type in the activity model designer API. The API can be found in the Microsoft.BizTalk.Hws.ActivityModelDesignerAPI assembly in the Developer Tools directory of your BizTalk installation. Constructing a workflow can be as simple as creating two-step objects and connecting them with a transition object, as shown in Figure 4. To create more complex workflows, you repeat the same logic, first creating one or more steps, and then connecting those new steps with transitions to steps that are already part of the activity model. This logic can be seen in the creation of the interview activity model, in the AMCreationTool.cs file. There are a few extra features available from the designer API exploited in the creation of the interview activity model, which can enhance a workflow.
Figure 4 Constructing a Workflow
DesignManager dm = new DesignManager();
dm.Connect(System.Environment.MachineName, "BizTalkHwsDb");
ActivityModel interviewProcess;
designManager.CreateActivityModel(out interviewProcess);
Step rootStep;
interviewProcess.AddStep(ActionId, out rootStep);
Step childStep = null;
interviewProcess.AddStep(ActionId, out childStep);
Transition transition;
interviewProcess.AddTransition(
rootStep.Id, childStep.Id, false, "", "", out transition);
Default Parameters
Generic actions usually require more runtime parameters to fine-tune their functionality to the situation. Requiring the user or client surface to supply all those parameters can be cumbersome, as you saw in the previous ad hoc workflow. To alleviate the burden, HWS allows you to specify default values for some or all of a step's parameters at design time. If you refer to the InterviewProcessCreationApp.cs file in the download, you will find sections of code which set up the default parameters for each step of the process.
// Add a transition from the "Contact Candidate" step to the "Conduct
// Phone Interview" step. Use the schema of the summary task to make
// sure the next step can only be performed when the summary is sent out.
interviewProcess.AddTransition(
contactCandidate.Id, phoneInterview.Id, false,
"http://tempuri.org/CommunicateAction_PrimaryTask", "",
out newTransition);
When the user asks the HWS Web service for the parameters for this step (via the GetActivityModelParameters method), the ParametersDoc property of the return ActionParameters structure will be pre-populated with an XML string containing the parameter values supplied at design time. The only information this user will need to supply is the ID of the target user and a URL string to substitute for the "{0}" marker in the MessageBody property.
Loop Transitions
In many processes, certain steps may be rerun. In our interview process, a problem may occur when the candidate chooses an interview day that not enough interviewers can commit to. To account for this, the process contains a loop transition from the Schedule Group Interview step back to the Schedule Interview with Candidate step.
Once you have a complete activity model, the final steps are to supply the Name and Description fields of the ActivityModel class instance you've created, and then upload the activity model to your HWS system through the SaveActivityModelToSystem method on the DesignManager class.
Putting It All Together
Now that you have a complete activity model uploaded to your HWS system, it's time to put it to use. The sample code for this article includes a fully functional UI front end for the interview process activity model. It begins with the Interview Process Kickoff Tool, a Windows Forms-based app that initiates an interview process. From then on, all participants in the process interact via the various Web Forms supplied by the InterviewWebApp project. Most of the code in these apps is pretty straightforward. While they are all tailored to one specific action or another, each follows the same basic logic, shown in Figure 5.
Figure 5 Web Form Logic
_HwsService = new Hws.HwsService();
_HwsService.Credentials = CredentialCache.DefaultCredentials;
Task[] tasks = null;
TaskFilter filter = new TaskFilter();
filter.StartTimeEnd = DateTime.MaxValue;
filter.StartTimeStart = DateTime.MinValue;
//Discover tasks assigned to the user
tasks = _HwsService.GetAllTasksForUser(filter, candidateEmail);
Activity[] activities = null;
activities = _HwsService.GetActivityList(tasks[0].ActivityFlowID,
tasks[0].ActionInstanceID, tasks[0].TaskID, null, null);
XmlDocument taskXml = new XmlDocument();
//Pick an activity and query HWS for params
taskXml.LoadXml(_HwsService.GetTaskMessage(tasks[0].TaskID, null));
Guid _ActivityModelInstanceId = new Guid(taskXml.SelectSingleNode(
@"//HwsSection/ActivityModelInstanceId").InnerText);
Guid _PartentActionInstanceId = new Guid(taskXml.SelectSingleNode(
@"//HwsSection/ActionInstanceId").InnerText);
//Populate the parameter list
ActionParameters[] _Parameters = _HwsService.GetActivityModelParameters(
activities[0].ActivityModelTypeID, activities[0].ActivationBlockID,
null);
XmlDocument paramsXml = new XmlDocument();
paramsXml.LoadXml(_Parameters[0].ParametersDoc);
paramsXml.SelectSingleNode(
@"//ActionSection/Issue").InnerText = "My Issue";
paramsXml.SelectSingleNode(
@"//ActionSection/SummaryTarget").InnerText = "User1";
_Parameters[0].ParametersDoc = paramsXml.InnerXml;
//Activate the Web service
_HwsService.AddActivationBlockToActivityFlow(tasks[0].ActivityFlowId,
ActivityModelInstanceId, ParentActionInstanceId, tasks[0].TaskID,
false, _Parameters, null);
The logic at the client site mainly consists of querying the HWS Web service to see what the current user can do and discovering any tasks assigned to the user; picking one of the activities and querying the HWS service for the parameters; populating the parameters that do not provide defaults or overriding those defaults; and finally activating the activity via the Web service. One of the nice features of HWS, as you can see, is that workflows become discoverable. There's no need for a user to keep track of a specific message that told them to do something, since their client UI can ask the HWS system for any information they require.
Next Steps
Now that you have a fully functioning automated interview process, where do you go from here? You really can see the power of the reusable actions created in developing the interview process activity model. Consider if you now wanted to model an expense report approval process in your company, having seen the cost savings that the automated interview process has brought. A basic expense approval process would send the expense report to a manager for approval, the manager would approve, and then send the expense report to accounting for approval. Accounting would then send an e-mail notifying the original submitter of the result and then the funds would appear in his or her paycheck.
While this doesn't resemble the interview process you just created, the steps in the expense process do closely resemble the generic actions you have already created. It would be rather trivial to assemble a new and completely different activity model that is based on the expense report process using the already existing actions. The most difficult part of the process is complete; all you need to do now is compose the activity model and create a UI front end to guide the user. Since the HWS Web service provides a discovery mechanism, you could design a generic UI to automatically handle any new activity models you introduce to your system.
Conclusion
This article has outlined the capabilities of the new Human Workflow Services feature in BizTalk Server 2004. HWS provides a flexible, reusable surface for automating predefined workflows, creating ad hoc workflows, and automatically tracking them at run time. Taking advantage of these new features in BizTalk Server 2004, you will be able to regulate many processes you could not have previously, and will be able to track each process efficiently.
Chris Whytock is a developer for the Microsoft E-Business Servers team. Hailing from Halifax, Canada, he has crossed the continent in his eight years developing software in the financial, media, and business server industries. You can reach Chris at
cwhytock@microsoft.com.