Microsoft Commerce Server 2000: Integrating Third-Party ERP with Commerce Server

Integrating Microsoft Commerce Server 2000 with existing Enterprise Resource Planning (ERP) systems, such as SAP, J.D. Edwards OneWorld®, PeopleSoft, and other corporate systems, is often critical to successfully implementing a Commerce Server application. E-Commerce data and business rules often exist on the ERP system. For accuracy and consistency, data and business rules residing on the ERP system need to be accessible from the Commerce Server application or copied (mirrored) to the Commerce Server application.

This chapter describes several techniques for making ERP data available to Commerce Server applications, including batch downloads, real-time connectors, queued connectors, and mirrored updates. The technique you choose depends on the requirements of your site, the availability and performance of your ERP system, and the availability of the different types of integration connectors available to your ERP system.

Figure 10.1 shows a common high-level architecture for integrating an ERP system with a Commerce Server application.

 

Figure 10.1 Sample physical architecture for integrating an ERP system with a Commerce Server application 

E-commerce data, such as the following, often exists on the ERP system and must be made accessible to the Commerce Server application:

• Customer data

• Product catalog date (including SKU numbers, vendor information, and availability)

• Product inventory levels

• Pricing data

• Order status and history

Additionally, algorithms and business rules, such as the following, usually exist on the ERP system and must also be made accessible to the Commerce Server application:

• Taxation rules

• Credit card processing policies

• Product authorization rules

• Pricing algorithms

• Shipping algorithms

Finally, data from the Commerce Server application, such as the following, must be sent back to the ERP System:

• Customer orders

• Web customer profiles and customer updates

It is important to decide which system should own the data; in most cases, it will probably be the ERP system.

Integration Techniques

There are four common techniques for integrating data on ERP and Commerce Server applications:

• Batch downloads

• Real-time connectors

• Queued connectors

• Mirrored updates

Batch Downloads

Using a batch download is a common technique for copying ERP-managed data from an ERP system to a Commerce Server application. Batch downloads often work well for the product catalog, customer data, and pricing data, and can also work well for inventory and order-status data. Fundamental to this technique is the idea that the ERP system owns the data.

On a regular (usually nightly) basis, the subset of data needed by the Commerce Server application is deleted from the Commerce Server application and refreshed with data from the ERP system. To accomplish this, you must extract the required data from a specific ERP system and copy it to the Commerce Server application. If you are using the Commerce Server Product Catalog System, you will probably use the Product Catalog objects and other objects to do this. If you aren't using the Product Catalog System, you can import data directly into Microsoft SQL Server tables using the Bulk Copy Program (BCP) or Data Transformation Services (DTS).

Figure 10.2 shows how data is extracted from an ERP system and copied to high-end SQL Server servers used by the Commerce Server application.

 

Figure 10.2 Transferring data from an ERP system to a SQL Server database 

Depending on the volume of data and the hardware you use to perform batch downloads, the transfer process can take from a few minutes to several hours. To keep the Commerce Server application available while the download is in progress, you should deploy two versions of the Commerce Server application database: the online version and the offline version.

If you do this, the Commerce Server application can direct all processing to the online database while the batch download is taking place. When the scheduled extract of ERP data is finished, you can begin the Commerce Server data import process and direct it to the offline database. When the update is complete, you update a global variable in the Commerce Server application to direct all processing to the offline database. The offline (updated) database then becomes the new online database and the target of Commerce Server application requests. The former online database becomes the new offline database, which is the target of the next download. Thus, by alternating between the two databases, you can ensure that your application is available even when the nightly batch downloads are in progress.

Figure 10.3 shows how you can increase system availability during a batch download by using two copies of the database, designating one as "online" for processing requests and the other as "offline" for batch updates. When the update is complete, you use a global variable to switch the two databases.

 

Figure 10.3 Using two copies of the database to ensure system availability 

The batch download is one of the most popular techniques for synchronizing data between an ERP system and a Commerce Server application. Consider the following points if you decide to use the batch download technique:

• You usually have to write custom scripts to export the subset of data needed by the Commerce Server application from the ERP system and import it into the Commerce Server application.

• The batch download technique is relatively straightforward and, if you incorporate the online/offline database strategy, you can update at any time, while still keeping the Commerce Server application available at all times.

• The batch load technique minimizes the performance burden on the ERP system. Because the data extract causes a measurable increase in processing on the ERP system, you can minimize its impact by scheduling the data extract during a time of low activity.

• Using the batch load technique separates the Commerce Server application from the performance or maintenance schedule of the ERP system and separates the ERP system from the processing requests of the Commerce Server application.

• The batch load technique works well for data that becomes stale slowly, or at least remains valid for the period between data refreshes.

  Product and pricing data usually must be updated only once in a 24-hour period.

  Product inventory data might need to be updated more often. For example, a customer who is ordering a software package is reassured by seeing an inventory level of 231 copies available as of 4 A.M. that morning and completes the order. But, if only 7 copies were available at 4 A.M., the same customer, believing that the software is likely to be sold out, might decide to check availability on another site. Items that have been restocked since the last update would still appear at their low, pre-restock levels until the next nightly batch download.

• If you have data that becomes stale quickly, you can conduct full data downloads nightly and conduct incremental downloads more frequently.

  For example, you can download the entire product catalog, pricing, and inventory data nightly, but update inventory data every hour. Although some data still might become stale between downloads, discrepancies will be much smaller using this technique.

• You can combine ERP data with data from other external sources before downloading it to the Commerce Server application in one batch.

  For example, you might want to combine ERP catalog data with product images, technical specifications, customer testimonials, or cross-sell data.

• You can simplify the batch download and achieve greater scalability if you put the data to be downloaded into a separate database, to be treated as read-only by the Commerce Server application. Doing this enables the batch load scripts to send all database tables to the offline database without doing any other data transfers.

Of all the techniques described in this chapter, the batch download technique is probably the fastest and easiest way to begin integrating your systems. The batch download technique also enables you to better control system security by limiting access between the DMZ connected to the firewall and the corporate network to the single ERP integration server, rather than opening access to all of the production servers. You should use a separate server to drive the process, rather than adding batch processing to the load on the production servers.

You can write an application in Microsoft Visual Basic that you schedule to run through the SQL Executive on the server you use to manage the data transfer process (the "ERP integration server"). This application should do the following:

• Move required data from the ERP system to the Commerce Server application. This includes:

  • Transferring data files from the hosts and Microsoft Windows 2000-based servers using the File Transfer Protocol (FTP). You can use the Internet Transfer Control to do this.

  • Using BCP functions (taken from the DB-Library for Visual Basic) to transfer data from text files into SQL Server. You can also use the DTS included in SQL Server 7.0 or SQL Server 2000 to do this. For more information about DTS, see https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx .

  • Starting SQL Server stored procedures for data processing.

  • Changing ASP global application variables or the Global.asa file after you have moved new product data into production. This tells the application that the download is complete; the online database then becomes the offline database, and vice versa.

• Move required data from the Commerce Server application to the ERP system. This includes:

  • Transferring order records (and other data, as appropriate) that are new since the previous batch download from SQL Server to text files.

  • Transferring the order text files to the ERP system, using FTP. You can use the Internet Transfer Control to do this.

  • Marking order records as uploaded when you have received verification that the transfer is complete.

A data transfer application must perform thorough error checking and data validation to ensure data integrity. The Internet Transfer Control included in Visual Basic 6.0 provides FTP transfer functionality. You can use DB-Library for Visual Basic to access BCP and SQL Server functions. Visual Basic also provides error handling, error checking, and transaction integrity to the application.

Real-Time Connectors

Another effective technique for integrating ERP systems with Commerce Server applications is to use a real-time connector. To use a real-time connector, however, the ERP vendor or a third-party vendor must provide the connector software. If you are integrating with SAP, you can get the SAP DCOM connector from https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx . For access to an IBM CICS host-based system, you can use Microsoft Host Integration Server 2000. Support for real-time connectors from other ERP vendors varies; check the Web site of your ERP vendor or check with a technical representative for more information about the real-time connectors that they provide.

In general, real-time connectors wrap the programming interfaces on the ERP system with a COM+ component executed in real time. The COM+ component is essentially a proxy object that can then be instantiated and called from any ASP page in the Commerce Server application by the Server.CreateObject() method.

Figure 10.4 shows the architecture of a Commerce Server application using the SAP DCOM connector to make real-time calls to SAP.

 

Figure 10.4 A Commerce Server application using the SAP DCOM connector to make real-time contact with an ERP SAP system 

Using a real-time connector, any application programming interface (API) functionality in the ERP system becomes available to the Commerce Server application synchronously and in real time. Even if an API for a specific function is not available, ERP systems can provide hooks for writing custom API functions, which can then be wrapped by a COM+ proxy object and made available to the Commerce Server application.

If the connector software is available, using real-time connectors can be a powerful and useful method; however, you should consider the following points before using this technique:

• Processing requests from the Commerce Server application can impact performance of the ERP system. It is very important that you analyze performance before you begin integrating the two systems. ERP systems are usually tuned to serve only tens to hundreds of users, but a Commerce Server application can expose the ERP system to thousands of additional users. You must prepare for that additional load on your ERP system before you integrate the two systems.

• You must test and monitor the performance of real-time calls. Monitor both Web servers and application servers for performance during stress testing.

• You should test performance beyond expected traffic levels to the point where system performance begins to erode significantly. The symptoms of a breakdown will then be much easier to recognize, should it occur in a production environment. The Microsoft Web Application Stress (WAS) tool, available at https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx , is an excellent tool for testing performance.

• Real-time connector software must be available for the targeted ERP system.

• You usually incur additional software and licensing fees when you use real-time connectors.

• If you decide to use real-time connectors, you should start implementing them very early in the development cycle.

  In a medium-to-large organization, different groups usually own the ERP system and the Commerce Server application. Additionally, ERP developers often know little about Commerce Server applications, and Web developers often know little about the APIs in ERP systems, so the integration effort has to be a joint project. Agreeing on priorities, coordinating development and test schedules, and coordinating software installations and server reboots can require additional time.

• You must have a high-speed network link between the Commerce Server application and the ERP system. If your Commerce Server application must be highly available, the high-speed network link must also be redundant.

• The performance of the ERP system can impact the Commerce Server application.

  If the ERP system doesn't respond to processing requests, the Internet Information Services (IIS) 5.0 worker thread making the call will be blocked. Because a COM+ object controls the ERP API call, the IIS ASP timeout setting won't take effect and the thread will be left waiting until the call completes. Tens or hundreds of nearly simultaneous requests to slow-running proxy objects could overload a Web site until all available worker threads are waiting and the ASP request queues are full. For this reason, a high-performing ERP system is essential to make synchronous calls successful.

• The maintenance schedule of the ERP system can affect the performance and functionality of the Commerce Server application. To avoid hanging IIS worker threads while connection attempts time out, you should use a global application variable to control access attempts to real-time calls.

• Remember that the hardware and software powering ERP systems is usually several times more expensive per processing cycle than that powering a Commerce Server application. Consequently, there is usually greater resistance to adding hardware to the ERP system to enable greater Web functionality.

• In general, it is difficult to guarantee the performance of API calls to the ERP system at any time from a Commerce Server application.

  For this reason, the batch download technique is often combined with the real-time connector technique to provide a hybrid solution. You can load product catalog, pricing, order, and inventory data nightly, update it hourly, and make it available to all customers, while offering real-time access to data such as order status and inventory only to your more privileged customers.

Figure 10.5 shows how a Commerce Server application might be integrated with a real-time connector to a host-based CICS system, combined with nightly batch downloads.

 

Figure 10.5 Combined real-time and batch integration between a Commerce Server application and a host-based CICS system 

Queued Connectors

The queued-connector technique for integrating a Commerce Server application with an ERP system is similar to the real-time connector technique. The key difference is that the queued-connector technique adds a queuing technology to make the calls asynchronous. The queued-connector technique, like the real-time connector technique, employs a proxy object to access the ERP API. However, instead of having the ASP page call the proxy object directly, the ASP page calls an object or function that places a request for the proxy object on Message Queuing. The Message Queuing message is sent to a listening server application that then invokes the proxy object to perform the requested function.

Figure 10.6 shows an ASP page calling a COM+ component that places an ERP request into a Message Queuing message, thus allowing the ASP page to complete quickly. The Message Queuing message gets delivered to the target server, where a Listener service picks up the message and executes the request.

 

Figure 10.6 Using a queued-connector 

The queued-connector technique works well for tasks like submitting orders to an ERP system or requesting order status from an ERP system. It also resolves some of the most important issues associated with making synchronous calls directly to an ERP system, such as the following:

• The performance and maintenance schedule of the ERP system has much less impact on the performance of the Commerce Server application than it does with the real-time connector technique. The IIS worker thread no longer calls directly into the ERP system, but simply makes a call to place a message on Message Queuing. This call executes quickly and doesn't block the IIS worker thread.

• If the ERP system is high performing and responsive, the request is delivered to the Listener service and executed at a speed that makes it appear to be executing in real time.

• If the ERP system is performing slowly, requests are placed in a queue and then executed. As long as the average speed at which the ERP system can process requests is faster than the average speed of incoming requests, performance should be acceptable. The net result is that spikes in the numbers of requests are flattened without over-burdening either the Commerce Server application or the ERP system.

• If the ERP system is taken offline for maintenance, requests can still be made and placed in the queue. The Commerce Server application can continue to function, even though the ERP system is offline.

• A custom Listener service can be built to limit the number of concurrent requests made to the ERP system, schedule the times at which calls to the ERP system are made, or prioritize the calls to the ERP system by type of request or by customer privileges.

The primary limitation of the queued-connector technique is that the calls are asynchronous. ASP requests to the ERP system always get queued; these requests can be executed almost immediately or not until much later.

The architectural challenge in implementing this technique is that the asynchronous model only lends itself to the techniques and functions associated with input parameters. Return parameters, such as error codes, only indicate whether the request was successfully queued, not whether the request was successfully executed. To provide results to the original caller, you must use an out-of-bounds mechanism, such as that outlined in the following steps:

1. An ASP page calls an OrderSubmit object to submit an order.

2. The OrderSubmit object allocates a unique request ID and places the request into a message queue. It also writes a record to a local SQL Orders table, recording the order and setting the status to Pending.

3. The ASP page dynamically displays the request ID to the customer and informs the customer that the order has been accepted.

4. At some later time, the Message Queuing service delivers the message to the target server.

5. A Listener service picks up the message with the request ID and invokes a proxy object to submit the order to the ERP system in real time.

   If an error occurs, the listener can retry, put the message back into the queue, or write an error to a log file.

6. The proxy object calls the ERP system and submits the order. It then updates the status in the local SQL Orders table to Accepted.

7. At any time, the customer can invoke an ASP page to query order status. The ASP page then checks the local SQL Orders table and returns the contents of the order, along with the status (Pending or Accepted).

Although the queued-connector technique can be implemented with any queuing technique, it works best with Message Queuing. In addition, you can facilitate development with COM+ by leveraging queued components in the implementation.

Mirrored Updates

The mirrored updates technique is another method for integrating ERP systems with Commerce Server applications, but it requires software event support on the ERP system. As events occur on the ERP system (inventory is updated, customers are added, product pricing is changed), they can be trapped and transmitted over a real-time connector to the Commerce Server application.

You can mirror updates from the ERP system constantly throughout the day to the back-end databases of the Commerce Server application. All processing requests related to Commerce Server application traffic are directed to SQL Server database servers, so there is no longer any reason to call directly into the ERP system.

When you use the mirrored updates technique, ERP system performance and maintenance schedules have only minimal effects on the Commerce Server application, and vice versa. The routines mirroring the events between the two systems are the only performance inhibitors. You can also add a queuing mechanism to the mirroring routines to limit the impact of ERP system updates on the Commerce Server application. A queuing mechanism also guarantees that all updates reach the Commerce Server application, whether or not the network link between the systems is available or the Commerce Server application has been taken offline for maintenance.

You should consider the following points before using the mirrored updates technique:

• You must have ERP real-time connector and event support.

• This technique works best if you add queuing to the implementation to prioritize the updates, limit the number of concurrent updates, and make sure all updates are completed, regardless of network availability.

• This technique minimizes, but doesn't eliminate performance risks. When you implement this solution, you should still monitor performance on both the ERP system and the Commerce Server application. Any performance impact will probably affect the Commerce Server application data servers, due to additional row updates.

• You can combine this technique with the batch download technique. If you do, batch downloads can be done nightly, thereby guaranteeing that data is always synchronized. Mirrored updates can then occur throughout the day, keeping the data synchronized until the next batch download occurs.

Figure 10.7 shows mirrored updates occurring between the ERP system and a Commerce Server application.

 

Figure 10.7 Mirrored updates 

Figure 10.7 shows an inventory-updated event occurring in the ERP system. It triggers a call across a real-time connector to an inventory COM+ object of the Commerce Server application. The inventory COM+ object then mirrors the update in the local SQL Server database. In the Commerce Server application, an order-submitted event triggers a call across a real-time connector to place the order in the ERP system.

You can extend the mirrored updates model on the Commerce Server application by leveraging COM+ events to start multiple autonomous COM+ components. These components perform multiple Commerce Server-related tasks in response to an ERP event.

General Considerations and Best Practices

This section describes general considerations and best practices for using integration techniques in the following areas:

• ERP systems and Commerce Server business rules

• Pricing and promotions

• Shipping, taxation, and credit card authorization

• Product catalog

• Replication

• Physical architecture (highly scalable)

ERP Systems and Commerce Server Business Rules

The ERP system normally contains business rules for such key commerce functionality as pricing and promotions, taxation, shipping, inventory management, and credit card authorization. You must identify each of the business rules and decide whether to mirror each one in the Commerce Server application or provide a real-time call for it to the ERP system. Consider the following as you make your decision:

• The type of business rule

• The frequency with which the business rule must be invoked

• The costs and risks associated with invoking the business rule directly, in real time

• The cost to mirror the business rule

This decision also depends on your organizational priorities.

In general, however, it is better to mirror frequently used business rules in the Commerce Server application. For example, pricing algorithms based on customer history are often table-driven and computationally expensive because they must be recalculated frequently. The best way to handle pricing algorithms is by moving the pricing data to the Commerce Server application using the batch download technique. You then create a COM+ component and/or stored procedure within the Commerce Server application to mirror the ERP business rule.

Credit card processing, on the other hand, occurs much less frequently, so you can either call this functionality in real time from the Commerce Server application or leave it for the ERP system to process after the order has been uploaded. If you leave it for processing by the ERP system, you can use a standard Commerce Server component to verify the card number.

Pricing and Promotions

The ERP system often contains a complex set of pricing business rules based on each of a company's customers. When you use this functionality, you might need to address the following variables:

• Quantity

• Customer and customer volume history

• Current availability

• Product market status (discontinued, recalled, and so on)

• Sales goals

• Advertisements and promotions

All of these items can influence pricing business logic. In some industries, pricing is also controlled by regulatory agencies. Consider the following suggestions when you deal with pricing issues:

• Use the pricing models and templates from the ERP system and mirror changes to the Commerce Server application.

• Establish a real-time connection to the ERP system only if any combination of customer, quantity, and SKU in the Commerce Server application falls outside the templates mirrored from the ERP system.

• Make sure you understand custom pricing. Apply the 80/20 percentage rule whenever possible. In other words, if you can accommodate most of your customers (80 percent or more) with a defined pricing logic, focus your development on that work.

• If you provide the capability for long-lived shopping carts (shopping carts that a customer can save and return to at a later date), pricing on products can change between the time the SKU was added to the cart and the time the purchase takes place. You can avoid problems if you include the pricing algorithm in the Order Processing pipeline (OPP) and invoke it just prior to check out.

Shipping, Taxation, and Credit Card Authorization

Shipping, taxation, and credit card authorization functions are each important to a Commerce Server application, but are also often provided by the ERP system. Because these functions occur only once per order, and near the end of a transaction, they make good candidates for real-time connections.

However, if you must provide these functions from the Commerce Server application, several third-party software developers provide components that you can use for this purpose. For a list of products, see https://www.microsoft.com/commerce .

Product Catalog

The Commerce Server Product Catalog System is a key part of the Commerce Server product. Its terms, attributes, category definitions, associations, and hierarchies provide powerful searching capabilities not found on ERP systems. You should perform early evaluation and prototyping using the Commerce Server product catalog during batch imports.

If you have to use another technique for building your catalog, then you should design the product database to match the structure of the corresponding ERP system as closely as possible. Doing so will simplify data transfer between platforms and make it easier to mirror the business logic in the ERP system. You should also consider the following points:

• You must develop a process to add content and add data to the product catalog as it is being built from the ERP system. The ERP system contains product SKUs, prices, and basic product details. However, to sell products on the Web, you must provide more detailed data, including images, multimedia, and so on. As the catalog is copied from the ERP system, add content to the data before serving it on the Web.

• The cleanest way to deliver the product catalog is to have a read-only copy of the catalog on the Web. This provides performance gains, because the Catalogs database can then be optimized for Web delivery.

• Design a scheduled update process. In some cases, the product catalog must be updated nightly, but there are two ways to handle updates: rebuild the entire catalog nightly or just apply the daily changes to the database.

Replication

Although it is possible to use replication as an ERP integration technique (writing custom applications to bypass the ERP vendor's recommended API or setting up replication between the ERP system's database and the Commerce Server Application database), it is definitely not recommended. You should not try to directly access database tables on the ERP system.

Many ERP systems support API access only to managed data and specifically don't permit direct access to the underlying tables. In addition, many ERP vendors specifically warn against replication because they might need to change the underlying table structures in future releases.

Physical Architecture

The Microsoft .NET architecture supports many different physical configurations that also support a highly scalable Commerce Server application with ERP integration. Figure 10.8 shows the logical architecture of a three-tier Commerce Server application with ERP integration. The ERP integration shown in Figure 10.8 includes batch downloads and a real-time connector.

 

Figure 10.8 Highly scalable Commerce Server application integrated with an ERP system 

Figure 10.8 shows the Web portion of a Commerce Server application. In this example, there are multiple Web servers, a set of clustered SQL Server servers, and an ERP system (the host) on the back end. The Web servers:

• Host the user interface (HTML and ASP pages).

• Host lightweight COM+ components called by the ASP pages.

• Provide the logic that requests data from the SQL Server servers, which provide the tables needed to build a shopping basket.

There is a membership environment that controls authentication, user accounts, and user profiling. The following table describes each component of the system shown in Figure 10.8.

System component	Services	Description
Web servers	IIS 5.0 COM+ Commerce Server Pipeline objects Commerce Server	Contain the ASP files of the site.
SQL Server servers	SQL Server 2000 (or SQL Server 7.0)	Provide all database services for the site, including customer, product, and pricing information, as well as the tables for shopping baskets and receipts.
ERP Commerce objects	ERP integration software provided by ERP vendors Custom-built integration objects	Provide Internet order processing and integration. This may be a combination of vendor-supplied objects and custom objects.
ERP system		Provides business management.

Integrating with SAP

Figure 10.9 shows a network diagram of an SAP system application with an integrated Commerce Server application.

 

Figure 10.9 SAP system with integrated Commerce Server application 

This section explains the following points to consider when you integrate a Commerce Server application with an SAP R/3 system:

• Using the SAP DCOM connector

• Integrating a product catalog

• Integrating item pricing

• Integrating inventory data

• Integrating orders

SAP DCOM Connector

The bridge between the Windows 2000 platform and the SAP business object framework is the SAP DCOM connector. You can download the DCOM connector from the SAP Web site: http://www.sap.com/ . For detailed installation instructions and programming procedures and considerations, see the article "SAP DCOM Connector: Expanding the Reach of Your SAP Business Processes," by Homann, Rogers, and Russo, in SAP Technical Journal, Vol. 1, No. 2. You can also find the article online at http://www.intelligenterp.com/feature/archive/homann.jhtml?_requestid=86899 .

You use the DCOM connector to write a COM component to access existing Business APIs (BAPIs) or custom-developed remote function calls (RFCs) in SAP R/3 on any SAP-supported platform. The COM component with which you access SAP resides on the SAP integration server (see Figure 10.9). The SAP DCOM connector package contains an Object Builder Wizard, which eliminates the need to write large amounts of C++ code using native SAP RFCs. The components you create with the wizard are COM+ components that are reusable by other applications.

The DCOM connector process is as follows:

1. An ASP page calls the generated DCOM connector object directly, or calls a custom business object that wraps the DCOM connector object so that it can provide custom functionality.

2. If the ASP page did not call the DCOM object directly, the DCOM connector call is automatically sent by COM+ to the SAP integration server.

3. The DCOM connector object on the SAP integration server calls a BAPI object or custom-written RFC.

4. The BAPI gets the results from the SAP environment and returns them to the calling object or ASP page.

5. The results are returned to the Visual Basic business object.

6. The results are returned to the ASP page.

Figure 10.10 shows an example of this process.

 

Figure 10.10 Using the DCOM connector 

The example in Figure 10.10 shows an availability query being made to SAP for a particular product, using the following process:

1. The ASP page calls the Visual Basic business object, which in this case wraps the DCOM connector object that resides in a COM+ package on the SAP integration server.

2. The DCOM connector object uses the SAP interface DLL (Librfc32.dll), which you can use to interface with any SAP system, regardless of the host platform.

3. The BAPI checks the tables and assembles an internal table of product availability for a selected warehouse, which is sent back to the DCOM connector object.

4. The product availability data is wrapped into a Microsoft ActiveX Data Objects (ADO) recordset, and is then passed back through the COM+ package.

The approach in this example works well as long as the ERP system is able to process all of the incoming requests. However, because Web traffic can surge unpredictably, this might not always be the case. In such instances, it is better to use a Commerce Server database synchronized in real time with the SAP application server instead of using the DCOM connector.

Product Catalog

You can use the following techniques to integrate a product catalog between Commerce Server and SAP:

• Batch download product catalog data

• Batch download incremental catalog changes

• Mirrored updates

• Real-time connections

In each of these techniques, the product catalog data obtained from SAP can be enriched with other site data, such as the path to an image for the product SKU, other technical data not residing on the SAP system, additional descriptions of the product, or cross- or up-sell product numbers.

Batch Download Product Catalog Data

You can export product catalog data from SAP by scheduling a custom extract program on the SAP R/3 system to extract relevant product data from the SAP tables into a comma-separated value (CSV) file, XML file, or flat file. You can then import that file into the Commerce Server product catalog. Figure 10.11 shows how you can use a batch download to transfer catalog data from SAP to Commerce Server.

 

Figure 10.11 Using a batch download to transfer product catalog data from SAP to Commerce Server 

Figure 10.12 shows a second way of doing this, which can only be used with version 3.x or 4.x of SAP R/3. In this scenario, you run a Windows 2000 scheduled process that uses the provided BAPI to extract product catalog data from SAP. You can then place the extracted product catalog data directly into a Commerce Server product catalog.

 

Figure 10.12 Placing extracted catalog data directly into the product catalog 

Batch Download Incremental Catalog Changes

Incremental changes to product catalog data on an SAP system can be reflected using a batch method, which can reflect changes almost in real time. The process looks exactly the same as that shown in Figure 10.11, except that the SAP batch process extracts only changed product data to send to Commerce Server instead of sending all product data.

Mirrored Updates

You can use either of the two mirrored update techniques shown in Figure 10.13 to send more immediate notification of changes to the product catalog. Both techniques for synchronizing data use SAP Application Link Enable (ALE) to notify the Commerce Server application of product changes by means of the IDOC message MATMAS02 IDOC.

 

Figure 10.13 Updating the product catalog using mirrored updates 

You can combine the mirrored-update technique with the batch-update technique, or you can use it by itself.

Item Pricing

Integrating item pricing can be a greater challenge than integrating catalog data, depending on how the pricing scheme is configured in SAP and at what point in the order process you decide to apply the pricing calculations. In some business-to-business (B2B) scenarios, you must deal with complex pricing formulas, such as contract pricing by customer, quantity discounts, and discounts on items ordered in relation to other items on the order. Some of these complex pricing formulas can be difficult to replicate in the Commerce Server application. This section describes the following ways to integrate pricing information for items:

• Batch download item prices

• ALE-triggered price change download

• Real-time pricing integration

Batch Download Item Prices

You can batch download item prices by customer, item, and quantity. To do this, you must first build pricing logic into the Commerce Server application to calculate the prices. Figure 10.14 shows the process for batch downloading item prices.

 

Figure 10.14 Batch downloading item prices 

In this scenario, a scheduled Windows 2000 process retrieves pricing data from SAP by means of a DCOM connector object that wraps a custom RFC to retrieve the data. When the data has been retrieved, a custom-built object is invoked to place the pricing data into the Commerce Server database.

ALE-Triggered Price Change Download

You can attach an Application Link Enable (ALE)-triggered price change download to a user exit when customer/item combination-specific prices change. This scenario requires that you build pricing logic into the Commerce Server application to calculate the pricing. Figure 10.15 shows how this technique works.

 

Figure 10.15 ALE-triggered price change download 

In this scenario:

1. A price change for a customer/item combination is detected when a user exits.

2. A custom IDOC message (in this example, zprice01) is created and passed to the ALE subsystem.

3. ALE invokes a custom RFC to pass the custom IDOC data to the SAP COM object for an ABAP-generic RFC server.

4. The custom RFC calls a custom COM object to place the data into the Commerce Server item pricing tables.

Real-Time Pricing Integration

You can access pricing for an order in real time by invoking a pipeline component calling the SAP SalesOrder_Simulate BAPI. Figure 10.16 shows how you would do this.

 

Figure 10.16 Real-time pricing integration 

In this scenario, you update pricing for items in the order at the time the customer confirms the purchase. This technique uses SAP for all pricing calculations. To use real-time pricing integration, you must create a custom pipeline component to call a previously created SAP DCOM component to invoke the SalesOrder_Simulate BAPI. When all of the item pricing and order costs have been retrieved from SAP, the Commerce Server OrderForm object is updated with the new data.

Inventory Data

This section describes the following methods of integrating inventory data:

• Batch download inventory data

• Batch download inventory changes

• Mirrored updates using ALE

• Real-time connections

These techniques are similar to those described for integrating the product catalog, except that inventory data is generally much more volatile than product catalog data. For this reason, you must carefully plan how to integrate this data.

If you expect a low volume of traffic, you can use the real-time connection, in which the DCOM connector transmits order data to the Product Availability BAPI. The Commerce Server application can then use the same inventory data used by SAP.

If you expect medium-to-high traffic volumes, integration becomes significantly more complex. In a high-volume situation, you probably should use a combination of the batch, batch plus changes, and ALE integration techniques described in this section.

Batch Download Inventory Data

In the batch download scenario, you extract SAP inventory data using a custom Advanced Business Application Programming (ABAP) report program to place the data into an XML file, a flat file, or a CSV file on the target system. A Windows 2000 service or scheduled program then either reads the extracted data and places it directly into the Commerce Server database, or uses the Commerce Server Catalog objects to place it in the Commerce Server database.

The batch download is generally run once a day and is particularly useful if you can allocate a certain percentage of inventory exclusively to the Commerce Server application. A disadvantage of this technique is that inventory data can be out-of-date by the time the next cycle runs. Figure 10.17 shows the batch download scenario.

 

Figure 10.17 Batch download scenario 

You can initiate another version of the batch download with a Windows 2000 scheduled process, as shown in Figure 10.18.

This scenario differs from the SAP-initiated batch scenario in that the batch download process is controlled from the Windows 2000 server instead of being scheduled from SAP. This gives the Commerce Server system administrator greater control over the timing of the batch update. However, this type of process must be coordinated with the SAP Basis administrators so that conflicts in the extraction process don't adversely affect the main SAP batch system processing.

 

Figure 10.18 Batch download using a Windows 2000 scheduled process 

Batch Download Incremental Inventory Changes

In addition to the nightly batch download, you can develop an inventory update process to download inventory changes to the Commerce Server application more often. The process looks exactly the same as the regular change process shown in Figures 10.17 and 10.18, except that the SAP batch process is configured to extract only changed inventory data to send to Commerce Server, instead of sending all inventory data.

Mirrored Updates Using ALE

You can also download inventory data on a real-time basis to the Commerce Server Application database. You can use this technique by itself as the primary technique for replicating inventory, or in conjunction with a batch download technique. Figure 10.19 shows the mirrored update technique using ALE.

 

Figure 10.19 Mirrored updates using ALE 

Real-Time Connections

A real-time connection scenario uses the DCOM object in a Commerce pipeline object to return the current inventory value in SAP in a real-time fashion. However, this method should be used with caution, because it can adversely affect performance on the SAP application servers.

Orders

There are several batch, synchronous (real-time), or asynchronous (queued) techniques that you can use to integrate orders from a Commerce Server application into SAP.

If you use a batch technique to send orders to SAP, you first must convert Commerce Server order data to an IDOC format, which you can then send to SAP by means of the IDOC interface. This technique requires little or no customization of SAP programs and can be administered easily by SAP system administrators.

To use a real-time order interface technique, you must create a SAP DCOM connector object to communicate with the SalesOrder_CreateFromDat1 BAPI.

If you expect relatively low order volumes, you can create a custom pipeline component to get the order data from the Commerce Server OrderForm object, map the data to the ADO recordsets required by the DCOM connector object, and then call the DCOM connector object to pass the data to SAP in real time. When you use this technique, you can generate an e-mail message, fax, or phone call to notify the customer if the order fails in SAP.

If you expect medium-to-high volumes of orders, you can pass the order number to a COM+ queued component, then return control to the pipeline to get faster execution. However, if you do this and the order fails in SAP, you can't notify the customer in real time.

If you expect very high volumes of orders, you should use a more controlled asynchronous method to update SAP. You can pass the order number through Message Queuing to a waiting service optimized for ERP order integration. The service can then update SAP with the order data. Again, a disadvantage to this approach is that you can't notify customers of order failures in real time.

As an alternative to using an asynchronous ERP integration service, you can use Microsoft BizTalk Server 2000 to pass the message to the appropriate Application Integration Component (AIC). The AIC can then map the passed XML document to the parameters necessary for the BAPI call in SAP.

Because SAP error information won't be sent to the customer in real time if you use one of the asynchronous techniques, you must design an asynchronous technique to notify customers if a SAP error occurs. One suggestion is to contact customers by e-mail with instructions to call a customer service representative or check the order status online.

This section describes the following techniques for integrating Commerce Server orders with SAP:

• Batch integration using IDOC

• Real-time integration using the DCOM connector

• Integration using queued connectors

• Mirrored updates using Message Queuing

• Mirrored updates using BizTalk Server

• Real-time integration using custom COM objects and DCOM connector objects

Batch Integration Using IDOC

When you use IDOC to batch upload Commerce Server order data to SAP, you extract order data and convert it to an IDOC format, then send it to the SAP IDOC processor. You generally use this technique with applications that do not require real-time order processing by the SAP system. Figure 10.20 shows the batch integration process using IDOC.

 

Figure 10.20 Batch integration process using IDOC 

Real-Time Integration Using the DCOM Connector

To send Commerce Server order data to SAP in real time, you can use the process shown in Figure 10.21.

 

Figure 10.21 Real-time integration process using the DCOM connector 

When the Purchase pipeline accepts an order, a custom pipeline component maps the order form data to the parameters required by the SAP DCOM connector object for the Sales Order BAPI. When the mapping is finished, you invoke the DCOM connector technique to create the order in SAP.

If the order is rejected, the pipeline component then fails the entire transaction and notifies the customer that an error has occurred. You should use this technique only if you expect low order volumes.

An example of code for a Visual Basic pipeline component object that can create an order in SAP is located on the Commerce Server 2000 Resource Kit CD in the file SAP_sales_order.txt. The code in the example is the minimum that you would need to write to implement this process; the code you need to successfully implement the BAPI call at your site might be different, depending on how your SAP system is configured. Because you can use the DCOM Connector Wizard to create the DCOM connector, the example doesn't show the original C++ code used to create the object.

Integration Using Queued Components

When you use the queued component technique to send order data from Commerce Server to SAP, you pass the order number to a COM+ queued component from a custom pipeline component in the Purchase pipeline. When you use this technique, Commerce Server doesn't have to wait until SAP processes the order before returning control to the customer.

COM+ invokes the queued component with the order number as the passed parameter. The queued component then uses Commerce Server objects to read the saved order and move the order data to the parameters required by the SAP DCOM connector object. Finally, you invoke the OrderCreate method and the order is created in the SAP system.

If an error occurs in the SAP update process, you must use an out-of-bounds mechanism to inform the customer of the error, so that the customer can initiate a correction.

Figure 10.22 shows the integration process using queued components.

 

Figure 10.22 Integration using queued components

You can find an example of code that creates a Visual Basic COM+ object to create an order in SAP on the Commerce Server 2000 Resource Kit CD, in the file SAP_create_order.txt. In this code example, the SAP order is created from the OrderForm object retrieved from the Commerce Server order tables.

Mirrored Updates Using Message Queuing

If you decide to use the mirrored updates technique with Message Queuing to download orders from Commerce Server to SAP, you use a custom pipeline component to place the order number in the message queue. The order is stored in the Commerce Server database and the customer is notified.

An asynchronous SAP updating service containing application server throttling reads the message queue and finds a new order number to process. The service then instantiates a custom Visual Basic object that uses Commerce Server objects to read the saved order and copies the order data to the parameters required by the SAP DCOM connector object.

After the parameters have been properly set up, the service invokes the OrderCreate method to create the order in the SAP system. If an error occurs in the SAP update process, an out-of-bounds mechanism is used to notify the customer.

Figure 10.23 shows the mirrored update technique using Message Queuing.

 

Figure 10.23 Mirrored update using Message Queuing 

Mirrored Updates Using BizTalk Server

Another technique is to download orders from Commerce Server to SAP using mirrored updates with BizTalk Server. To do this, you can create a custom pipeline component in the Purchase pipeline to create an XML document from the OrderForm object data and submit the document to BizTalk Server. BizTalk Server then instantiates the specified channel to pass the XML order document to the AIC that is responsible for updating SAP with the new order data.

This logic follows many of the same principles used by the batch download technique. In fact, you can use this technique in conjunction with the batch download technique to provide greater control of the download to SAP.

Figure 10.24 shows the mirrored update technique using BizTalk Server.

 

Figure 10.24 Mirrored update using BizTalk Server 

You can find an example of Visual Basic COM+ code that creates pipeline component pseudocode to create the XML document from the OrderForm object on the Commerce Server 2000 Resource Kit CD in the file SAP_mirrored_update.txt.

Real-Time Integration Using Custom COM Objects and DCOM Connector Objects

If you decide to download orders in real time using custom COM objects and DCOM connector objects, use Commerce Server ASP pages to request and display real-time order status for order header and detail records. You use custom Visual Basic COM objects to wrap the call to the generated DCOM connector object that calls the Sales Order BAPI methods.

Because real-time queries are generally less CPU- and database-intensive, a site with low-to-medium order volume can make real-time inquiry calls to the SAP application server with little performance degradation. However, it is sometimes easier to wrap complex calls in a COM object.

Figure 10.25 shows the process of real-time integration using custom COM objects and DCOM connector objects.

 

Figure 10.25 Real-time integration using custom COM objects and DCOM connector objects 

You can find a code example containing Visual Basic COM+ code snippets on the Commerce Server 2000 Resource Kit CD, in the file SAP_realtime_integration.txt. The example contains functions that return order header records in summary form and return order detail records, and a function that creates a disconnected recordset to contain the summary order header records.

Integrating with J.D. Edwards OneWorld

This section describes the following techniques used to integrate Commerce Server with J.D. Edwards OneWorld:

• OneWorld COM wrapper objects

• Product catalog and pricing

• Orders

OneWorld also supports other integrations, such as the Microsoft Integration Solution. The Microsoft Integration Solution uses the following technologies for integrating with software such as Commerce Server:

• OneWorld Message Queuing Adapter. An asynchronous integration using Message Queuing and XML-based documents.

• OneWorld Orchestration Adapter for BizTalk Server 2000. An Application Integration Component (AIC) written with COM that exposes predefined transactions into OneWorld using OneWorld COM wrapper objects.

OneWorld also supports XML through the following APIs:

• XML CallObject. An API used for synchronous requests to OneWorld.

• XML Transactions. An API used for asynchronous requests to OneWorld.

• XML Z-Table Inquire. An API that uses an Index passed in an XML document to retrieve records from a Z-Table and returns the result in an XML string.

The OneWorld XML APIs support well-formed XML documents. OneWorld also supports UTF-8 and UTF-16 Unicode standards for inbound and outbound information. J.D. Edwards provides XML schemas for each type of XML document API. OneWorld can also return an XML CallObject Template for a specific business function. This template contains an XML document with required elements for calling the requested business function. No data or environment information is returned.

Before you attempt to integrate sales orders, a product catalog, pricing, or other function, it is important to understand how OneWorld performs these functions.

OneWorld processes are based on Master Business Functions (MBFs). OneWorld Master Business Functions can be accessed from a Windows 2000 platform through several different configurations. OneWorld can process XML documents, and can be called directly with COM through the OneWorld COM server. In most cases, you can leverage existing MBF, but OneWorld also provides development tools to create new, custom business functions depending on your business requirements.

When you have decided which integration solution to use (batch download, real-time connectors, and so on), you must then decide which business functions to implement for the functionality you want to integrate. You use the OneWorld GenCom client tool to create the OneWorld COM wrapper objects used by the OneWorld COM Server to access the business functions within OneWorld.

Figure 10.26 shows a network diagram consisting of a OneWorld system application with a Commerce Server application integrated into the entire system.

 

Figure 10.26 Network diagram showing how Commerce Server integrates with OneWorld 

OneWorld GenCom Component Wrapper

The bridge between the Windows 2000 platform and the OneWorld MBFs is the OneWorld COM server. The OneWorld GenCom client tool and server components are shipped with OneWorld software. Detailed documentation describing how to use the OneWorld GenCom client tool to create OneWorld COM wrapper objects to OneWorld business functions is contained in the Interoperability Manual that comes with OneWorld. You can also use outbound Z-Table processing or the Universal Batch Engine (UBE) to provide batch interface capabilities with OneWorld.

The process for using a generated OneWorld COM object is as follows:

1. An ASP page calls the generated OneWorld COM object directly, or calls a custom business object that wraps the OneWorld COM object.

2. The OneWorld COM object call is automatically sent by COM+ to the OneWorld COM server.

3. The OneWorld COM object on the OneWorld COM server calls a particular OneWorld MBF or custom-written business function.

4. The business function gets the results from the OneWorld environment and returns them to the calling object or ASP page.

Figure 10.27 shows the process for using the OneWorld COM object.

 

Figure 10.27 Using the OneWorld COM object 

Figure 10.27 also shows an inventory query being made to OneWorld, as follows:

1. An ASP page calls a Visual Basic business object, which in this case wraps the OneWorld COM object that resides in a COM+ application on the OneWorld COM server.

2. The OneWorld COM object runs through the low-level J. D. Edwards thinnet interface protocol, which interfaces with any OneWorld system regardless of the host platform.

3. The business function checks the availability of the requested item and returns the results to the OneWorld COM object.

4. The results are wrapped in an ADO recordset by the COM+ wrapper object and passed back through the COM+ package.

Product Catalog and Pricing

You can use the following techniques to integrate a product catalog or pricing data between Commerce Server and OneWorld:

• Batch download data from OneWorld

• Mirrored updates

• Real-time integration

Using any of these techniques, product catalog data retrieved from OneWorld can be enriched with other data, such as images, additional product descriptions, or other technical data that doesn't reside on the OneWorld system, before it is presented to customers.

Batch Download Data from OneWorld

To download product catalog data from OneWorld using the batch download technique, you have to schedule a custom UBE extraction program to pull the relevant product data from OneWorld tables into a Z-Table (a temporary interface table for imports and exports) that can be imported into the Commerce Server product catalog. Unless the pricing scheme is extremely complicated, pricing data can also be placed into the UBE program. Figure 10.28 shows the process of downloading product catalog data using the batch download technique.

 

Figure 10.28 Downloading product catalog data using the batch download technique 

Another way to download product catalog data using the batch download technique is by means of a Windows 2000 scheduled process that calls a wrapped custom business function of the OneWorld COM object to extract product catalog data directly from OneWorld tables. Extracted data can then be placed directly into a Commerce Server product catalog. Figure 10.29 shows the process for this batch download technique.

 

Figure 10.29 Downloading product catalog data using the OneWorld COM object 

The process for downloading incremental changes to the product catalog is similar to that shown in Figures 10.28 and 10.29.

Mirrored Updates

If you need more immediate notification of changes to the product catalog than you can get from a batch technique, you can use the mirrored update technique to integrate product data. This technique leverages the outbound processing technology in OneWorld to notify Commerce Server about product changes. You can handle mirrored updates for inventory, pricing, order status, and other data in a similar manner. Figure 10.30 shows the process for mirrored updates.

 

Figure 10.30 Mirrored updates 

You can use the mirrored update technique by itself or you can combine it with the batch download technique.

The outbound trigger mechanism in OneWorld is single-threaded and can be a performance bottleneck. To optimize performance, you can assemble all of the parameters received from the OneWorld trigger to the outbound DLL and place the message into a message queue. A code example showing how to do this is located on the Commerce Server Resource Kit CD in the file JDE_mirrored_update.txt.

Real-Time Integration

You can use the real-time technique to immediately download a product price from OneWorld to Commerce Server. Figure 10.31 shows the process for this real-time technique.

 

Figure 10.31 Real-time downloads 

Using real-time downloads, prices for the items in an order are calculated only when the order is ready for purchase. Prices are configured in OneWorld, not in the Commerce Server Product Catalog System. This technique also relies on a custom pipeline component that calls a previously created OneWorld COM object created with the GenCom client tool. The OneWorld COM wrapper object then invokes the OneWorld custom business function to obtain pricing information. After the item prices and order costs are retrieved from OneWorld, the Commerce Server OrderForm object is updated with the new data.

Orders

You can use any one of the following techniques to upload Commerce Server orders to OneWorld:

• Batch download using the Z-Table

• Real-time integration using the OneWorld COM object in the Purchase pipeline

• Integration using queued connectors

• Mirrored updates using Message Queuing

• Mirrored updates using BizTalk Server

You can design batch techniques for sending Commerce Server orders to OneWorld by exporting Commerce Server order data to a Z-Table format. The Z-Table can then be processed by a custom UBE, which places orders into OneWorld by means of the batch interface in Batch mode. This technique requires little customization of OneWorld programs.

If you use a real-time (synchronous) technique to download order data from Commerce Server to OneWorld, you must use the GenCom client tool to create a OneWorld COM object to communicate with the master business functions (MBFs) required for sales order entry.

If you expect only low order volumes, you can create a custom pipeline component to get the order data from the Commerce Server OrderForm object, map the data to an ADO recordset, and invoke the COM object generated by the GenCom tool for sales order entry. The OneWorld COM object can then download the order into OneWorld synchronously. When you use this technique, you can easily alert customers if an order fails during processing by OneWorld.

If you expect medium order volumes and want to ensure faster execution, you can pass the order number to a COM+ queued component, then return control to the pipeline. However, if you use this queued technique, you can't notify a customer in real time if the order fails in OneWorld; you have to notify the customer by a generated e-mail message, fax, or phone call.

If you expect high order volumes and want to update OneWorld in a more controlled, asynchronous manner, you can pass the order number through Message Queuing to a Listener service optimized for ERP order integration. The service then picks up the message and calls the OneWorld COM object to update OneWorld with the order data.

As an alternative to using an asynchronous ERP integration service, you can use BizTalk Server to pass the message to the appropriate AIC. The AIC can then map the passed XML document to parameters necessary for the OneWorld COM wrapper object call into OneWorld. Alternatively, it can transform and pass a OneWorld-specific XML document directly into OneWorld using Message Queuing or the XML CallObject API.

If you use any of the asynchronous techniques, including the batch download Z-Table technique, you can't send OneWorld error information to customers in real time. You have to devise an asynchronous technique to notify customers if you use any of these techniques.

Batch Download Using the Z-Table

If you place extracted Commerce Server order data into the appropriate Z-Table, you must then run a UBE to import Z-Table data into OneWorld by means of the business functions used to create sales orders. You usually use this technique with applications that do not require real-time order processing by the OneWorld system.

Figure 10.32 shows how you would use a Z-Table for the batch download technique.

 

Figure 10.32 Batch download technique using a Z-Table 

Real-Time Integration Using OneWorld COM Objects in the Purchase Pipeline

Using the real-time integration technique, as soon as the Purchase pipeline accepts an order, a custom pipeline component maps OrderForm object data to the parameters required by the OneWorld COM wrapper object for the Sales Order MBFs. After the data is mapped, the OneWorld COM object is invoked to create the order in OneWorld. If the order is rejected for any reason, the pipeline component fails the entire transaction and notifies the customer that an error has occurred.

You can use this technique in a low-volume site, because the volume of traffic does not adversely affect application server performance. Figure 10.33 shows real-time integration using the OneWorld COM wrapper object.

 

Figure 10.33 Real-time integration using the OneWorld COM object 

The file JDE_sales_order.txt, located on the Commerce Server 2000 Resource Kit CD, contains a script and batch file that shows how to create a OneWorld COM wrapper object to wrap the business function and data structures used to retrieve updated catalog data. The file JDE_sales_order.txt also contains an example of Visual Basic COM+ code illustrating a Commerce Server Purchase pipeline function that calls a generated OneWorld COM object to wrap the sales order business function.

Integration Using Queued Connectors

When you use queued connectors to download order information from Commerce Server to OneWorld, the Commerce Server application does not have to wait until OneWorld processes the order before returning control to the customer. Using this technique, you pass the order number to a COM+ queued connector from a custom pipeline component in the Purchase pipeline. The queued connector then uses Commerce Server objects to read the saved order and map the order data to the parameters required by the OneWorld COM object. The OrderCreate method creates the order in the OneWorld system. If an error occurs in the OneWorld update process, you have to use an out-of-bounds mechanism to inform the customer that an error has occurred.

Figure 10.34 shows the process of using queued connectors to download order information from Commerce Server to OneWorld.

 

Figure 10.34 Using queued connectors to download order information 

The file JDE_create_order.txt, located on the Commerce Server 2000 Resource Kit CD, contains an example of code for a Visual Basic COM+ object that creates an order in OneWorld from a Commerce Server OrderForm object. The only items passed to the function are the order number and the ADO connection string to the Commerce Server database. This object could be placed in a COM+ application marked as Queued. Most of the code is similar to that found in the JDE_sales_order.txt file.

Mirrored Updates Using Message Queuing

When you use Message Queuing with the mirrored updates technique, you use a custom pipeline component to place the order number in the message queue. The order is also stored in the Commerce Server database and a confirmation is displayed to the customer. An asynchronous OneWorld updating service with application server throttling reads the message queue and picks up the order message. The updating service then instantiates a custom Visual Basic object that uses Commerce Server objects to read the order data and map it to parameters required by the OneWorld COM object. The OneWorld COM wrapper object then invokes the OrderCreate method to submit the order to OneWorld. If an error occurs during order submission, you must use an out-of-bounds process to notify the customer.

Figure 10.35 shows the process for using mirrored updates with Message Queuing.

 

Figure 10.35 Using mirrored updates with Message Queuing 

Mirrored Updates Using BizTalk Server

When you use the mirrored updates technique with BizTalk Server, a custom pipeline component in the Purchase pipeline creates an XML document from OrderForm object data and submits the document to BizTalk Server. BizTalk Server then instantiates the specified channel, which passes the XML order document to the AIC responsible for updating OneWorld.

This technique is similar to the asynchronous service technique. In fact, you can use this technique with the asynchronous updating service to get better control of the data being downloaded to OneWorld.

The file JDE_orderform.txt, located on the Commerce Server 2000 Resource Kit CD, contains pipeline component pseudocode that creates the XML document from the OrderForm object. It also contains application integration component pseudocode that creates the OneWorld order from the XML document.

Figure 10.36 shows the mirrored updates process using BizTalk Server.

 

Figure 10.36 Mirrored updates using BizTalk Server