BizTalk Tutorial, Part I: Jean and David: An E-Commerce Story

By Brian E. Travis

Abstract

The marriage of XML and business-to-business ( B2B) commerce is a big topic these days. XML can be used as an open-standard, platform-independent way to communicate between companies. An XML document can be created using an interface system that translates business information into a deliverable format. Then, the XML document can be transported in many different ways over public or private networks to a business partner. An interface system interprets the XML document on the receiving end, where it goes through the business processes of the recipient company.

The marriage of paper and business-to-business ( B2B) commerce is a big topic these days. Paper can be used as an open-standard, platform-independent way to communicate between companies. A paper document can be created using a clerk who translates business information into a deliverable format. Then, the paper document can be transported in many different ways over public or private networks to a business partner. A clerk on the receiving end interprets the paper document, where it goes through the business processes of the recipient company.

Now, let's replace "paper" in the previous paragraph with " XML", and "clerk" with "interface system" and see that XML provides a way of replacing both with a more reliable means:

This article describes a typical business transaction, and shows how XML can be used to replace expensive and error-prone interfaces now in place.

Business Arrangements

When two companies want to do business with each other, certain things must be done. First, the two companies usually have some form of agreement that defines the relationship. This agreement will have provisions for payment, delivery of goods or services, conflict resolution, and so forth.

Once these terms are agreed to, an interface is created by each company that consists of business rules that must be enforced on each side of the transaction.

Let's take a look at a typical business transaction the way it has been done for centuries.

Jean

First, an event triggers the need for a business transaction. This event might be someone in an organization wanting to buy a product from a vendor. This particular event requires a purchase order to be sent to the organization.

Let's say I want to by a product from your company. One of the procedures in my company is to create a purchase requisition form, which has fields that help the appropriate people process the request.

I give the purchase requisition to the person in my organization who is responsible for processing requisitions and creating purchase orders. Her name is Jean. Jean knows the business rules for processing these documents, and will take my request from there.

The first thing Jean does is to make sure I have the authority to spend the company's money. Jean looks at her list of budget approvers, and notices that my name is on the list, and that I have enough authority for this purchase.

Next, Jean makes sure we don't already have a store of the products I requested in stock. Ordering parts when we already have parts is a bad business idea, and this business rule has been put in place to prevent that possibility.

Once Jean is satisfied that my order is valid, she adds my purchase requisition to the pile of purchase requisitions in one corner of her desk. There are other people in my company who want to buy products from your company. Another business rule states that, unless the order is an emergency requisition, no purchase order is made until there are at least three items to be ordered. It so happens that Jean notices there are two other purchase requisitions for items from your company, so it's time to create a purchase order with these three items.

Jean puts a form in her typewriter and starts filling out the fields. There are fields for address information, financial and shipping terms, and, finally, a place where the part numbers, descriptions, and prices are placed.

Jean completes the form and takes it out of her typewriter. Then, she puts in another blank document, a #10 paper envelope. She types my company name and address in the upper-left-hand corner and your company name and address in the center of the envelope. She doesn't need to explicitly say that the address in the center of the envelope is the "To" address and the other is the "From" address. By two centuries of convention, we all know that the address in the center is the destination address, and the address in the upper-left is the return address.

At the top of the "to" address, Jean puts an important piece of information: "Attn: Purchase Order Processing Department". We will see later that this is an invocation of a method that causes your company to do certain things.

Jean takes the envelope document out of the typewriter, folds the purchase order document, puts it in the envelope, and seals it. Then she walks down to the corner and puts the package in a blue box. Through the magic of the U.S. Postal Service, the envelope takes a mysterious journey that results in it being delivered to your company's mailroom.

This is an important part of the story.

If our two companies had to design a purchase order delivery system, that is, if we didn't have the infrastructure provided by the post office, we would have spent most of our time designing the delivery system, instead of the more direct business of ordering parts. We would need to develop an addressing structure, hire couriers or contract courier services, worry about insurance, accidents, and a thousand other problems. Lucky for us, there is an infrastructure in place that we can use for a small fee.

It is also important to note that Jean had several options for delivering the message from my company to yours. She used the U.S. Postal Service, but she could also have used FedEx, Airborne Express, or even a local courier if our companies were within bicycling distance. She could also have chosen to fax the order, or to send it by email or even a Web page interface to you if there was a need. She chose the blue box on the corner, the U.S. Postal Service.

A couple days later, the envelope shows up at your company's mailroom, where the mailroom clerk notices the "Attn:" designation Jean placed at the top of the address block, and routes the envelope internally to the person responsible for processing purchase orders. His name is David.

David

David looks at the envelope, noting who sent it, then opens the envelope and takes the business document out. David is responsible for processing many different kinds of business documents. He enters purchase orders, invoices, RFPs, and others.

He notices that our document is a purchase order, so he goes into "purchase order process" mode. David is the keeper of your company's business rules for processing a purchase order. First, David makes sure your company and mine have a business arrangement for doing these transactions. This business arrangement probably states terms and conditions such as shipping times, return policies, and payment details. He then checks to make sure that my company has paid its bills, and that there is nothing in dispute. Sending items to a company that is not paying is a bad business idea.

Once David is satisfied that your company has a current business arrangement with mine, he moves over to his purchase order processing system and transcribes the information from our purchase order to his system, using the business rules that your company has in place. One of the rules here is to send a request to the warehouse to see if the items on the purchase order requested are in stock.

He finds out that two of the three items are in stock and can ship immediately, but the third is out of stock and must be back-ordered.

As part of our contractual arrangement, your company promises to send me a confirmation of the purchase order Jean sent to David. So David puts a form in his typewriter and fills out the information required. He notes that two of our items will ship today, and the third needs to be backordered.

David takes the form out of the typewriter, puts a blank envelope in, and types two addresses. He refers to the envelope that Jean sent him and swaps the two address blocks, putting my company's address in the center, and your company's address in the upper-left-hand corner.

He takes out the envelope, folds, inserts, and seals the confirmation and drops it in a mailbox. A couple days later, Jean gets the confirmation and processes it according to my company's business rules. One of those rules is to contact the three people in the company and tells them the status of their orders. The one person who ordered parts that are backordered might want to have Jean send a cancellation order your company and place a new order to another supplier of that particular part. This event would trigger certain other business rules on both sides of the company.

This is just one scenario. Jean has other ways to deal with purchase requisitions. For example, if an order is a rush, it might not need to be combined with two other items. Jean might also fax a rush order directly to David, or even call him on the phone to confirm that the order was received. Sometimes, Jean might decide to send a purchase order and supporting documents by overnight courier. These are transport issues, but there are many more that Jean can use to make her job more effective. Each one of these decisions is made based on business rules.

The point is that there are rules that have been in place for the life of my company, and other rules in place at your company. The advent of XML, or even computers, will not change the requirements either of our companies have for doing our business. All we can expect the computer to do is to help us do our business more effectively.

Interchange

Over the years, my company has developed a set of applications and business processes that allow it to do business. We select computer programs, interfaces, and people to make everything work.

You also have selected a set of applications and business processes that work well for your business. However, our systems are probably completely incompatible with each other. In the case study above, we have used paper as the universal interchange form for getting business information between our companies.

Paper is foreign to both of our systems, however, and requires an interpreter to convert to and from our internal systems. The interpreter needs to know the business rules and be able to perform the translation. In this example, Jean and David fill that role for our respective companies.

The transaction I described above does not happen in a vacuum. Before any purchase orders were sent, your company and my company formed a contractual arrangement for doing business. That contract set out payment and shipping terms, dispute resolution and other things businesses need to do business. Part of this contractual arrangement was the form in which our transactions take place.

In the case of a purchase order, you told us what kind of information you needed in order to successfully process the order, and we told you what format we would like to see the confirmation returned.

Where Does XML Come In?

This type of transaction has been happening for centuries, and works well. An automated system that emulates this would be useful for making the transaction more efficient. In next month's < TAG>, we will explore how XML can augment or replace expensive an inefficient parts of the business transaction described here. <end/>