nterprise Application Integration (EAI) is a collection of architectural principles combined to integrate new and existing applications both within the enterprise and in business-to-business or partner integration scenarios.

Building on the principles introduced in Part 1 of this series, I’ll provide a step-by-step example of how to implement a solution that addresses a business case and suggest some real-world patterns and techniques for fulfilling the business case.

Part 1 of this article discussed what Enterprise Application Integration is all about, along with a bird’s eye view of some of the common challenges associated with integrating legacy applications with new systems, and building transport-agnostic workflow-modeled software in a loosely coupled manner. This is especially important when integrating existing investments with new applications and systems.

The article presented a high-level look at how Microsoft BizTalk Server 2006 provides a robust platform and complementary toolset for building elegantly connected applications while addressing many common EAI chores. Specifically, it explained how the Messaging Engine and Orchestration Engine work together to address discrete aspects of the problem domain in a loosely coupled manner.

Part 1 finished with an overview of the Visual Studio 2005 Project System, which consists of tools that enable you to work with BizTalk Server 2006. This part of the article moves beyond the theory and puts into practice a simple (yet common) integration scenario that will help to form a foundational understanding for leveraging BizTalk Server 2006 within your own application integration projects. The project uses BizTalk Server to streamline an existing business process and increase automation by focusing more closely on the business domain, and less on the plumbing itself.

Streamlining and Automating an Order and Fulfillment Process

	?
Figure 1: The current Northwind Traders Order & Fulfillment process proceeds clockwise in this figure.

Northwind Traders, purveyors of gourmet foods and other fine goods, have vendors all over the world so that they may provide customers with the best selection of products available.

While the company has been very successful, the sales team conducts most business over the phone and via e-mail, as well as through their award-winning mail order catalog. Some existing relationships go so far back that some customers still place their orders in person.

Until now, how the sale was made hasn’t really mattered much, because sales get entered into a purchase order template within a spreadsheet that has been used successfully for several years. A use case diagram (see Figure 1) shows the business process.

A sales person enters the items in the purchase order, saves it, and then simply sends an email with the purchase order spreadsheet attached to the IT team. The IT team takes the spreadsheet?given a very strict service-level agreement (SLA) of course?and imports the spreadsheet into the Orders table in the company database, archiving the email message containing the purchase order in case the order gets lost along the way. With purchase orders hitting the company database at any given time, the fulfillment department runs intra-day reports. Members of the fulfillment team proactively monitor the report for purchase orders hitting their region and act promptly on them. Upon taking ownership of a purchase order, the fulfillment team takes several actions:

1. The fulfillment specialist checks inventory for the purchase order. If the requested item is not in stock, the vendor is contacted over the phone to place an order for the item.
2. Provided the item ordered is in stock, the customer’s payment is processed and entered into the general ledger. Northwind Traders accepts checks for older, loyal customers, but prefers credit cards as the method of payment. As such, the fulfillment specialist charges the customer’s credit card (or uses an e-check) and posts monies to the general ledger. Should the credit card transaction fail, the fulfillment specialist must contact the customer to request an alternate form of payment.
3. Once the payment has cleared, the fulfillment specialist pulls the item from the warehouse, affixes the customer’s purchase order to it, and prepares the order to be shipped.
4. A shipping specialist picks up packages, striving to synchronize carrier pick up times so that the packages go out the day they are staged for shipment. The shipping specialist weighs the contents, measures the dimensions, and affixes the appropriate paid shipping label, which also contains the carrier’s tracking number. The shipping specialist then manually duplicates the tracking number on a shipping log, which the shipping specialist carries on a clipboard. At the end of each day, all shipping specialists drop their shipping logs in the fulfillment team’s “inbox” for manual processing later.
5. Each morning, a designated fulfillment specialist takes the tracking numbers listed in the paper shipping log and manually enters the data into another spreadsheet and then promptly sends the spreadsheet via email to the IT team. The IT team faithfully imports the spreadsheet into the company database where the parcel’s tracking id is correlated to the purchase order.

The use case in Figure 1 represents an overview of Northwind Trader’s current business process. Perhaps not unlike the reader, many of the business analysts and stakeholders have identified several opportunities for improving the Northwind Traders’ business process:

• Orders take too long to fulfill.
• The IT team is too slow in processing purchase orders, and sometimes purchase orders just seem to “disappear.”
• The fulfillment team is understaffed and overworked; too much of their job is manual and clerical in nature.
• There is a lack of visibility as to where an order is within each step of the process, which leads to confusion and frustration for members of all teams.
• Orders are often shipped late because the fulfillment and shipping team is overwhelmed with packages that need to be prepared and staged for shipment.
• The fulfillment team is frustrated that they have to enter the tracking IDs from the shipping log. It often takes a couple of hours each morning to get all tracking IDs entered, which prevents the sales team from accurately answering customer inquiries on the status of orders in a timely manner. (Sometimes, this information is not available in the database until mid-morning the next business day.)

Furthermore, the marketing team is convinced that if the business process were streamlined using a more robust back office, orders could be fulfilled more rapidly. With some automation improvements, the timing would be great to put together an online store front which would, in turn, drive revenues even higher.

Looking for a better way to streamline the business process and improve morale while increasing revenue and expanding the reach to customers all over the world (via the Internet), the leadership team at Northwind Traders commissions a new project that will provide enhanced business process automation and better visibility through closely instrumented business process management. They identify several nifty applications as part of the new vision for a faster, more responsive, and transparent business process:

• Design and deliver a new, public-facing web site along with a number of applications and services to support the new online store.
• New applications and services should interface with each other as well as with middle-tier services that the IT department will implement as part of the business process automation and management streamlining effort.
• It is critical that existing operations are not disrupted. As such, during development (and after delivery), things must remain business-as-usual from an order fulfillment perspective.
• The company must maintain their legacy database.
• Sales associates (the lifeblood of the company) must be able to continue submitting purchase orders via the spreadsheet templates. It is likely that one day the spreadsheets will be phased out; but until then, they must be fully supported and still benefit from the new investments in automation. To this end, once the online store front is complete, the IT team will start using it as their new interface for entering new purchase orders so that data entry and processing is consistent.

While the marketing team works with a design firm to come up with a snazzy new web site, let’s focus on the middle-tier applications and services that will drive this new era of productivity!

Requirements and Scope
One of the primary roles of application integration is to integrate new and existing applications to support the business process. In this case there are a number of components and services that need to be developed and integrated to support the new and improved Northwind Traders business process. Assume that another team is building the new web site, so the deliverable that this article will address is an entry point, or a gateway to the middle-tier components and services. I’ll show you how to use the .NET Framework, Visual C#, SOAP web services, and BizTalk Server to build, orchestrate, and deploy the foundation for the company’s business process engine.

The best way to communicate the requirements for these new middle-tier components and services is by looking at the proposed business process depicted in Figure 2, which provides a “happy path” for the new and improved order fulfillment process at Northwind Traders.

	?
Figure 2: The proposed Northwind Traders Order & Fulfillment process.

The use case diagrams make it clear that the IT department must design and develop a number of components and services to support the new Retail Operations application. This is the Northwind Trader’s business process at its core, and as such represents a blueprint?representative of the desires and expectations of its stakeholders?for addressing a technical solution. This kind of interactive dialogue with the business and stakeholders is critical, because they are not so much concerned with the technology or architecture as they are in getting the results they expect. The fact that this article has no user interface deliverables will make it even more important to maintain the right focus on the component and service definitions and APIs so that they can be consumed as easily as possible by the developers of the Web site that will leverage the Retail Operations application as it’s middle-tier.

Designing the Solution
After digesting the requirements it is time to perform some pragmatic modeling. This step is critical in not only understanding the business domain, but in thinking about how, technically, the requirements will be met.

There are several great options for capturing this information. Figure 3 depicts an informal sketch of a system-level sequence diagram. Architects use sequence diagrams to think about and communicate time and interaction between platforms and components to depict synchronous versus asynchronous calling patterns. Method signatures may change during development, but because this is a system-level aspect diagram, we will be able to discern the various components and services being proposed for each interaction that contain the Retail Operations application.

? Figure 3: A system-level sequence diagram for the new Northwind Traders Order & Fulfillment process provides the time and component interaction aspects of the system.

? Figure 4: The object model for the core components and services that will be orchestrated by BizTalk Server Orchestration.

Figure 4 provides a light object model of the required components/services. This model serves as a basic API reference for architects, developers, program managers, and analysts. Although object models will undoubtedly change somewhat during the development process, initial drafts should capture all of the major operations that will be supported. In fact, the API should be somewhat simple to correlate to the use case diagram.

The goal of this modeling exercise is not to provide academically accurate UML 2.0 diagrams; but rather to be pragmatic in communicating the proposed design and other relevant aspects to the appropriate audience. See Sidebar 1, “Agile Modeling,” for a great reference to these and other modeling diagrams.

Sequence diagrams and object models provide a useful system and API aspect to the design, which is useful mostly to architects, developers, program managers, and analysts. The business process, or workflow, must also be carefully modeled to ensure that all of the artifacts depicted in the previous models are implemented such that they actually support the business process. It goes without saying that getting the business process right is critical, and as such should be a very collaborative exercise between architects, developers, program managers, analysts, and business stakeholders. To do so, I’ll use a business process model diagram to communicate the workflow of the proposed business process.

Business process modeling facilitates the ability for both engineering and business roles to collaborate and verify that the model is accurate and reflects the current (or proposed) business process. The BizTalk Orchestration Designer has an extremely intuitive design surface that naturally resembles business process models very well. In addition, BTS 2006 provides an optional Microsoft Visio add in, known as the Orchestration Designer for Business Analysts (ODBA). The tool facilitates collaboration among all roles in planning the design of orchestrations around business processes.

I will use the ODBA to model the business process and workflow depicted in the proposed use case in Figure 2. Later, I’ll show you how to import the diagram into Visual Studio 2005 and use it as a blueprint for implementing the orchestration itself.

Using ODBA to Model the Business Process

	?
Figure 5: The Orchestration Designer for Business Analyst template is an add-in to Microsoft Visio.

1. Having installed ODBA, go to Start?> Programs?> BizTalk Server 2006, and select Orchestration Designer for Business Analysts. Alternatively, within Microsoft Visio 2003, click New, select BizTalk, and choose the Orchestration Designer for Business Analysts template. You will see a blank drawing as shown in Figure 5.
2. Drag a Group Shape from the Orchestration Designer stencils and drop it under the Begin Shape. A Group Shape isolates activities so they occur as a unit of work. The first part of the orchestration will begin with retail-related operations, so name the new Group “Retail Activities.”
3. As reflected in the use case, you’ll first handle billing and general ledger posting. Drag two Action Shapes into the Retail Activities Group and name each similar to what was captured in the use case (see Figure 2). Connect each shape (by simply dragging the arrow), starting with the Begin Shape, down to the Group Shape, and from the beginning of each shape to the next shape.
4. Perform similar steps for Inventory and Print activities.
5. Now, outside of the groups, add a final Action Shape called “Notify.” Connect the outer boundary of the Print Activities Shape to the top of the Notify Shape. At this point, the diagram should resemble the image shown in Figure 6.

? Figure 6: An Action Shape is added to the business workflow which will be used to send a notification when the order and fulfillment process has completed successfully.

? Figure 7: The Orchestration Checker provides Orchestration Designer for Business Analysts users with a way to validate workflow logic.

6. This is a great time to introduce the Orchestration Checker. This tool is like a logic debugger to validate that you’ve followed the rules for interconnecting shapes and overall flow. To run it against the orchestration you just built, within Visio, click on the ODBA menu and select Check Orchestration. The tool reports that the business process does not end with a valid shape, (see Figure 7).
7. With the Orchestration Checker still running, drag an End Shape to the bottom of the diagram and connect the bottom of the Notify Action Shape to the top of the End Shape. Click Recheck. The validation succeeds. Figure 8 shows the final diagram.

? Figure 8: The process is modeled in Orchestration Designer for Business Analysts, a Microsoft Visio add-in designed for the collaboration between developers and business analysts in modeling business workflow.

? Figure 9: The business process diagram modeled in Orchestration Designer for Business Analysts can be easily exported as a blueprint for BizTalk Server 2006 Orchestration.

8. Rename the tab at the bottom of the screen to SendPO. The SendPO orchestration will be the heart of the order and fulfillment workflow.
9. Next, click the ODBA menu and select Export to BizTalk. In the dialog box, ensure that you’ve selected the SendPO Business Process page and click Browse to name the file. Save it in the location shown in Figure 9.
10. Click OK to export the Visio diagram as a BizTalk Server 2006 Orchestration called SendPO.odx.

Implementing the Design

Let me take a quick moment to review the work that lies ahead. First, you’ll learn to create an application that encapsulates the business rules and workflow of the new Retail Operations business process. This service will be implemented as a BizTalk Server Orchestration (called SendPO.odx) that will be exposed (at least initially) as a SOAP web service endpoint.

Create the Orchestration
As part of the design phase of the solution, you created a business process diagram (see Figure 8) of what the SendPO workflow might look like using the ODBA. Now, to add the orchestration to Visual Studio 2005, complete the following steps:

1. If it isn’t already running, start Visual Studio 2005 and create a new BizTalk Server 2006 project. Figure 10 provides recommended naming for the solution and project file. This naming convention is prevalent throughout the entire solution and promotes standardization and conceptual integrity throughout the application.

? Figure 10: To create a BizTalk Project, select the Empty BizTalk Server Project template.

? Figure 11: An orchestration exported by Orchestration Designer for Business Analysts can be added to the Visual Studio Orchestration Designer for implementation.

2. Right-click the Northwind.BusinessWorkflows.RetailOps BizTalk Server project, select Add, and then choose Existing Item. Browse to the SendPO.odx file and click Add. Figure 11 shows the orchestration you just imported. Note: If you did not use the ODBA to create the business process diagram, you must add the ODX artifact now. Refer to Figure 11, which shows the state of the newly imported orchestration.
3. Notice that each ODBA Group was forward-engineered as an Orchestration Scope, and that each ODBA Action was translated as an Orchestration Group Shape. Within each Group Shape you’ll see a Shape Connector Line. I’ll show you how to use these stubs to wire up the components/services that the SendPO.odx orchestration will coordinate.

Before continuing, I want to point out one very important orchestration property. Recall that in BizTalk Orchestrations, there are two types of transactions: atomic and long-running. Although I’ll limit the scope of this article to the successful processing of a purchase order (the happy path), there are many future enhancements (and things that can go wrong) within the order-fulfillment process that makes opting for a Long Running Transaction a good choice.

4. Right-click anywhere in the Orchestration Designer and select Properties. Set the values for the Transaction Identifier and Transaction Type to SendPOTx and Long Running respectively.

Working with .NET Components and SOAP Services
With the exception of some business entities listed in Table 1 (which I will create as special C# classes) it is beyond the scope of this article to focus too much on the particulars of each service that the SendPO orchestration will coordinate.

Table 2 shows a list of classes, SOAP endpoints, and assemblies that are provided as part of the article download.

From your perspective as the reader, you will merely consume or invoke these components/services as if they’ve already been built (they are built in the download). It is important, however, to distinguish between the types of services that will be implemented and consumed:

.NET Components:

• This project will expose the majority of the services via vanilla .NET components. In both theory and practice, these components should adhere to the principles of component-oriented programming (Binary Compatibility, Language Independence, Location Transparency, Concurrency Management, Version Control, and Component-based Security). Whether internally, each component itself is making local intra-process calls to perform work within the CLR, or out-of-band calls across process boundaries to components that are hosted using remoting technologies such as ASP.NET Web services (SOAP), .NET remoting or Windows Communication Foundation is immaterial. As interface-based components, the implementation of each service is completely abstracted from the caller, leaving the caller to only be concerned with the contract presented.

SOAP Services:

• The SendPO orchestration is exposed as an ASMX web service called RetailOpsService.asmx. To provide a comprehensive overview of how orchestration interacts with other pseudo-protocols on the Send side, the solution will implement the Acme.Billing.BillingService service as a SOAP web service using the BizTalk SOAP Adapter. Obviously, the decision to implement services as .NET components, custom or vendor-provided SOAP services, will vary by scenario. See Sidebar 3, “Tenets of Service-Oriented Programming,” for guiding principles for exposing applications as contract-based services.

To add the components and services to the BizTalk project, right-click the References folder within the Northwind.BusinessWorkflows.RetailOps project and add a reference to each relevant project, assembly, or service endpoint just as you would for a class library or other Visual Studio 2005 project type. The artifacts that will be used in this solution are listed in Table 2. The NorthwindTraders solution already contains all of the source projects so you may either reference the pre-compiled assemblies or use project references (for ease of use, the latter is used by default in the solution available for download).

Create the Domain Entities
Due to the graphical nature of the BizTalk design-time experience, the orchestration itself usually requires little programming (of course you must still develop components and services used in the workflow). However, you must create entities that describe the data being consumed, sent, and received. A common approach is to create domain-specific business entities using either XSD schema or .NET classes. Since many organizations will already have significant class-specific code bases, it is not always practical or necessary to strictly use XSD schema for modeling entities. In my opinion, while XSD schema has its place in messaging, the esoteric and cumbersome nature of building and maintaining the schema makes using it desirable only when higher level APIs are not available to abstract the messaging details. Thanks to .NET’s rich support for serializing and de-serializing types, using classes is perfectly acceptable for creating entities within orchestration.

Now that you’ve added the references to pre-existing .NET components and classes used as part of the orchestration, you must create the business entities you’ll use as data transfer “objects” within the solution.

1. Within the NorthwindTraders solution, create a C# Class Library project called Northwind.BusinessEntities.RetailOps. This naming convention standardizes artifact naming and promotes conceptual integrity throughout the application.
2. Create two new C# classes named PurchaseOrder.cs and InventoryItem.cs using Listing 1 and Listing 2 as a guide. (The downloadable code for this article contains a fully functional solution, including the class files that may also be used as a reference.) Note that as entities, these classes contain no behavior, so the only work here is to add the private members and corresponding properties, along with some special attribute decorations used by BizTalk Server.

Recall from earlier discussions on messaging and pipelines that BizTalk Server treats all messages as XML (XLANG to be precise). Whether data comes in naturally as an XML document or you convert it by brute force using a specific pipeline, orchestration can only work with serializable types or XML itself (it is actually quite possible to use binary formatting, but the default serialization behavior relies on the XML formatter). Remember from our discussion in Part 1 of this article that just because a class or message is in XML format doesn’t mean that all of its fields will be automatically available to the orchestration. Fields that should be available within an orchestration instance must be marked as Distinguished.

3. Add a reference to the Microsoft.XLANGs.BaseTypes.dll to the Northwind.BusinessEntities.RetailOps project (located in Program FilesMicrosoft BizTalk Server 2006), and add the following namespace to the InventoryItem and Purchase Order classes (which contains the attribute classes necessary to mark properties as Promoted or Distinguished):

   using Microsoft.XLANGs.BaseTypes;

4. Next, decorate each class name with the Serializable attribute class:

InventoryItem class:

   [Serializable]   public class InventoryItem       {?}

PurchaseOrder class:

   [Serializable]   public class PurchaseOrder       {?}

5. For each public property within each class, distinguish each property using the DistinguishedField attribute class as shown below (this will make these properties available to the BizTalk orchestration at run time):

   [Serializable]   public class InventoryItem   {      private int m_ItemNumber;      private decimal m_price;      [DistinguishedField()]      public int ItemNumber      {         get          {              return m_ItemNumber;          }         set          {            m_ItemNumber = value;          }      }   }

Defining Messages
The Purchase Order class is the heart of this workflow because it will be used to store and transport order details from the client application to the Retail Operations application. As a result, you must define it as a Message at the global Scope within the orchestration.

In the Northwind.BusinessWorkflows.RetailOperations project, double-click the SendPo.odx file. Click the Orchestration View tab, right-click the Messages folder and click New Message. A new Message artifact is created. Right-click the new Message artifact and click “Properties Window” or, if visible, click the Properties tab.

	?
Figure 12: A Message Variable is created to declare the Message type.

Note that this is the last time I will go into such detail for bringing up artifact properties. All subsequent actions will consist of creating new artifact types or dragging shapes onto the design surface of the Orchestration Designer and setting the corresponding properties.

Under Message Type, expand .NET Classes and click “Select from Referenced Assemblies.” Select Northwind.BusinessEntities.RetailOps.PurchaseOrder as the Type and enter purchaseOrderMsg for the Name property. You can see the result of this step in Figure 12. This step is the equivalent of creating a traditional variable declaration, except that BizTalk-distinguished variables from messages (due to the fact that each is handled a bit differently). The purchaseOrderMsg Message Variable will be used to initialize purchase order Message data and move the message around within the orchestration.

Wiring Up the SendPO Orchestration
With the .NET components and services referenced and ready to go, you’ll wire up these components within the workflow, paying close attention to transaction semantics. For now just completely ignore messaging concerns such as ports, adapters, and receive locations until you’re done with the orchestration itself. This will allow you to focus on solving the business problem, leaving the configuration of these lower-level artifacts as a deployment-time exercise.

1. In the Orchestration Designer, right-click on the line directly below the green button, expand Insert Shape and select Receive. This places a Receive Shape directly below the green button. Select the Properties window for the Receive Shape and ensure the Message property is set to purchaseOrderMsg. Finally, provide an intuitive name such as Receive Purchase Order.
2. Set the Activate property to True. This lets the orchestration know that if it receives a purchaseOrderMsg message, an instance of the orchestration should fire. This property is especially important when orchestrations are capable of receiving multiple intra-process messages, such as is the case when implementing sequential convoy patterns.

As discussed in Part 1 of this article, you can use Scope Shapes to further demarcate activities and change the transaction type at the Scope level (if you need a refresher on transaction types, please refer to Part 1 of this article). This provides a logical grouping and isolation of the constituent activities within a given Scope.

Most of the activities are going to be orchestrated as calls to .NET components, which can be called within an Atomic Scope that is either the outermost scope in an orchestration or is nested within a parent Scope that is marked as Long Running. A Long Running Scope can consist of other nested Long Running or Atomic Scopes, but an Atomic Scope cannot contain any child transactions (although nesting Scopes with Transaction Type set to None is acceptable).

The only exception is the Bill Customer activity, which will be fulfilled by our fictitious payment processing vendor via the Acme.Billing.BillingService SOAP endpoint. This activity will simply inherit the Transaction Type property set to Long Running (if this just went over your head, don’t worry, after creating your first scope below, this will be much clearer).

3. Click the Retail Activities Scope and note the properties. Change the Transaction Type to Long Running and provide a useful name for the Transaction Identifier such as RetailTx. Perform the same steps for each of the remaining Scopes (Inventory and Print), but instead of Long Running, choose Atomic. Notice that when changing the Transaction Type to Atomic, the Isolation property was changed to Serialized.

Going back to the Retail Activities Scope, an excellent example of Scope nesting is the Post Funds to GL Activity/Group. Since the IRetailOps interface will be used to bind to the RetailManager component, the Post Funds to GL Activity/Group will need to be isolated within an Atomic Scope because interfaces cannot be marked for serialization as it cannot ever be assumed that the implementation of an interface would itself be serializable:

4. Right-click the line directly above the Post Funds to GL Activity/Group and insert a Scope Shape. Name the Scope Post Funds, provide a Transaction Identifier of PostFundsTx, and set the Transaction Type to Atomic. Now, simply drag the Post Funds to GL Activity/Group inside the new Post Funds Scope.

The Post Funds to GL activity will still execute within the RetailTx long-running transaction; however, it will be executed as a nested Atomic Transaction within its own Scope. This approach is perfectly legal as Atomic Scopes can be nested within Long-Running transaction Scopes; however, remember that the same is not true for the inverse.

Consuming SOAP Services within Orchestration

Figure 13: To add a Web Reference to a BizTalk Server Project, right-click References and select Add Web Reference.

After preparing the Scope, it is time to start consuming the components and services that will perform the heavy lifting in our orchestration. This exercise demonstrates how to use the SOAP Adapter for consuming external SOAP services to simulate the billing services provided by our fictitious third-party vendor.

1. Add a Web Reference to the Northwind.BusinessWorkflows.RetailOps project just as you would for any other Visual Studio 2005 project (see Figure 13). For the web reference name, use ACME. The service can be hosted within Visual Studio’s integrated web server for ease of debugging or published to an IIS server in your environment. Next, you’ll configure a Web Port (which uses the SOAP Adapter) to connect the ACME billing service to the Retail Activities transaction.

Figure 14: The Port Configuration Wizard allows you to choose the proxy generated by adding a new Web Reference as a Port Type.

2. On the right Port Surface, right-click and select New Configured Port from the shortcut menu. Name the Port (something like “SOAP Request”) and select the Acme BillingService as the Web Port type (this new Port Type was created automatically when adding the Web Reference) as shown in Figure 14. A Request/Response Port is created. Now you must create a Message Variable for the SOAP request and the SOAP response Messages that will be wired up to the Request/Response Port just created.
3. In the Orchestration View, under Messages, create a Message Variable called debitRequestMsg and select the appropriate Message Type from the list of Web Message Types. Although the name will be quite verbose and somewhat cryptic, the end of the type will indicate the operation and direction such as ?debit_request or ?debit_response. Perform the same step for the debitResponseMsg.
4. Inside the Bill Customer activity, right-click and insert a Construct Message Shape from the shortcut menu. Provide a name such as “Construct Debit Request” for the Shape and associate it with the type of message to be constructed (that is, the debitRequestMsg Message Variable).

Working with Expression Shapes
Expression Shapes provide a C#-like scripting syntax for working with .NET types and orchestration variables. You’ll use Expression Shapes to instantiate the business components and cast to the appropriate interface.

1. Ensure that you’ve defined the debitRequestMsg Message for the Message to be Constructed property within the Construct Message Shape. This is simply an initialization step, very similar in concept to a traditional variable initialization. The Orchestration Engine will automatically create an instance of the debitRequestMsg Message Variable for you, but you must initialize the fields with relevant request data, which you’ll do using special C#-like expressions.
2. Inside the Construct Message Shape, right-click and choose the Message Assignment Shape. Provide an intuitive name for the Shape such as “Prepare Debit Request.” Now, double-click the Shape to bring up the Expression Editor. Simply enter the following code into the Expression Editor (you will notice that the Expression Editor has full IntelliSense support):

   debitRequestMsg.accountNumber =    purchaseOrder.AccountNumber;   debitRequestMsg.accountNumberDetails =    purchaseOrder.AccountDetails;   debitRequestMsg.amount = purchaseOrder.Amount;

The expression consists of a simple mapping from the current instance of the purchaseOrder entity to the debitRequestMsg entity that will be sent to the ACME billing service. The reason that the properties are available to us from the instance of the purchaseOrder entity is because they were marked as Distinguished. At run time, the Orchestration Engine will populate an instance of the debitRequestMsg variable with these values.

	?
Figure 15: The Debit Customer Send Shape and Ack Response Receive Shape are connected to the generated Request/Response Web Port.

3. Within the Bill Customer activity, but outside of the Construct Message Shape, add a Send Shape (that will call the Billing Service) and a Receive Shape directly after that.
4. Drag the Send Shape connector to the Web Port so that it locks with the Request. Take the same step to establish a connection between the Receive Shape and the Response. At this point, the orchestration looks like Figure 15.

Now only simple wiring activities remain. You’ll add an Expression Shape to each activity and call the appropriate .NET component to do the work. Because you are dealing with .NET components, you must first configure the interface that you wish to bind to as a variable (as opposed to a Message Variable):

5. On the Orchestration View, under Retail Activities, right-click Variables and create a new variable. Any variables created here are not global and are scoped to the Scope in which they are created. The same is true for Message Variables.
6. Select “.NET Class” and browse to the Northwind.BusinessComponents.RetailOps.Interfaces package. Select the IRetailOps interface and click OK. Name the variable retailService.

In a roundabout way you’ve defined a variable, retailService, as an IRetailOps interface, just as you would with any .NET type. The Orchestration Engine initializes it at run time, just as if it were in a C# or Visual Basic interface.

7. Add an Expression Shape within the Post Funds to GL activity, and add the following code, which is the equivalent of an implicit interface cast in C#:

   retailService = new    Northwind.BusinessComponents.   RetailOps.RetailManager();

The IRetailOps.PostGeneralLedger method takes an instance of the PurchaseOrder class (purchaseorder), performs some work, and returns a Boolean value indicating success or failure. As with any program, you need a variable to store the response so that you can use it as needed.

8. Again, within the Retail Activities Scope, under Orchestration View, create a new variable, this time of type Boolean and provide a name, such as generalLedgerSuccess.
9. Now simply place the call to the retailService instance, passing the purchaseOrder variable (which contains the actual purchase order submitted), and return the response to the generalLedgerSuccess variable:

   generalLedgerSuccess =   retailService.PostGeneralLedger   (purchaseOrderMsg);

Using the object model as a reference, cross checking with the use case and business process diagram, you’ll take the same approach for the remaining activities for both Inventory and Print Scopes. The calling patterns are identical, only the variables and types change. Remember to always use implicit casting of the interfaces to keep the calls type-safe.

Because the API is modeled after the business domain, the steps should be fairly intuitive. If you do get lost or stuck, you may reference the solution which is available in the download.

The last thing to do from an orchestration perspective is to implement the Notify Activity/Group.

10. Right click anywhere inside the Notify Activity/Group and select a Send Shape. Specify the purchaseOrderMsg as the message and “Send Purchase Order” for the Name.

This solution will simply pass through the processed purchaseOrderMsg as a way to notify that the orchestration has completed successfully. Obviously, this is a somewhat primitive notification technique, but it will provide the ability to simulate a notification action and at the same time fully test one way, asynchronous invocation of the orchestration.

Configuring the Orchestration to Receive Messages
Although it is largely a matter of preference, I like to try to leave logical port configuration last so that the focus can remain on the business process itself. Whether you configure ports before or after creating and wiring up your workflow is up to you.

This sample solution will use a Receive Shape to actually receive the purchase order from the originating client. On the left Port surface, right-click anywhere to create a new Configured Port. Provide a Port Name of ReceivePurchaseOrderPort and Port Type called ReceivePurchaseOrderPortType. Specify the communication pattern as One Way as shown in Figure 16. Specify the intent to use the Port to receive messages, and leave the default to specify bindings later. You will notice that under the ReceivePurchaseOrderPortType, BizTalk created an Operation called Operation_1. Rename the Operation to something a bit more intuitive such as SubmitPurchaseOrder.

? Figure 16: A logical One Way Receive Port is created to route purchase orders to the orchestration.

? Figure 17: The ReceivePOPort receive port is added to the left Port Surface.

Notice that the port is completely logical and has no physical bindings or knowledge of any adapters. This is the beauty of orchestration; it requires absolutely no commitments regarding transport or other plumbing, leaving these largely as mere deployment details.

	?
Figure 18: The SendPOPort send Port is added to the right Port Surface.

Connect the new Receive Port to the Receive Purchase Order Receive Shape. Figure 17 provides a snapshot of the orchestration after adding the logical Receive Port.

Configuring the Orchestration to Send Messages
Similarly to the Receive Purchase Order One Way Receive Port you just created, right-click the right Port Surface and create a corresponding One Way Send Port called SendPurchaseOrderPort. Connect the new Send Port to the “Send Purchase Order” Send Shape. The orchestration should now resemble Figure 18. This Send Port will simply pass through the original instance of the purchaseOrderMsg to a destination that we will configure as a file drop during deployment.

Deployment
In BTS 2006, an Application is a group of related artifacts (orchestrations, pipelines, resources, etc.) that are managed as a single unit. When deploying a solution, you can choose the default BizTalkApplication 1 application, or create your own.

BTS 2006 offers two options for deploying BizTalk applications. In production deployment scenarios, the most common is via the BizTalk Server 2006 Administration Console, which is an MMC snap-in style administrative console. During design time, however, developers may use BizTalk Explorer, which provides a light version of the BizTalk Server 2006 Administration Console for use within the Visual Studio IDE.

Using Visual Studio 2005 to Deploy a BizTalk Application

In practical terms, it is very unlikely that a solution will use the BizTalk Explorer for deployment chores outside the local development environment. Often an organization will use BizTalk Server on single or multiple server class machines that are separate from the development environment. BizTalk Explorer does not lend itself well to distributed deployments; however, for developing locally it is the perfect tool to deploy and test a solution and will help to isolate some of the complexity inherent to using the fully featured BizTalk Server Administration Console.

1. After successfully building the entire solution, right-click on the Northwind.BusinessWorkflows.RetailOps project and click Deploy. The project DLL is deployed to the GAC and appropriate entries are made into the BizTalkMgmtDb database.
2. Next, install all remaining assemblies from Table 2 to the GAC. Remember that these assemblies must be strongly named. Again, you may use the existing Northwind.snk file or use your own if you wish.

At this point the example orchestration is not very useful. With the exception of the SOAP Port you created for the Billing Service, there is no physical correlation between the logical Send and Receive Ports and the physical endpoint(s) (adapters) that will be the interface between this application and the rest of the world.

Exposing the Orchestration as an ASMX Web Service
Deploying an orchestration as a SOAP ASMX web service is simply a matter of invoking the BizTalk Web Services Publishing Wizard. There are two options for doing this. One is to deploy an endpoint that is bound explicitly to the orchestration. Because you’ve defined the primary message, purchaseOrderMsg, as a serializable .NET type, exposing the orchestration directly is a perfect choice.

Note that publishing an orchestration itself as a web service may not be the best approach if you are making heavy use of XSD schema or you want to preserve XSD semantics on the incoming document. Note, however, that the trend with vendors (including Microsoft) is to abstract as much about the XML itself from the design-time experience and leave to the plumbing the task of adhering to a specific standard or schema. Although there are passionate debates over using XSD versus XML serializable types (and vice versa), anyone working heavily with XSD can testify to its cumbersome nature. That said, XSD is a very common sure-fire approach to maintaining strict control over the message while guaranteeing interoperability and is especially useful in maintaining contract-based semantics where traditional interfaces are either unpopular or unsupported. If maintaining entities/messages as XSD schema is the chosen approach, the second option will allow you to publish schema as a web service and provides more control over the naming, request, and response schema used.

	?
Figure 19: Using the BizTalk Web services Publishing Wizard, an orchestration can be easily exposed as an ASMX SOAP endpoint.

Since you’ve opted for exposing the orchestration directly, choose the first option below:

1. To start, under Tools, click BizTalk Web Services Publishing Wizard and click Next.
2. Choose the first option (Publish BizTalk orchestrations as web services), as shown in Figure 19 and click Next.
3. On the next screen, select the Northwind.BusinessWorkflows.RetailOps.dll assembly and click Next.
4. On the Orchestrations & Ports step, check the option to merge all Ports into a single ASMX service definition, and proceed to the next screen.
5. For the namespace, enter a valid URL in the textbox such as “http://NorthwindTraders.com” and click Next.

	?
Figure 20: Publishing details such as location, security, and BizTalk Application are configured via the BizTalk Web services Publishing Wizard.

6. Replace the default Location entry with a cleaner name such as http://localhost/Northwind.Services.RetailOps. Enable anonymous access and select the option to create a physical Receive Location in the BizTalk Application 1 application. Figure 20 summarizes these options.
7. On the final screen, click Create to deploy the SOAP service interface to the local IIS web site.

This results in the deployment (and creation) of an IIS application that hosts the Northwind.Services.RetailOps web service. If you followed the naming guidance, the URL should be:

http://localhost/Northwind.Services.RetailOps/   WebService_Northwind_BusinessWorkflows_RetailOps.asmx

Navigating to the URL loads a familiar WSDL discovery page as shown in Figure 21.

	?
Figure 21: Browsing to the URL after publishing of the service via the BizTalk Web services Publishing Wizard is complete reveals a familiar discovery Web page.

Binding the SOAP and File Drop Locations
Thanks to the indirection provided by the logical ports, you can begin by supporting the submission of purchase orders via HTTP SOAP. You can leverage this same indirection to support additional protocols and file formats.

At this point, the only thing left to do is associate the logical ReceivePurchaseOrderPort and SendPurchaseOrderPort with the respective HTTP URL and physical file drop URI.

1. Within Visual Studio, click View and select BizTalk Explorer. Expand the Orchestrations folder and select the Northwind.BusinessWorkflows.RetailsOps Orchestration as shown in Figure 22.

	?
Figure 22: The BizTalk Explorer is a one-stop show for managing BizTalk artifacts from Visual Studio.

2. Within the Orchestrations folder, right-click the Northwind.BusinessWorkflows.RetailsOps Orchestration entity and click Bind. Under InBound Ports, select the Receive Location created by the BizTalk Web Services Publishing Wizard. This connects the logical ReceivePurchaseOrderPort Receive Port with the physical SOAP/ASMX endpoint created by the wizard. Click OK to close the Port Binding Properties.

	?
Figure 23: The FILE Transport Properties dialog box allows you to specify the destination folder for file drops.

Now you’ll correlate the logical SendPurchaseOrderPort with a physical Send Port.

1. Right-click the SendPorts folder ,and click Add Send Port. Select the Static One-Way port. In the Static One-Way Send Port Properties window enter FileDrop for the Port Name, choose FILE as the Transport Type, and enter a URI of C:OutboundCompletedPurchaseOrders (or something similar) as shown in Figure 23. Click OK.
2. In the tree view on the left pane, under Send, set the Send Pileline property to use the Microsoft.BizTalk.DefaultPipelines.XMLTransmit Pipeline, and click OK to exit.
3. Open the orchestration bindings and configure the logical SendPurchaseOrderPort to use the physical FileDrop Port you just created.

Verifying Bindings, Enlisting, and Starting the Orchestration
To verify the orchestration bindings, refer to Figure 24, which provides a snapshot of all required bindings and settings.

	?
Figure 24: The Port Binding Properties provides a summary of Inbound and Outbound logical and physical port mappings.

The process of enlistment associates ports and orchestrations with the appropriate host and creates the corresponding subscriptions within the configuration database.

1. Right-click the Northwind.BusinessWorkflows.RetailsOps orchestration and click Enlist.

At this point, the orchestration and ports are not yet capable of receiving or sending messages because the orchestration has not yet been started.

2. Right-click the Northwind.BusinessWorkflows.RetailsOps orchestration, and click Start.

Testing

	?
Figure 25: Generating a UI wrapped proxy for the SOAP endpoint exposed by the SendPO orchestration using .NET WebServiceStudio, a free tool for testing SOAP Web services.

You’ll need to perform some testing to verify that the orchestration and all services meet the functional requirements.

First, you should be able to submit a purchase order for processing via a SOAP service endpoint. To test this, I use a great tool called Web services Studio (see Sidebar 4, “.NET WebServiceStudio”). This tool makes a fantastic, no-frills test harness for exercising SOAP services. The value and necessity of using test harnesses to provide interactive testing of services that make up a complex application cannot be overstated. After querying the WSDL file at the endpoint, I have a contract that I must fulfill as shown in Figure 25. Populating all relevant fields, I submit the purchase order to simulate the interface that the new online storefront will use.

Since this is a one way, asynchronous call, I do not expect any response via SOAP other than HTTP 202 Accepted (any errors in receiving the message would have resulted in a SOAP fault). Figure 26 shows the expected response from the RetailOpsService.

? Figure 26: An HTTP 202 (Accepted) is returned by the SOAP endpoint indicating that the message was accepted asynchronously by the orchestration.

? Figure 27: The orchestration outputs the original message contents to the specified file folder to simulate notification of a successful transaction.

Finally, to ensure that the purchase order was processed, inspect the C:OutboundCompletedPurchaseOrders folder (or physical location you configured in the bindings) for an XML file corresponding to the purchase order submission. As shown in Figure 27, there should be one .xml file for each submission made during the test. Opening the XML document reveals the details of the purchaseOrderMsg payload.

Delivery
At this point, the Retail Operations application is ready to be turned over for integration with the new online store front! Leveraging the Retail Operations application is simply a matter of consuming the service endpoint and invoking the service. In addition, the foundation has been laid for integrating various other applications with the new and improved Northwind back-office, all the while increasing transparency and increasing automation so that the business process can be managed more efficiently.

In addition to a very solid Messaging Engine, I demonstrated how the Orchestration Engine is a very flexible tool for getting the most out of messaging while naturally supporting the implementation of complex business process via intuitive and easy-to-use workflows.

After a high-level overview (in Part 1 of this article), you leveraged both the Messaging Engine and Orchestration Engine by jumping into a common integration scenario and demonstrated how a new, automated workflow, along with .NET, and ASMX SOAP web services could be implemented to streamline existing business processes while providing the building blocks for improved business process management.

Furthermore, you now understand the foundation for integrating the new solution with an existing business process to drive value without abandoning legacy systems, providing virtually endless possibilities for connecting new and existing services and applications without impacting the business process itself.

Finally, you applied some design techniques allowing you to address the problem domain in a loosely coupled manner that can be extended to support new workflows, components, and services as the needs of the organization change and grow.

Although our scenario has been grossly simplified for the purposes of illustration, it is a good example of similar integration scenarios that are prevalent in the enterprise today. It is clear that BizTalk Server 2006 is a very practical solution for addressing many of these EAI chores and goes far beyond messaging to provide a toolbox for addressing the integration spaghetti that exists as a result of the evolution of new and existing investments in enterprise software.

Final Thoughts
During the introduction (see the May/June issue of CoDe Magazine), I suggested that the Orchestration Designer provides a hint as to what the future of building software might look like (see Sidebar 5, “Orchestration Designer for Business Analysts”). As a matter of fact, Windows Workflow Foundation (WF), a new workflow modeling framework that is part of .NET 3.0, builds upon what Microsoft, and the industry as a whole, has learned from BizTalk Orchestration. Looking even further into the future, I believe that workflow-modeled software will become a mainstay in developing line-of-business applications, and we will start to see a number of specializations emerge in the industry, creating a distinction between traditional programmers and future information workers.

New technologies, including WF and Windows Communication Foundation (WCF) will no doubt be relevant to BizTalk Server, but I believe that by leveraging BizTalk Server 2006 as the integration glue for developing new applications that assimilate with legacy systems today, while laying a solid foundation for future enterprise application integration projects in the future, BizTalk will continue to provide tremendous value as an application server platform.

I hope that you have developed an appreciation for the depth and breadth of the core functionality and features available in BizTalk Server 2006 and that you will consider it for your future adventures in application integration!

Acknowledgments
I would like to thank Todd Sussman, Principal Consultant and BizTalk VTS, for teaching me what the books and hands-on experience could not. Those coffee breaks, instant messaging sessions, and white board discussions have been invaluable.

In addition, I would like to thank Tim Heuer and Diane Faigel at Microsoft for their help with the BizTalk Server 2006 documentation, which is referenced throughout the article.

Last, but certainly not least, I would like to acknowledge Juval Lowy, who over the course of a week in the summer of 2005 changed my career forever. His books, articles, classes, and lectures continue to provide valuable insight and mentoring; the fruits of which are interwoven throughout this article and my work at large.