Did I hear correctly in our last discussion? There is a solution to the customization upgrade problem? That would be huge, you guys. I spoke to several colleagues over the last two weeks about this, and it seems we might be on to something. Let me explain.
THE PROBLEM:
In one of my current engagements, we are struggling with the issue whether and how to build an critically needed, complex customization in R12 that may have to be abandoned or completely re-written, once the client completes their Cloud journey over the next 3-5 years. This is not uncommon.
But we need most of it
What a mess ! Get rid of it!
As our clients are migrating within the R12 versions and / or preparing for Cloud migrations the customization issue is one of the biggest headaches. Reviewing, adjusting, and testing existing customizations is torturous. However, most clients cannot easily get rid of them and still don’t want to wait for Oracle to build all of them. What to do? Here the notes from our meeting:
We also discussed that multi-systems integration applications could even be used by our clients to develop and maintain EBS on-premise customizations separately. Quite an exciting thought! Further exploration could lead us to ways to escape the torturous upgrade purgatory of retrofitting all existing customizations. Can we figure out how to organize and provide customizations that can be connected to both, multiple EBS on premise releases and even Cloud Fusion.
THE RE-SOLUTION – THE CONCEPT
Did we stumble on a quite remarkable option, an integration “container” for customizations and extensions? My dream would be to have a “container” that provides the following functions pre-built:
Just Boxes
Single Purpose Extension
Secure Platform
Security protocols and access control with Oracle strength
Data storage facility for required additional master data and rules
User Interface and Automation tools for data entry and controls
Pre-built Integration
Data extract connectors for Oracle EBS versions R12 and Fusion Cloud
Data load and data update connectors Oracle EBS versions R12 and Fusion Cloud
Custom Programming Ability
Available configurable rule engine to my customizations
Ability to use my own tools to build customizations and load them into the container.
Complex Configuration - for me!
It seems that some of our colleagues are building or have built key elements of this solution. Check the posts below for more information. Let’s follow up and explore. I am anxiously waiting for your answers and perspectives.
The Discussion: Integrating with Oracle Cloud Systems - a Report
On Friday, April 22, 2022, we had a interesting conversation on how to integrate existing apps or your newly created apps with the software running on the networked computers of some of the Cloud service providers, including Oracle.
First, Peter Care of FXLoader discussed his company's case. FXLoader provides foreign currency exchange rates from over 60 banks and institutions as input. The output populates tables for Oracle's EBS on your own machines, and for Oracle Cloud on the provider's machines. Integrations are also in place for other service providers like Workday, PeopleSoft, JD Edwards, and SalesForce. Peter uses web services (FBDI, SOAP or REST) as appropriate, to align the banks' various fields with the Cloud service fields. FXLoader is strictly focused on exchange rates. Therefore it deals with many data sources, but needs only few client's master data elements.
Keith Porter of Virtual Trader, by comparison, has to layer in master data from the client in addition to the source data. Like FXLoader, input at Virtual Trader is acquired by FBDI, REST or SOAP, from products resident on the client's computers or at the providers, and is processed by VT's intercompany engine. VT also provides a centralized intercompany subledger and a home for intercompany reconciliation and settlements.
Virtual Trader - More Information
Virtual Trader populates tables on the client's or provider's machines, and provides comprehensive reporting and analytic tools. The attributes of the data are many: intercompany entities (legal owners), internal product lines and references, management organizations (responsible managers) and other client data. VT replicates some metadata on the VT database, in order to achieve best performance. VT offers a scalable integration module connecting the VT engine to various ERP or partner systems.
Matthias Sauer from Promatis and Jonathan Hart with Celantra participated with their multi-system integration approaches. The comparison and discussion was very interesting in respect of the spectrum, commonalities and differences between them. With external complexity and client standardization on the cloud boxes, FXLoader was able to focus on the data resolution in their engine, while Virtual Trader built resolution for internal complexity in metadata tables supporting their software. Both apps use the range of web services to process source data and to transport them to the target Cloud providers' databases, and where necessary to other Cloud services. Both use Cloud reporting tools to publish data.
We also discussed that multi-systems integration applications could even be used by our clients to develop and maintain EBS on-premise customizations separately. Quite an exciting thought! Further exploration could lead us to ways to escape the torturous upgrade purgatory of retrofitting all existing customizations. Can we figure out how to organize and provide customizations that can be connected both, multiple EBS on premise releases and even Cloud Fusion. To be continued urgently. Thank you, Seamus, for drafting this report.
