The Internet Environment

As previously explained, with the rapid growth of the Internet, organizations are increasingly using the Web to conduct business with greater speed, reach, and efficiency. This transformation is especially prevalent in business-to-business (B2B) commerce and trade. Many of the Fortune 500 companies have adopted e-procurement systems such as Ariba (see sidebar, “Ariba”), Commerce One, and mySAP. Many others participate as buyers in e-marketplaces, such as Commerce One MarketSet, Ariba Hosted Market Place, and IBM’s WebSphere Commerce Suite, Marketplace Edition (WCS MPE, or MPE for short), among others.

Figure 2.1 illustrates the environment for B2B procurement on the Web^[1]. B2B buyers have diverse procurement systems, such as those offered by Ariba, Commerce One, and SAP, among others. Each of these procurement systems uses different B2B protocols for interaction with seller systems. Many of these protocols are proprietary and specific to the procurement system. For example, as illustrated in Figure 2.1, Ariba uses the punchout process between the Ariba Order Request Management System (ORMS) and seller systems using their Commerce XML (cXML, or Commerce Extensible Markup Language) specification for the messages. Commerce One uses XML Common Business Library (xCBL) as the format of messages, and mySAP uses the Open Catalog Interface (OCI; for a process similar to punchout) between buyer and seller systems.

Figure 2.1: Business-to-business procurement environment.

Ariba

With purchasing managers facing the prospect of tighter corporate budgets, developers Verticalnet Inc., PeopleSoft Inc., and Ariba Inc. are each readying software that they indicate will enable their customers to better manage spending. The goal is to enable companies to more closely tie the process of finding sources of raw goods, negotiating the price for those products, and closing the loop with electronic settlement.

Verticalnet has recently released an enhanced Spend Management module as well as the next version of its Metaprise collaborative planning and order management suite. Spend Management introduces a supplier score card and enhanced reporting and analytics, which will let suppliers see through a Web browser how they are serving buyer and performance metrics, such as actual costs versus standard spending. New functionality in Metaprise, which comes from the company’s acquisition of Atlas Commerce Inc., facilitates the process of improving requisitions and managing purchase orders. Enhanced logistics functionality integrates shipping updates with third-party logistics providers.

Meanwhile, PeopleSoft, of Pleasanton, California, recently announced the general availability of its strategic sourcing suite. The company unveiled PeopleSoft Strategic Sourcing as a collaborative solution that helps companies manage the complex bidding and negotiation process in the procurement of direct goods, services, and large capital expenditures, according to officials.

Separately, Ariba, of Sunnyvale, California, recently unveiled its Spend Management Suite, which has been in beta testing. The suite consists of new and enhanced software modules for analysis, sourcing, and procurement to help companies manage their spending before, during, and after the procurement process-stages that Ariba refers to as “find it,” “get it,” and “keep it.”

In the find-it category, the new Ariba Analysis module gathers procurement information, which typically resides in the Ariba Buyer platform, accounts payable, and ERP planning systems. It then generates reports to help companies find potential savings.

The second new module, called Ariba Contracts, falls into the get-it and keep-it categories, by focusing on the administration of contracts—those being used successfully and those requiring renegotiation. Integrated with Ariba Buyer and Enterprise Sourcing, the module helps companies track and manage contract life cycles. Ariba Invoice, the third new module, automates every stage in the invoicing process to help companies reduce reconciliation cycle times and lets suppliers upload invoices into Ariba Supplier Network and transmit them back to buyers.

As for enhancements, Ariba Buyer has new integration with the Contracts module. Ariba Workforce features an expanded capability to capture and manage a broader spectrum of workforce procurement, indicate officials^[2].

Many other protocols for B2B processes, many proprietary to procurement and other systems, and others customized for specific partners are being defined and implemented. In addition to the procurement systems, which typically reside within the firewall of the buying organizations, marketplaces are being set up on the Internet through which buyers can access a large number of suppliers, typically for specific industry segments. Many of these marketplaces use the same or similar technology to connect to procurement and supplier systems and offer buyers at small and medium-sized businesses access to suppliers.

Meanwhile, standards bodies are defining protocols and message formats for B2B processes. One of the early processes was that defined by the Open Buying on the Internet (OBI) consortium, a precursor of the punchout process. The RosettaNet consortium used OBI as a starting point and defined Partner Interchange Processes (PIPs), including both flows and XML-based message formats for interactions between partners. The electronic business XML (ebXML) framework (sponsored by the United Nations Center for the Facilitation of Procedures and Practices for Administration Commerce and Transport [UN/CEFACT] and the Organization for the Advancement of Structured Information Standards [OASIS]) includes a messaging service, a Collaborative-Protocol Agreement (CPA) specification, and a Business Processes Specification Schema. These are all used for enabling the interaction between business processes.

The Web services approach defines both a messaging and a remote procedure call mechanism using Simple Object Access Protocol (SOAP). On top of SOAP, the Web Services Description Language (WSDL) defines a Common Object Request Broker Architecture (CORBA) interface definition language (IDL)-like interface for Web-based B2B remote procedure calls. And, the Universal Description, Discovery, and Integration (UDDI) consortium has defined a directory mechanism for registering and locating businesses on the Web, with an optional WSDL interface specification. The Open Application Group (OAG) has defined Business Object Documents (BODs) for the content of B2B messages.

Some of these originally disparate efforts are now coming together. For example, the RosettaNet consortium has announced that they will move to the ebXML messaging protocol, and OAG has announced that they will support ebXML. In spite of these efforts, however, the number of B2B protocols continues to grow.

This proliferation of B2B protocols gives rise to several connectivity requirements and problems, as illustrated in Figure 2.2^[1]. First, from a supplier’s point of view (box A in Figure 2.2), suppliers need to connect to the many customer procurement systems and private marketplaces, using various B2B protocols. Second, private marketplaces (and, over time, procurement systems as well) need to connect to procurement systems (box B in Figure 2.2), using different B2B protocols. Third (box C in Figure 2.2), private marketplaces need to connect to suppliers that may support different B2B protocols. Fourth (box D in Figure 2.2), private marketplaces need to connect to each other, in order to access suppliers connected to other marketplaces, or to access services offered at other marketplaces.

Figure 2.2: Business-to-business connectivity requirements.

Now, let’s look at the connectivity requirements for suppliers and private marketplaces, and how suppliers and marketplaces relying on IBM’s WebSphere Commerce Business Edition (WCBE), WebSphere Commerce Suite, and Marketplace Edition (WCS MPE) can interoperate within the environment for B2B procurement. Simple B2B connectivity using punchout processes as supported by WCBE are also discussed. Next, marketplace connectivity for emerging asynchronous processes and distributed trading mechanisms, as supported by WCS MPE, are discussed. Finally, the last part of this chapter discusses connectivity, how to use a B2B protocol exchange, and how many of these protocols can be mapped to each other—thus allowing procurement systems and suppliers to use different protocols.

Simple B2B Connectivity Using Punchout

Now, let’s focus on two of the B2B connectivity problems previously mentioned, and illustrated in Figure 2.2. First, let’s discuss the supplier connectivity problem and present a solution based on IBM’s WCBE for connectivity of suppliers to diverse procurement systems. Second, a discussion of marketplace connectivity takes place, as well as a presentation of a solution based on IBM’s WebSphere Commerce Suite and Marketplace Edition (WCS MPE) for connectivity of marketplaces to diverse procurement systems and diverse supplier systems.

Most procurement systems and private marketplaces support the notion of punchout (albeit sometimes using a different term, such as RoundTrip, used by Commerce One). A buyer at a procurement system or marketplace selects a remote supplier, and the buyer is automatically logged on to the supplier catalog server and presented with a catalog customized for his organization, with prenegotiated prices. The buyer shops at the site, as the items selected for purchase are being stored in a shopping cart. On checkout, the shopping cart contents are sent back to the buyer’s procurement system for approval. The procurement system provides workflow for approvals and, on approval, a purchase order is sent from the procurement system to the supplier. Additional messages may be exchanged between the supplier and the procurement system, such as shipping notices and invoices. By having punchout capability, suppliers and marketplaces can interoperate with procurement systems or marketplaces, with significant benefits to both suppliers and buyers.

Note

Details of the punchout flow are provided later in the chapter.

For example, IBM’s WCBE is a solution for the business-to-consumer trade, whereas WCS MPE supports the private trading exchange customers. Customers can connect to the WCBE Web site, browse through the catalog, and place orders. In the case of WCS MPE, customers have the benefit of working with various trading mechanisms, such as request for quotations (RFQs), auctions, reverse auctions, and exchanges. It is especially useful, given the emerging trends in the industry, that the WebSphere Commerce products have punchout capability and can interoperate with buyers’ procurement systems and marketplaces.

Although WCS MPE supports aggregation of suppliers’ catalogs, certain suppliers may have enormous catalogs and their systems may include complex configuration tools. Often, it is not feasible to offload supplier catalogs into external marketplaces. Thus, suppliers often have their supply-side Web sites enabled for punchout, and expect WCS MPE to initiate punchout to the supplier Web site.

Catalog aggregation in the current WCS MPE product is done using the WebSphere Catalog Manager (WCM) product. WCM supports the loading of catalog data into an electronic marketplace (eMP) database, transforming catalog data from ASCII, spreadsheet, and XML formats into a canonical XML format, and extracting catalog data from any relational database. More enhancements to support industrial catalogs are planned for future versions of WCM.

Many large corporations have relatively independent subsidiaries and are classic examples of customers that require support for both receiving punchout requests and initiating punchout requests. Such corporations often have aggregated supplier catalogs across their subsidiaries, so their customers see a unified company-wide catalog and require support for receiving punchout requests from the buyers’ procurement systems to the aggregated catalog. They also require punchout initiation functionality to connect from their aggregated-catalog server to individual catalogs supported by their subsidiaries.

Punchout from Procurement Systems to WCBE and WCS MPE

For example, IBM’s Commerce Integrator is a generic framework that enables WCBE and WCS MPE to handle business-to-business transactions using industry standard protocols. It offers customers the opportunity 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 participate as a supplier in the procurement system’s marketplace, to increase sales and to enhance their business-to-business presence on the Web. Specifically:

• Suppliers maintain a single catalog within WCBE and use that catalog to enable their own Web presence as well as to participate in the procurement system’s network.

• Suppliers can take advantage of WCBE connectivity to supply chain management systems, retail business systems, and order management backend systems to automatically flow orders from the buyer’s procurement system.

• Suppliers can take advantage of the updated business-to-business features of the WCBE product for using and maintaining information about buyer organizations, buyer-specific catalogs and price lists, and contract pricing.

Figure 2.3 illustrates a high-level view of a typical punchout flow in which WCBE interoperates with an e-procurement system, which includes the following steps^[1]:

Figure 2.3: Typical punchout flow using WCBE and Commerce Integrator.

1. An agent in the buyer organization logs on to the procurement system using 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 using 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 quote to the buyer in the format required by the buyer’s procurement system. An authorized agent for the buyer is prompted for acceptance of the quote.

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

8. Commerce Integrator forwards the order to WCBE^[1].

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

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

Figure 2.4 also shows a B2B gateway. The function of the B2B gateway is to provide a means of connecting remote trading partners over the Internet, each using its protocol of choice. Clearly, this functionality facilitates the integration of interenterprise business processes. Although the B2B gateway may support additional 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.4: WCBE Commerce Integrator architecture.

The protocol associated with an incoming message is identified by the URL to which the request is sent. The use of a single servlet for all requests should have no negative performance impact, because the servlet engine launches a new thread for each request. Performance bottlenecks would only be caused by undue contention for shared resources. Were such contention present, it would impact multiple servlets in the same manner as a single servlet. Because the servlet is merely the entry point for requests that quickly fan out to different parts of the server, it is unlikely that the degradation of reliability from the use of a single servlet would be significant.

There are two scenarios of interest: 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 requests are sent to Commerce Integrator, and appropriate 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.

Punchout from WCBE and WCS MPE to External Suppliers

A traditional electronic marketplace (eMP) or a private trading exchange (PTX), such as IBM WCS MPE, provides various trading mechanisms: RFQs, contract-based buying, fixed-price buying, auctions, exchange, and so forth. It also provides support for aggregated catalogs. Both buyers and sellers begin by using the catalog to select a product to buy or to sell. When sellers offer products for sale, they specify the method of purchase to be used: RFQ, contracted price, fixed price, auction, or exchange. Buyers must purchase products using the method specified by the seller (with the exception of RFQ, which they can initiate).

Aggregating the catalog at the eMP site offers advantages including: it makes a parametric search across suppliers possible, and it enables small businesses, which do not have the infrastructure to host catalogs, to engage in e-commerce. However, aggregating catalogs has its own limitations, including:

• It does not preserve each supplier’s unique brand and Web site design (it requires direct links to the supplier’s Web pages).

• It supports only static content rather than promoting dynamic, up-to-date information.

• It provides limited support for suppliers with very large catalogs.

• It provides no support for product configurators (needed for complex products).

• It provides limited support for suppliers with fast changing catalogs or pricing^[1].

Thus, in situations in which there is a need for product configurators, or if the catalog contains fast changing products and prices, the suppliers have to maintain catalogs at their own sites and not aggregate the catalog onto an eMP. In the common eMP approach, a buyer has access to only the sellers who participate in the marketplace with which the buyer is registered. Similarly, a seller cannot sell goods and services in a marketplace different from the one with which the seller is registered. Now, let’s look at a mechanism called punchout, in which a buyer in a private marketplace can “punch out” to a remote supplier to buy fixed-price and contract price offerings.

Figure 2.5 shows the flow for setting up a punchout process (steps 1 to 7) from a procurement system (or marketplace) to a supplier site; for example, a WCBE site^[1]. Remote suppliers are listed at the procurement system. They may provide their entire catalog remotely using punchout. Alternatively, a supplier may provide a local catalog at the procurement site, with links for specific functions or details. For example, a supplier may use punchout for system configuration, or for parts of the supplier catalog that may change frequently. As shown in Figure 2.5, after selecting a remote supplier for initial or further shopping (step 1), a login request (step 2) is sent to the remote supplier as an XML document, encapsulating the user and organization credentials as well as a URL for postback to the procurement system (used at step 7, as shown in Figure 2.5). The remote supplier authenticates this request and returns a URL (step 3) with embedded user information. The client’s browser is redirected (step 4) to this URL, allowing the buyer to directly shop (step 5) at that remote site using the appropriate catalog for the buyer’s organization. At the end of the shopping session, a quote representing the shopping cart is sent back to the client (step 6) and posted back to the procurement system (step 7) at the postback URL referred to previously.

Figure 2.5: Typical punchout request flow.

After the purchase request (in XML format) is received back at the procurement system (step 7), it is parsed and added to the buyer’s requisition. The buyer then submits the requisition for approval. After submission, the buyer can then view the submitted requisition and its status, and modify the requisition, if so desired.

Note

The buyer may punch out to multiple suppliers and add the contents of those shopping carts to his or her requisition.

Subsequently, the approver views the submitted requisitions and, optionally, may punch out to the supplier to view details of the requisition. The approver can modify the requisition, if so desired. If the approver rejects the requisition, the status is so indicated, and can be viewed by the buyer. If the requisition is approved, it is converted into one or more purchase orders (POs), and is sent to the supplier(s). The PO is sent as an XML document, in the format required by the supplier. If the remote supplier’s system is based on WCBE, the PO is formatted in a common canonical format. Also, if it is an Ariba-compliant supplier, it is formatted in cXML. And, if the format is different, a B2B protocol exchange can be used to convert the PO to the desired format and protocol. When the remote supplier acknowledges the receipt of the PO, the state of the order at the procurement system is updated. Subsequently, additional messages may be sent by the supplier to the procurement system to indicate further events, such as issuing an advance shipping notice.

Marketplace Connectivity for Asynchronous Processes

As illustrated in Figure 2.6, IBM’s WCS MPE provides different trading mechanisms, such as fixed-price buying, contract-based buying, RFQs, auctions, and exchanges^[1]. Also, the punchout mechanism can be used for remote supplier integration when dealing with fixed and contract pricing. However, the more advanced trading mechanisms, including RFQs, auctions, and exchanges, cannot be supported by the basic punchout mechanism. This is because the flows between WCS MPE and the remote suppliers for fixed and contract pricing are synchronous, and occur during a real-time session with the buyer, thus making them amenable to the online punchout process. RFQs, auctions, and exchanges involve asynchronous interactions between WCS MPE and the supplier. Next, let’s look at how such asynchronous processes are handled. RFQs are used as a typical example. Similar flows and XML document interchanges can be used for other asynchronous trading mechanisms.

Figure 2.6: Trading mechanisms in WCS MPE.

In WCS MPE, an RFQ is a trading mechanism used when a buying organization attempts to obtain a special price for a purchase, or when a buying organization cannot find an acceptable offering in the eMP aggregated catalog that meets its needs. The RFQ may be issued in order to obtain a special price based on quantity for well-defined items or for a group of items. The RFQ may also be issued for unique items based on the buyer’s description. The request is sent to one or more selling organizations, and these may submit a bid on the RFQ. The selling organizations respond to the RFQ and the buying organization may select one or more winning responses. The result of the RFQ process could be an order placed by the buyer or a contract could be created for the negotiated price. Figure 2.7 shows this process flow in WCS MPE^[1].

Figure 2.7: RFQ process flows in WCS MPE.

Now, let’s look at two different mechanisms for extending the RFQ process to a distributed environment. The first mechanism, referred to as “local RFQ,” exploits the advantages of aggregating the catalogs at the eMP site, while distributing only the RFQ process. The second mechanism, which is referred to as “remote RFQ,” allows buyers to connect to a remote WCBE at a supplier or a remote WCS MPE and issue an RFQ.

For local RFQs, the catalog is hosted at the WCS MPE site where the buyer is registered. Figure 2.8 shows the process flow for this configuration^[1]. The configuration includes the following parties:

Figure 2.8: RFQ process flow for local RFQ.

• One or more buyers

• An eMP where the buyers are registered

• One or more remote eMPs

• One or more sellers registered on the remote eMP^[1]

The flow starts with the buyer browsing the catalog on the eMP and creating an RFQ. The RFQ is sent as an XML message to the remote eMP. Upon receiving the RFQ, the remote eMP notifies the target sellers. Each seller views the RFQ and creates a response for it. The asynchronous responses are then sent to the eMP as XML messages. The buyer can check the status of the RFQ at any time. The buyer views the RFQ responses by logging on to the eMP, evaluates them, and selects a winner. Selecting a winner leads either to a purchase order or a negotiated contract. The order or the contract is then sent to the remote eMP or remote seller as an XML message. This solution has the advantages of an aggregated catalog and allows buyers on one eMP access to sellers on a remote eMP, and vice versa. It has, however, the previously mentioned limitations of aggregated catalogs.

For remote RFQs, the catalog is hosted either on the remote eMP where the seller is registered, or on the remote seller’s Web site. Figure 2.9 shows the process flow for this configuration^[1]. This configuration also involves four parties. The flow starts with the buyer selecting on the local eMP a registered remote eMP or a remote seller. The eMP connects the buyer to the remote eMP site. The buyer browses the catalog on the remote eMP and creates an RFQ template. The RFQ template is then sent as an XML message to the eMP. The RFQ template received from the remote eMP is converted into RFQ by providing additional information. It can then be optionally submitted for approval. Finally, it is sent to the remote eMP or remote seller as an XML message. The remote eMP notifies the target sellers. The sellers view the RFQ and create responses for it. The responses are then sent to the local eMP as XML messages. The buyer views the RFQ responses by logging on to the eMP, evaluates them, and selects a winner. Selecting a winner leads either to an order or to a negotiated contract. The order or the contract is then sent to the remote eMP or remote seller as an XML message.

Figure 2.9: RFQ process flow for remote RFQ.

This solution overcomes the limitations of aggregated catalogs for such asynchronous trading mechanisms, and allows buyers on one eMP access to sellers on a remote eMP, and vice versa. This comes at the price of losing the advantages of aggregated catalogs.

Connectivity Using a B2B Protocol Exchange

As previously mentioned, some suppliers participating in a private marketplace prefer to keep the catalog contents to themselves and not participate in an aggregated catalog hosted by the marketplace. As B2B connectivity becomes increasingly popular, the number of protocols for engaging in B2B transactions continues to grow. Given this growing “babelization,” it is likely that businesses and marketplaces that need to communicate will be using different protocols. For example, IBM built the B2B/M2M Protocol Exchange, a prototype capable of converting between different protocols.

Now, let’s look at how the exchange could be used to enable punchout between a buyer and a supplier using different protocols. Although this example is limited to punchout, the protocol exchange can cover many other common B2B interactions, such as shopping cart processing and order processing.

Suppliers participating in a marketplace may have catalog systems already in place supporting existing standard or proprietary formats. These formats may vary from supplier to supplier. Thus, Supplier A may support cXML punchout messages, Supplier B may support OCI punchout messages, and Supplier C may support some other format. The marketplace punchout function must send punchout messages in the format and protocol that a specific supplier is capable of processing. The B2B protocol exchange is a tool that allows suppliers to interact with buyers whose protocols would otherwise be incompatible.

Unlike some kinds of protocol conversions, most B2B protocol conversions cannot be achieved in a stateless manner, that is, in a manner in which the protocol converter has no knowledge of prior events or message exchanges. This is because many of the protocols refer to the session state or to prior messages. In other words, a B2B protocol involves not only message formats, but also message flow and the state of the interchange process between business partners. Thus, session state management is required along with message format translation.

A block diagram of a typical environment is shown in Figure 2.10^[1]. In this illustration, Buyer 1 and Supplier 1 use protocol A, whereas Buyer 2 and Supplier 2 use protocol B. Information exchange between Buyer 1 and Supplier 2, or between Buyer 2 and Supplier 1, requires the use of the protocol exchange. The presence of the exchange is transparent to buyers as well as suppliers. When Buyer 1 and Supplier 2 are interoperating, Supplier 2 appears to Buyer 1 to be a protocol A supplier, and Buyer 1 appears to Supplier 2 to be a protocol B buyer.

Figure 2.10: Typical B2B environment using protocol conversion.

Now, let’s look in some detail at a punchout operation such as an Ariba cXML punchout between a buyer and a supplier that use the same protocol. The data flow is illustrated in Figure 2.5, shown earlier. The numerals refer to the process steps described here. To purchase from a network catalog, the buyer typically uses a browser to interact (step 1) with the procurement system, and through the procurement system, establishes a connection to a network catalog hosted on the supplier’s behalf. The procurement system thus sends a login request (step 2; a cXML PunchOutSetupRequest) to the supplier system. The login request contains the credentials (userid/password) of the procurement system, a session identifier (<BuyerCookie> in cXML), and the postback URL, which is the HTTP URL at which the procurement system accepts the completed purchase requests (in step 7). The supplier system authenticates the request and responds (step 3) with the URL for accessing the network catalog (in a cXML PunchOutSetupResponse). The procurement system then redirects the browser to the network catalog URL (step 4), and the buyer connects directly to the network catalog system (step 5) bypassing the procurement system.

As previously described in some detail, the punchout operation illustrated in Figure 2.5 (between a buyer and a supplier) uses the same protocol. In the event the buyer and supplier use different protocols, they will be unable to support a punchout interoperation unless some mechanism such as the protocol exchange is used. The data flow is shown in Figure 2.11^[1].

Figure 2.11: Punchout request flow with protocol conversion.

When using a protocol exchange for this mapping, the procurement system is configured to treat the exchange as the supplier system. The initial login request (step 2a in Figure 2.11) is sent to the exchange rather than the target supplier system. The processing required at the exchange at this point may be fairly involved. Typically, the protocol conversion involves two different authentication domains (the source protocol and the target protocol). The exchange must validate the incoming credentials and generate the outgoing credentials for the target protocol domain. In addition, the incoming request typically has an associated session ID (BuyerCookie), which must be recorded and mapped to an equivalent session ID in the target protocol. Also, the postback URL must be saved, and the URL of the exchange must be substituted in the outgoing message. Finally, the target supplier system must be identified, and the converted request must be passed as a new login request (step 2b) to the target supplier system.

When the login response (step 3a) is received by the exchange, the response is converted into a protocol A response by the exchange and is returned to the procurement system (step 3b). The procurement system redirects (step 4) the browser to the network catalog site, and the shopping session (step 5) takes place directly between the buyer’s browser and the network catalog site. At checkout time, the browser accepts the contents of the shopping cart in protocol B format (step 6), and sends it to the exchange (step 7a) rather than to the procurement system, due to the substitution of the exchange URL for the procurement system URL in the protocol A login response. In order to process the checkout, the exchange creates a new checkout page, with the shopping cart converted into the protocol A format, and returns this page to the buyer’s browser (step 7b). The target URL of the “checkout” button on this page is the postback URL of the procurement system, which was saved during the translation of the login request in step 2a. The buyer is instructed to perform a second checkout operation (step 7c), which causes the purchase request to be submitted to the procurement system for approval. The second checkout may be hidden from the user by using scripting (JavaScript) in the HTML page generated by the exchange.

This particular punchout description is one example of how the exchange flows might operate. Specific protocol flows will vary in the exact details. The protocol exchange runtime is constructed from a set of common protocol objects (Login, ShoppingCart, Order), with plugins for specific functions of the various protocols. For example, the mySAP inbound logon plugin accepts a mySAP logon request and converts it to an internal logon object. The cXML outbound logon plugin converts the logon object into a cXML PunchOutSetup Request. The various shopping cart plugins convert shopping carts in different protocols into a common ShoppingCart object. The exchange also contains code to map between credential domains (from Ariba Network IDs to mySAP OCI userid/password). Finally, there is a state management framework to maintain the state of a session and keep track of message content (such as the postback URL), which must be extracted from one message, temporarily saved, and replaced in a subsequent message.

The B2B interaction between two parties is defined within the protocol exchange as a series of plugin transformations to be performed. One plugin accepts a message and turns it into a common object. A subsequent plugin takes the object and issues it as a message in a different protocol. There is no implicit assumption, for example, that a cXML punchout to a supplier will result in the supplier returning the shopping cart in cXML format, or that a shopping cart returned in cXML format is to be followed by an order to the supplier in cXML.

This flexibility is necessary to accommodate some of the interactions that are common today. As an example, the SAP Open Catalog Interface allows the shopping cart to be returned in either XML or HTML, depending on the configuration of the buyer’s procurement system. Some of the private buyer and supplier marketplaces are implemented using combinations of different protocols. A supplier might expect an OBI logon from which it might return a cXML shopping cart to the purchasing system. And, the subsequent order may have to be transmitted in EDI, because the supplier’s EDI order processing system was in place, running over a value added network long before the supplier had implemented any B2B interactions over the Internet.

Finally, it is hoped the various electronic commerce dialects will someday coalesce into a smaller and more concise set. But until then, it seems that something like a B2B protocol exchange will be required to bridge the communication gap between prospective trading partners.

^[1]Dias, D. M., Palmer, S. L., Rayfield, J. T., Shaikh, H. H., and Sreeram, T. K., “E-Commerce Interoperability with IBM’s Websphere Commerce Products,” IBM Systems Journal, Copyright 2002 IBM Corporation, IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, United States (2002): pp. 272-286.

^[2]Ferguson, Renee Boucher, “E-Sourcing Apps Lead to Time Well-Spent,” eWeek, Copyright 2003 Ziff Davis Media Inc., Ziff Davis Media Inc. 28 East 28th Street, New York, New York 10016-7930, ( March 2002): p. 18.