Ever since its introduction a few years ago, I’ve always regarded BizTalk Server as one of Microsoft’s most ambitious—and largely successful—server products. Most of Microsoft’s powerful (and popular) .NET Enterprise Servers—such as SQL Server and Exchange Server—evolved over years into the products they are today. BizTalk, however, was introduced as a powerful and complex product that solves some of the computer industry’s most irritating problems.
| For more information on the problems that BizTalk helps solve, see “BizTalk Server,” p. 33 |
BizTalk is, in many ways, a revolutionary product. Based entirely on XML, BizTalk requires you to learn so many new terms and concepts that you might find it completely unapproachable. Don’t worry! Throughout this chapter, I’ll introduce you to everything in a logical order that’ll make it easy to understand. In fact, in the next section, I’ll start with a basic introduction to XML, to help get you in on BizTalk’s “ground floor.”
BizTalk is based completely upon XML, and there are a variety of XML standards that play into BizTalk’s features. Before you can start to understand how BizTalk works and what it can do, you need to understand a little bit about XML.
XML stands for Extensible Markup Language, which is actually a bit of a misnomer, because XML isn’t really a language at all. Instead, XML is a set of rules that describe how you can write other languages—making XML a kind of “meta-language.” The XML rules are used to create XML applications, which are XML-based languages used to describe some specific type of data. For example, someone created an XML application named MathML that’s used to describe complex mathematical equations. Whenever you hear someone say something like, “the data is formatted in XML,” that’s just shorthand for “the data is formatted in an XML application.” BizTalk makes use of several XML applications with names like XSL, XLANG, and more, and I’ll cover those in this chapter.
At its simplest, XML is designed to describe data. For example, Listing 7.1 shows a sample XML-like listing that describes the items in a music collection.
Example 7.1. Sample XML Listing
<COLLECTION>
<ITEM>
<FORMAT>CD</FORMAT>
<TITLE>Greatest Hits</TITLE>
<ARTISTS>
<ARTIST>Ugly Kid Joe</ARTIST>
<ARTIST>Bloodhound Gang</ARTIST>
</ARTISTS>
<TRACKS>
<TRACK>
<TITLE>Cats in the Cradle</TITLE>
<SEQUENCE>1</SEQUENCE>
<LENGTH>2:35</LENGTH>
<ARTIST>Ugly Kid Joe</ARTIST>
</TRACK>
<TRACK>
<TITLE>The Bad Touch</TITLE>
<SEQUENCE>2</SEQUENCE>
<LENGTH>3:21</LENGTH>
<ARTIST>Bloodhound Gang</ARTIST>
</TRACK>
</ITEM>
</COLLECTION>Each XML file begins with a single top-level element, and in this case it’s the <COLLECTION> element. Note that each element has an opening tag and a closing tag—<COLLECTION> is paired with </COLLECTION>, <ITEM> is paired with </ITEM>, and so forth. Those basic rules are laid out by the XML standard, and documents that follow them are referred to as well-formed XML. Each XML application has additional rules. For example, the XML in Listing 7.1 might comply with an XML application named MCXML—Music Collection XML—which specifies that each collection can have multiple items, and each item can have one title, a format, a single artists section, and a single tracks section. The artists section can have multiple artist child elements, and the tracks section can have multiple track child elements, as shown in the listing.
As you can see, XML doesn’t describe how the data should be displayed, unlike another markup language you might be familiar with, HTML. Instead, XML focuses on describing what the data actually is. In Listing 7.1, it’s easy to pick out which piece of data is the artist, which is the track name, and so forth. Contrasted with more traditional ways of displaying data, XML is much easier to read. For example, Listing 7.2 shows the same music collection in a comma-separated values (CSV) format.
Listing 7.2 is a lot more efficient—the same data is packed into much less space. But without some kind of external reference, you’ve no idea what any of the data means. Is “Cats in the Cradle” the name of a band or a song? Is it a minute long, or 2:35? XML is designed to solve those problems by including data descriptions within the data itself, a concept known as self-describing data. BizTalk Server relies heavily on this basic fact about XML.
BizTalk Messaging is designed to transport and translate data between different systems. Those systems might be within the same organization, or they might be in different organizations that simply have a need to exchange data with one another.
BizTalk Messaging is composed of a number of different components. I’ll start by introducing you to receive functions, which are designed to receive data from various sources and submit that data to channels, which are BizTalk’s means of organizing its message processing.
One of BizTalk’s often-overlooked features is file receiving. This feature enables BizTalk to pick up a file that was created by another application and begin working with it. File receiving enables your internal applications, for example, to continue creating output files in whatever format they currently use. BizTalk then grabs the file and begins processing it. You can configure BizTalk with a polling location, which is where BizTalk will look for files, and a filename pattern—such as output*.xml—to look for. You can also configure the file receive function to feed the file it grabs into specific BizTalk channels for processing.
BizTalk also supports HTTP receive functions, which are easily the most popular receive function included with BizTalk. HTTP receive functions use a special Internet Server Application Programming Interface (ISAPI) extension in IIS that enables BizTalk to intercept and process incoming HTTP data. Essentially, IIS receives the data, passes it off to the ISAPI extension, and the extension passes the information off to a particular BizTalk channel.
The third type of receive function that BizTalk supports is message queuing. BizTalk can monitor a specified Microsoft Message Queuing (MSMQ) message queue, pick up any documents delivered to that queue, and process those documents through a specific channel.
Not all data has to come in through a receive function. Developers can write standalone applications that use BizTalk’s Interchange COM object to submit data directly to channels, bypassing receive functions completely.
Ports and channels are at the heart of how BizTalk Messaging processes data. A port—more properly known as a messaging port—represents a destination for data. Ports define all kinds of properties about the destination, including the receiving organization, the network transport which will be used, the time during which the port may be used, a backup transport, security options, and much more. For example, you might create a port that specified a particular Web server on a business partner’s network. Whenever BizTalk delivers data to that partner, it could use the port to determine the Web server’s address, whether or not encryption will be used, and so forth.
Channels cover the other end of the equation, defining the source organization or application for the data, the steps that BizTalk must perform before delivering the message to a port, and so forth. Channels and ports are always associated with one another, creating a complete path for data to come into and out of BizTalk. Channels are also where you define tracking options, encryption requirements, and so forth. Figure 7.1 shows the relationship between channels and ports. Notice that the figure includes a file receive function, which can deliver data to a specific channel. That delivery is where BizTalk’s processing of the data begins.
Channels and ports have a couple related concepts: organizations and applications. Organizations represent exactly that: organizations. You’ll always create one home organization to represent your own company, and will probably create additional organizations to represent the other companies that you exchange data with. Within your home organization, you can also create applications, which represent the business applications within your environment. BizTalk associates document specifications with applications, which allows BizTalk to keep track of which application needs data in which format. Applications can be assigned as the destination of a messaging port, which means the port will deliver its output to that application. Applications can also be the source for a channel, meaning the channel accepts data from that source. Figure 7.2 shows the expanded relationship between these various components.
Modern businesses rely heavily on documents of all kinds: invoices, purchase orders, requests, and so forth. When businesses say they are exchanging data, what they’re really exchanging are documents. Those documents may be as simple as an inventory invoice or as complex as an entire product catalog. Each document has a specific format associated with it. For example, invoices generally have a “Bill to” section and a “Ship to” section, with particular pieces of information within each section. BizTalk uses document specifications to keep track of the rules for each type of document. BizTalk includes the BizTalk Editor, which provides a graphical user interface that enables you to create and edit document specifications. The specifications themselves are stored in an XML format and contained within BizTalk’s WebDAV repository. The repository is simply a place for document specifications and other types of data to live, where they can be easily accessed by BizTalk administrators and BizTalk Server computers.
Closely related to document specifications are document maps. While document specifications describe a particular document, maps tell BizTalk how one type of document corresponds to another. For example, suppose a supplier sends you a document specification for its purchase order format. Using the BizTalk Mapper, you can view your existing database and the document specification in a single window, and draw lines to indicate how your data matches up to the document specification. The Mapper can perform complex translation and transformation operations, too, so that your data winds up in the right format for your business partner. When you configure a new channel, you can specify a map from the WebDAV repository, and BizTalk will use that map to translate incoming and outgoing data.
Document maps are the translators for BizTalk. BizTalk understands your partners’ data because they’ve provided you with document maps that describe their data. And BizTalk understands your data because you’ve provided it with document maps that describe your data. Perhaps the biggest step in implementing BizTalk is in creating or obtaining the necessary document maps.
Transports provide the underlying mechanism for messaging ports. Messaging ports can use any transport that comes with BizTalk, and you can extend BizTalk to include transports that you devise. BizTalk includes the following transports:
File, which allows BizTalk to write its output to a file, rather than sending it to another organization directly.
HTTP, which allows BizTalk to transmit data over the Web. A variant of this transport is the encrypted HTTPS.
Loopback, which takes an outbound document and feeds it back into the same application that originally submitted it. This is the only transport type that doesn’t require a specific destination address, since the destination is by definition the same as the source.
Message Queuing, which uses Microsoft Message Queuing (MSMQ) to transport data. MSMQ is an ideal way to transport data between applications that aren’t always online, as the data can remain in-queue until retrieved by the recipient application. You can think of MSMQ as a form of email for applications.
SMTP, which uses email to transfer data.
As I mentioned, you can also write your own BizTalk transports using the Software Development Kit (SDK) included with BizTalk. You might, for example, create an outbound-only transport that delivers data to a fax machine, enabling you to send data to less technologically advanced business partners. You could also write an FTP transport to pull data or send data to and from business partners’ FTP servers.
Tip
You can generally use an existing transport type to access others. For example, many services exist that let you send faxes via email. Utilizing one of those services could enable you to deliver faxes through BizTalk’s SMTP transport. However, keep in mind that BizTalk can’t track the document any further than BizTalk’s transport, which in this example would be SMTP. If the SMTP server failed to deliver the email to the fax service, or if the fax service was unable to contact the fax machine, BizTalk would still consider the message to be successfully sent.
Each message port defines at least one transport, and can define an optional backup transport, which BizTalk will use if the first transport is unavailable or fails to operate.
Closely related to transports are envelopes. An envelope encapsulates business data and prepares it for transport, just as a paper envelope encloses paper documents for transport. BizTalk supports different envelope formats, including XML, ANSI X12, EDIFACT, and more. One custom type of envelope is the reliable type, which specifies an envelope format that is compatible with Microsoft’s open BizTalk Framework 2.0. Reliable envelopes provide the means necessary for full document tracking, guaranteed once-and-only-once delivery, and so forth. Envelope types are specified in a messaging port definition, and tell the messaging port which envelope type, as well as certain envelope properties, to use when sending data out from the port. Figure 7.3 illustrates the relationship between all of the BizTalk Messaging components.
Messaging ports can also be configured to deliver their data to an XLANG schedule. These schedules are used by BizTalk Orchestration. In other words, BizTalk Messaging can deliver processed data to BizTalk Orchestration, either supporting or kicking off an automated business process with the document’s data.
BizTalk Orchestration enables you to easily model and automate business processes with a minimum of software development. Orchestration works on the concept that most business processes can be broken down into very discrete tasks which pass information from one to another; by modeling this process in software and providing a framework to execute the entire process, Orchestration can significantly reduce programming time and administrative effort. You start by modeling your business process in BizTalk’s Orchestration Designer. Once modeled, software developers create scripts, COM components, and other software components that implement each step in the business process.
Microsoft cleverly purchased Visio right around the time that BizTalk was under development, giving the BizTalk product team the perfect flowchart-drawing tool. As a result, you can draw business process flowcharts in a familiar, flexible environment: The BizTalk Orchestration Designer simply instantiates Visio and provides a special set of drawing objects, as shown in Figure 7.4 (which is taken from one of the sample business processes included with Visio).
Note
BizTalk doesn’t include Visio as part of its setup, but it does require it. You’ll need to make sure you have the correct version of Visio (Visio 2000 SR 1 or Visio 2002) installed before you can run the Orchestration Designer. Some distributions of BizTalk include the proper Visio, although they don’t automatically install it for you.
The Orchestration Designer is built so that business professionals—the people who understand your organization’s business processes—can create these flowcharts with an absolute minimum of technical knowledge. Basically, if someone can be trained to operate Visio, then they can create business process diagrams. Once the diagrams are completed, they can be turned over to a software developer for implementation.
The Designer also supports the use of transactions. A transaction is a series of business process steps that must be completed as a single unit. For example, consider a purchase request that’s been approved: The request must generate a purchase order for a supplier, debit the appropriate department’s budget, and so forth. If any one of those steps occurs independently, the books won’t balance, orders won’t be placed, and all kinds of things will go wrong. By designating those steps as a transaction, you can provide separate implementations for them, while ensuring that they still complete as a single unit. BizTalk itself handles the execution of the business process and ensures that transactions are either completed in total or rolled back so that no step within the transaction is completed.
Developers implement each step in a business process by creating scripts, COM components, and other software components, and assigning them to the appropriate business steps. This assignment is made within the Orchestration Designer on the right side of the flowchart, as shown in Figure 7.5.
By default, BizTalk enables you to use COM components, scripts, message queuing, and BizTalk Messaging to implement business process steps. Once you’ve defined the components that implement each business step, you must actually connect the implementation components to the business steps, thereby tying the components to the steps. The beauty of this method is that the implementation components are tied to specific business steps; if a business professional reorders the business process to accommodate changes in the company’s needs, the implementing components are automatically rearranged. This behavior allows the maintenance of business processes to reside with business process owners, rather than with software developers. This behavior only works, of course, when each implementing component is completely self-contained.
The last step is to define how your business document’s data will be passed from one step to the next. This is also accomplished in the Orchestration Designer, by using a graphical user interface to draw a path for the document’s data through the various implementation ports.
| To learn how to accomplish these various steps, see “Managing BizTalk Orchestration,” p. 453 |
BizTalk stores Orchestration information in the XLANG format. XLANG is an XML application that describes business processes. When you create a business process drawing in the Orchestration Designer, BizTalk saves it as an XLANG schedule drawing. When you’ve finished with a drawing and are ready to use it, BizTalk compiles the drawing into an XLANG schedule, which BizTalk can execute. XLANG schedules use the SKV filename extension.
BizTalk uses an XLANG Scheduler Engine to actually parse and execute compiled XLANG schedules. In other words, the XLANG Schedule Engine is responsible for physically executing your business processes. The Schedule Engine relies on a SQL Server-based persistence database, which it can use to store information about XLANG schedules that are currently executing. Some business processes may need to wait for a while during execution. For example, a business process requiring executive approval might sit for several days while that approval is considered. Rather than wasting server memory to persist the XLANG schedule while approval is pending, the Schedule Engine can dehydrate the schedule into the persistence database. When approval is received (or declined), the Schedule Engine can rehydrate the schedule from the database back into memory, effectively picking up where it left off.
Note
You can think of dehydration and rehydration as a kind of suspension or hibernation for an XLANG schedule.
Not all XLANG schedules can be dehydrated. XLANG schedules are dependent upon the technologies of their implementation ports. For example, COM components often hold information in server memory while completing actions. These components don’t expose that information to the Schedule Engine, which prevents the Schedule Engine from dehydrating that information to a database. The Schedule Engine can detect XLANG schedules which use non-persistable implementation technologies, and it will refrain from dehydrating these schedules—at a cost in server memory, as the only alternative is to continue persisting the schedule in RAM until it completes. The Schedule Engine also cannot dehydrate schedules that utilize Microsoft’s Distributed Transaction Coordinator (DTC), because the DTC does not expose sufficient information to be successfully rehydrated. However, DTC transactions are by their very nature very short-running, which means the transactions usually complete before the Schedule Engine would consider the schedule for dehydration.
Microsoft offers accelerators that are designed to speed up development and performance of BizTalk Server computers in specific environments. These accelerators cost extra, but can save you a great deal of time and effort, and so may be worth it. The available accelerators include
HIPAA, which is designed specifically for the healthcare industry. This accelerator is consistent with the regulations of the Health Insurance Portability and Accountability (HIPAA) Act of 1996. This accelerator enables business to more easily comply with HIPAA standards while still leveraging their existing IT environment.
Suppliers, which is a general accelerator designed for use in many different supply-chain (business-to-business) environments. This accelerator makes it easier for business-to-business companies to expose critical information electronically, and to participate in less-expensive data interchange with their partners.
RosettaNet, which includes several applications that integrate BizTalk with RosettaNet-standard Partner Interface Process (PIP) XLANG schedules. This accelerator enables BizTalk users to build RosettaNet-compatible solutions.
Microsoft has also produced a series of adapters for BizTalk Server, and several third-party companies have created their own line of BizTalk adapters. Adapters enable BizTalk to easily understand the data formats used by a variety of applications and technologies, enabling BizTalk to quickly integrate with your existing enterprise management systems. Microsoft has produced two adapters, including one for SAP (no surprise, since Microsoft is a huge SAP user) and one for MQSeries.
Third-party adapters include solutions for Ariba, Clarus, Commerce One, Great Plains (oddly enough not produced by Microsoft, even through they now own the Great Plains brand), J. D. Edwards, Peoplesoft, Oracle Financials, Remedy, Siebel, and many more. For a full list, visit www.Microsoft.com/biztalk/evaluation/adapters/adapterslist.asp. If you find that URL to be out-of-date, visit the main BizTalk Web page at www.Microsoft.com/biztalk.
| For details on adapter and accelerator pricing, see “BizTalk Server,” p. 168 |
If you’ve been following along with how BizTalk works, you know that the toughest parts of using the product are developing document specifications that tell BizTalk what your data looks like, and developing COM components that allow BizTalk Orchestration to interface with your existing systems. Adapters contain all of these components, making BizTalk much more of a “plug and play” solution.
Tip
If you’re considering implementing BizTalk but don’t know how difficult it’s going to be to interface BizTalk with your existing systems, see if an adapter is available. In my experience, the adapters are always worth the price, as they can get you up and running on BizTalk in a matter of weeks, not months.
No technology as complex as BizTalk can stand alone. In the case of BizTalk, both IIS and SQL Server are prerequisite technologies, providing core functionality that BizTalk can build upon.
BizTalk Server can’t live without SQL Server. In fact, BizTalk is happiest when it has two—or more—SQL Server computers to work with. BizTalk Messaging requires three databases: Messaging Management, Shared Queue, and Tracking. Of these three, Tracking is by far the most heavily used, and a busy BizTalk environment will dedicate an entire SQL Server to the Tracking database. Tracking is used to track messages as they flow through BizTalk, and every minor action on BizTalk’s part results in tracking entries. The Messaging Management database contains configuration information, such as port definitions, channel definitions, and so forth. The Shared Queue database stores all documents that are being handled by a group of BizTalk Server computers.
BizTalk Orchestration has its own database, too: the Persistence database. As I’ve already discussed, this database is used to store information about XLANG schedules that are running or have been dehydrated by the XLANG Schedule Engine.
Normally, SQL Server is a scale-up solution, which means that overloaded SQL Servers are simply upgraded to more powerful servers. Because BizTalk spreads its functionality across up to four databases, you can use more effective scale-out techniques to increase your SQL Server capacity. If one SQL Server computer becomes too busy, simply move a database or two off to another SQL Server computer.
Note
Keep in mind that an entire group of BizTalk Server computers share a single set of back-end databases. If you’ve implemented each database on a separate, high-powered SQL Server computer and you’re still running into SQL Server performance problems, then you should think about splitting your BizTalk Server computers into two groups. Each group can then have separate SQL Server computers, increasing your working capacity.
Your SQL Server computer should be built to maximize disk throughput speeds. That means equipping them with lots of memory, so that they can cache data rather than reading it from disk, and using large RAID-5 disk arrays. In general, the more physical disks you have in the servers, the better. It’s not the disk size you’re necessarily after, it’s a large number of disks across which the disk throughput load can be spread.
IIS provides one of BizTalk’s most important capabilities: HTTP receive functions. As I described earlier, IIS accepts all incoming data on HTTP ports (80 for regular HTTP and 443 for encrypted HTTPS). The BizTalk ISAPI extension is given the opportunity to handle any incoming traffic; the extension only grabs the traffic directed to the IIS virtual root configured by BizTalk. That traffic can then be delivered as a file on the hard disk or, more commonly, delivered to a designated BizTalk channel for processing.
You can configure one or more virtual roots under IIS for use as HTTP receive functions. HTTP receive functions are always directed to the BizTalkHTTPReceive.dll file. For example, you might use the URL http:// servername/BizTalk/BizTalkHTTPReceive.dll. You’ll need to provide this URL to your business partners so that they know where to send data.
| To learn more about HTTP receive functions’ options, see “Managing BizTalk Messaging,” p. 438 |
Although SQL Server is certainly a .NET Enterprise Server, I listed it under “Supporting Technologies” because BizTalk absolutely requires it. There are other .NET Enterprise Servers; however, they either enhance BizTalk’s functionality or benefit themselves from integrating with BizTalk. I’ll cover these .NET Enterprise Servers in the next three sections.
Commerce Server 2000 and 2002 come prepackaged with document specifications and maps, so you can hook them right up to BizTalk Server and start exchanging data. Perhaps the best utilization of this integration is the capability to accept orders through BizTalk Server and have them input directly into Commerce Server’s order processing system. This enables you to sell your products through other vendors, and gives those vendors an automated means of submitting their orders to your site. Figure 7.6 illustrates the order flow process through BizTalk to Commerce Server.
| To learn more about Commerce Server’s capabilities, see “Technology Capabilities,” p. 260 |
Application Center is a must-have for BizTalk implementations that include more than one server. BizTalk allows you to configure servers in groups, and each server in the group shares the same back-end databases. This feature means that the BizTalk computers can balance your workload between themselves. Unfortunately, maintaining multiple servers can be time-consuming and error-prone. That’s where Application Center steps in.
Application Center can enable you to create clusters of BizTalk Server computers which can be managed as easily as a single computer. Application Center provides load balancing, enables you to ensure that each BizTalk Server computer contains the same information and Web-related data, and Application Center’s included Health Monitor can proactively monitor your entire BizTalk installation and alert you if performance begins to fall below predetermined norms. BizTalk Servers can be members of an Application Center cluster, as shown in Figure 7.7, and you can manage the cluster by connecting to the member designated as the cluster controller.
Note that BizTalk requires Application Center Service Pack 1 or higher, and includes Service Pack 1 on the BizTalk CD. For full details on using Application Center’s clustering capabilities with BizTalk, refer to the BizTalk documentation, as a number of specific installation and configuration steps are required.
Caution
Under most circumstances, the SQL Server computers supporting BizTalk must be local to the Application Center cluster controller in order for the cluster to access the Messaging Management database. If that won’t be the case in your environment, be sure to consult the BizTalk documentation for an alternate configuration that will work.
| For more information on what Application Center can do, see “Technology Capabilities,” p. 180 |
Internet Security and Acceleration Server is a firewall and proxy solution, and it’s a great way to protect BizTalk Server computers that exchange data with business partners over the Internet. In a typical configuration, you’ll use two ISA Server computers to create a demilitarized zone, or DMZ, which contains your BizTalk Server computers. As shown in Figure 7.8, the outer ISA Server computer—connected directly to the Internet—allows only permissible traffic through to the BizTalk Server computers. The inner ISA Server computer only allows the BizTalk Server computers to communicate with their supporting SQL Server computers. This type of configuration helps protect valuable resources as much as possible. If your BizTalk Server computers will only be accepting traffic via HTTP, then you can even configure ISA Server’s reverse-publishing feature to provide additional protection against Internet-based attacks on your BizTalk Server computers.
| For more information on ISA Server’s capabilities, see “Technology Capabilities,” p. 324 |
BizTalk isn’t difficult to integrate into a network design, since it’s a relatively standalone product. While it does require SQL Server, BizTalk’s heavy use of SQL Server means that it’s likely to have its own SQL Server, and not share with—or impact—another application’s SQL Server. Where people usually miss out on BizTalk designs is in creativity. So, rather than showing you the “typical” BizTalk implementation, I’ll show you some creative designs that can help you to think about all the places where BizTalk can make your organization more efficient.
BizTalk excels at helping to integrate data with legacy systems that may be otherwise difficult to reach. For example, in Figure 7.9, BizTalk is helping to integrate two different applications with the data on a back-end mainframe computer. In one instance, BizTalk is using a file receive function to pick up new data files from a file server and add that data to the mainframe. This might help support a file-based data feed from a business partner who doesn’t know the data layout used on the mainframe. In the second instance, the middle tier of a multi-tier application is sending data to a BizTalk HTTP receive function. Using BizTalk for this sort of back-end data integration is a great idea, because BizTalk can ensure that each new set of data is added as a single transaction, preventing potential data corruption. Many companies use technologies similar to SQL Server’s Data Transformation Services (DTS) for this kind of task. While DTS can log errors, though, it’s more difficult to have DTS treat an incoming bundle of data as a transaction and ensure its delivery to the mainframe.
For another example, suppose that you’re in an environment with a traditional multi-tier application. The application is built around SQL Server, with a middle-tier server handling business logic and a client application for end users. Now suppose that, in addition to data input by users, you receive an occasional data feed from a business partner. Your middle tier can process part of that data feed, but part of it is in a complex XML format that is very time-consuming to process. Enter BizTalk, as shown in Figure 7.10. Your middle tier can submit the XML data to BizTalk, and enable it to process the data and place it into the back-end SQL Server databases. Since BizTalk specializes in this type of data translation, your middle tier won’t have to work as hard, and will be able to handle additional end-user requests instead of processing the data feed.
Finally, Figure 7.11 shows a more traditional use for BizTalk, which is interacting directly with business partners for data interchange. In this case, BizTalk is set up to send invoice data to selected organizations. It also has an open channel, which is a special type of channel that can accept data from any organization. This channel is used to accept purchase orders into an ordering system. Normally, channels have a designated sender; in this case, BizTalk is able to accept orders from anyone using the proper document specification. This is a common use for BizTalk in a business-to-business environment, allowing you to post your purchase order document specification on a Web site and have BizTalk accept orders from anyone, even new customers.
Figure 7.12 shows a typical Orchestration design. End users visit a Web site to begin a procurement request. That Web page sends information off to BizTalk, triggering a new instance of an XLANG schedule that defines the business process. BizTalk processes the request, interacting with the company’s existing enterprise resource management (ERP) system to check department budgets, store information about the request, and check the ERP system’s chart of approvals for procurement requests. BizTalk probably sends emails to approvers, who visit a separate Web page to view and approve or reject the request.
Many Orchestration designs, however, involve BizTalk Messaging as well. For example, consider the expanded example in Figure 7.13. In this case, the approved procurement request triggers a purchase order, which is submitted by BizTalk Orchestration to a separate BizTalk Messaging server. Messaging determines the proper outgoing format for the data, translates it, and delivers it to the appropriate supplier. That officially ends the business process, but Messaging also accepts the supplier’s invoice when it arrives, translates it, and places it into the ERP system for payment. The incorporation of BizTalk Messaging into the business process creates a completely automated e-procurement system, which is in fact one of the most popular uses for BizTalk.
I’ve already touched a bit on BizTalk’s ability to scale out to support large environments, and I want to provide some sample designs to help you get an idea of how to scale BizTalk in your own environment. From a scalability standpoint, you can think of BizTalk as a three-tier system, as shown in Figure 7.14. Tier 1 is the BizTalk client, which may consist of business partners or your own internal systems. These are the systems where data originates and is sent by BizTalk. BizTalk itself is the middle tier, with SQL Server providing support for the back-end tier.
When a single BizTalk Server computer or SQL Server computer isn’t enough to support your workload, you can scale each tier independently. For example, BizTalk’s Enterprise Edition allows you to create server groups which share workload and a single SQL Server back-end. You can also scale the back-end tier by adding SQL Server computers and dedicating each to a specific BizTalk Server database. Figure 7.15 shows the three-tier structure again, with the latter two tiers scaled to support higher workload volumes.
If the workload you’re putting through BizTalk is too much for your SQL Server back-end to support, and you’ve already dedicated three servers to the task, then you’ll need to create a new BizTalk Server group with its own dedicated SQL Server back-end, as shown in Figure 7.16. The disadvantage of this technique is that BizTalk groups can’t share workload. That means you’ll have to decide how to split your workload manually, and direct your communications partners to send their requests to one of the groups specifically.
One of Microsoft’s strategies in enterprise communications is the BizTalk Framework. Designed to be an open project based at www.biztalk.org, the Framework is a specification for creating data interchange specifications. The BizTalk.org Web site includes a repository, so that BizTalk Server implementers have immediate access to a wide variety of document specifications and other information which they can put to immediate use.
Microsoft isn’t the only one playing the repository game. A number of other companies and consortiums, including OASIS (www.xml.org), RosettaNet (www.rosettanet.org), and Commerce Net (www.commerce.net) have created repositories for document specifications and other information, and created data-interchange solutions. All of these differ slightly from BizTalk in their approach to data interchange, but all are aimed at the same goal: providing a way for business to share data between one another more easily using the power of the Internet and XML.
Another alternative is the predecessor to the current wave of XML-base data exchange: EDI, or Electronic Document Interchange. EDI has been around for a long, long time, and shares a number of concepts with BizTalk. In general, two companies agree on a common EDI format for exchanging data, and then translate their data into that EDI format. EDI Value-Added Networks (VANs) and the Internet can be used to transport the data between companies. The downside of EDI is that its document specifications are notoriously complex and difficult (and expensive) to implement. Most specifications are tweaked slightly by companies when they use them, making it difficult to rely on the so-called standards when exchanging data. In fact, one primary goal behind BizTalk was to solve some of the problems that have plagued EDI. Its problems aside, however, EDI remains one of the most popular ways for large companies to exchange data with one another.
In this chapter, I’ve shown you what BizTalk can do, and given you some basic information on how it does it. I’ve shown you how you can fit BizTalk into your existing environment, and most importantly how to ensure that BizTalk can integrate closely with your existing systems and make the data they contain more useful.