Learning BizTalk Server 2000: Lesson 5

Igor Leybovich and Scott Woodgate
Microsoft Corporation

May 2001

Summary: The fifth in a series of 7 articles designed to show you how Microsoft BizTalk Server 2000 can help your business exchange a variety of documents with business partners, as well as integrate internal business processes and applications. In this lesson, we look at how the Requisition document is prepared for submission to a trading partner, and at the steps taken within BizTalk Messaging Services to accomplish this task. (6 printed pages)

Note
   
You will need to install Microsoft® BizTalk™ Server 2000 in order to complete this lesson. Before you install Microsoft BizTalk Server, make sure you have read the Readme.htm and Installation Guide.htm documents, paying particular attention to the following important prerequisites:
  • You must have a computer running Microsoft Windows® 2000 with Service Pack 1 or above (Professional or Server both work), including IIS and MSMQ services, and an account with administrative rights on that computer.
  • You must have Microsoft SQL Server™ 7.0 with Service Pack 2 or above (you can install SQL Server Desktop Edition if you choose to run everything on a single workstation running Windows 2000 Professional) and password for the "sa" account. If you use SQL Server 2000, you must configure it for "mixed" security mode in the install wizards that is not the default.
  • Microsoft Visio® 2000 SR1 Standard or above must be installed on the computer where you are installing BizTalk Server.
  • In Internet Services Manager, turn off the Enable authoring option on the Server Extensions tab of the Default Web Site.
Also, in order to execute the scripts for these lessons, you need to install the MSMQ component of Windows 2000.

Contents

Introduction
The Map Holds the Answer
Putting it Together
Testing the Solution

Introduction

In the previous lessons, we learned how Microsoft BizTalk Server 2000 accepts documents from line-of-business applications, and how these documents are processed within BizTalk Orchestration Services.

Now let's look at how the Requisition document is prepared for submission to Contoso Ltd., and the steps taken within BizTalk Messaging Services to accomplish this task.

The Map Holds the Answer

As you recall, the Requisition document we have been using so far represented an internal purchase requisition produced by an application at Northwind Traders. Once this requisition is approved by a business process (implemented in our scenario using BizTalk Orchestration Services), a purchase order must be sent to Contoso to actually buy the merchandise. Do you see what's missing here? We don't have a purchase order (PO) document yet; all we've got is a requisition! However, we do know the structure of Contoso PO, and we also know that most of the data required to create the PO document, such as list of items and a billing address, is actually contained within the requisition. Can BizTalk Server once again assist us in transforming one document into another without doing much coding? If you answered yes, you are right!

The tool that helps us do this job is BizTalk Mapper. BizTalk Mapper uses another Internet standard called XSL Transformations (XSLT), which is a language for transforming XML documents from one XML schema into another.

XSLT is a W3C recommendation and you can learn more about it by visiting W3C's Web site at http://www.w3.org/TR/xslt.html.

Luckily, you don't need to know anything about XSLT to use BizTalk Mapper. BizTalk Mapper is a highly graphical tool that presents you with both specifications side-by-side and lets you define transformations by simply drawing lines between the specification fields. For those cases when simple rules such as "Field A from Document 1 is mirrored into Field B in Document 2" are not enough, the Mapper offers a series of powerful transformation elements called functoids. There are over 60 functoids included with BizTalk Mapper, enabling you to perform mathematical, logical, string, date/time, scientific, database, and other operations. There is also a script functoid that enables you to write your own subroutines in Microsoft Visual Basic® Scripting Edition (VBScript), in case none of the existing functoids are suited for the operation. The resulting VBScript code is embedded directly into the XSLT generated by BizTalk Mapper.

You can do even more powerful things using "cascading functoids," a method of passing results of one functoid execution as an input to the next functoid.
You can also create custom functoids in a language such as Visual Basic and add them to your functoid pallet for future use.

For our business scenario, we built a map that translates Northwind's requisition document into Contoso's purchase order. This map is stored in the file ContosoPOMap.xml located in the C:\LearnBizTalk\Documents\ directory. By opening this map in BizTalk Mapper, you will see the screen shown in Figure 1.

Ee265608.biztalk_lesson5_1(en-US,BTS.10).gif

Figure 1. A requisition mapped to a purchase order in BizTalk Mapper

Most of the fields required to build the PO document for Contoso were already present in the Requisition document, perhaps under different names. Some of the fields, such as PO Number, are new, and therefore their values had to be generated.

You can see that we used three functoids in this map: a string concatenation functoid that combines two address fields in the requisition into one field in the PO, a date/time functoid that generates the current timestamp for the "created" field, and a script functoid that implements a specific business rule to generate a PO number (in our simplified world it simply picked a random number for the PO number).

If the values of some destination fields do not change over time (for example, your company's name and address), BizTalk Mapper enables you to specify constant values to be used. Simply highlight the field for which you need to provide a constant value, click the Values tab, and enter your value. Figure 2 shows the Values tab.

Ee265608.biztalk_lesson5_2(en-US,BTS.10).gif

Figure 2. Specifying constant values in BizTalk Mapper

Putting it Together

Now that we have created the map, let's go back to BizTalk Messaging Manager and configure the channel called "Channel To Contoso", which is used to deliver the PO to Contoso while using our map.

Remember, this is the same channel that we specified in XLANG schedule drawing described in Lesson 3 when we configured an orchestration port "Send PO" that delivered the Requisition document to Contoso. Note that our XLANG schedule outputs the same Requisition document as it receives, and it is not aware of any potential transformations to this document (such as translation into a Purchase Order) that occur later inside the BizTalk Messaging Services. This separation between a business process used for the requisition approval and technical details behind managing document format and delivery mechanism is what makes the overall solution so flexible and easily adaptable.

The key point here is that BizTalk Orchestration Services is the technology for creating business processes, while BizTalk Messaging Services is the technology for reliably sending documents between business processes to integrate them.

In the future, if Contoso decides to change the format of its POs, you will only be required to update your specification for Contoso PO and update the map to reflect the new specification changes, rather then recreate the entire business process.

When you configure the channel in BizTalk Messaging Manager, if you specify an outbound document definition that is different from an inbound one, BizTalk Messaging Manager will automatically ask you to provide a map document to translate between these two document specifications. Figure 3 shows this process.

Ee265608.biztalk_lesson5_3(en-US,BTS.10).gif

Figure 3. Configuring a channel in the Channel Properties dialog box

Testing the Solution

Let's test the solution we have built so far. Before continuing, locate the L5Post.vbs script file in the C:\LearnBizTalk\Scripts\ directory and double-click to run it. This script will undo the temporary changes we made to our orchestration process at the end of Lesson 3 and will once again enable BizTalk Orchestration Services to output the document to BizTalk Messaging Services.

Now copy the ReqToDecline.xml file we used earlier and paste it into the C:\LearnBizTalk\Pickup\ directory. As before, this requisition gets declined and you receive the message box that informing you of this.

Copy and paste the ReqToApprove.xml file instead. This requisition will get approved and sent by BizTalk Orchestration Services to BizTalk Messaging Services. The channel receives the document, converts it into Contoso's PO by applying the map we specified, and for now BizTalk Messaging Services simply writes the resulting document under the name ContosoPO.xml to the C:\LearnBizTalk\Output\ directory.

Go ahead and double-click the output file to open it in Microsoft Internet Explorer. Look at the values of PO Number field that was randomly generated by the script functoid, the Created field that has the time when this file was generated, and the Address field that contains the values from both original Addr1 and Addr2 fields concatenated by the string functoid.

In the next lesson, we will learn about some different ways to deliver documents to your business partners and how standard Internet protocols once again help to make this job easier.

Show: