This US based transportation giant had just signed up with my customer – let’s call them “Acme Inc” – a large wholesaler in the US, for all of their requirements world-wide of a particular range of products. In order to fulfil this contract, Acme needed their ecommerce stores integrated with several of the customer’s internal systems to allow seamless access to the stores for tens of thousands of staff all over the world. I linked the store to Peoplesoft eProcurement and Tivoli Access Manager.
(a note to my UK readers: I’ve deliberately used some American spellings and terms, to allow this to be found more easily by US readers. Examples are “store” instead of “shop”, “shipping” instead of “delivery” and of course “zip code” instead of “postcode”.)
Acme called on their online storefront provider to provide this functionality, and in turn they called on me as their retained punchout store expert.
There were two distinct requirements:
- a “cXML” based punchout, whereby staff would click through to the store, be seamlessly signed in to their own account, create a shopping cart, take it back to their internal system, and then electronically send a purchase order with credit card (or “PCard”) payment information included.
- allowing the company’s external distributors to sign in via the internal “Tivoli” based system, using Tivoli Access Manager (TAM)
cXML Integration: Punchout, Requisition and Purchase orders
Although cXML is a standard, it is implemented slightly differently by every company, and so each integration involves a process of testing and tweaking in a QA (or ‘test’) environment.
In this case, our standard cXML settings gave us a good start, but as with most punchouts, we quickly found a few new features were needed. In this case, we had to make the following additions:
- allow ‘PCard’ (or ‘corporate credit card’) payments to be taken while a purchase order was being processed
- address formatting: some translation of the address format needed to be made, so that the store could correctly calculate the sales tax and shipping price (for my European readers, US sales tax depends on the destination city, state and zip code)
- username formatting: we needed to allow the same user to access two different stores, yet usernames needed to be unique accross the whole store system. To ensure this we simply added a configurable prefix to the username dependant on which store they accessed
Tivoli Access Manager Integration with a Web Store
This system allows regulated access to specific websites for internal and external users. It works by providing a ‘transparent proxy’, whereby the URL you see in your browser is a URL on the TAM (Tivoli Access Manager) system, and behind that it will send your request through to the destination website, along with your sign-in information.
It can work in several modes:
- Regular junction: where the user sees ‘http://the-tam-gateway/your-app/index.html’ which is mapped through to ‘http://your-app-server/index.html’
- Transparent junction: this keeps the ‘path’ part of the URL the same, and the user sees ‘http://the-tam-gateway/your-app/index.html’ which is mapped through to ‘http://your-app-server/your-app/index.html’
- Virtual Host junction: this changes only the ‘host’ part of the URL, and the user sees ‘http://your-app’s-tam-gateway-name/index.html’ which is mapped through to ‘http://your-app-server/index.html’
- Understanding the technical requirements: Having worked through dozens of punchout and purchasing system integration projects together in the past, my contact at Acme and I were able to anticipate many of the technical issues that came up, and in many cases work them into the solution before handing over to the end customer for testing.
- Understanding the commercial requirements: It’s important to see the big picture when faced with a technical project like this, and understand where the technical solution fits into Acme’s cashflow. For example, if a particular end customer was only likely to produce $100k/year of profit for Acme, then it’s probably not worth them spending $60k to make that happen, whereas a contract worth $1m net profit would certainly be worth spending $60k on.
- Learning the customer’s jargon: Staff in large organisations often forget that you don’t know their internal jargon. Generally there will be words for specific systems or processes, or departments. By asking questions in the right way, being patient and closely observing the email chains and screenshots that arrived in my inbox, I was able to figure out some of the end customer’s internal jargon, which helped to avoid confusion on conference calls and later emails.
- Programming without regression: A ‘regression’ in programming is (in very simple terms) when something that was previously working breaks due to a new feature being added. In this case, the ‘cXML’ module of the system I built is used to power over $5m/year in revenue for various customers, and so it’s imperative that any features added for new integrations will have no impact on existing integrations. Thorough testing, and careful ‘backwards compatible’ addition of any changes is the only way to do this.
- Programming on-the-fly: In some cases, by changing the code on a QA (‘testing’) system during a conference call, the whole integration process can be speeded up by days or weeks, because you’re able to get instant feedback after making a change. This requires a little planning (ensuring that the QA system is not being used by others!), careful programming, and the presence of mind to perform a quick test before announcing that a change has been made.
If you have any questions, just fill in the form below and I’ll respond by email soon.