Anyone integrate osCommerce with ARIBA cXML?

[Guest]

I'd rather not re-invent the wheel, but it seems there's no add-on module that assists in integrating customers, checkout and order history with ARIBA cXML (the cXML User’s Guide now updated as of July 2015). Ideally the solution would be scalable to multiple client stores and perhaps other e-procurement systems such as ARIBA's sister company SAP, and would give us a leg up on enterprise, government and public sector supplier centers.

 

I see no new solutions despite years of several members inquiring about it and no updates to CXML API add-on attempts since 2007.

 

A couple of vendors look promising: PunchOut2Go Gateway and PunchoutGateway. They have built plug-and-play integrations with Magento and other popular or proprietary storefront systems, to define and host cXML documents that must be exchanged when an ARIBA buyer goes shopping and requires procurement approval before the transaction can be completed and submitted to the supplier for order processing.

 

One punchout vendor contact said he had multiple osCommerce integrations, but when pressed for references, he downgraded to a handful, then knew of only 1 osCommerce integration that's done and 1 in progress.

 

The gateway vendors do not touch the osCommerce code itself, and instead provide osCommerce developers with documentation and support during the implementation phase.

 

The gateway can be set to notify the supplier when an order is ready for processing and the cXML PO is ready to be translated. However, it may not actually communicate back to the osCommerce Checkout page when the order has been approved so that the status can be updated; it just looks like an abandoned cart.

 

I'm waiting for vendors' responses and references, but appreciate any suggestions!

 

 

 

 

 

 

 

[MrPhil]

Hmm. If I understand the flow here, rather than someone purchasing from a store directly, all they do is create a proposed purchase (in XML format), which is the last time a human interacts with the store. They send that to their procurement group, who checks that the purchase meets spec, is acceptable price, is approved, etc., and who shoots it back to the store to actually make the purchase? Does the cXML document have all the information needed, or does the procurement group need to access the store catalog to get more information? Anyway, is that the gist of it from the customer viewpoint? Does this process create some sort of "pending order" that the store needs to maintain, or does it look only like someone browsing the catalog, and later some sort of batch purchase (not human entered) comes in to the store?

 

I suppose it can be done, but it's a major change to osC. I glanced at the opening chapters of the guide (TL;DR), so my questions may have been answered there. There have been add-ons before that don't allow purchase, but only act as a read-only catalog. I don't recall if any of them would generate a document that goes back to the visitor. Browsers generally aren't allowed to create files on their PC, so I'm guessing the document would have to be emailed somewhere. Is that acceptable, or is the practice to present the XML itself as a page? At checkout, rather than making payment, it seems that the shopping cart (and whatever other information is required) could be exported in cXML format and then emailed (or presented, if someone on the other end is prepared to scrape the document in some manner). That would clear up the problem of it looking like an abandoned cart. Stock would not be reserved for this possible future purchase.

 

Next, does the procurement group need to interact with the store in some way to get more information, or does nothing happen until the purchase order comes in? Once the batch purchase order comes in, osC would have to in effect fill its shopping cart for this virtual customer, and go through checkout (it will have the information at hand for shipping address, etc.). I assume that payment is on terms (30 day net, etc.) rather than immediate payment via credit card, which could be left to a separate financial system. What happens if the store goes out of stock in some item? Is the whole order cancelled, or partially filled?

 

Does this cover the waterfront, or have I overlooked anything of importance? Be forewarned that I have no intention of actually implementing this -- just thinking out loud in hopes that it could trigger some thoughts in someone willing to do the work.

 

 

One punchout vendor contact said he had multiple osCommerce integrations, but when pressed for references, he downgraded to a handful, then knew of only 1 osCommerce integration that's done and 1 in progress.

 

Gotta love those salesmen!

[Guest]

Thank you MrPhil for your thoughts!

 

(We don't need no stinkin' batches. ;-)

 

On our legacy proprietary storefront platform using ASP/SQL Server, here's a typical ARIBA order flow:

• Customer logs into ARIBA Buyer website, finds our name/product lines, and punches out to our web storefront with a session cookie that registers/logs them in so they have access to their products and order history.
• Customer chooses from our catalog and specifies product attributes, quantity/price and other options and adds to the Cart.
• The script also sends various debug messages to our developer and service desk.
• At Checkout, customer specifies phone number for delivery purposes. Shipping address, shopper name and email address have come across from the ARIBA system.
• In lieu of completing the Payment entry (PO or Credit Card) the customer clicks a Confirm Order button to send the order details via cXML to their ARIBA Buyer system to complete the transaction. (Payment terms vary per customer organization contract.)
• In return, the ARIBA system responds via HTTPS cXML so we can update our storefront order to our own status values, such as from Pending ARIBA to Confirmed or Cancelled.
• If Confirmed, our MSASP/SQL storefront generates an email order confirmation to the customer, and an email with a cXML attachment to our service desk that we save to translate for Order Entry and PrePress Production, and I believe it also sends a response back to the ARIBA network regarding the order status from our side.

Back to osCommerce: There's certainly enough osCommerce CSV export scripts around, so why couldn't the server output cXML via the HTTPS request/response connection to ARIBA? Granted, our particular flavor is complicated by Quark HyperPublishing modifications to generate a Quark publication and PDF file that is available for download from Admin Order History. It seems plausible that we could have the cXML available for download in the same way in Admin Order History.

 

Our ASP/SQL developer might be persuaded to lend his expertise on cXML-related scripting and debugging, and has done some modifications to our osCommerce Checkout and Order Totals before in PHP so he is familiar with the structure.

 

But we're hoping someone else has done this before. I stand on the shoulders of GIANTS. o:)

[Guest]

RE: What happens if the store goes out of stock in some item? Is the whole order cancelled, or partially filled?

 

One of our ARIBA customers on our MS ASP/SQL shop likes to allow shoppers and approvers to split orders and allow partial fills. There's a line item status for that.

 

But out of stock does not apply to us since all our products are custom printed.

[MrPhil]

So the ARIBA Buyer website is kind of acting like a front-end to a number of stores, with remote user validation and provision of customer data to the store, among other things? This is starting to sound very complicated, and a major change to the structure of osCommerce. It might be easier to find a store that is written from the ground up with ARIBA in mind, rather than trying to adapt osC to it. It sounds like it's much more than exporting the shopping cart in cXML and accepting robot interaction of further stages of the purchase process. If it can share the database with a standard osC store for non-ARIBA buyers, so much the better. Not having really played in this area, it sounds fascinating, but I'm afraid I'm in over my head.

[Guest]

So the ARIBA Buyer website is kind of acting like a front-end to a number of stores, with remote user validation and provision of customer data to the store, among other things?

 

Yep, ARIBA is very much a front-end for Procurement personnel and administrative staff of major enterprises and public sector agencies.

 

IceShop Batavi OS, which evolved from a branch of osCommerce, looked promising in terms of an XML-EDI integration friendly architecture, but our Quark Hyperpublishing mods are business critical and are limited to our version of osCommerce.

 

The Punchout Gateway approach seem promising, but I am not sure how much osCommerce development would be needed to align customer login, checkout, and order status/history with the cXML parsing and output requirements.

 

Cheers, and again thank you for your thoughts.