SAP Commerce and Punchout – Part 1

This article is brought by Robert Bull, Lead Solution Architect

Introduction

Punchout is an electronic procurement process used in B2B scenarios. The typical process involves a purchaser’s system accessing a supplier’s product catalog to allow the purchaser to build up a list of products to be purchased (the list exists in the supplier’s system) and then the session is completed with the list being transferred back to the purchaser’s system. The purchaser can then place the purchase through the use of their own procurement process.

Typically, punchout is used by larger organizations making multiple purchases to multiple suppliers and the systems they use are part of corporate ERP platforms. Effectively, all this transcribes to a large network of connections between purchasers and suppliers, and that concept immediately warrants for the need for standardization: enter OCI and cXML standards.

In this article I have split into 2 parts:

• In this part 1, I am providing information on punchout standards, their background and typical scenarios
• In the follow-up Part 2, I will be exploring and demonstrating the use of Punchout in SAP Commerce.

Punchout Background

In the 1960s the U.S. transportation industry developed EDI (Electronic Data Interchange) to enable communications between companies’ computer systems with an objective to standardize electronic transactions between customers and vendors. EDI evolved into many variations and is still used today.

However, two new standards emerged in the late 1990s – OCI RoundTrip and cXML both offering similar punchout capabilities, but not interoperable with each other.

OCI RoundTrip was developed by SAP to enable procurement between their own enterprise systems and external supplier catalogs. One of the ERP systems at the time was SAP SRM – Supplier Relationship Management – an enterprise tool for goods procurement through a web-based platform (remember that web applications had only existed for a few years at this point and networking was nothing like the infrastructure we have today). The objective was to simplify the procurement system to enable real-time access to supplier product catalogs to support informed purchasing decisions.

Around the same time, the cXML (commerce eXtensible Markup Language) standard was introduced by a relatively new company called Ariba (founded in 1996) who specialized in ecommerce and supply chain management solutions and cXML was created to support seamless B2B transactions. The cXML specification was designed as an open standard (i.e., to encourage engagement in its design from other interested parties) to allow companies to exchange catalog content, purchase orders, and other procurement-related documents over the internet in a structured and standardized format, the XML standard itself having only existed for a year or so. The cXML standard quickly became popular among large organizations who used the Ariba procurement platform. Essentially, everyone is free to use cXML with any and all modifications as long as they don’t publish their own standard and call it “cXML”.

With either of the two standards of OCI and cXML, interoperability was achieved at a syntactical level, (i.e., OCI to OCI and cXML to cXML), but both can suffer from semantic issues concerning the data passed from supplier to purchaser. For example, lengths of strings, format of strings, character sets used, use of hyphenation or whitespace, etc. These were (and are) always challenges to overcome in such initiatives. To meet these situations, the standards also focused on data transfer rules such as field lengths, data types and with OCI 5.0, introduction of JSON objects within the data fields were added. For cXML there are many references to other standards such as ISO-3166 country codes, ISO-8601 date/time standard, ISO-639 language codes, ISO-4217 currency codes, and ISO-6523 for the identification of organizations and parts. Solution choices have emerged over the years – either the catalog and/or purchasing system could deal with the semantic interoperability or a service acting as a middleware component between purchaser and catalog could undertake data modifications to achieve the desired interoperability – and those approaches are still typical of punchout solutions today.

OCI and cXML Version History

I have listed below the version history of OCI and cXML:

For OCI, there is very little to find nowadays on the original specification but I believe it was called SAP “Business-to-Business-Procurement 1.0”, and was released in 1999. However, there is more tangible evidence for the subsequent versions as these can be found online in PDF form:

• OCI Release 2.0B – November 2000
• OCI Release 3.0 – November 2001
• OCI Release 4.0 – November 2003
• OCI Release 5.0 – 2013

For cXML, the history is easier to determine via the cXML website:

• cXML/1.0 – August 1999
• cXML 1.1 – June 2000
• cXML 1.2.001 – 2001
• …with multiple releases since 1.2.001 through to:
• cXML 1.2.062 – May 2024

Both protocols are now under the ownership of SAP since SAP acquired Ariba in 2012.

OCI Punchout Protocol and Services

The specifics of OCI implementations are many but the protocol itself comprises the procurement system calling up to the catalog system where the procurer then performs some actions. The calling up contains a number of parameters according to the specific action specified including a return URL. The session ends with the catalog system calling back to the procurement system to a return URL that is provided.

The call to the catalog is a POST request and the OCI parameters are carried as form fields that include authentication, the return URL, the OCI version number supported. This is frequently referred to as a Level 1 punchout and takes the user to a catalog page where they can begin a product search. Other OCI fields can carry focus to a specific known product or brand for sourcing, such as the vendor, the product-id and quantity. This is frequently referred to as a Level 2 punchout and takes the user to a catalog page such as the PDP. The details are provided in the specification documentation.

Additional security outside the scope of OCI could be applied such as whitelisting connection sources, or use of VPNs but this would need to be on a case-by-case basis and is outside the scope of the protocol itself.

The OCI documentation publication in fact provided an example catalog interface as excerpts of the HTML and XML code generated by a catalog engine, inviting the reader to see in a web browser.

Other services in OCI Punchout

In addition to the flows mentioned above for cart transfer, the OCI punchout protocol also has other services:

• Detailed Display of a product or service – where the details of a product that is already in the procurement system can be retrieved;
• To validate the quantity/price of a product as compared to what the procurement system may know;
• To search for a product by its Id, vendor and a search string
• To perform a background cross-catalog search.

cXML Protocol and Services

cXML is designed to allow buying organizations, suppliers, service providers, and intermediaries to communicate using a protocol defined in XML. There are three main documents defined:

• Catalogs;
• Punchout; and,
• Purchase orders.

These functionalities are defined in the cXML as documents rather than services because the focus is on the format of the data being conveyed. However, where a document is conveyed on a web service, the cXML protocol defines this also.

The cXML catalog document specification is to enable suppliers to send their catalog product information to procurers. The transport of the data is not prescribed, it could be on a web URL response, it could be a file transfer.

The punchout specification provides for the procurer to retrieve products during an online session and the products are sent back to the procurer system (like OCI, referred to as Level 1 punchout, and if a specific product is defined, referred to as Level 2 punchout).

The Purchase order specification provides for a procurer to send the purchase order to the supplier.

Like OCI, the specifics of cXML implementations are many. With focus on the punchout service, the protocol focuses on the commencement of a session connecting to the catalog provider and ends with the products that the procurer has selected being sent back to the procurement system. The session commencement is a POST request to the designated URL, and the response with the products is a URL with the punchout specification as a payload.

Other services in cXML Punchout

In addition to the specifications mentioned above, the cXML specification also has other services:

• Purchase Requisition process
• Purchase Order process
• Quotation Request process
• Payment Processes
• Master Agreements and Contracts
• Timecard Transaction processes (for placing orders related to temporary labor and contractors).

From experience and projects at EPAM, we see most implementations focusing on the punchout service, where there is similarity between OCI and cXML for both Levels 1 and 2. I have not focused on the other services and leave these for the reader to digest as they require.

Authentication in Punchout

In OCI, the authentication details are provided in the request form fields as user and password. These are not encoded. However, a more secure specification exists in the OCI standard called Secure OCI which uses a backend call to initially convey the authentication data and the response contains a session Id and a session transmission Id which are then used for the user catalog session. This approach keeps the credentials hidden from the user session making it harder to be visually intercepted.

In cXML, the punchout authentication comprises a number of parameters on the cXML body request, under elements called From, To, and Sender. The From and To are analogous to the same elements on an email, and the Credential element contains an identity and a shared secret which serve as the authenticating elements. The catalog end can factor in multiple aspects for authentication, it might not just validate the identity and shared secret, but could also validate the From and To values. Note that when punchout sessions are passing through third-party hubs, multiple instances of the From and To can be added (again, like forwarded emails), and the authentication can be more complex by having to parse through the From and To and Sender elements in a prescribed sequence until a valid combination is found. In addition, an OAuth authentication can be used with a bearer token key/value provided in the header.

Punchout Sessions

The basic concept for both OCI and cXML is similar and is analogous to regular eCommerce where the suppliers have the responsibility of making products available online in terms of detailed product information, pricing, availability, etc. and a purchaser has the responsibility to pick and choose what they want from the supplier in an online session. Whereas in a conventional eCommerce session the purchaser puts selected products in a cart and completes their purchase through a “check out” process; in a punchout session the selected items in the cart are transferred back to the purchaser system and the punchout session is then closed. The basic flow is shown below and is referred to as Level 1 Punchout.

Level 1 Punchout Scenario

The punchout session that the procurement user has is typically very similar to a regular eCommerce session – it can have a home page, search, facet filtering, PLP, PDP, add to cart and so on, and even have access to the purchaser’s account information such as order history etc. The typical differences are of the following:

• There is usually no need for user account password changes because the punchout session commencement carries authorization credentials;
• The session concludes at the point when the purchaser has either identified all required products they wish to purchase or they decide to terminate the session – there is no checkout like you would have in a regular online eCommerce session;
• The authorization to purchase is outside the scope of the initial punchout session.

Other aspects that are outside the scope of the standards, could be:

• Whether any customer-specific pricing, or entitlements, or catalog product information is made available to the purchaser during the session;
• Whether the eCommerce system retains any customer carts or not, or makes saved carts available for future sessions;
• System availability or other NFRs such as performance etc
• Any business process aspects related to purchase limits.

One other aspect is whether to permit all purchasing customers to have visibility of all products, this could be accomplished in the supplier’s system but would have a significant overhead on product indexing and search.

One way to make this more efficient is for the supplier to send a catalog of products to the purchaser, where the products are loaded into the purchasing system and the purchaser can find and select within their purchasing system before they initiate a punchout session. This is referred to as Level 2 punchout with the revised flow shown below. The supply of the catalog of products, and the selection of a product within the procurement system is not part of the OCI or cXML standards

Level 2 Punchout Scenario

Punchout Services

There are a number of services that support punchout and act as intermediaries between procurers and suppliers. These services offer cloud-based procurement and supply chain management solutions that help companies manage their spend, procurement, and supplier relationships. Examples include SAP Ariba, Coupa, Jaggaer and differences are usually in industry-specific customizations, supported integration with enterprise systems, and their pricing models.

A typical example would be when a procurer uses a number of suppliers, and instead of contacting them directly, they connect to the cloud service, select the supplier and the punchout session commences. Benefits here are that the cloud service can handle data transformations and resolve any interoperability issues I mentioned earlier. Take SAP Ariba for example, a Google search will reveal that in 2022:

• over $3.75 trillion in transactions between 5.4 million organizations;
• more than 4.6 million companies;
• over 4.4 million suppliers connected to the service; and,
• over 195 million catalog items across all suppliers.

SAP Commerce and Punchout – Part 2

Please come back for Part 2 where I will be focusing and demonstrating the OCI and cXML Punchout standards as implemented for Hybris / SAP Commerce.

References:

• Further info on the OCI standard and specifications: https://punchoutcommerce.com/guides/punchout/oci-roundtrip/
• Further info on the cXML standard and specifications: https://cxml.org/