Saturday, June 20, 2009

validating PunchOut cXML pt. 1

A while back – I promised I’d write up something about a cXML validation tool… and I even showed some screen shots of one I’d been working on.  Well that tool worked so well – it now belongs to where I work so I’ve had to come up with a nice simple version to show you all here that doesn’t violate any confidentialities or agreements.

I will actually build that same kind of features here … but we’re going to take it slow and easy and work our way up.   So let’s start with why you need to validate cXML – and what you need to perform a validation.

This might seem obvious to a lot of us, but believe it or not you have no idea how many paid consultants I deal with that will argue with me that their cXML is valid when it’s missing even the most basic and common tags for even normal XML, let alone those specific to cXML, and then they will wonder why it is they can’t connect to your catalogs and process orders. <rolls eyes>

PunchOut cXML is really nothing more than a standard eCommerce transaction system protocol. 

In the first step of a PunchOut system, a PunchOutSetUpRequest (POSR) is sent to a supplier of a product.  This POSR has all the information needed to connect the two systems securely.  It is made up of three data structures or tables if you will, the Header, which contains validation information.  Who the POSR is From, who the POSR is sent To, who the POSR’s Sender is and their secure password.

The data structure looks something like this…image

 

The <From> tag contains the <Identity> of who the POSR is from.

The <To> tag contains the <Identity>, usually a DUNS number of who the transaction is being sent to (the Supplier).

The <Sender> tag contains the <Credential> <Identity> and <Credential> <SharedSecret> of who the supplier is recieving the POSR from and what sort of system they sent the POSR from found in the <UserAgent> tag.

This can be somewhat confusing as the <From> and the <Sender> are not always the same.  For this reason many systems you’ll deal with (Ariba, Oracle Supplier and Oracle Exchange for example) actually authenticate based not on the <Sender> <Identity> but on the <From> <Identity> and the <Sender> <SharedSecret>. 

The reason for this is actually pretty logical.  A Buyer, for example Acme Corporation, may utilize a 3rd party like Ariba Supplier Network or Oracle Exchange / Oracle Supplier Network to actually handle their transactions.  So the Supplier will need to authenticate based on the original sender – Acme Corporation, which has established an Identity on one of these Supplier Networks.  The Supplier network will replace the Identity and SharedSecret values with their own, and this is what is sent on to the Supplier.  So the Supplier in a PunchOut model will need to know who the actual originator is in the transaction, not the last person to touch the transaction – in the case shown here, Ariba Supplier Network.

If the Supplier authenticates only on the Sender Field they would be exchanging credentials with the Supplier Network, and not the actual originator – Acme.  So by hybridizing the systems, they authenticate using the <Identity> from the originator, and the <SharedSecret> provided by the Supplier Network (Ariba).  For this reason they use the <From> <Identity> which is the orignator, or who the POSR is from. 

In fact, many Supplier Networks (ASN, OSN, OEN) completely ignore the name of the <Sender><Identity> and you can put any value you like in there and it will still authenticate.

Since a POSR is a direct communication between the Originator / Buyer and the Seller / Supplier, and the Supplier Network is not yet involved – the Buyer and Seller must have agreed upon values to authenticate with, so they will generally use the <From> <Identity> and the <Sender> <SharedSecret>. 

imagecXML rules like these seem complicated but really can be very simple, and like all simple things if you follow very basic rules it’s very easy to work with.  Rule #1… if the file can’t be validated… you’re going to have problems.  So make sure your files validate.  To help with this I’m including a free tool written in vb.net using the free VB Express version.

I’ll get into the code for this in the next blog posting – but for now you can play around with this and get a feel for how to validate an recognize files which are good and bad against the www.cxml.org files.  (Yes…. you can get the samples for all cXML transactions at… www.cxml.org.  So go there and download the guide book and samples to play with this a bit.

 cXML Validator Tool (Zipped Format)
cXML Validator Source Code

3 comments:

Anonymous said...

Interesting article about Puncout cXML.
CXML Punchout

Digihost said...

It's very interesting, thanks for sharing.
CXML Punchout

Unknown said...

Thanks for sharing great article about What is cXML : how to integrate it with eCommerce
What is cXML : how to integrate it with eCommerce