Learning BizTalk Server 2000: Lesson 6
Igor Leybovich and Scott Woodgate
Microsoft Corporation
May 2001
Summary: The sixth 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, you will learn about the business process used to send a purchase order to a trading partner, and how this order is received and stored by the partner. (6 printed pages)
NoteYou 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
IntroductionChoosing a Protocol
Receiving Documents Over HTTP
Using the Queue
Testing the Scenario
Introduction
In this lesson we will learn about the process Northwind uses to send the purchase order (PO) to Contoso, and how this order is received and stored by Contoso.
Choosing a Protocol
After the PO document is generated, it needs to be submitted to Contoso for processing. When choosing a transport for this task, you must consider several important aspects:
- The transport must use a standard protocol—you want to know that your trading partner can receive documents using a variety of software running on any platform.
- The transport must be reliable—you want to be sure that the document was indeed received by the trading partner on the other side.
- The transport must be secure—you want to know that you can encrypt the entire transmission process to protect sensitive data.
For our solution, we chose a transport that utilizes the HTTP protocol. HTTP is a standard protocol used by Internet browsers to retrieve information from Web servers. Most administrators of corporate firewalls feel comfortable with allowing transmissions based on HTTP to be sent outside the company. This is an important aspect of the process, and it involves choosing the right transport. Your Microsoft BizTalk Server needs to communicate with internal applications, databases, and legacy systems; therefore, it must be located within the firewall. At the same time, it may need to send and receive documents from an outside partner, preferably using a well-known protocol that can go through the firewall.
HTTP is reliable from a transport perspective because it defines a standard way for the receiving side to communicate the status of the transmission back to the sender. From a business process perspective, you want to be able to recover when temporary Internet glitches cause a transmission failure. BizTalk Server can monitor the transmission process, retry sending documents for a pre-configured number of times, and alert an administrator if transmission was unsuccessful.
Finally, HTTP has a secure variation, HTTPS, which allows encryption of the entire transmission by using standard algorithms. HTTPS encrypts the entire communication stream with a trading partner, and it can be used in conjunction with encrypting and digitally signing the document to provide an extra level of security.
An alternative way of sending documents to business partners is to use the File transport to save a document into a file on a hard drive, and then use another process to pick up these files and deliver them to a partner with an EDI-VAN dialer or an FTP process.
Receiving Documents over HTTP
Now let’s look at what must be done on the receiving side in order to accept a document transmitted by BizTalk Server using HTTP and process it. For our scenario, we will assume that Contoso also uses BizTalk Server to receive POs and generate and send invoices.
Since BizTalk Server is running on Microsoft Windows 2000 Server, a platform that includes Internet Information Server (IIS) 5.0, Contoso can use a fairly simple Active Server Page (ASP) script to accept documents from Northwind’s BizTalk Server and submit them for processing to BizTalk Server on Contoso’s side.
Please note that in these lessons, we use a single instance of BizTalk Server to simulate processing on both Northwind and Contoso’s sides. In the real world, these would be separate servers running at each respective company’s sites.
After an ASP script receives the document, it must eventually send it back to BizTalk Server for further processing. While there are several options available to achieve this, we would like to emphasize the importance of designing a solution that can achieve this result in a fail-safe way. For example, if Contoso’s servers are temporarily down for a scheduled maintenance or an upgrade, or if Contoso is experiencing an unusually high load on their servers, and the processing of POs cannot be done in real time, this should not affect Northwind’s or any other trading partner’s ability to submit PO documents. As a matter of fact, Northwind should be completely unaware of anything happening on Contoso’s side and of technology being used, short of the fact that the PO can be transmitted successfully. Therefore, although BizTalk Server provides a standard way to accept documents using COM, it isn’t the best approach in this particular example.
Let’s look at a better way to architect this part of a solution. Once the ASP script receives the transmitted document, it should store it on some reliable medium, and then exit indicating that the document was successfully received. Meanwhile, BizTalk Server can retrieve the stored document and process it in a completely asynchronous manner. In Lesson 2, we learned about File Receive functions in BizTalk Messaging Services and how to use them to monitor directories for files that have to be processed. So, in one possible scenario, our ASP script could simply store a document into a file to be picked up later by a File Receive function. Such architecture provides a lot of flexibility for us to decide when documents are to be processed by BizTalk Server, and to decide when to add more BizTalk Servers to process incoming documents, should business needs increase.
Now we would like to present an alternative way of achieving the same reliable results without storing documents in files and having the added benefit of being transactional.
Using the Queue
Message Queuing (also known as MSMQ) is one of the standard components of Windows 2000 Server, and it provides a simple and reliable way to build an asynchronous solution just like the one we are designing.
After the document is received by an ASP script, instead of storing it into a file on a hard drive, we can post the document as a message on a message queue on the server, and then deliver it to BizTalk Messaging Services by using a Message Queuing Receive function, which works similarly to a File Receive function.
The overall process is presented in Figure 1.

Figure 1. BizTalk Messaging Services transaction using ASP and MSMQ
To create a new Message Queuing receive function, open BizTalk Server Administration, expand BizTalk Server Group, right-click Receive Functions, click New, and then click Message Queuing Receive Function. Provide a name for your function, then enter the queue name for the polling location, and click Advanced to enter a name of a channel that will process documents received by this function. You can look at the properties of the ReceivePO Message Queuing Receive function that was configured during setup. This receive function will process PO documents accepted by the ASP script discussed previously. This function has been temporarily suspended, so the documents will remain on the queue, which enables you to examine them. You can re-enable this function at the end of this lesson.
If you are using a private message queue to store documents, enter the queue name using the following format: DIRECT=OS:.\private$\<queue_name>. If you are using a public queue, enter the queue name in the following format: DIRECT=OS:<server_name>\<queue_name>.
Now let’s review the script inside the ContosoReceive.asp file to see the series of steps performed to accept the data transmitted by BizTalk Server, and to post it to a message queue. We begin by using a BinaryRead method of a Request object provided by ASP to read all of the transmitted data. Next, we utilize Microsoft Active Data Objects to transform the received data from binary format to text format. Finally, we use Message Queuing functions to create a new queue message and post it to a private queue that we chose.
You can see the entire source code inside the ContosoReceive.asp file located in C:\LearnBizTalk\ASP\ directory.
Testing the Scenario
Before testing our scenario, please locate the L6Post.vbs script file in the C:\LearnBizTalk\Scripts\ directory and double-click to run it. This script will restore the configuration of the Port To Contoso messaging port that was modified earlier and instruct it to deliver documents to Contoso using HTTP transport, rather than writing it to a file as was done in Lesson 5.
Now, copy the requisition file ReqToApprove.xml and paste it into a Pickup directory. The file will get processed by a File receive function, then passed from BizTalk Messaging Services to BizTalk Orchestration Services for approval, then delivered back to BizTalk Messaging Services, and finally transmitted to Contoso by using the HTTP protocol.
An ASP script simulating Contoso’s side will read the transmitted data, convert it back into a document, and post the document to a local private queue.
Afterwards, a Message Queuing receive function should retrieve the document off the queue and submit it to BizTalk Messaging Services, however as you may recall we temporarily disabled this receive function so we can examine the document posted to the queue.
In order to see the messages on the queue, open the Administrative Tools application on your Windows 2000 computer and double-click the Computer Management icon. In Computer Management, expand Services and Applications and locate Message Queuing. Expand Message Queuing, expand Private Queues, and then expand ContosoPOQueue. When you click Queue Messages in the left pane, the right pane shows all the messages currently posted to the queue. You can right-click on the message in the right pane, click Properties, and then click the Body tab to see the beginning of the message body.
After you examine the message, delete it from the queue by right-clicking Queue Messages in the left pane, and then clicking All Tasks and Purge.
In the next lesson, we will discuss the final steps of our scenario, such as processing the Purchase Order document by Contoso, generating the Invoice, and delivering it to Northwind.