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

• EBS

  Oracle EBS gives developers a high level of access to the database. Developers can create not only their own packages and procedures to support their integrations but also database objects such as tables and views.  (At More4apps we have created our own web service which EBS customers install on their mid-tier to support our integration software.)

  

  Oracle packages such as APIs are visible and accessible to developers, enabling us to easily inspect them and understand the business rules in the application.  Reading a SQL statement in an API is a great way of finding out why a particular rejection occurs! As a developer, this is often the only way to learn properly about how to use an API.  Oracle’s own system documentation of the APIs mostly consists of a simple list of parameters presented in a PDF!  Sample code calling the APIs is very rare and seldom updated for new releases.

• Cloud ERP

  In the new system, instead of seeing all the ingredients, we can only see the “packaging”

  In the new system, instead of seeing all the ingredients, we can only see the “packaging”.  The Cloud ERP environment allows no visibility inside the application, so our ability to “dig into the forms” to view logic and SQL does not exist. Getting lists of values and business logic requires far more investigation and analysis just to understand the system. As for documentation, the PDF has been replaced with web pages listing the web services.  This is not a great improvement, but at least there are sample payloads and responses.  Release documentation describing changes is a vast improvement over EBS.

• Commonalities

  Database tables and views are visible in both ERP systems.  In EBS you can use TOAD or SQL Developer.  In Cloud ERP you can use the BI report editor. SoapUI and Postman are great environments for working with SOAP and REST web services.

Upgrades

• EBS

  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.

• Cloud ERP

  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

• EBS

  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

  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:

  1. File transfer (via UCM application or web service)
  2. SOAP / REST services (the web service types used by More4apps in the newly released Cloud ERP Toolbox)

• Commonalities

  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:

1. You can pull data OUT with a BI report but getting data IN is complex.
2. Querying the data is almost impossible since you cannot easily see the table names.
3. 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.
4. 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.

×