Nope… not a mis-spelling – that’s POSR, as in Punch Out Setup Request. As part of this current set of postings on cXML and the magic that is eCommerce that’s the subject dujuor. The totally awesome and completely cool … POSR.
Now, a POSR is probably the single most important part of the eCommerce step by step. It’s what authenticates and allows and online catalog to be sent to you.
Here’s what one looks like courtesy of www.cxml.org…
The first section of a POSR handles the Doctype and how to handle the document…
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.020/cXML.dtd">
<cXML payloadID=1233444@ariba.com timestamp="2000-03-12T18:39:09-08:00">
Now the grey line up there has the doctype and you can put all kinds of good things in there but what I’m showing here is the most important part – the DTD. With this badboy you can write an app that will allow you to validate all your cXML and make sure it works, using some very simple XML routines and a few free tools available on the web.
TIP:
You can – also find xml validators that can read the DTD – but many will choke on this line. XML Notepad for example is designed for pretty much XML only and not cXML, and will choke. The same thing goes for some browser based viewers. If that’s all you’ve got to view xml – remove this line and you’ll find it’ll load the file fine.
Anyway, you can use the DTD to learn a lot about what’s wrong with any cXML that you’re given (or that you create) by validating it against the DTD. So if you’re not – do so. It’ll save you weeks of headaches. This is especially true if you’re dealing with SAP or some of the Oracle solutions out there that like to write their own versions of cXML, or worse let you output in any fashion you want without telling you there are rules to how cXML is processed.
<cXML DTD and Consultant Rant Begins Here>
I would say 80% of the work I’m currently doing is on telling people how to validate their cXML, and fighting with people who tell me, “But we work successfully with dozens of vendors doing it this way…”. That may be the case – but cXML has rules, and it doesn’t matter how anyone else works – if you’re outputting to cXML you follow it’s rules or you pay.
The reward for following the rules is that if you do have a valid document – cXML is as stable as a rock, and your cXML will process like cannonball from a cannon. So it is worth the effort to do it right, even if your “consultant” tells you it’s not necessary. (Clue – if your “expert” tells you it’s not necessary to follow a standard… slap them. They either don’t know how to follow the standard, have been told by a software application advertisement it’s not necessary, or something but the bottom line is – they don’t know. I’ve seen a rash of “consultants” who claim this standard or that standard isn’t needed. It usually is – and the only reason why they don’t or they won’t use the recommended DTD standard is that they assume what they’ve been told by articles or others who are not familiar with them, that a DTD is basically the same thing as an XSD schema.
They hold many things in common, and often have a degree of interchangeability – but there is a reason why a DTD and an XSD exist and we don’t just use one or the other. The subtle nuances in how they work allow them to perform different degrees of use for different types of uses. For cXML the DTD is the model you need to be using, and one of the reasons is that certain required fields within the cXML DTD file enforce rules needed to make cXML work efficiently and correctly. When consultants try to slip around these rules, or try to get loose with the rules – it may work fine on their local system, but when they try to connect to anyone else, it becomes costly and time consuming.
</End Rant>
Before move on, it’s important to point out one thing in the DTD. DTDs are versioned. Each version has it’s own requirements and rules. If you find that you’re not validating – check the version which you’re validating against – it does make often a very big difference. You can read more about each of the versions, and get copies of them at www.cxml.org.
So… let’s get back to the POSR. What this does is it handles the hand shaking between the customer who is “Punching Out” to the vendor who has the catalog of goods that they will punch out to us. Now the concept of the “PunchOut” is very simple. A customer may have a massive catalog of items, but we don’t want all of them, or we may have rules regarding certain items in the catalog. (Joe the Janitor probably isn’t allowed to buy the same things that Victor the V.P. does at a company.) This can be controlled by the catalog that is “punched out” to the customer. And all of this – begins with the POSR, where we authenticate not just the company but often the employee at the company who is requesting access to the catalog.
This is done at the header of the POSR. Here’s what a header looks like:
<Header>
<From>
<!-- Supplier's identity -->
<Credential domain="NetworkID">
<Identity lastchangedTimestamp="2000-03-12T18:39:09-08:00">AN01333333333</Identity>
</Credential>
</From>
<To>
<!-- BCE's identity -->
<Credential domain="NetworkID">
<Identity>AN01222222222</Identity>
</Credential>
</To>
<Sender>
<Credential domain="AribaNetworkUserId">
<Identity>admin@ariba.com</Identity>
<SharedSecret>bce's shared secret with AN</SharedSecret>
</Credential>
<UserAgent>Ariba Network v20</UserAgent>
</Sender>
</Header>
The area you need to pay closest attention to is the one that reads “AribaNetworkUserId”, which I’m going to break from things here and point out that cXML is a standard developed by Ariba, and so – you’re going to see a lot of cheerleading for them in it. But you will probably have to change this for some eCommerce companies who… ahem… have competing products. But what you should never deviate from – is the use of a ID and SharedSecret. These will generally be supplied to you – from the vendor doing the punchout. These are the most important part of the punchout. Without them… you won’t authenticate, you won’t get a catalog and you will most definitely not pass go and collect $200.
Now if you’re familiar with earlier versions of cXML you’ll note that up in the Suppliers Identity – there’s a lastChangedTimestamp and you may not have seen that before. The truth is cXML (even with all those DTD rules) is very flexible. And you can actually put in your own Identities in this section so if your internal cXML processor needs other names to identify it – go to it. I’ve actually seen cXML where there were up to 15 Identities here. So long as the Identity that you and your vendor have agreed upon is in here amongst the others you can get pretty creative and this is a good place for you as an organization to make use of multiple identities.
The next part of a good punchout setup request is … the request itself. It contains a cookie, and if you have to do debugging something really handy… the BrowserFormPost. If you can locate this you can discover exactly here it originated from – and often this can help with network an connectivity issue resolution. So – keep track of that.
<Request>
<ProviderSetupRequest>
<OriginatorCookie>c546794949</OriginatorCookie>
<BrowserFormPost>
<URL>http://service.ariba.com/returntome</URL>
</BrowserFormPost>
<Followup>
<URL>http://service.ariba.com/laterUpdates</URL>
</Followup>
<SelectedService>BCE.Edi</SelectedService>
<Extrinsic name="user">
<Identity>user234</Identity>
</Extrinsic>
<Extrinsic name="url">
<URL>http://service.ariba.com/anotherurl</URL>
</Extrinsic>
</ProviderSetupRequest>
</Request>
Also up in there… are the extrinsics. Now I’ll let you in on a secret. Most of the stuff you see up there? Look up in the DTD – you’ll find a lot of it is not required. Remember that rant on DTDs I had up above? The DTD – will tell you exactly what fields are required and which fields are optional for cXML. Now, some vendors may have rules over and above those – but the DTD is core. It speaks – the world listens. So – check to see what you need and what you don’t need. A good rule of thumb for efficient processing is that if you don’t need to be sending it – don’t. All that does is make the systems on the vendor’s end have to read through it and figure out if it’s needed or not.
Put into a cXML document only those things you absolutely need for the best performance.
And that leaves us to the last part about the POSR… the closing tag.
</cXML>
I won’t go into a rant over tags here – but I will say that a well formed document with complete tags is essential. Don’t get sloppy. cXML is not forgiving when it comes to tags. It’s not chopped HTML where an unclosed tag will let it slide through. It may work on your system – but validate, validate, validate.
Get a tool which handles DTD validations, or roll your own. Either way – validate your stuff. If you use a tool like SAP or Oracle, find out how to get your output – even if you have to get it from the server logs and validate that. Make sure the application you’re using actually does churn out valid cXML if you’re sending it to a vendor. The time you save on that one chore – may save you weeks of arguing back and forth which of you has the problem. Don’t just assume your cXML output is good – KNOW it’s good because with the flexibility in some tools that I’ve mentioned it will actually let you create very bad cXML that no one can run no matter how forgiving their system is.
Well this is a larger post than I meant – but I’ve been behind on my postings… so seemed I should make up for it here. Next we’ll look at the PunchOutSetupResponse (the return to the POSR) – the OrderRequest and the POOM. (Yeah, yeah… I can tell you’re all shaking with anticipation.)
See you next week.
Posts
No comments:
Post a Comment