BizTalk Server Scenarios

To better understand how BizTalk Server can help an organization leverage the capabilities of the product, this section presents several scenarios noting how BizTalk Server can be implemented to improve data transaction interchange. Seven different scenarios are given with the first four (automated procurement, product catalog exchange, B2B portals, and embedded forms data submission) focused on B2B transaction scenarios, and the last three (business process integration, back-end supply chain integration, and consolidation of information) focused on internal EAI scenarios.

Automated Procurement

In this first scenario, two organizations want to automate their procurement system on B2B transactions. Currently, the organizations use a combination of manual fax forms that contain purchase order information that is then manually entered into the order processing system, and the organizations exchange information over a Web-based data entry system. The buyer does not like the Web-based data entry system because it takes a lot of time and effort to manually key in similar orders, and when the Internet is slow, there are considerable delays in accessing and entering information. The buyer prefers to continue to process the information in his local purchase order system, print the purchase order, fax it to the supplier, and have a customer service representative contact him with a confirmation of the order receipt and processing.

The supplier created the Web-based data entry system to cut costs by having the buyer enter the information directly into the order processing system. Although the concept sounded great when it was being developed, the supplier realized that although organizations want to occasionally look up current price and availability information or they want to check on the status of an existing order, buyers rarely want to actually key in their own order information. This is primarily due to the fact that the buyer is already keying the information in his own purchase order transaction system. So for the buyer to enter it into the supplier's system over the Web creates a double entry system that burdens the buyer.

The solution in this scenario was to install BizTalk Server and have information extracted straight from the buyer's purchase order creation system and securely transfer the information to the supplier's order entry system, as shown in Figure 1.3. The automation built-in to this system requires the buyer to enter the information only once. That information is then parsed to create a transaction ticket that is transferred to the supplier's system that is automatically processed in the supplier's order entry. The automated structure eliminates entry errors, decreases the transaction time to process the information, and allows both the buyer and the supplier to see real-time transaction reports.

Because all the transactions are now automated, the buyer can get order confirmations much faster than before. Additionally, because there is only a single entry of the information into the buyer's own purchase requisition system, both the buyer and the seller do not need to re-enter the information, thus creating a faster transaction system for scaling additional orders into the system. The buyer can now drastically increase purchase volumes without having to increase the time spent to process the orders beyond basic entry. The supplier can scale up or scale down transactions to this client and to other clients without adding personnel to process the orders because they are automatically handled by BizTalk Server.

Overall, both buyer and seller can lower their transaction costs, improve transaction times, and minimize errors introduced to the system. This scenario is created and implemented through the use of BizTalk Server Messaging, which is detailed in Part II, “BizTalk Server Messaging.”

Product Catalog Exchange

In this scenario, an organization wants to receive the latest part number, price, and product description catalog of its major supplier. Today, the catalog is provided in both a printed form that is mailed each month as well as an electronic copy that is available for download weekly. The challenge to this process is that the information is frequently out-of-date, and it requires the buyer to manually download the updated catalog. Furthermore, when the buyer wants to select an item, the individual must enter the information into the purchase requisition system, which has created an occasional data entry error in the past.

The better solution for these organizations was to set up a BizTalk Server system in each location and have the price, part number, and description information parsed for any changes and automatically extracted and sent to the buyer's BizTalk Server. The buyer's BizTalk Server translates the information and formats the data to be imported directly into the buyer's requisition system. Because the information only processes modified data, the amount of information transferred regularly is minimal. Because the information is updated regularly, the buyer's requisition system has the most current set of part numbers, pricing, and descriptions readily available for requisitions to be created immediately. Any changes are automatically reflected in the buyer's system.

Because the supplier's part numbers are used all the way from requisition through order processing, there are no longer any errors caused by the mistyping of information. Additionally, because the information is automatically updated, there is no longer the need for either the buyer or the seller to create product catalogs, create download catalogs, or manually update information. This has a huge benefit to the buyer by minimizing interaction time to acquire up-to-date information, and it greatly improves the transaction time because outdated part numbers and incorrect price information are no longer introduced to the system. Both organizations have been able to decrease their cost per transaction, and the supplier has even been able to replicate the process for several other organizations wanting updated price, product description, and part number information provided in real-time.

B2B Portals

Although the previous scenario provides a way to exchange part number, product description, and price information updated regularly, it fails to provide up-to-date product availability information. As an extension to the previous scenario, after the product catalog exchange was working perfectly, the same two organizations wanted to eliminate a manual step that required the buyer to call to check on availability of the products being ordered. Because most products are regularly available, the buyer can assume that any order placed would typically be filled; however, certain items are purchased in quantity on an irregular basis and frequently need to be special ordered. Although this is limited to a certain list of products on a random basis, the buyer wants the ability to check availability on a real-time.

The solution was to extend the product catalog exchange system to include a B2B portal add-in that links availability information to the regularly updated price, part number, and detailed description information. The first revision of the solution allowed the buyer to click on a link that then sent a query to the supplier's system that displayed product availability in 2 to 3 seconds. Because the buyer was really only interested in the availability of certain parts on any given order, the portal look-up to the information provided the desired results of having real-time access to product availability information.

However, over time, the buyer wanted to see availability on all items being purchased and wanted to have not only the ability to one-click request current availability, but also to have product availability automatically appear onscreen for all items desired for purchase. This requires an automated portal processing system that takes the queued-up order and automatically requests the parts availability information to be sent to the buyer's system. After the modification was added to the system, within 3 to 4 seconds, all order requisition information had the corresponding current availability information for parts displayed onscreen.

The buyer now has all the information desired including price, part number, detailed product description, and product availability data. The supplier does not have to provide a full-time customer service representative to export data files and relay availability information. Instead, the mundane tasks are automated, providing faster access to more accurate information. Rather than eliminate the customer service position, the supplier trained the customer service representative to provide more specific service information to the buyer, follow up on transactions, and improve other customer support tasks for the client. This enables the supplier to provide new services that ultimately improve the communications and relationship, thus improving relations with the buyer.

This solution is built on application integration components that are plugged in to BizTalk Server that extend BizTalk Server beyond just data transfers but also into portal information access, scripted queries, and updates to information. This solution to BizTalk Server can be found in Part IV, “Advanced BizTalk Server Topics,” which is specific to Web Services integration, as well as in Part V, “Extending BizTalk Server,” which discusses application integration components.

Embedded Forms Data Submission

In this scenario, an organization accepts orders from buyers in a variety of formats, including orders written on paper and mailed and orders printed on forms and faxed. Other information is manually entered over both a Web-based and a custom entry form system directly into the supplier's business system. However, as the organization began to grow, the amount of time and resources required to process the information grew. Additionally, because the organization's business is seasonal, the constant hiring for the holidays and then reducing personnel after the holidays was a human resources nightmare.

The organization needed the capability to have orders automatically submitted into the order processing system. However, because the buyers used many different systems, it was not going to be easy to create a system that extracts information manually from each system and transfers the transactions system-by-system. The solution required a process flexible enough to allow for the processing of information from a variety of different sources and centrally consolidate the information for order acceptance.

The solution was built on BizTalk Server. The BizTalk Mapping tool was used to create data maps between each buyer's system to BizTalk Server using a number of input formats including HTTP, HTTPS, EDI, and XML. With the new system, buyers enter the information once into their own purchase requisition systems, and an export file is then created that securely sends the information to the supplier's BizTalk Server. The supplier's BizTalk Server processes the information and automatically transacts the data in the supplier's order processing system. Within minutes, the buyer is notified that that the order has been processed and accepted.

The advantage of this system is the capability for the supplier to accept the input from a variety of different sources. It also does not require the buyers to convert their systems or use special forms to enter information. All the data entry forms and individual system processes were automated, minimizing entry errors and decreasing the time and effort it took to process the orders. Forms were replaced almost altogether as the processing of information was automated.

This solution is based on the BizTalk Mapper covered in detail in Chapter 5, “The BizTalk Mapper,” as well as in the Part II, “BizTalk Server Messaging.”

Business Process Integration

Business process integration is critical to organizations wanting to simplify their internal application-to-application communication. This scenario took an organization that, like most organizations, had its back-end processes completely unlinked. The organization frequently required double and multiple manual entry of the same information from the point-of-sale system, to the general accounting system, to the organization's customer relationship management system, to the order fulfillment system. Users were constantly cutting and pasting information between systems; in fact, the organization did a study and determined that each employee spent an average of 52 minutes each day entering information or cutting/pasting information that had already been entered into another system.

The solution was to integrate all the organization's applications so that common information was transferred automatically between systems. The organization did not want to create custom gateways between each system because the applications being used were expected to be updated or replaced over the next year or two anyway. So the organization installed BizTalk Server and created data maps between its various business applications.

This EAI initiative focused not on making the accounting system tie directly to the customer relationship system, and the customer relationship system tie directly to the product fulfillment system, and so forth. Instead, each application was configured to communicate with a single centralized BizTalk Server system, as shown in Figure 1.4. Each dataset was mapped using BizTalk Mapper into a common data exchange format. After each system was able to successfully communicate with BizTalk Server, information was transmitted to BizTalk Server in a common format and then communicated with several other systems automatically. A single entry system provided multiple sets of data being distributed out of the BizTalk Server system.

In addition to minimizing cut-and-paste manual processes, the organization is also able to monitor transaction logs to better track information distribution, and the organization is able to throttle and schedule transaction processing that did not have real-time demands to a time when processing power was idle. The system is able to ensure consistency of data interchange, and it minimizes the chance of typos or other entry errors being introduced into the data stream.

This solution is based on several BizTalk technologies, including BizTalk Mapper covered in Chapter 5, as well as the information covered in detail in Part VII, “Line of Business Adapters and Industry Toolkits.”

Back-end Supply Chain Integration

When many organizations think of extending their business to facilitate an external e-commerce presence on the Internet, they frequently forget to take into account the effort needed to integrate the e-business system into their existing order processing and transaction systems. This scenario highlights the challenges and the solution implemented by one organization that integrated its existing internal accounting and inventory management system with a new e-commerce system.

This scenario involves a traditional e-commerce system that accepts business-to-consumer orders on a Microsoft Commerce Server 2000 system. A Web-based front-end enables consumers to enter information that is then tracked and forwarded on to the organization's back-end system. This is where the challenges arose—trying to integrate an existing accounting and inventory system with the new e-commerce system.

The organization found that there was no direct gateway product that transferred e-commerce information into the order processing system, nor was there a seamless way to get inventory information out of the inventory management system into a viewable mode available for the e-commerce system. The organization set up a Microsoft SQL Server that served as the depository for inventory, pricing, and order information, as shown in Figure 1.5. The BizTalk Mapper was used to get extracted information out of the inventory management system and into the SQL Server. The e-commerce system was linked to the SQL Server and gave external customers a view of the most current price and availability information that was updated on the system.

When an e-commerce order was entered, the information was sent to the SQL Server where the temporary transaction was held. The information was then processed by the BizTalk Server that mapped the transaction into the organization's existing order processing system. Because the information was now directly accepted by the order processing system, the organization had an automated method of getting information from the e-commerce system directly into the order processing system. Confirmation information was then processed and sent back to BizTalk Server. This system mapped the data to update the e-commerce system where the transaction was accepted with updated status information.

In this example, instead of replacing its accounting and inventory management system or creating a manual bridge between its old and new systems, EAP allowed the organization to integrate its business systems. BizTalk Server facilitated more than just a manual bridge but actually an automated system that linked the external with the internal system.

Key to this solution is the integration of BizTalk Server with Commerce Server 2002, covered in Chapter 25, “Integrating BizTalk with Server Accelerator for Ressetta.NET.” Also important in this solution is the integration of BizTalk Server with other .NET technologies covered in Part IV and Part VII.

Consolidation of Information

This last scenario involves BizTalk Server where it helped an organization integrate several different business application systems that were eventually consolidated into common applications across business units. The organization had more than 20 different applications where customer data, product information, inventory data, and other critical business information reside. The variation in systems was brought on by several recent mergers and acquisitions of the organization.

Each user had to open several specialized applications to simply view a full list of customers and company products and services. BizTalk Server helped the organization by using the BizTalk Mapper that allowed the mapping of information between systems and ultimately the exchange of key information between systems. This included the connecting of inventory management and accounting systems, centralization of price and availability look-up information, the creation of a transaction database system, and the provision of a centralized look-up of information.

All the systems extracted core data and mapped the information to be stored in a SQL Server. The SQL Server became the centralized depository of the transacted data. Several data maps were created to link the information between the various systems, and because there were more than 20 different applications in use, the maps became extensive as the correlation of critical data necessitated a complex network of informational links.

BizTalk Server was able to accept the information and simplify the organization's integration of data between and within the applications. This solution was built on BizTalk Mapper also covered in Part III, “BizTalk Server Orchestration.”