The BizTalk Framework in B2B Transactions

[Previous] [Next]

Let's look at a scenario of a business that will enable B2B transactions by using the BizTalk Framework to create XML documents.

We are a manufacturer of radio-controlled toy cars: serious toy cars. Our cars run on gasoline and have enough of a range to chase dogs and small children around the neighborhood. To make our toy cars, we buy parts, supplies, and services from a number of suppliers. These suppliers also have their own suppliers and other customers.

We want to use the Web to communicate with our suppliers and also to keep in touch with our customers, both retail stores and end-users. And of course we want to reuse as much of our existing processes as possible.

Preparing the Purchase Order

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 my company wants to buy 10 small engines 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. This is an internal document designed to communicate between departments in my company.

After I fill out the purchase requisition, I give it to the person in my organization responsible for processing requisitions and creating purchase orders. Her name is Jean. Jean knows the business rules for processing these documents and will use these rules to deal with my request.

The first thing that Jean does is 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 that we already have in stock 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. Other people in my company want to buy products from your company. As part of the agreement between your company and mine, we promise that, unless the order is an emergency requisition, no purchase order is made until there are at least three requisitions to order items from your company. It so happens that Jean notices two other purchase requisitions for items from your company, so it's time to create a purchase order with these three items.

Jean pulls up a form in her word processor and starts filling out the fields. The form has fields for address information, financial data, and shipping terms, and a place to put the part numbers, descriptions, and prices.

Jean completes the form and prints it. Then she pulls up a form for another document—a #10 paper envelope. She types my company's name and address in the upper left-hand corner and your company's 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. From centuries of convention, we all know that the address in the center of the envelope is the destination address and the address in the upper left-hand corner is the return address.

Above your company's address, Jean puts an important piece of information: Attn: Purchase Order Processing Department. Later we will see that this is an invocation of a method that causes your company to perform certain actions.

Jean prints the envelope, folds the purchase order document, puts it in the envelope, seals it, and adds proper postage. Then she walks down to the corner and puts the envelope in a blue box. Through the magic of the U.S. Postal Service, the envelope takes a mysterious journey that ends in 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 much of our time designing the delivery system, instead of dealing with the more direct business of ordering parts. We would need to develop an addressing structure, hire couriers or contract courier services, and worry about insurance, accidents, and a thousand other problems. Lucky for us, an infrastructure is already in place that we can use for a small fee.

It's 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 of each other. She also could have faxed the order, sent it by e-mail, or even posted it to a Web page interface.

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

Processing the Purchase Order

David looks at the envelope, notes who sent it, and then opens the envelope and takes the business document out. David is responsible for processing many different kinds of business documents. He deals with purchase orders, invoices, and Requests for Proposals (RFP), among others.

David notices that the 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 that 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 no transactions between our companies are 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 your rules is to send a request to the warehouse to see whether the items requested in the purchase order are in stock.

David 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 brings up a form in his word processor and fills out the information required. He notes that two of our items will ship today and the third needs to be back-ordered.

David prints the form, brings up an envelope form, 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 and inserts the confirmation, seals the envelope, adds the proper postage, and drops it in a mailbox. A couple of 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 who made purchase requests and tell them the status of their orders. The one person who ordered parts that are back-ordered might want to have Jean send a cancellation order to 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 transaction.

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

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

Interchange Evolution

My example company has developed a set of applications and business processes that allow it to do business. We select computer programs, interfaces, and employees 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. Our companies use paper as the universal interchange format for exchanging business information, but human interpretation is required to process the paperwork.

The interpreter needs to know the business rules and be able to perform the translation. In our case study, Jean and David fill that role for our respective companies.

The transaction I described does not happen in a vacuum. Before I sent any purchase orders, your company and my company formed a contractual arrangement for doing business. That contract set out specific terms for payment, shipping, 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 to successfully process the order, and we told you in what format we would like to see the confirmation.

This type of transaction has been happening for centuries and works well, but an automated system that emulates it would be useful for making the transaction more efficient. The BizTalk Framework emulates this model for getting information from one place to the other.

Ordering by Using the BizTalk Framework

A BizTalk document is a SOAP 1.1 message in which the body of the message contains one or more business documents. The SOAP envelope is described in Chapter 8. Figure 9-1 illustrates the different parts of a BizTalk document.

click to view at full size.

Figure 9-1. A BizTalk document is a SOAP 1.1 message that has a number of elements designed to route and deliver business documents.

A BizTalk document can be thought of as an extension of a SOAP document. The set of elements in a BizTalk document come from several namespaces, each one optimized for a particular purpose. The tags in these namespaces are called BizTags.

The entire document is contained in the SOAP Envelope element—that is, Envelope is the document's root element. As you might recall from Chapter 8 and as illustrated in Figure 9-1, a SOAP document consists of an optional Header element and a required Body element. In a BizTalk message, the SOAP:Header element is required because it contains some required BizTags. The SOAP:Body element contains the business data, which consists of one or more business documents.

Table 9-1 lists the BizTags in the BizTalk header's SOAP:Header element. Each one of these elements has its own namespace, which you can learn more about at the schemas.biztalk.org site.

Table 9-1. The elements contained in the BizTalk header's SOAP:Header element.

BizTag Name Required Namespace
delivery Yes http://schemas.biztalk.org/btf-2-0/delivery
properties Yes http://schemas.biztalk.org/btf-2-0/properties
manifest No http://schemas.biztalk.org/btf-2-0/manifest
process No http://schemas.biztalk.org/btf-2-0/process

The BizTalk document by itself can't really do anything until you send it somewhere. Transporting the document is the job of the transport envelope, which can be just about any electronic transfer protocol, such as HTTP, SMTP, or FTP. The BizTalk 2.0 specification describes only HTTP bindings.

Let's take a look at the BizTalk Framework tag set in action. Listing 9-1 shows a BizTalk document that provides the same data as the envelope and paper case study with Jean and David. Table 9-2, which follows the listing, describes this document line by line. Appendix B contains the BizTalk Framework 2.0 Document and Message Specification in its entirety.

Listing 9-1. A BizTalk document containing a purchaseorder.

 

NewPO.xml

1<?xml version="1.0"?> 2<SOAP-ENV:Envelope 3 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 4 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 5 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 6 <SOAP-ENV:Header> 7 <dlv:delivery SOAP-ENV:mustUnderstand="1" 8 xmlns:dlv="http://schemas.biztalk.org/btf-2-0/delivery" 9 xmlns:agr="http://www.trading-agreements.org/types/"> 10 <dlv:to> 11 <dlv:address xsi:type="agr:department">Toy Car Parts</dlv:address> 12 </dlv:to> 13 <dlv:from> 14 <dlv:address xsi:type="agr:organization">Toi Carz</dlv:address> 15 </dlv:from> 16 <dlv:reliability> 17 <dlv:confirmTo>http://toicarz.com/biztalk/confirm.asp</dlv:confirmTo> 18 <dlv:receiptRequiredBy>2000-07-7T08:00:00+08:00</dlv:receiptRequiredBy> 19 </dlv:reliability> 20 </dlv:delivery> 21 <prop:properties SOAP-ENV:mustUnderstand="1" 22 xmlns:prop="http://schemas.biztalk.org/btf-2-0/properties"> 23 <prop:identity>uuid:74b9f5d0 33fb 4a81 b02b 5b760641c1d6</prop:identity> 24 <prop:sentAt>2000-05-14T03:00:00+08:00</prop:sentAt> 25 <prop:expiresAt>2000-05-15T04:00:00+08:00</prop:expiresAt> 26 <prop:topic>http://toycarparts.com/BTServer.xar</prop:topic> 27 </prop:properties> 28 <fst:manifest xmlns:fst="http://schemas.biztalk.org/btf-2-0/manifest"> 29 <fst:reference fst:uri="#PurchaseOrderBody"> 30 <fst:description>Purchase Order</fst:description> 31 </fst:reference> 32 <fst:reference fst:uri="toicarz.sig"> 33 <fst:description>Digital signature</fst:description> 34 </fst:reference> 35 </fst:manifest> 36 </SOAP-ENV:Header> 37 38 <SOAP-ENV:Body> 39 <PurchaseOrder_1.0 40 xmlns="x-schema:http://toicarz.com/schemas/PurchaseOrder.xdr" 41 id="PurchaseOrderBody" 42 type="order" 43 PONumber="10-01-2118"> 44 <Item number="122-11" quantity="100"/> 45 <Item number="237-82" quantity="10"/> 46 <Item number="811-91" quantity="25"/> 47 </PurchaseOrder_1.0> 48 </SOAP-ENV:Body> 49</SOAP-ENV:Envelope>

Table 9-2. Line-by-line description of the BizTalk document in Listing 9-1.

Line Description
1 This is an XML document, so it begins with the XML declaration.
2 An XML document must have a single root element that starts at the top of the document and ends at the bottom. Since this is a SOAP envelope, the root element for this BizTalk 2.0 document is SOAP-ENV:Envelope.
3-5 This document uses three XML namespace declarations to indicate the schemas that will be used by the SOAP envelope.
6-39 The SOAP-ENV:Header BizTag contains identification and routing information for your BizTalk document.
7-20 The dlv:delivery BizTag contains information about the delivery and confirmation of the document.
7 The mustUnderstand attribute tells the receiving application that it must understand what it is getting. If it doesn't understand, it must return a SOAP fault element rather than try to fake the processing.
8 The delivery BizTags are found in the namespace indicated by this namespace declaration.
9 Another namespace that points to a set of trading partner agreements is declared.
10 The dlv:to BizTag indicates the name of the entity that will be receiving your document.
11 The xsl:type attribute indicates the data type according to the XML Schema Part 2: Datatypes Working Draft, which is published by the W3C.
12 The to data type is defined in the trading-partner agreement schema.
13-15 The from address takes the same form and contains the same attribute type as the to address.
16-19 The BizTalk server creating a message document can ask for confirmation that the message is received. This is done by adding an optional BizTag, dlv:reliability.
17 The dlv:confirmTo BizTag gives an address to which a receipt will be sent.
18 If the transmitting system does not get a receipt by the time indicated in the dlv:receiptRequiredBy BizTag , the transmitting system should resend the document.
21-27 The properties section defines certain properties of the BizTalk document.
22 The BizTags in the prop:properties element belong to the namespace indicated by the namespace declaration.
23 The prop:identity BizTag contains a Universally Unique Identifier (UUID). Most platforms have a way of generating this identifier.
24 The prop:sentAt BizTag contains a timestamp indicating the document was sent. This is a datetime.tz data type.
25 The prop:expiresAt BizTag contains the time the document expires. After this time, the associated BizTalk document is considered to be expired and must not be processed by the destination business entity.
26 The prop:topic BizTag contains the address of the BizTalk processor that will process the document.
28-35 The fst:manifest BizTag is optional. It contains a catalog indicating the contents of the BizTalk document.
29-31 The fst:reference BizTag occurs one or more times. It indicates the Uniform Resource Identifier (URI) and provides a description of what is in the BizTalk document. The first fst:reference element is a pointer to the document in the Body element of the SOAP Envelope.
32-34 This document also contains a digital signature file to guarantee the originator of the document. This will probably be included in the transport envelope as a MIME-encoded attachment.
38-48 The SOAP-ENV:Body element follows the SOAP-ENV:Header element. The Body element is analogous to the inside of the paper envelope in our case study. The Body element contains your business document and is defined using your schema.
40 Because your schema defines your document, you need to use a namespace declaration to indicate the location of the schema. In our case, we are using a schema called PurchaseOrder.xdr, which is located on our server. The receiving application will be able to find this schema if that application has access to the Web.
41-49 All that remains is the remainder of the purchase order itself and the closing tags to the PurchaseOrder_1.0 element, the SPOAP-ENV:Body element, and the SOAP envelope, SOAP-ENV:Envelope.

The BizTalk document is actually two different documents. One document replaces the general-purpose paper envelope; the other document replaces the paper document inside that envelope. The innovation of namespaces and XML schemas allows us to create our virtual envelope and the virtual document inside.

NOTE
Remember that the document type definition schema syntax allows only a single document type in a document. A BizTalk document has at least two document types, which is allowed with the XML Data Reduced (XDR) schema syntax. This type of BizTalk transaction processing is not possible if you are using the document type definition (DTD) schema syntax.

When your company receives the XML document in Listing 9-1, a BizTalk server will read it and look for the information inside. First the BizTalk server will look at the dlv:to BizTag to determine which partner is to receive the document. Then the BizTalk server will probably parse the rest of the data items so that it can make an entry in an order-tracking database. Finally the server will take the actual order—the thing in the SOAP-ENV:Body element—and pass that order to an application that will process it. This processing depends entirely upon the systems each company has in place.

Delivery Receipt

Since we included the dlv:reliability BizTag, the receiving BizTalk server is required to send us a receipt. This receipt is shown in Listing 9-2.

Listing 9-2. The receipt generated by the BizTalk server.

 

Receipt.xml

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <rct:receipt SOAP-ENV:mustUnderstand="1" xmlns:rct="http://schemas.biztalk.org/btf-2-0/receipt"> <rct:receivedAt>2000-05-15T04:08:10-05:30</rct:receivedAt> </rct:receipt> <prop:properties SOAP-ENV:mustUnderstand="1" xmlns:prop="http://schemas.biztalk.org/btf-2-0/properties"> <prop:identity>uuid:74b9f5d0-33fb-4a81-b02b-5b7606387dc1</prop:identity> <prop:sentAt>2000-05-14T03:00:00+08:00</prop:sentAt> <prop:expiresAt>2000-05-15T04:00:00+08:00</prop:expiresAt> <prop:topic>http://toycarparts.com/POProc.asp</prop:topic> </prop:properties> </SOAP-ENV:Header> <SOAP-ENV:Body/> </SOAP-ENV:Envelope>

The header of this document is similar to the header of the message that was sent. The only things that changed were the unique identifier in the prop:identity BizTag and the timestamps.

Notice in Listing 9-2 that the SOAP-ENV:Body element is empty. Although this element is required, it doesn't need any contents because the receipt document is just an indicator that the document was received properly.

The Order Confirmation

Once your back-end system confirms the order, you will create a BizTalk document that has the information we need to close out our order. Listing 9-3 shows the document; Table 9-3 describes it line by line.

Listing 9-3. A BizTalk document that confirms a purchase order sent from one company to another.

 

Confirm.xml

1<?xml version="1.0"?> 2<SOAP-ENV:Envelope 3 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 4 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 5 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 6 <SOAP-ENV:Header> 7 <dlv:delivery SOAP-ENV:mustUnderstand="1" 8 xmlns:dlv="http://schemas.biztalk.org/btf-2-0/delivery" 9 xmlns:agr="http://www.trading-agreements.org/types/"> 10 <dlv:to> 11 <dlv:address xsi:type="agr:department">Toi Carz</dlv:address> 12 </dlv:to> 13 <dlv:from> 14 <dlv:address xsi:type="agr:organization">Toy Car Parts</dlv:address> 15 </dlv:from> 16 <dlv:reliability> 17 <dlv:confirmTo>http://toycarparts.com/BTServer.xar</dlv:confirmTo> 18 <dlv:receiptRequiredBy>2000-07-7T08:00:00+08:00</dlv:receiptRequiredBy> 19 </dlv:reliability> 20 </dlv:delivery> 21 <prop:properties SOAP-ENV:mustUnderstand="1" 22 xmlns:prop="http://schemas.biztalk.org/btf-2-0/properties"> 23 <prop:identity>uuid:74b9f5d0-33fb-4a81-b02b-5b7606434d3</prop:identity> 24 <prop:sentAt>2000-05-16T03:00:00+08:00</prop:sentAt> 25 <prop:expiresAt>2000-05-17T04:00:00+08:00</prop:expiresAt> 26 <prop:topic>http://toicarz.com/biztalk/confirm.asp</prop:topic> 27 </prop:properties> 28 </SOAP-ENV:Header> 29 30 <SOAP-ENV:Body> 31 <PurchaseOrder_1.0 32 xmlns="x-schema:http://toicarz.com/schemas/PurchaseOrder.xdr" 33 type="confirm" 34 PONumber="10-01-2118"> 35 <Item number="122-11" quantity="100" shipped="100"/> 36 <Item number="237-82" quantity="10" shipped ="0" 37 backordered="10"/> 38 <Item number="811-91" quantity="25" shipped="25"/> 39 </PurchaseOrder_1.0> 40 </SOAP-ENV:Body> 41</SOAP-ENV:Envelope>

Table 9-3. Description of the document in Listing 9-3.

Line Description
1 This is an XML document, so it begins with the XML declaration.
6-28 The structure of this SOAP-ENV:Header element is pretty much the same as the one that initiated the process, but this one contains information about the response document.
11, 14 The to and from addresses have been swapped.
30 The beginning SOAP document's Body element.
31-39 Notice that the confirmation document uses the same schema as the original purchase order in NewPO.xml. This isn't necessary; a confirmation document can have an entirely different schema for the Body element. In our case, we differentiate the function of the document by changing the type attribute in line 33 to confirm.
40-41 The closing tags to the Body element and the Envelope.

XML is a powerful syntax for communicating business transactions. As you have seen in this chapter, XML defines the entire transaction by using two independent schemas: the BizTalk message envelope and our purchase order.

Because BizTalk is rooted in XML, it is compatible with any business document specification, including those I mentioned earlier. BizTalk is an open specification that can be used by anyone who needs to do B2B e-commerce.

When your company's system receives this envelope at http://toycarparts.com, The BTServer.xar script will start processing the purchase order. This process replaces the work of David in our initial example. It will apply the same business rules that David used and send a confirmation in the form of a BizTalk document back to my company.

Potential for Automating Procurement

The scenario illustrated by the BizTalk request, confirmation, and response documents duplicates the manual processing that Jean and David have been performing for years. The big win in our scenario is that we have replaced humans with dependable computer processes, allowing us to do business faster and more efficiently. Don't worry about Jean and David, however. We promoted them because of their help in getting our BizTalk systems up and running. Jean and David are now vital resources for their organizations because of their knowledge of internal systems and the requirements for creating B2B applications in other areas of the company.

Of course, when computers replace people, errors replicate much faster, so debugging is of critical importance; no human cognitive processes are in place to make sure everything looks right.

No matter how great the system I've described here is, we are not taking full advantage of new technologies in the way we could be. The BizTalk server, acting as Jean's replacement, still gets catalogs from vendors. (Of course, these are also BizTalk messages that go through a different workflow in order to be added to our list of products that can be ordered.) These arrive at a leisurely pace, whenever the vendor gets a chance or has a product change. Assume that for most products ordered by my company, multiple vendors can provide suitable items.

At any given time, the system that our company uses to decide which vendor to place an order with doesn't know what each vendor has in stock and therefore runs the risk of finding out an item was back-ordered.

In the old system, Jean had time to consider only a small number of possible vendors when she was looking for the best combination of price and delivery for any given item. She could save money if she could look at several dozen different vendors, and she could save even more if she could look at thousands.

If each vendor with whom we do business exposed catalog and warehouse information to us in real time as Web services, we could ask each vendor whether a quantity of a particular part was in stock and how much it cost before we tried to place an order. We could use SOAP to request this information from thousands of potential vendors in a small amount of time. Once we determined our best combination of quality, availability, and price, we could create a formal purchase order, using BizTalk as the workflow package. We would potentially save a good deal of money by shopping around and placing our orders through BizTalk, and we would rarely get a notification that a part was back-ordered.

This scenario—which already describes what some companies are doing—turns the ordering process upside down. The process is called a reverse auction: vendors compete to provide their wares to a requesting organization by offering lower and lower prices in response to a bid from the purchaser. Real-time Web services can make reverse auctions a reality. As open standards that run on any platform, SOAP and BizTalk can help foster widespread acceptance of these practices.



XML and SOAP Programming for BizTalk Servers
XML and SOAP Programming for BizTalk(TM) Servers (DV-MPS Programming)
ISBN: 0735611262
EAN: 2147483647
Year: 2000
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net