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’
The online store system takes over the whole URL space – eg. it can’t be placed in a ‘sub folder’ on the URL, such has http://your-online-store/sub-folder/, and so initially it appeared that the ‘virtual host’ solution was the only option. However, this was going to be very difficult for the end customer due to constraints on time and in their IT environment. It’s important to remember that large organisations must have strict controls to govern their IT systems, because any change has a potentially huge impact.
The ‘transparent junction’ option would have been a lot of work to implement on our store, because the entire system was based around having full control over the URLs.
So we were left with one option: a regular TAM junction.
Authenticating the TAM users was the next challenge. The TAM gateway adds extra ‘HTTP headers’ into the request to the application server, which can include the username, the user’s group, and other information. For this global transport company’s internal staff, the username alone was enough, but for thousands of external dealers who also had access to the system, we had to make a ‘SOAP’ call to a web service which could provide further information about the user, such as their full name, email, phone and shipping address.
Another issue we had was taking payment. For this store, users were redirected to a 3rd party ‘payment gateway’, Authorize.net, using their SIM (Server Integration Method) platform. Once they had paid, we needed Authorize.net to redirect them back to the store, but at this point they had ‘escaped’ from the TAM junction, and were directly accessing the Authorize.net website. We needed to tell Authorize.net to redirect them back to the TAM junction, but our store was automatically telling them to head back to the actual store URL. Naturally, when they reached the store that way, the URL in their web browser was different, which meant that their web browser didn’t send any cookies to the server, and so the server saw an un-authenticated user. To work around this, I linked our Authorize.net code into the TAM code, so that the Authorize.net module would detect that this was a TAM user and automatically tell Authorize.net to send them back to the TAM URL.
The only remaining issue was a usability problem. We found that in some cases, users had created links directly to specific categories and pages on the store, using their TAM gateway URL. This was not a problem if the user was already signed in to our store via TAM, but in order to sign into our store, we needed them to hit a specific URL on the store first! The solution in this case was to educate the end users to ensure they linked only to the ‘sign in’ URL on the store, which would automatically sign them in and redirect them to the appropriate category.
- 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.
Leave a Reply