Punchout from Procurement Systems to WCBE and WCS MPE

For instance, IBM's Commerce Integrator is a generic framework that enables WCBE and WCS MPE to hold business-to-business transactions using industry standard protocols. It offers customers the chance to integrate their systems with the procurement system's own network of high-volume buyers. Commerce Integrator provides an integrated, scalable system that enables suppliers with WCBE to contribute as a contractor in the procurement system's marketplace, to raise sales and to improve their business-to- business presence on the Web. Specially:

• Suppliers can get advantage of WCBE connectivity to contribute chain management systems, retail business systems, and order management backend systems to automatically flow orders from the buyer's procurement system.
• Suppliers keep a single catalog within WCBE and make use of that catalog to make possible their own Web presence as well as to participate in the procurement system's network.
• Suppliers can get advantage of the updated business-to-business features of the WCBE product for maintaining and using information about buyer-specific catalogs, buyer organizations, and price lists, and contract pricing.

Figure 1 illustrates a high-level view of a typical punch-out flow in which WCBE Interoperates with an e-procurement system, which includes the following steps:

Figure 1 classic punch-out flow using WCBE and Commerce Integrator.

1.  An manager in the buyer organization logs on to the procurement system via the user ID (identifier) and password, and then selects an external catalog. The procurement system authenticates the buyer agent.

2.  The procurement system constructs a request to access the external supplier catalog via a user ID and other buyer organization credentials.

3.  The Member Subsystem of Commerce Integrator authenticates the buyer agent against the buyer organization data stored in the WCBE database. If successful, the buyer agent is presented with a catalog customized for the buyer organization.

4.  The buyer agent browses the catalog in the WCBE database while a shopping cart is created. On checkout, the shopping cart is submitted to WCBE, and a quote is recorded in the database.

5. Commerce Integrator picks up the quote from WCBE.

6.  Commerce Integrator sends the quotation to the buyer in the layout required by the buyer's procurement system. An official agent for the buyer is encouraged for approval of the quote.

7.  The official agent approves the quotation. An order from the procurement system is sent to Commerce Integrator.

8.   Commerce Integrator forwards the order to WCBE

Additional messages, such as advance shipment notices and invoices (not shown in Figure) are sent from WCBE to the procurement system.

Though the punch-out flow is similar for most procurement systems, the message design is different for different procurement systems. For instance, mySAP uses Hyper Text Markup Language (HTML) name-value pairs, Metiom uses the OBI electronic data interface (EDI) message formats,   Ariba uses cXML messages, and Commerce One uses XCBL message formats. There are some differences between the flows, as outlined earlier in the B2B protocol exchange. To handle these differences, Commerce Integrator includes some protocol-specific functions, in accumulation to functions common to all protocols. As shown in Figure 1.6, incoming messages are handled by a familiar servlet, which identifies the protocol and calls protocol-specific functions that map the message to a common internal format. Then, WCBE commands, shared by all punch-out protocols, are invoked. Responses are converted from the common format into protocol-specific formats by Commerce Integrator.

Figure displays a B2B gateway. The function of the B2B gateway is to offer a means of connecting remote trading partners over the Internet, each using its protocol of choice. Obviously, this functionality facilitates the integration of inter enterprise business processes. Although the B2B gateway may support further functions, such as business process management, audit trails, and intraenterprise connectivity, it is beyond the scope of this chapter to elaborate further on these functions.

Figure 2: WCBE Commerce Integrator architecture.

The protocol linked with an incoming message is recognized by the URL to which the request is sent. The use of a single servlet for all requirements should have no negative performance collision, because the servlet engine launches a new thread for Performance bottlenecks would only be caused by undue argument for shared resources. Were such argument present, it would impact multiple servlets in the identical manner as a single servlet. Because the servlet is just the entry point for requirements that quickly fan out to various parts of the server, it is suspect that the degradation of consistency from the use of a single servlet would be significant.

There are two scenarios of attention: one in which there is no separate B2B gateway and one in which there is a gateway present. When there is no B2B gateway, protocol- specific requirements are sent to Commerce Integrator, and suitable commands are invoked. If a B2B gateway is present, the incoming requests are mapped into a common canonical format, and then Commerce Integrator invokes appropriate WCBE commands. Thus, there is a synergistic relation between WCBE/Commerce Integrator and the gateway.