It is a fact that all the organizations running On Premise (like Oracle EBS) or SaaS Enterprise Solutions (like Oracle ERP Cloud) need customizations, extensions, and integrations as part of the implementation. When you calculate the ROI of a customization today, in your on-prem solution with a mostly possible journey to the cloud you might consider stranded costs due to the change in the technology.
Here’s a quick tip to get a better ROI, by allowing you to keep your customizations investment, even when you migrate to Oracle Cloud SaaS.
There are multiple options that would allow you to build this strategy, one of the options is Oracle APEX application development tool. We’ll present in the post to help you move forward with a sustainable development strategy.
Oracle Application Express
Oracle Application Express (APEX) is a rapid application development tool that can be used to create complete back-office, front-end, and mobile applications. Originally launched in 2004 with a different name, it has been evolving year after year becoming one of the strongest in the market.
Oracle APEX can be installed On Premise on an Oracle database (even on the database that supports your Oracle Applications) and can also be used as an Oracle Platform as a Service.
Oracle Application Express doesn’t require very extensive development skills and leverages existing knowledge your organization may have in-house such as Oracle PL/SQL, HTML, and JavaScript.
When talking about application extension development, Oracle APEX is an ideal tool to bridge the gap between On Premise and SaaS, due to its intuitive developer experience, page design and powerful components.
We want to make use of extensions built today, that in the near future when the move to Oracle Cloud SaaS is executed with minimal work on the Oracle APEX version (that can remain in on-premises or cloud) will guarantee that the customizations will still be functioning.
At the moment of writing this article, Oracle Apex version 19.2 is the most current version and it requires Oracle database 11.2.0.4
Although Oracle APEX can be installed on the Oracle Applications database, product version dependencies may be an obstacle to installing the latest versions, so installing APEX on a separate database can be the best option.
Oracle APEX Benefits
Oracle Application Express (APEX) to EBS integration
Oracle APEX can access Oracle Applications database data directly if installed on the same database, or through alternative procedures like database links if installed on separate databases. But despite that, we want to implement a method to read and write data that will still work when we migrate to SaaS.
Web-Services are a good way of doing that as they are platform agnostic and can be deployed On Premise and in the Cloud. Web-Services are available on the Oracle Applications as part of the Oracle Integration Repository or can be developed to provide special functions that are not available on standard Web-Services.
Working with Web-Services to read and write Oracle Applications data is certainly more complex than executing simple SQL commands but the fact that this will allow us to preserve customizations when we migrate can make it worth the effort.
Oracle Integration Repository
Oracle Integration Repository (OIR) is a compilation of numerous interface endpoints exposed by Oracle Applications which provides a complete catalog of Oracle E-Business Suite’s business interfaces and a comprehensive view of all the interface mechanisms available.
As part of those interface mechanisms, OIR lists all the Web-Services available and provides functions to deploy them so you can start using them. These are Web-Services that come pre-packaged with the application and require no additional coding to work with.
Creating Additional Custom Web Services
Leveraging standard Web-Services bundled with the application will always be our first choice but we may also need to create new services to provide special features or return special values not included in the payload (parameters) of any of the standard Web-Services.
There are many different tools available to create Web-Services, like Java of course, but Oracle APEX can also be used to easily publish information as a Web-Service just be writing a special kind of APEX report.
This means that by installing Oracle APEX (even old versions like APEX 4 or 5) on the E-Business Suite database we will be able to generate Web-Services to publish data than can be consumed by our external APEX environment.
This approach has the advantage of reusing knowledge of the Oracle APEX tool so that you don’t need to learn about a new development framework to create the Web-Services.
Suggested Architecture for On-Premise Application Extension Development
The following diagram summarizes the architecture suggested based on the concepts discussed so far:
(Please note it is beyond the objectives of this analysis to focus on the different available Oracle APEX configurations to support secure access from outside the VPN)
The EBS database holds the schemas for the standard data model (the data that supports the application modules) plus additional schemas created to hold custom database objects.
Data in the standard data model is published by Web-Services generated from Integration Repository, while data from the custom schemas is published by Web-Services generated from the Oracle APEX environment installed on the EBS database.
The external Oracle APEX environment installed in a current version of the database holds the application extensions and integrates with EBS through the Web-Services published from that database.
Migrating to SaaS and PaaS
When the On-Premise E-Business Suite is decommissioned and the Oracle Cloud SaaS application is rolled out, extensions built on the external Oracle APEX environment are modified to work with the standard Web-Services available on Oracle Cloud SaaS application.
This can be an easy job to do if we built services in our On Premise EBS that resemble the services available on SaaS.
The Oracle Fusion application documentation provides extensive information about the services available and their payloads and business rules enforced, so this behavior can be built into the services we build while still on the On Premise model.
Although this strategy will allow you to preserve your application extensions when you move to a cloud application its complexity deserves a complete analysis of the pros and cons before taking the decision to implement it.
The additional effort required to access data through web services and the need to modify/test the extensions when moving to the cloud have to be evaluated and compared to the effort required to re-build the extensions when you’re already on the Oracle Cloud SaaS application.
Among other items to evaluate, you will want to consider the following circumstances:
- When you move to Oracle Cloud SaaS you will have to build your extensions on the PaaS model as that’s the only way to extend a SaaS application. So you will reuse a good portion of the code built today while still with your EBS On Prem.
- If the extensions to be built make a separate system or satellite module, then the number of functions to build may make it worth the effort to follow this strategy given the volume of code that will be built and will be able to be reused even when adjustments will be required.
- Even when current extension requirements may be limited, the fact that you still do not know when you will move to the cloud indicate that more and more extension requirements will come up over time. So the sooner you implement a preservation strategy, the better.