Experienced EBS developers around the world are figuring out how their work would change with a shift to Oracle Cloud ERP. In truth, the easier question to answer is, “What’s the same?”
Oracle never said they would start with a blank sheet of paper for Cloud ERP. After all, they had a well-developed ERP system already as a place to start. An experienced EBS developer looking at the schema for Cloud ERP will get some comfort from the familiar data model in most areas. In fact, HCM is the only module remarkably different from EBS, as it was adapted from Peoplesoft.
But everything else has changed!
This is a high-level overview of how the two different worlds compare for developers starting to work in the Cloud ERP.
Understanding the system
The general rule is: If it’s not broken, don’t touch it!
Being on-premise, the customer has a high degree of control over the environment; they can control the timing of patches, upgrades, testing, and any downtime. However, this is a double-edged sword. As a software company trying to support its installed base, More4apps has to support sites still on R11i. Our server room is stacked to the ceiling with variations of EBS from 11.5.9 to 12.2.10, and our EBS Wizards are full of branching code looking for various items in the database such as columns in tables and parameters in procedures so it knows how to deal with the instance correctly. Imagine how much more efficient your support could be from Oracle (and ISVs) if everyone used the same software version.
With a SaaS product, the serious issue of outdated, legacy software is a thing of the past. We know of huge organizations citing this as their most compelling reason to migrate to the new ERP system. Oracle updates the suite on a quarterly basis enabling organizations of all sizes to quickly and easily take advantage of innovations. But with Oracle also controlling the timing of all upgrades (which are mandatory), patches, and downtime, there is LITTLE flexibility for customers. Of course, organizations that depend on integrations with Cloud ERP for their business processes must re-test them every single quarter.
Getting data into the system
Because EBS was not designed as an internet-facing application, it lacks important security features, and therefore must be kept well hidden behind firewalls. Integrations with the system normally take place behind those firewalls.
A significant issue with EBS is its very limited connectivity options. Web services have only recently been appearing for EBS and are few in number. The main method employed by developers to get data into EBS has been to copy files to the servers and run processes to input them. This approach is considered clunky and inelegant by today’s standards. More4apps has chosen to build real-time access to the instance from the spreadsheet via a proprietary web service. This level of sophistication is unlikely to be achieved by in-house developers and has taken a team of experts many years to refine.
Cloud ERP on the other hand IS designed to face the internet, and because Oracle is hosting it, Oracle has full control over access. There is only one way for integration software to communicate with Oracle Cloud ERP, and that is via Oracle’s own published web services. There are TWO main types of web service:
- File transfer (via UCM application or web service)
- SOAP / REST services (the web service types used by More4apps in the newly released Cloud ERP Toolbox)
Oracle has always provided desktop integration platforms based on MS-Excel. For EBS, it is WebADI, and for Cloud ERP there is ADFdi and VBCS. Whilst these platforms have some benefits, they are quite limited. It is possible though for developers to create software that can communicate with SOAP/REST web services. Any software that can communicate with SOAP/REST web services can communicate with Oracle, provided the instance is visible to the calling software. More4apps’s newly-released ERP Cloud Toolbox is an example of this type of interface.
What these differences mean for developers:
- You can pull data OUT with a BI report but getting data IN is complex.
- Querying the data is almost impossible since you cannot easily see the table names.
- A large part of the investigation of web services is finding the role that grants the users access to it. Assigning too high a level privilege may give the user power to other areas outside of his or her jurisdiction. So, this needs to be 100% correct, which takes a considerable amount of time.
- Developers in Cloud ERP are required to develop integrations external to Oracle Cloud ERP. This requires significantly more resources to develop and maintain solutions for Oracle Cloud ERP.
- Within EBS, consultants could develop PL/SQL packages to adjust Oracle functionality to suit their needs, which would sit within EBS.
- With Oracle Cloud ERP, the solutions must be developed externally requiring different skill sets, significantly more development resources, and knowledge into specific frameworks.
- With Oracle EBS, developers can investigate the innerworkings, whereas Cloud developers have minimal internal access requiring reliance on functional knowledge and Oracle documentation.
If you are considering moving to Cloud ERP, there is much to consider on behalf of your development team. And whilst the environment can pose its challenges, there is a growing array of third-party providers whose work may provide a cost effective and straightforward solution to some common business process issues.