Home > Articles > Information Technology

How Does Biztalk Relate to EDI and Workflow?

  • Print
  • + Share This
Jim Koblieus explains how Microsoft's BizTalk initiative defines an environment in which EDI and workflow can operate across the Internet.
James Kobielus is a contributing editor for Network World and writes its popular column "Above the Cloud." He is the author of more than 150 columns, books, feature articles, and buyers' guides. This article is excerpted from his book BizTalk: Implementing Business-to-Business E-Commerce (Prentice Hall PTR, 2000, ISBN 0-13-089159-2).
From the author of

As with traditional B2B EDI, BizTalk applications support information flows between companies engaged in routine online transactions, such as purchasing, inventory control, and logistical coordination. The flow of control in such transactions follows the procedures that allow one company to interface its internal processes to those of its trading partners, including customers, contractors, distributors, and suppliers. These procedures, in turn, follow business rules that are codified in the trading partners' various business contracts, operating agreements, and internal policies. And these business rules come to life in the programming code upon which the trading partners build their e-commerce and supply-chain applications.

In the usual flow of point-to-point B2B EDI connections, corporations map data to and from a common format for transmission between their otherwise incompatible back-end applications. Note that traditional EDI applications often use traditional X.25 or frame-relay value-added networks (VANs) rather than the Internet or Internet Protocol (IP)-based extranets.

BizTalk doesn't replace traditional B2B EDI; it supplements it and takes it to a new level of openness, flexibility, and Internet-orientation. The BizTalk Framework uses the EDI and workflow feature set of Microsoft's existing Site Server Commerce Edition as a baseline. The BizTalk Framework defines a standardized electronic "envelope" for routing and handling structured and unstructured business documents. Each BizTalk message may contain two or more linked business documents to be processed as a unit. A BizTalk-enabled B2B workflow, in turn, may involve one or more BizTalk messages transmitted as e-mail attachments, riding on the Internet's ubiquitous Simple Mail Transfer Protocol (SMTP). However, BizTalk-enabled transactions could just as easily ride over the Web's HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), or any other network "transport" protocol. Each transport protocol that carries a BizTalk message wraps it a second time within an envelope appropriate to that transport. Consequently, a BizTalk-enabled workflow or transaction can run over several transports.

The essence of BizTalk—what makes it a powerful alternative to "EDI as usual"—is what's in the header of a BizTalk message envelope. The BizTalk message's header includes some simple fields that allow applications to specify how a particular business document, contained in the message, fits into a broader workflow (or, in Microsoft's term, into an "orchestration"). The header also allows the message to specify how the document is to be processed when it reaches its destination. As such, a BizTalk message can describe its precise role within an ongoing business transaction.

One might say that a BizTalk message makes the workflow of which it is a part "self-describing." Traditional EDI, by contrast, has never had anything resembling self-describing workflows. Rather, EDI has always focused on exchanging just the content of a transaction, encoded in standardized "transaction sets." There is rarely any "process state information" contained in EDI transaction sets that specifies where a particular document fits into a precise routing and processing sequence. All the state information in traditional EDI resides in the business applications that generate and receive the transaction sets.

One reason for this is that EDI has historically been a point-to-point solution, requiring any two companies to spend a great deal of time and money to establish specific connections and processes that apply to them—and only to them. Within each of the trading partners' networks and systems, the transaction sets usually follow a rigid chain of routing and processing steps involving one or more databases. Often, these internal processes are totally hidden from direct tracking by EDI trading partners.

EDI will not mature until it becomes part of a much broader, more general-purpose e-commerce infrastructure that applies to all companies, not just to big companies that can afford to build specific connections for a specific application. In such an environment, companies will be able to view each others' B2B workflow "process models" in a standardized format. They can merge, concatenate, and otherwise interface internal business processes to establish a new trading partner relationship. BizTalk will a fundamental technology for establishing just such a general-purpose, e-commerce infrastructure.

BizTalk will also be a catalyst for transforming traditional EDI into a full-fledged workflow-management environment. A workflow-management system is one that supports the structured routing and tracking of documents and other information throughout a business process. For EDI to count as a true workflow-management environment, it must support intercompany processes that specify the precise routing and processing sequence that a transaction follows. This allows each company to track (and possibly control) a transaction path into and through its trading partners' systems.

Furthermore, BizTalk will be a catalyst for transforming traditional workflow systems into e-commerce environments. BizTalk's routing envelope addresses a gap in the workflow market that has heretofore stymied implementation of robust interorganizational workflow. There are no widely implemented standards in the workflow management market. As a result, workflow-management tools have been applied primarily to intraorganizational business-process re-engineering, within intranets that revolve around a single vendor's proprietary workflow product.

Clearly, a single-vendor workflow solution is not a viable option for B2B EDI. You are not very likely to impose a single monolithic workflow solution on all your trading partners.

About the Author

James Kobielus has more than 15 years experience as an analyst in the distributed computing and telecommunications industry. He is a recognized authority on strategic telecommunications and information systems topics, and is an occasional speaker at network-computing industry conferences. He is a contributing editor for Network World, and writes its popular column "Above the Cloud." He is the author of more than 150 columns, books, feature articles, and buyers' guides, including Measuring Business Value of Information Technologies (International Center for Information, 1987, ISBN 0-9450-9802-2) and Workflow Strategies (IDG, 1997, ISBN 0-7645-3012-7). His latest book is BizTalk: Implementing Business-to-Business E-Commerce (Prentice Hall PTR, 2000, ISBN 0-13-089159-2).

  • + Share This
  • 🔖 Save To Your Account