If you follow me on LinkedIn, I recently posted this:

I did this because I found myself guilty doing that very thing.  Wanting to do something the way it has always been done.  It would have been easy.  We had all the scripts and processes worked out.  It was a no brainer.  Our vendor however, wanted to send us invoices through the Oracle Supplier Network (OSN).  This of course meant that we needed to configure XML Gateway for yep, EBS 11i (no jokes please).  Why would we do that?  Our current process worked just fine:

1. Vendor/Partner uploads a flat file to the sFTP site
2. A scheduled script would move the file from the sFTP site to the SAMBA share
3. Another script would archive the file and move it from the SAMBA share to the EBS file system where is was archived again
4. A concurrent program would run to “process” that file and when everything was done, the log files were checked to see if any errors occurred.

Did I mention that at points throughout the process email notifications are flying back and forth letting us know at each step whether it was successful or not?  Simple huh?

Just think … that process was repeated for each business partner we needed to exchange data with.  But we had that down pat, why do something different?  “We’ve always done it this way.”  I was going against my very nature.  Now there was good reason to want this.  Our functional area made a few wrong assumptions:

• XML Gateway was already configured
• OSN was already configured
• Vendors were already set up as trading partners

I got a lot of push back, so I looked at this XML Gateway, and once I understood it, I saw the potential.  If for whatever reason, you don’t know about it, click here. Hope Oracle doesn’t get mad about that.  In a nutshell, XML Gateway is a set of services that allow you to subscribe to inbound events and consume XML data for processing.  It takes advantage of workflows and there is even a XML Gateway map builder that will allow you to remap messages to match any standard.  The map builder isn’t the best looking tool.  It looks like workflow builder’s cousin, but it gets the job done.

What does this mean for me as a solutions provider?

1. Standardization on how data is delivered
2. More solutions offering (the other process isn’t going away anytime soon)
3. Cleaner integration into EBS
4. Elimination of a multi-step process and multiple points of failure
5. Deliver streamlined and repeatable processes
6. Simpler modification process for system upgrades …  R12.2, here we come!!!