Connectivity Using a B2B Protocol Exchange

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

Now, let's look at how the exchange could be used to facilitate punch-out between a buyer and a supplier using different protocols. Although this example is limited to punchout, the protocol swap over can cover many other general B2B interactions, such as shopping cart dealing out and order processing.

Suppliers participating in a marketplace may have catalog systems already in place sustaining presented standard or proprietary formats. These formats may differ 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 an exact supplier is capable of processing. The B2B protocol switch is a tool that allows suppliers to interact with buyers whose protocols would or else be incompatible.

Unlike some kinds of protocol conversions, most B2B protocol conversions cannot be achieved in a stateless way, that is, in a manner in which the protocol converter has no knowledge of prior events or message exchanges. This is because a lot of of the protocols pass on 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 swapping process between business partners. Thus, session state management is necessary along with message format translation.

A block figure of a typical atmosphere is shown in Figure 1.13. In this illustration, Buyer 1 and Supplier 1 use protocol A, whereas Buyer 2 and Supplier 2 make use of protocol B. Information swap between Buyer 1 and Supplier 2, or among Buyer 2 and Supplier

1, requires the make use of of the protocol exchange. The existence 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.

At this moment, let's look in some feature at a punchout process such as an Ariba cXML punchout between a supplier and buyer that use the same protocol. The data flow is illustrated in Figure 1.14, shown earlier. The numerals pass on to the process steps described here. To obtain from a network catalog, the buyer naturally uses a browser to cooperate (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 application contains the credentials (userid/password) of the procurement system, a session identifier ( in cXML), and the post back URL, which is the HTTP URL at which the procurement system accepts the finished 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 straightforwardly to the network catalog system (step 5) bypassing the procurement system.

As earlier described in some feature, the punchout operation illustrated in Figure 2 (between a buyer and a supplier) uses the similar protocol. In the event the supplier and buyer use different protocols, they will be incapable to support a punchout interoperation unless some mechanism such as the protocol exchange is used. The data flow is shown in Figure 2.

Figure 2 Punchout request flow with protocol conversion.

While using a protocol exchange for this mapping, the procurement system is configured to treat the exchange as the supplier system. The primary login application is sent to the exchange rather than the objective supplier system. The processing requisite at the exchange at this point may be literally involved. Typically, the protocol alteration involves two different validation domains (the target protocol and the source protocol). The exchange must authenticate the incoming recommendation and produce the outgoing credentials for the target protocol domain. In addition, the incoming request typically has an associated session ID (Buyer Cookie), which must be recorded and mapped to an equal to session ID in the target protocol. Also, the post back URL must be saved, and the URL of the exchange must be substituted in the outgoing message. Finally, the objective supplier system must be recognized, and the changed request must be passed as a new login request (step 2b) to the target supplier system.

When the login response (step 3a) is expected by the exchange, the reaction is changed into a protocol a reaction 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 network catalog site and buyer's browser. 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 replacement of the exchange URL for the procurement system URL in the protocol A login response. In order to process the checkout, the swap creates a new checkout page, with the shopping cart transformed into the protocol a format, and precedes this page to the buyer's browser (step 7b). The target URL of the "checkout" button on this page is the post back URL of the procurement system, which was saved during the transformation of the login request in step 2a. The buyer is instructed to carry out 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 means of scripting (JavaScript) in the HTML page generated by the exchange.

This exacting punchout explanation is one example of how the exchange flows might operate. Exact protocol flows will vary in the exact facts. The protocol swap runtime is constructed from a set of common protocol objects (Login, Shopping Cart, Order), with plug-ins for exact functions of the various protocols. For instance, the mySAP inbound logon plug-in accepts a mySAP logon demand and converts it to an internal logon object. The cXML outbound logon plugs in converts the logon objective into a cXML PunchOutSetup Request. A variety of shopping cart plug-in convert shopping carts in dissimilar protocols into a common ShoppingCart object. The swap also contains code to map between credential domains (from Ariba Network IDs to mySAP OCI user id/ password). Lastly, there is a state management framework to keep the condition of a session and keep track of message content (such as the post back URL), which must be extracted from one message, temporarily saved, and replaced in a subsequent message.

The B2B dealings between two parties are definite inside the protocol substitute as a series of plug in transformations to be performed. One plug in accepts a message and turns it into a general object. A subsequent plugs in takes the issues and objects it as a message in a dissimilar protocol. There is no implicit assumption, for instance, 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 litheness is essential to accommodate some of the communications that are common today. As an instance, the SAP Open Catalog Interface allows the shopping cart to be returned in either HTML or XML, depending on the design of the buyer's procurement system. A number of the private buyer and supplier marketplaces are implemented using combinations of dissimilar protocols. A dealer might be expecting an OBI logon from which it might return a cXML shopping cart to the purchasing system. And, the consequent order may have to be transmitted in EDI, because the supplier's EDI order processing system was in situate, running above a value added network long before the supplier had implemented any B2B interactions over the Internet.

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