Windows Workflow Foundation, or WF, is oftentimes compared to BizTalk’s orchestration-underlying XLANG language. WF’s underlying XAML language, like the XLANG language, provides an extensible and declarative means to describe the execution of a business process. Within BizTalk, this business process is implemented in the form of an orchestration. Within WF, the business process is executed as either a sequential or a state machine workflow.
Since WF’s introduction and given the striking similarities to BizTalk orchestrations, BizTalk architects have wondered how WF is aligned with BizTalk, and whether that alignment takes advantage of the umbrella of ancillary technologies, such as BAM, that BizTalk has to offer. The answer is that WF may be positioned alongside BizTalk and BAM quite nicely, complementing BizTalk, BAM, and other technologies that are a part of BizTalk.
This chapter will cover the following:
- WF overview and concepts
- BizTalk orchestrations vs. WF workflows
- The WF interceptor architecture
- Understanding a WF tracking profile
- How to monitor a WF workflow with the WF interceptor
- The syntax of a WF interceptor file
- Editing the
app.configfile - Exercises on monitoring WF with BAM
This chapter assumes you have basic knowledge of workflow within applications, XML, Visual Studio 2008, and BizTalk Server Administration.
While Microsoft has announced significant changes will be coming within .NET Framework 4.0 with regard to WF and WCF (effectively dubbed WCF+WF 4.0), you may assume that the next version of BizTalk, built upon the .NET Framework 4.0, will be updated to include these changes.
WF Overview and Concepts
Although it was known that Microsoft had an SOA product (Indigo) in the works at the time of Microsoft’s Professional Developer’s Conference 2005, little was known about its companion product, Windows Workflow Foundation, which was announced at the conference.
As the portfolio of Microsoft’s server offerings has grown, so too has the number of proprietary implementations of workflow-like technology. While BizTalk implemented its own business process workflow first as orchestrations and then later added Human Workflow Services, products such as Content Management Server hosted long-running workflows some time ago. Microsoft also had no application-level workflow offering by which developers could build .NET applications without resorting to third-party offerings, such as K2 or Skelta.
With each server implementing its own flavor of workflow, it made sense for Microsoft to provide some “foundational” workflow APIs by which application-level workflows could be constructed and upon which additional capability could be built (e.g., Microsoft Office Share-Point Server builds its workflows using WF).
As WF emerged, many questioned whether it would replace XLANG as the execution engine of BizTalk. While the same team worked on both technologies, it was ultimately decided that the two technologies would coexist as they target different environments. In fact, Microsoft, as part of its pledge toward future BizTalk versions, has made it clear that existing investments within XLANG will never be sacrificed at the expense of the “latest and greatest.”
Application Workflows
Within WF, a workflow represents the implementation of a specific process. Application code, in general, is the implementation of a specific process. What differentiates application code from a workflow is the means in which it executes and the way in which that execution is represented.
Workflows within WF execute in one of two ways: either sequentially or as a result of an event firing or a condition being met (referred to as state machine workflows). BizTalk orchestrations may be thought of as sequential as well. Figures 9-1 and 9-2 depict a sequential BizTalk orchestration and a sequential WF workflow. Note the similarities.
In building an orchestration, it’s oftentimes known what the proposed outcome will be or what the set of steps to take place are. Sequential workflows lend themselves to the same design pattern: a fixed set of steps that largely follows a path from A to B and may take some tangents.
State machine workflows are more geared toward human interaction or interaction from an outside force. They are less fixed, less rigid, and more adept at handling events as they occur (see Figure 9-3). Over time, message and orchestration design patterns have emerged within BizTalk as a result of a desire to handle events in a nonlinear fashion. Publish-subscribe responds to the event of a message publication. The convoy pattern fully accepts message events will occur out of order and expects to build some mechanism to deal with them. The same may be said of the aggregator pattern.
Figure 9-1. BizTalk orchestration (sequential)
Figure 9-2. WF sequential workflow
Figure 9-3. A state machine workflow
Activities
If a workflow represents the implementation of a specific process, activities represent the individual tasks or units of work of that process. Out of the box, BizTalk provides activities in the form of shapes within the toolbox. WF provides similar capabilities, but also the ability to build custom activities by inheriting from the activity class.
When a BizTalk developer wishes to encapsulate a process or promote reuse of a sequence of events, this is accomplished by either building a separate orchestration that is called or started by a primary orchestration or calling into a custom code component within a code shape. Within WF, a developer may encapsulate multiple activities in a single activity, known as a composite activity, instead of calling across activities (or their BizTalk equivalents). This is done by inheriting from the CompositeActivity class.
When you use the activities and the WF designer within Visual Studio, it begins to become clear that the toolset is largely geared toward building workflow within an application.
Hosting
From a purely physical standpoint, after creation, an orchestration file (ODX) is simply a code file. Likewise, a WF workflow is code as well. Both provide a rich visual interface for designing the code. BizTalk, however, has the distinct advantage of providing for not only the creation of the code, but also the execution environment, known as the BizTalk run time or BizTalk host.
WF workflows, in the form of WF libraries, must be executed using a .NET 2.0–compliant hosting process, such as a Windows Forms application, WPF application, Windows service, web application, console application, etc.
WF Run-Time Services
Once the workflow hosting process has been instantiated, it communicates to the WF run time, which provides access to the WF framework. In order for the WF run time to properly execute workflows, it must support three services.
Of note, the Dublin suite of technologies, while not fully detailed, is expected to address many of the shortcomings of the management of WCF and WF technologies.
Persistence Service
Persistence, within the context of a business process, is the ability to store the state of the process in a typically durable medium (such as a database, file store, etc.). BizTalk implements this capability utilizing persistence points, specifically when
- The end of a transactional scope is reached.
- A debugging breakpoint is reached.
- A message is sent with the exception of message being sent in atomic scope.
- The orchestration starts another orchestration asynchronously (as in a Start Orchestration shape).
- The orchestration instance is suspended.
- The system shuts down under controlled conditions (abnormal termination not included).
- The engine determines that the instance should be dehydrated.
- The orchestration instance is finished.
Some argue that the fact that BizTalk automatically provides management of its persistence points is beneficial to the developer; others argue that this persistence mechanism should be surfaced via an API and that calls to it should be made more explicit.
Because it is unknown where the WF run time will be hosted, WF implements a PersistenceService, which provides the ability to persist, dehydrate, or rehydrate the state of a workflow. A Windows Forms application, WPF application, or Windows service that runs continually manages the state of the workflow within the execution space of the application or service. But for an ASP.NET application, the state of the workflow must be maintained in some external store. In instances where the request made to the ASP.NET application is load balanced across multiple servers, there is no guarantee that the same server will receive the successive request. As such, some medium must be in place between changes to the business process to maintain the state of the workflow.
As with BizTalk, there are times when it is necessary to “sleep” a process, awaiting either external input or for a specific period of time to elapse. From a memory management standpoint, especially when considering scalability, keeping each workflow in memory soon becomes unrealistic.
WF provides one out-of-the-box persistence mechanism, SQL Server, using SqlWorkflowPersistenceService. Fortunately, unlike BizTalk, WF provides you the ability to “roll your own” persistence service by creating a class that inherits from the WorkflowPersistenceService class. As with SqlWorkflowPersistenceService, your persistence service then serializes the state of the workflow in the following instances:
- When a workflow becomes idle.
- When a workflow completes or terminates.
- When a
TransactionScopeActivitycompletes. - When a
CompensatableSequenceActivitycompletes. - When a custom activity that is decorated with the
PersistOnCloseAttributecompletes. - When one of the methods on a
WorkflowInstanceis invoked that causes a persistence operation, such asUnloadandTryUnload. TheLoadmethod results in a previously unloaded and persisted workflow being retrieved and loaded back into memory.
The mechanism utilized to persist to the store, binary representation and GZIP compression, is identical between BizTalk and WF.
Tracking Service
The WF Tracking Service is to HAT what WF workflows are to BizTalk orchestrations. The WF Tracking Service provides visibility into the execution process of a workflow, such as duration, decision points made and route taken, and completion state of activities executed therein. While many comparisons have been made between the WF Tracking Service and BAM, it’s important to remember that BAM is business and activity focused, whereas the WF Tracking Service and HAT are message based.
As may be surmised, WF ships with one tracking service out of the box, the SqlTrackingService, which provides the ability to write tracking data to a SQL Server–based data store. Additional tracking services may be created to persist data and aggregated during the execution process (with some performance penalty, of course).
As with BAM, there are two primary phases to the design of a tracking profile for WF. However, BAM provides you at least one tool for the creation of an observational model, whereas WF leaves implementation and configuration to the developer. Again, expect this shortcoming to be introduced with the Dublin suite of technologies, currently slated to be released at the time of Visual Studio 2010.
Scheduling Service
The WF Scheduling Service manages how workflow instances are scheduled by the workflow run-time engine. While not directly analogous, the WF Scheduling Service is akin to the service window capabilities found within a BizTalk receive or send location, providing for a specific date/time during which an orchestration may be executed.
The WF Scheduling Service provides two out of the box classes: DefaultWorkflowSchedulerService and ManualWorkflowSchedulerService. The difference between the two largely has to do with the threading model; while the former is more positioned toward Windows Forms and WPF apps, the latter is geared toward ASP.NET applications.
Rules Engine
The purpose of a rules engine tool is the centralization of an application’s or enterprise’s business rules. From a central repository, rules are made accessible for reuse by multiple business processes and may be efficiently and consistently maintained while avoiding the need to change code in multiple places. Additionally, redeployments of rule sets are often unnecessary for small changes to variables. The underlying principles serve to promote reuse of code and abstraction of logic.
While BizTalk provides a rules engine in the form of the BRE, WF also provides its own rules engine in the form of the WFRE. Although they were engineered by the same team, the BRE and the WFRE differ greatly in their design and implementation.
BAM in the BizTalk vs. WF Debate
While similar in concept and designed by the same team, BizTalk and WF are strikingly different in their implementation. Table 9-1 summarizes those differences.
What emerges clearly from this comparison chart involving BAM are the following assertions:
- BizTalk orchestrations are better suited for business processes that execute across multiple systems.
- WF workflows execute best within a domain-specific application space.
- The tools and workflow technologies differ in their offerings.
- It is important to utilize the proper technology.
- BAM is the only technology that may take advantage of BizTalk, WCF, and WF by abstracting messages, activities, message data, or service calls into a higher level.
Think of BizTalk as executing business processes between systems. Think of WF as executing business processes within a system. Think of WCF as the entry points to and exit points from a system. Also, remember that as of .NET 3.5, WCF can be used to instantiate a WF workflow.
So how may the contents of a WF workflow or activity provide data to BAM? We’ll explore that next.
The WF Interceptor Architecture
As the overall interceptor architecture was covered in detail in Chapter 8, we won’t revisit it again. However, it is important to understand how the WF interceptor works.
The WF interceptor is implemented as a WF Tracking Service named BamTrackingService, which inherits from the base TrackingService class and implements the IProfileNotification interface. The WF run time sends three types of events to a tracking service: workflow events, activity events, and user events. These events are implemented as track points.
Workflow events, as you may imagine, provide visibility into the life cycle of the work-flow instance with events such as Created, Completed, Idle, Suspended, Resumed, Persisted, Unloaded, Loaded, Exception, Terminated, Aborted, Changed, and Started.
Activity events describe and provide visibility into the life cycle of an activity instance. Status events for an activity include Executing, Closed, Compensating, Faulting, and Canceling.
User events are defined by the developer of the workflow and the activity. Each activity offers a TrackData() method with two overloads. The objectData or key and objectData passed to this method is passed to the tracking service as a User event.
The tracking run time, which executes within the host application, uses a tracking profile similar to BAM’s to filter which events will be reported to the tracking service. Because BamTrackingService determines the items to be tracked based upon what the BAM developer determines should be tracked via the IC file, the implementation of BamTrackingService is unique.
When BamTrackingService is first initialized, it first creates a new instance of a BamProfileManager, the primary class used to manage BAM tracking profiles as they relate to WF tracking profiles, validating and managing track points, and validating activities, users, and workflows. The configuration file is read to set the ConnectionString to the PI tables as well as the polling interval, and then WF event source names are read into a collection.
The first functional event that occurs is a TryGetProfile() call from the tracking run time to the tracking service, requesting a specific workflow type and tracking profile. The first attempt is to retrieve a local WF tracking profile. An attempt is then made to retrieve an interceptor configuration from the PI tables for the specific workflow event source. Providing everything is successful, BamProfileManager then takes over and begins parsing the interceptor configuration via the SetupMetadata and HelpSetupMetadata methods. A TrackingProfile object is returned. This object is the mechanism that communicates which events, by way of its call to the PI tables, are to be observed rather than monitoring all events that occur within the WF workflow.
The tracking run time then calls the GetTrackingChannel() method from BamTracking-Service. A BamTrackingChannel is a mechanism to handle the tracking events and data that occur within the workflow instance. It’s important to note that in its construction, the BamTrackingChannel instantiates a DirectEventStream object and a WorkflowInspector object. The WorkflowInspector object actually transforms tracking data and produces events that are recorded to the BAM Primary Import database.
At execution time, events and data that the service requested through the tracking profile are sent to the tracking channel for the instance via the Send method of the tracking channel. A new tracking channel is used for each WF workflow instance, preventing synchronization and locking issues from occurring as each workflow instance runs on a single thread.
Understanding a WF Tracking Profile
WF tracking profiles are much like BAM tracking profiles. WF tracking profiles include work-flow track points, activity track points, and user track points. So what is a track point? Simply a construct that defines information on the type of data to collect and when to collect it.
A WF tracking profile is simply a collection of track points. The BAM WF interceptor, by way of the SetupMetadata method, actually performs mapping between the WF interceptor configuration (which in essence is a BAM tracking profile) and the WF tracking profile.
Without going into too much detail here (you can find detailed info on MSDN by searching for “Windows Workflow Foundation: Tracking Services Deep Dive”), the WF tracking profile is structured as follows:
WorkflowTrackPointsMatchingLocationsEvents
Annotations
Activity TrackPointMatching/Excluded LocationsActivityTypeMatchDerivedTypesExecutionStatusEvents (for example, Executing or Closed)ConditionsMemberOperator (Equals/Not Equals)Value
AnnotationsExtractsWorkflow ExtractActivity Extract
User TrackPoint
From a cursory glance, a BAM tracking profile/interceptor configuration and a WF tracking profile appear rather similar.
How to Monitor a WF Workflow with the WF Interceptor
The basic process for enabling BAM to monitor WF workflows is as follows:
- Create the WF workflow(s) within a WF class library.
- Decide upon a hosting model for the workflow.
- Install the BAM Eventing software if it is not already installed.
- Create and deploy an observation model.
- Create and deploy the interceptor configuration file.
- Ensure that the user under which the WF host application executes is set with the correct (
bam_<activity>_EventWriter) SQL Server roles to enable the application to read the interceptor configuration information and write to the BAM activities. - Modify the WF application
app.configfile to load the BAM Tracking Service or manually load the BAM Tracking Service within your code, and then restart the application.
With a little experience with WF, you should be familiar with each of these steps with the exception of creating the interceptor configuration file targeted toward WF applications and modifying the app.config file. Let’s cover the WF IC file first.
The Syntax of a WF Interceptor File
The WF interceptor file is based upon XML Schemas stored in the <Installation Path>Microsoft BizTalk Server 2009SDKSamplesBAMInterceptorXSDs directory. These files, CommonInterceptorConfiguration.xsd, WcfInterceptorConfiguration.xsd, and WorkflowInterceptorConfiguration.xsd, are used by the bm.exe utility to validate the configuration file before deployment.
Chapter 8 covered the WCF interceptor schema as well as the CommonInterceptor-Configuration schema. The WorkflowInterceptorConfiguration schema includes the following:
<xs:element name="Operation">
<xs:complexType>
<xs:sequence>
<xs:element name="Argument" type="xs:string" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Name" type="WorkflowOperationType" use="required" />
</xs:complexType>
</xs:element>
<xs:simpleType name="WorkflowOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="GetActivityName" />
<xs:enumeration value="GetActivityEvent" />
<xs:enumeration value="GetWorkflowEvent" />
<xs:enumeration value="GetActivityType" />
<xs:enumeration value="GetUserDataType" />
<xs:enumeration value="GetUserKey" />
<xs:enumeration value="GetUserData" />
<xs:enumeration value="GetWorkflowProperty" />
<xs:enumeration value="GetActivityProperty" />
<xs:enumeration value="GetContextProperty" />
</xs:restriction>
</xs:simpleType>
As stated in Chapter 8, the config file for your BAM WF interceptor is really just a means for BAM to call specific methods without requiring you to write code, namely
BeginActivity(activityName, activityInstance)UpdateActivity(activityName, activityInstance, params object[] data)EndActivity(activityName, activityInstance)EnableContinuation(activityName, activityInstance, continuationToken)AddReference(activityName, activityID, referenceType, referenceName, referenceData, longReferenceData)
The EventSource Element
The EventSource element specifies the source of the events appearing in the interceptor configuration file. The element includes the three attributes listed in Table 9-2.
Following is a complete example of an EventSource element for WF:
<ic:EventSource Name="ProcessingWorkflow" Technology="WF"
Manifest="SimpleWorkflow.OrderWorkflow, SimpleWorkflow, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null"/>
The BAMActivity Element
The BAMActivity element simply defines the name of the BAM activity and is a container for other elements. The element includes only one attribute, which is listed in Table 9-3.
Following is an example of a BAMActivity element containing the preceding example:
<ic:BamActivity Name="Order">
...
</ic:BamActivity>
The OnEvent Element
The OnEvent element is the heart and soul of the config file definition. It defines a logical event that is mapped to the BAMActivity element that encloses it. The OnEvent element contains the four attributes listed in Table 9-4.
The OnEvent element will also include child elements, as listed in Table 9-5.
WF Interceptor Operations
You may have noticed within the WF interceptor schema an enumeration of WFOperationTypes. The WF interceptor provides the ten operations listed in Table 9-6 to extend filter and updating capabilities within an interceptor configuration file.
While incredibly useful when extracting data from WF activities, mapping to WF activities, and flushing that data to BAM, these operations also have their limitations due to the implementation of the WF interceptor, as you may have noticed.
Each of these operations (as well as Equals, And, Concatenate, and Constant) may only be used against specific track point categories. As you may recall from Chapter 8, Filter elements and data extraction or manipulation operations are defined within an IC file.
Tables 9-7 and 9-8 summarize whether the operations may be used in filter expression operations and whether they may be used within data extraction or manipulation operations.
Now, with a thorough understanding of the WF IC config, the last step is to edit the WF application’s app.config file.
Editing the app.config File
The app.config file edit is really a simple process. Open the app.config file in Notepad or Visual Studio 2008. Locate the Configuration element, and within it paste the following:
<WorkflowServiceContainer>
<Services>
<add type="Microsoft.BizTalk.Bam.Interceptors.Workflow.BamTrackingService,
Microsoft.BizTalk.Bam.Interceptors, Version=3.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
ConnectionString="Integrated Security=SSPI;
Data Source=.;Initial Catalog=BAMPrimaryImport"
PollingIntervalSec="5"/>
</Services>
</WorkflowServiceContainer>
You’ll need to make sure the Section element is the same name as the one used by your application code when using the WorkflowRuntime class. You’ll also need to modify the ConnectionString section to point to the BAM PI database, save the file, and restart your application.
BAM and WF at AWO
Now that you have a better understanding of how BAM and WF complement one another, we’ll detail how the Arnold, Wilbur, and Olivia Corporation (AWO) utilizes the two technologies to complement one another.
As you’ll recall, AWO is an international leader in specialty building materials construction. AWO began in the 1840s because of combined contributions from its founders Jacobs and Lang. AWO is nearing some 170 years of accrued business knowledge and expertise in the building materials construction space.
Over time, separate and distinct applications have emerged under the guidance and supervision of the enterprise architect at AWO. Some of these systems include
- An externally-facing ASP.NET 3.5–based web application (BuilderWeb) used by builders to place orders for and check the availability of specialty building materials. BuilderWeb hosts WF activities to provide users with an updated status of their order at all times using sequential and state machine workflows.
- A Microsoft Office SharePoint Server 2007 implementation (PigPen) that includes Microsoft InfoPath server. AWO quality inspectors perform random spot checks of many of their suppliers to ensure that only quality materials are being utilized. They fill out InfoPath forms via tablet PCs in the field, which are then submitted to MOSS and a BizTalk WCF endpoint. The form data stored within MOSS is used for collaboration. The form data sent to the WCF endpoint is published to BizTalk and sent to the AWO CRM system (HogCall). Within HogCall, the data undergoes a series of WF custom workflows that generate documents and e-mails that are sent to suppliers to notify them if the standards are not met.
- A WPF security application (SheepDetector) used to detect fraudulent orders, enforce perimeter security, and prevent trade materials from falling into the hands of AWO’s largest competitor, BBWolf LLC. AWO and BBWolf have a history of legal entanglements stemming from the death of BBWolf’s founder and former CEO on AWO property in a ghastly but contained fire. SheepDetector hosts a number of WF work-flows that periodically execute against the WF rules store.
- A BizTalk Server 2009 implementation that integrates all enterprise applications.
Figure 9-4 presents the diagram for this enterprise architecture.
Figure 9-4. The BizTalk and WF architecture at AWO
The BizTalk Server 2009 implementation utilizes the WF interceptor to monitor WF work-flows within each of the applications and provide an end-to-end systems integration business process for builders.
One of the big “value-adds” for AWO over its competitors is that BuilderWeb is fed with real-time data from the enterprise in BAM. When a builder visits the application and browses the catalog, he is able to determine not only whether the building material is in stock and the current price, but also whether there have been any problems in the past with the material and whether the supplier has had a track record of problems. This is important because builders provide a warranty to their houses from defects in materials. Comprehending this risk provides the builder a better understanding of whether the material will withstand a huff and a puff.
BAM is able to monitor outstanding workflow complaints from customers and correspondence that has gone out to suppliers from HogCall, monitor attempts to order materials by BBWolf as part of SheepDetector, and monitor whether BuilderWeb is selling enough materials to meet expected sales.
AWO’s enterprise architect has also contacted AWO’s Microsoft Partner account manager and asked that the next version of SharePoint Server include the ability for BAM to monitor SharePoint Server–based workflows. Currently, BAM may not be used to monitor MOSS work-flows as MOSS is a “closed” workflow system.
EXERCISE 9-1. CREATING A WF SEQUENTIAL WORKFLOW TO MONITOR
While this chapter provides an overview of WF workflows and activities, there are still many items outside of the scope of this book related to creating WF sequential workflows including custom activities, binding, integration of custom entities, and so forth.
Great resources are available on the Internet for learning WF, as well as training available from independent sources. We recommend Pro WF: Windows Workflow in .NET 3.5 by Bruce Bukovics (Apress, 2008).
This example will simulate the validation and preapproval of a credit card charge. Many times when you go to a restaurant and use a credit card as payment, the card will be validated first to ensure it meets certain criteria. A preapproval amount will be established, and a final approved amount will be calculated based upon current balance, credit limit, and a number of other factors (such as protecting you from a waitstaff member providing herself a 500% tip).
In the exercises in this chapter, you will create the sequential workflow to monitor and use BAM to monitor the workflows as they take place. This scenario is common in the real world, as BAM is used by fraud detection systems to alert a cardholder to the card being used too frequently at a single merchant or within a timespan, to detect patterns where a card may be used multiple times at a single merchant without the cardholder’s knowledge, to alert the cardholder that he may be nearing his credit limit, and other scenarios. Because the workflow merely performs the work, BizTalk and BAM may raise alerts to perform other actions, temporarily suspend the card should fraudulent activity be detected, or even e‑mail the cardholder of the activities that are taking place.
- Open Visual Studio 2008. Click Create and from the New Project dialog, select the Visual C# > Workflow tab, and then select the Sequential Workflow Console Application. Name the project and solution appropriately (in this case, ProBAM2009.WFConsoleApp), and click OK. We have you select a sequential workflow here because it is a closer model to the validation process than a state machine workflow.
- Double‑click
Program.csand, at the end of theMainmethod, within the end of theusingblock afterwaitHandle.WaitOne();, add the following code and save the file:Console.WriteLine("Press any key to exit");
Console.ReadKey(); - Double-click
Workflow1.cs. Using the Toolbox, between the green and red indicators drop two Code Activity shapes and an IfElse Activity shape, and within the left branch of the IfElse shape, drop a third Code Activity shape. - Click the topmost Code Activity shape, named codeActivity1, click the Properties tab, and then rename codeActivity1 to GenerateRequestActivity.
- Click the Code Activity shape beneath GenerateRequestActivity, named codeActivity2, click the Properties tab, and then rename codeActivity2 to ValidateRequestActivity.
- Click the IfElse activity, click the Properties tab, and rename the activity from ifElseActivity1 to ifIsValidActivity.
- Click the left branch of ifIsValidActivity, click the Properties tab, and rename ifElseBranchActivity1, the left branch of the activity, to isValidBranchActivity.
- Click the right branch of the activity and change its name from ifElseBranchActivity2 to isInvalidBranchActivity.
- Click the Code Activity shape within the left branch, named codeActivity3, and change its name to SetFinalAmountActivity. Your workflow should now look as shown in Figure 9-5.
Figure 9-5. The sequential workflow after the basic setup
- Right-click
Workflow1.cswithin Solution Explorer and select View Code. Beneath the following code segment:public Workflow1()
{
InitializeComponent();
}enter the following code and save the file:
public partial class CreditCard
{
public CreditCard()
{
}
public int CardId;
public string AccountNumber;
public DateTime ExpirationDate;
public string CardHolderName;
public string BillingPostalCode;
public int SecurityCode;
public Double CreditLimit;
public Double CurrentBalance;
}
public partial class Purchase
{
public Purchase()
{
}
public Guid PurchaseId;
public Guid MerchantId;
public Double PreapprovalAmount;
public Double FinalApprovedAmount;
}
public partial class ValidationRequest
{
public ValidationRequest(CreditCard cardInstance, Purchase
purchaseInstance)
{
CardInstance = cardInstance;
PurchaseInstance = purchaseInstance;
}
public CreditCard CardInstance;
public Purchase PurchaseInstance;
public bool IsValid = true;
}
public CreditCard myCreditCard;
public Purchase myPurchase;
public ValidationRequest myValidationRequest;
private int GenerateRandomIntegerInRange(int min, int max)
{
Random random = new Random();
return random.Next(min, max);
}
private DateTime GenerateRandomDateTimeInRange(DateTime fromDateTime,
DateTime toDateTime)
{
System.Random random = new Random();
TimeSpan range = new TimeSpan(toDateTime.Ticks -
fromDateTime.Ticks);
return fromDateTime + new TimeSpan((long)(range.Ticks *
random.NextDouble()));
}
private void WriteConsoleData(CreditCard creditCard)
{
Console.WriteLine("Credit Card instance data generated");
Console.WriteLine(" Card Account Number: " +
creditCard.AccountNumber);
Console.WriteLine(" Card Billing Postal Code: " +
creditCard.BillingPostalCode);
Console.WriteLine(" Card Holder Name: " +
creditCard.CardHolderName);
Console.WriteLine(" Card Id: " + creditCard.CardId.ToString());
Console.WriteLine(" Card Credit Limit: " +
creditCard.CreditLimit.ToString());
Console.WriteLine(" Card Current Balance: " +
creditCard.CurrentBalance.ToString());
Console.WriteLine(" Card Expiration Date: " +
creditCard.ExpirationDate.ToShortDateString());
Console.WriteLine(" Card Security Code: " +
creditCard.SecurityCode.ToString());
}
private void WriteConsoleData(Purchase purchase)
{
Console.WriteLine("Purchase instance data generated");
Console.WriteLine(" Purchase Merchant Id: " +
purchase.MerchantId.ToString());
Console.WriteLine(" Purchase Id: " +
purchase.PurchaseId.ToString());
Console.WriteLine(" Purchase Pre-Approval Amount: " +
purchase.PreapprovalAmount.ToString());
} - Double-click
Workflow1.cs, and then double-click the GenerateRequestActivity shape. This should automatically create an event handler for theexecutemethod of the activity. Enter the following code for the event handler:// Generate card data
myCreditCard = new CreditCard();
myCreditCard.AccountNumber =
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString();
myCreditCard.BillingPostalCode =
GenerateRandomIntegerInRange(10000, 99999).ToString() + "-" +
GenerateRandomIntegerInRange(0, 9999).ToString();
myCreditCard.CardHolderName = "Jeff Sanders";
myCreditCard.CardId = GenerateRandomIntegerInRange(1, 641000000);
myCreditCard.CreditLimit = 3500;
myCreditCard.CurrentBalance = GenerateRandomIntegerInRange(0, 4150);
myCreditCard.ExpirationDate =
GenerateRandomDateTimeInRange(DateTime.Today.AddYears(-1),
DateTime.Today.AddYears(3));
myCreditCard.SecurityCode = GenerateRandomIntegerInRange(0, 999);
WriteConsoleData(myCreditCard);
// Generate purchase data
myPurchase = new Purchase();
myPurchase.MerchantId = System.Guid.NewGuid();
myPurchase.PurchaseId = System.Guid.NewGuid();
myPurchase.PreapprovalAmount = 100;
WriteConsoleData(myPurchase);
// Generate validation request
myValidationRequest = new ValidationRequest(myCreditCard, myPurchase);
// Generate card data
myCreditCard = new CreditCard();
myCreditCard.AccountNumber =
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString() + "-" +
GenerateRandomIntegerInRange(1, 9999).ToString();
myCreditCard.BillingPostalCode =
GenerateRandomIntegerInRange(10000, 99999).ToString() + "-" +
GenerateRandomIntegerInRange(0, 9999).ToString();
myCreditCard.CardHolderName = "Jeff Sanders";
myCreditCard.CardId = GenerateRandomIntegerInRange(1, 641000000);
myCreditCard.CreditLimit = 3500;
myCreditCard.CurrentBalance = GenerateRandomIntegerInRange(0, 4150);
myCreditCard.ExpirationDate =
GenerateRandomDateTimeInRange(DateTime.Today.AddYears(-1),
DateTime.Today.AddYears(3));
myCreditCard.SecurityCode = GenerateRandomIntegerInRange(0, 999);
WriteConsoleData(myCreditCard);
// Generate purchase data
myPurchase = new Purchase();
myPurchase.MerchantId = System.Guid.NewGuid();
myPurchase.PurchaseId = System.Guid.NewGuid();
myPurchase.PreapprovalAmount = 100;
WriteConsoleData(myPurchase);
// Generate validation request
myValidationRequest = new ValidationRequest(myCreditCard, myPurchase);
} - Double-click
Workflow1.csagain, and double-click the ValidateRequestActivity shape. Within the event-handler code, enter the following:private void ValidateRequestActivity_ExecuteCode(object sender, EventArgs e)
{
// Is it an expired card
if (myValidationRequest.CardInstance.ExpirationDate < DateTime.Today)
{
myValidationRequest.IsValid = false;
}
// Does the amount to debit exceed the credit limit
// e.g., a $10,000 charge on a card with a $1,000 limit
if (myValidationRequest.PurchaseInstance.PreapprovalAmount >
myValidationRequest.CardInstance.CreditLimit)
{
myValidationRequest.IsValid = false;
}
// Other logic
// ...
Console.WriteLine("Is Valid: " +
myValidationRequest.IsValid.ToString());
} - Finally, double-click
Workflow1.csagain, and double-click the SetFinalAmountActivity shape. Within the event-handler code that is generated, enter the following:private void SetFinalAmountActivity_ExecuteCode(object sender, EventArgs e)
{
myValidationRequest.PurchaseInstance.FinalApprovedAmount =
myValidationRequest.PurchaseInstance.PreapprovalAmount * 1.3;
Console.WriteLine();
Console.WriteLine("Final Approved Amount for request: " +
myValidationRequest.PurchaseInstance.FinalApprovedAmount
.ToString());
} - Once again, double-click
Workflow1.cs. You’ll notice an exclamation icon within the IfElse activity. Click it, and then click the window option Property “Condition” is not set. - In the Properties window, under the Condition property, set the drop-down value to Declarative Rule Condition. A + sign will appear to the left of the word “Condition.” Double-click the ellipses in the ConditionName value property, which will open the Select Condition dialog.
- Click the New button, which will open the Rule Condition Editor. In the dialog, type the following and click OK:
this.myValidationRequest.IsValid == True - Rename the condition (Condition1) to IsValidRequest, and click OK to close all dialogs. Your workflow should now build. If it does not build, remedy any problems that occur.
Your WF should now generate a sample credit card validation for a purchase and through random number generation provide sample data that is within statistical norms (e.g., there are 641 million credit card numbers currently in circulation, the average credit limit per card is $3,500, the average current balance per card is $8,300, cards are usually replaced after every 2–3 years, etc.). The validation should appear similar to what you see in Figure 9-6.
Figure 9-6. An example of the WF console application output
- Run the workflow several times just to examine the different scenarios. You should see a couple instances in which the purchase is not valid because either the card is expired or the amount to charge exceeds the credit limit.
EXERCISE 9-2. CREATING A WF OBSERVATION MODEL
The purpose of this exercise is to create a simple, but effective observation model for the sequential workflow created in Exercise 9-1.
- Open Microsoft Excel 2007, and ensure that the BAM Add-In for Excel is still functioning. If it is not, follow the instructions in Chapter 3 to enable it.
- Click the Add-Ins tab, click the BAM button drop-down, and select BAM Activity.
- Click New Activity and set the activity name to CardValidationActivity.
- Click New Item and create the new activity items listed in Table 9-9.
- Click OK to close dialogs until the Business Activity Monitoring View Creation dialog appears, and then click Next.
NOTE At this point, it’s important to mention that this gathered data could be used in numerous scenarios. For instance, a check could be done simply with AccountNumber and SecurityCode to determine how frequently a SecurityCode was not being provided. If frequent, it’s likely that someone had a copy of the card number, but not the actual card itself, and was trying to use it for fraudulent activities.BillingPostalCode and CurrentBalance could be used together to determine the average current balance per postal code. In tough economic times, many people charge excess amounts on their credit cards to cover other expenses. This data could be used to detect likelihood of default by geographic region when correlated with median income values.
- Select Create a new view and click Next. Specify a view name of ViewPurchase and select the Card-ValidationActivity. Click Next.
- In this scenario, you’d simply like to provide all data for analysts to consume within the BAM Portal. In the New BAM View: View Items screen, select Select all items and click Next.
- In the New BAM View: Aggregation Dimensions and Measures screen, add a new dimension. Set the dimension name to PostalCodeDimension, set the dimension type to Data Dimension, and add BillingPostalCode to the DimensionLevels.
- In the same screen, add a new measure. Set the measure name to AvgCurrentBalance, set the base data item to CurrentBalance (CardValidationActivity), and set the aggregation type to Average. Click OK, and then click Next.
- Review the items to be created, and click Next.
- Click Finish.
- Save your workbook, and use the BAM Add-In for Excel to export the XML file for the observation model definition. Name it
WFCreditValidationActivity.xml. - Populate the PivotTable with some basic data elements.
- Deploy
WFCreditValidationActivity.xmlto BAM using thebm.exeutility.
You now should have an observation model in place, as well as the necessary tables and views against which BAM will aggregate data.
Your XML file should contain the following values (note that it’s OK for the CubeRefs and ID values to be unique):
<?xml version="1.0" encoding="UTF- 16"?>
<BAMDefinition xmlns="http://schemas.microsoft.com/BizTalkServer/2004/10/BAM">
<Activity Name="CardValidationActivity"
ID="ID927C20DBBC5B4360AC2991AD02ED502D">
<Checkpoint Name="BillingPostalCode" ID="
IDF3883587FB8243D58F5EDACB409C8C53" DataType="NVARCHAR"
DataLength="10"/>
<Checkpoint Name="CreditLimit" ID="ID79EC19C7C8C04D979468C2791BEFC2AD"
DataType="FLOAT"/>
<Checkpoint Name="CurrentBalance" ID="ID8033A8365BC74AB8AF2293FA8D85AE30"
DataType="FLOAT"/>
<Checkpoint Name="ExpirationDate" ID="ID5EE406D8D8D7486CAA8BB1A74868651B"
DataType="DATETIME"/>
<Checkpoint Name="MerchantId" ID="IDFB18611CF38A4F1CA867F6930781C015"
DataType="NVARCHAR" DataLength="100"/>
<Checkpoint Name="AccountNumber" ID="IDF03617B6A25249B890279DAEE5A4F06C"
DataType="NVARCHAR" DataLength="19"/>
<Checkpoint Name="SecurityCode" ID="IDEE671F746E664BE694BF30DE240C7386"
DataType="INT"/>
<Checkpoint Name="PreApprovalAmount" ID=
"ID9B3F0A326FF445DD8A53352725441B2C" DataType="FLOAT"/>
</Activity>
<View Name="ViewPurchase" ID="ID097F3E17C4E84609BE7DECC429B7A73D">
<ActivityView Name="ViewCardValidationActivity" ID=
"ID8F0EE5D172964234830CBF4D9F71A7FB"
ActivityRef="ID927C20DBBC5B4360AC2991AD02ED502D">
<Alias Name="AccountNumber" ID="ID6773829E971349AA851C989C9D352A73">
<CheckpointRef>IDF03617B6A25249B890279DAEE5A4F06C</CheckpointRef>
</Alias>
<Alias Name="BillingPostalCode" ID=
"ID4F345643B9304B02A45293476F996E69">
<CheckpointRef>IDF3883587FB8243D58F5EDACB409C8C53</CheckpointRef>
</Alias>
<Alias Name="CreditLimit" ID="IDBEF71A3909D04C998CCB7D4F2F5F26D8">
<CheckpointRef>ID79EC19C7C8C04D979468C2791BEFC2AD</CheckpointRef>
</Alias>
<Alias Name="CurrentBalance" ID="IDAEE685FF52584DB5B6601AD3788F3F61">
<CheckpointRef>ID8033A8365BC74AB8AF2293FA8D85AE30</CheckpointRef>
</Alias>
<Alias Name="ExpirationDate" ID="IDBE1DD6F03F374A749864137ABDDF9A83">
<CheckpointRef>ID5EE406D8D8D7486CAA8BB1A74868651B</CheckpointRef>
</Alias>
<Alias Name="MerchantId" ID="ID197A3A90897740EFB728B7E2E6BE551B">
<CheckpointRef>IDFB18611CF38A4F1CA867F6930781C015</CheckpointRef>
</Alias>
<Alias Name="PreApprovalAmount" ID=
"IDAE119D3964DB4379BCD34465BA3BDC38">
<CheckpointRef>ID9B3F0A326FF445DD8A53352725441B2C</CheckpointRef>
</Alias>
<Alias Name="SecurityCode" ID="ID577A4D74D3CB4457B4D259E291CA4A10">
<CheckpointRef>IDEE671F746E664BE694BF30DE240C7386</CheckpointRef>
</Alias>
</ActivityView>
</View>
<Cube Name="ViewPurchase" ID="IDF4EB46891D044808AA3F2965EAECBAFF"
CreateOlapCube="true" ActivityViewRef=
"ID8F0EE5D172964234830CBF4D9F71A7FB">
<Measure Name="AvgCurrentBalance" ID="ID1E123759207842D3A6D4B9A47A905665"
AliasRef="IDAEE685FF52584DB5B6601AD3788F3F61" AggregationFunction=
"Avg"/>
<DataDimension Name="PostalCodeDimension" ID=
"IDF06F6EA6D4B24802A7B2ED30AAEBE626">
<LevelAliasRef>ID4F345643B9304B02A45293476F996E69</LevelAliasRef>
</DataDimension>
</Cube>
<Extension>
<OWC xmlns:x="urn:schemas-microsoft-com:office:excel">
<PivotTableView CubeRef="IDF4EB46891D044808AA3F2965EAECBAFF">
<x:PivotTable>
<x:ConnectionString/>
<x:DataMember>Sample</x:DataMember>
<x:PivotField>
<x:Name>AvgCurrentBalance</x:Name>
<x:SourceName>[Measures].[AvgCurrentBalance]</x:SourceName>
<x:SourceHierarchy>[Measures].[AvgCurrentBalance]
</x:SourceHierarchy>
</x:PivotField>
<x:PivotField>
<x:Name>BillingPostalCode</x:Name>
<x:SourceName>[PostalCodeDimension].[BillingPostalCode]
</x:SourceName>
<x:Orientation>Row</x:Orientation>
<x:Position>1</x:Position>
<x:SourceHierarchy>[PostalCodeDimension]</x:SourceHierarchy>
</x:PivotField>
<x:PivotField>
<x:Name>Data</x:Name>
<x:Orientation>Row</x:Orientation>
<x:Position>-1</x:Position>
<x:DataField/>
</x:PivotField>
<x:PivotField>
<x:Name>AvgCurrentBalance</x:Name>
<x:Orientation>Data</x:Orientation>
<x:Position>1</x:Position>
<x:ParentField>[Measures].[AvgCurrentBalance]</x:ParentField>
</x:PivotField>
<x:PivotView>
<x:IsNotFiltered/>
<x:Label>
<x:Caption>PivotTable1</x:Caption>
</x:Label>
</x:PivotView>
</x:PivotTable>
</PivotTableView>
</OWC>
</Extension>
</BAMDefinition>
EXERCISE 9-3. CREATING THE WF INTERCEPTOR CONFIGURATION
EXERCISE 9-4. LOADING THE WF INTERCEPTOR RUNTIME
Finally, you must either modify the app.config file included with the console application to enable it for BAM tracking or add to the Program.cs file the code to manually load the BAM Tracking Service. By default, console applications don’t include app.config files, so you’ll elect to manually load the BAM Tracking Service using code.
- Open the Visual Studio 2008 console application. Open the
Program.csfile. - Right-click the References folder and select Add References.
- Click the Browse tab, navigate to
<BizTalk Installation Drive>Program FilesMicrosoft BizTalk Server 2009Tracking, click theMicrosoft.BizTalk.Bam.Interceptors.dllfile, and click OK. - Within the
Program.csfile, add ausingdirective at the top of the file:using Microsoft.BizTalk.Bam.Interceptors.Workflow; - After the following line within the auto-generated code:
AutoResetEvent waitHandle = new AutoResetEvent(false);insert the following code:
string connectionString = "Integrated Security=SSPI;Data Source=.;
Initial Catalog=BAMPrimaryImport";
int interceptorConfigurationPollingInterval = 5;
workflowRuntime.AddService(new BamTrackingService(connectionString,
interceptorConfigurationPollingInterval)); - Save your solution and rebuild the application. Open the BAM Portal within a web browser, and access CardValidationActivity within the Activity Search menu item.
- Run the WF console application five to ten times. Execute a query to include all available data and milestones. You should see the BAM data that was captured in BAM from WF, as shown in Figure 9-7.
Figure 9-7. WF activity data intercepted, mapped to BAM, and displayed within the BAM Portal
Summary
Windows Workflow Foundation is a strong complementary technology to BAM.
In this chapter, you learned about WF and the context of BAM within BizTalk and WF. The chapter included coverage of the WF interceptor architecture, how a WF tracking profile is structured, and how to monitor a WF workflow using the WF interceptor. The chapter also covered the syntax of a WF interceptor configuration file and how to edit the app.config file to enable monitoring of WF workflows within BAM.
Sometimes it is useful to get at an even more granular level when writing data to BAM or when you want to monitor an application that doesn't utilize BizTalk, WCF, or WF. The next chapter will cover the BAM API and how it may be used to capture and process BAM data.