Integrating Third-Party ERP Systems with Microsoft Commerce Server 2000 Applications
Summary: This article describes several techniques for making ERP data available to Microsoft Commerce Server 2000 applications, including batch downloads, real-time connectors, queued connectors, and mirrored updates. (49 printed pages)
General Considerations and Best Practices
ERP Systems and Commerce Server Business Rules
Pricing and Promotions
Shipping, Taxation, and Credit Card Authorization
Integrating with SAP
SAP DCOM Connector
Integrating with J.D. Edwards OneWorld
OneWorld GenCom Component Wrapper
Product Catalog and Pricing
Integrating Microsoft® Commerce Server 2000 with an existing Enterprise Resource Planning (ERP) system, such as SAP®, J.D. Edwards OneWorld®, PeopleSoft, and other corporate systems, is often critical to successfully implementing a Commerce Server application. 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 white paper 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 to your ERP system.
Figure 1 shows a common high-level architecture for integrating an ERP system with a Commerce Server application.
Figure 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 (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 customers and customer updates
It is important to decide which system should own the data; in most cases, it will probably be the ERP system.
There are four common techniques for integrating data on ERP and Commerce Server applications:
- Batch downloads
- Real-time connectors
- Queued connectors
- Mirrored updates
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 that the Commerce Server application needs 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 by using the Bulk Copy Program (BCP) or Data Transformation Services (DTS).
Figure 2 shows how data is extracted from an ERP system and copied to high-end SQL Server servers that the Commerce Server application uses.
Figure 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, 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 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 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. If you decide to use the batch download technique, consider the following points:
- 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 do updates 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.
You usually must update product and pricing data only once in a 24-hour period.
You might need to update product inventory data more often. For example, a customer who is ordering a software package is reassured to see an inventory level of 231 copies available as of 4 A.M. that morning and completes the order. But if only seven 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 in a separate database that the Commerce Server application will treat as read-only. Doing this enables the batch load scripts to send all database tables to the offline database without transferring any other data.
Of all the techniques described in this white paper, 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, instead of 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 entails:
- Transferring data files from the hosts and the servers running Microsoft® Windows® 2000 by using the FTP. You can use the Internet Transfer Control to do this.
- Using BCP functions (taken from the DB-Library for Microsoft Visual Basic) to transfer data from text files into SQL Server. You can also use the DTS included in Microsoft SQL Server 7.0 or Microsoft SQL Server 2000 to do this. For more information about DTS, see http://www.microsoft.com/sql.
- Starting SQL Server stored procedures for data processing.
- Changing Active Server Pages (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 entails:
- 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 by 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 Microsoft 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.
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 http://www.sap.com. 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 4 shows the architecture of a Commerce Server application using the SAP DCOM connector to make real-time calls to SAP.
Figure 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 powerful and useful; however, you should consider the following points before using this technique:
- Processing requests from the Commerce Server application can have an impact on 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 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 have an impact on the Commerce Server application.
If the ERP system doesn't respond to processing requests, the Internet Information Services (IIS) worker thread making the call will be blocked. Because a COM+ object controls the ERP API call, the IIS ASP time-out 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 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 5. Combined real-time and batch integration between a Commerce Server application and a host-based CICS system
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 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 process picks up the message and executes the request.
Figure 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 process 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 process 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 lends itself only 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:
- An ASP page calls an OrderSubmit object to submit an order.
- 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.
- The ASP page dynamically displays the request ID to the customer and informs the customer that the order has been accepted.
- At some later time, the Message Queuing service delivers the message to the target server.
- A listener process 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.
- The proxy object calls the ERP system and submits the order. It then updates the status in the local SQL Orders table to Accepted.
- 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 taking advantage of queued components in the implementation.
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 (for example, 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 7 shows mirrored updates occurring between the ERP system and a Commerce Server application.
Figure 7. Mirrored updates
Figure 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-related tasks in response to an ERP event.
This section describes general considerations and best practices for using integration techniques in the following areas:
- Physical architecture (highly scalable)
- Product catalog
- ERP systems and Commerce Server business rules
- Pricing and promotions
- Shipping, taxation, and credit card authorization
The ERP system normally contains business rules for such key commerce functions 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 by 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.
The ERP system often contains a complex set of business rules for pricing, based on each of a company's customers. When you use this functionality, you might need to address the following variables:
- 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 business logic regarding pricing. In some industries, regulatory agencies also control pricing. 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 checkout.
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 http://www.microsoft.com/business/ecommerce.
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 by using the Commerce Server product catalog during batch imports.
If you have to use another technique for building your catalog, 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 you can then optimize the catalog database 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.
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 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.
The Microsoft .Net architecture supports many different physical configurations that also support a highly scalable Commerce Server application with ERP integration. Figure 8 shows the logical architecture of a three-tier Commerce Server application with ERP integration. The ERP integration shown in Figure 8 includes batch downloads and a real-time connector.
Figure 8. Highly scalable Commerce Server application integrated with an
Figure 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 that the ASP pages call.
- 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 8.
|Web servers||IIS 5.0
Commerce Server Pipeline objects
|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, in addition to 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. They may be a combination of vendor-supplied objects and custom objects.|
|ERP system||Provides business management.|
Figure 9 shows a network diagram of a SAP system application with an integrated Commerce Server application.
Figure 9. SAP system with integrated Commerce Server application
This section explains the following points to consider when you integrate a Commerce Server application with a SAP R/3 system:
- Using the SAP DCOM connector
- Integrating a product catalog
- Integrating item pricing
- Integrating inventory data
- Integrating orders
The bridge between the Microsoft 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.
For detailed installation instructions, along with programming procedures and considerations, see the article "SAP DCOM Connector: Expanding SAP Business Processes," by Homann, Rogers, and Russo, in SAP Technical Journal, Vol. 1, No. 2.
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 9). The SAP DCOM connector package contains an Object Builder wizard, which eliminates the need to write large amounts of C++ code by using native SAP RFCs. The components you create with the wizard are COM+ components that other applications can reuse.
The DCOM connector process is as follows:
- 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.
- If the ASP page does not call the DCOM object directly, COM+ automatically sends the DCOM connector call to the SAP integration server.
- The DCOM connector object on the SAP integration server calls a BAPI object or custom-written RFC.
- The BAPI gets the results from the SAP environment and returns them to the calling object or ASP page.
- The results are returned to the Visual Basic business object.
- The results are returned to the ASP page.
Figure 10 shows an example of this process.
Figure 10. Using the DCOM connector
The example in Figure 10 shows an availability query being made to SAP for a particular product, using the following process:
- 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.
- 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.
- 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.
- The product availability data is wrapped into an 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.
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 values (CSV), XML, or flat file. You can then import that file into the Commerce Server product catalog. Figure 11 shows how you can use a batch download to transfer catalog data from SAP to Commerce Server.
Figure 11. Using a batch download to transfer product catalog data from SAP to Commerce Server
Figure 12 shows a second way of doing this that you can use only 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 12. Placing extracted catalog data directly into the product catalog
Batch Download Incremental Catalog Changes
To reflect incremental changes to product catalog data on a SAP system, you can use a batch method, which can reflect changes almost in real time. The process looks exactly the same as that shown in Figure 11, except that the SAP batch process extracts only changed product data to send to Commerce Server, instead of sending all product data.
You can use either of the two mirrored update techniques shown in Figure 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 Intermediate Document (IDOC) message MATMAS02 IDOC.
Figure 13. Updating the product catalog by using mirrored updates
You can combine the mirrored update technique with the batch update technique, or you can use it by itself.
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 14 shows the process for batch downloading item prices.
Figure 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 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 15 shows how this technique works.
Figure 15. ALE-triggered price change download
This scenario entails the following steps:
- A price change for a customer/item combination is detected when a user exits.
- A custom IDOC message (in this example, ZPRICE01) is created and passed to the ALE subsystem.
- ALE invokes a custom RFC to pass the custom IDOC data to the SAP COM for an Advanced Business Application Programming (ABAP)–generic RFC server.
- 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 Order Simulation BAPI. Figure 16 shows how you do this.
Figure 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 BAPI_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.
This section describes the following methods of integrating inventory data:
- Batch download inventory data
- Batch download incremental 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, it is probably best to 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 by using a custom 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 17 shows the batch download scenario.
Figure 17. Batch download scenario
You can initiate another version of the batch download with a Windows 2000 scheduled process, as shown in Figure 18.
Figure 18. Batch download using a Windows 2000 scheduled process
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.
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 17 and 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 19 shows the mirrored update technique using ALE.
Figure 19. Mirrored updates using ALE
A real-time connection scenario uses the DCOM object in a Commerce Server pipeline object to return the current inventory value in SAP in a real-time fashion. However, this method must be used with caution, because it can adversely affect performance on the SAP application servers.
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 BAPI_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 about 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 components
- 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. This technique is generally used by applications that do not require the SAP system to process orders in real time. Figure 20 shows the batch integration process using IDOC.
Figure 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 21.
Figure 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 that the SAP DCOM connector object requires 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 22 shows the integration process using queued components.
Figure 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 23 shows the mirrored update technique using Message Queuing.
Figure 23. Mirrored update using Message Queuing
Mirrored Updates Using BizTalk Server
Another technique is to download orders from Commerce Server to SAP by 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 that the batch download technique uses. In fact, you can use this technique in conjunction with the batch download technique to provide greater control of the download to SAP.
Figure 24 shows the mirrored update technique using BizTalk Server.
Figure 24. Mirrored update using BizTalk Server
For an example of Visual Basic COM+ code that creates pipeline component pseudocode to create the XML document from the OrderForm object, see the file SAP_mirrored_update.txt on the Commerce Server 2000 Resource Kit CD.
Real-Time Integration Using Custom COM Objects and DCOM Connector Objects
If you decide to download orders in real time by 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 25 shows the process of real-time integration using custom COM objects and DCOM connector objects.
Figure 25. Real-time integration using custom COM objects and DCOM connector objects
You can find an example containing Visual Basic COM+ code samples 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; it also contains a function that creates a disconnected recordset to store the summary order header records.
This section describes the following techniques used to integrate Microsoft Commerce Server 2000 with J.D. Edwards OneWorld:
- OneWorld COM wrapper objects
- Product catalog and pricing
OneWorld also supports other integrations, such as the OneWorld 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 AIC written with COM that exposes predefined transactions into OneWorld by 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 (a temporary interface table for imports and exports) 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 incoming and outgoing 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 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 take advantage of existing Business Functions, but OneWorld also provides development tools to create new, custom Business Functions tailored to 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 are trying to integrate. You use the OneWorld GenCom client tool to create the OneWorld COM wrapper objects that the OneWorld COM server uses to access the Business Functions within OneWorld.
Figure 26 shows a network diagram consisting of a OneWorld system application with a Commerce Server application integrated into the entire system.
Figure 26. Network diagram showing how Commerce Server integrates with OneWorld
The bridge between the Windows 2000 platform and the OneWorld Business Functions is the OneWorld COM server. The OneWorld GenCom client tool and server components are included 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 outgoing 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:
- An ASP page calls the generated OneWorld COM object directly, or calls a custom business object that wraps the OneWorld COM object.
- The OneWorld COM object call is automatically sent by COM+ to the OneWorld COM server.
- The OneWorld COM object on the OneWorld COM server calls a particular OneWorld MBF or custom-written business function.
- The business function gets the results from the OneWorld environment and returns them to the calling object or ASP page.
Figure 27 shows the process for using the OneWorld COM object.
Figure 27. Using the OneWorld COM object
Figure 27 also shows an inventory query being made to OneWorld, as follows:
- 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.
- 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.
- The business function checks the availability of the requested item and returns the results to the OneWorld COM object.
- The results are wrapped in an ADO recordset by the COM+ wrapper object and passed back through the COM+ package.
You can use the following techniques to integrate a product catalog or pricing data with Commerce Server and OneWorld:
- Batch download data from OneWorld
- Mirrored updates
- Real-time integration
Using any of these techniques, you can enrich product catalog data retrieved from OneWorld with other data, such as images, additional product descriptions, or other technical data that doesn't reside on the OneWorld system, before you present it to customers.
Batch Download Data from OneWorld
To download product catalog data from OneWorld by 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 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 28 shows the process of downloading product catalog data by using the batch download technique.
Figure 28. Downloading product catalog data by using the batch download technique
Another way to download product catalog data by 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 29 shows the process for this batch download technique.
Figure 29. Downloading product catalog data by using the OneWorld
The process for downloading incremental changes to the product catalog is similar to that shown in Figures 28 and 29.
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 uses the outgoing 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 30 shows the process for mirrored updates.
Figure 30. Mirrored updates
You can use the mirrored update technique by itself or you can combine it with the batch download technique.
The outgoing 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 2000 Resource Kit CD in the file JDE_mirrored_update.txt.
You can use the real-time technique to immediately download a product price from OneWorld to Commerce Server. Figure 31 shows the process for this real-time technique.
Figure 31. Real-time downloads
When you use 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.
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 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 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 2000 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 by 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 the OneWorld system to process orders in real time.
Figure 32 shows how you use a Z-Table for the batch download technique.
Figure 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 that the OneWorld COM wrapper object requires 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 33 shows real-time integration using the OneWorld COM wrapper object.
Figure 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 that the OneWorld COM object requires. 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 34 shows the process of using queued connectors to download order information from Commerce Server to OneWorld.
Figure 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 that the OneWorld COM object requires. 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 35 shows the process for using mirrored updates with Message Queuing.
Figure 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 36 shows the mirrored updates process using BizTalk Server.
Figure 36. Mirrored updates using BizTalk Server
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.
© 2001 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, BizTalk, Visual Basic, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.