When it comes to extending applications in the Oracle E-Business Suite Environment, EBS Developers and their managers have been presented with some difficult options over the years. To understand where they are coming from, you must go back to the beginnings of EBS Development.
Forms Development in E-Business Suite
EBS was originally put together with SQL*Forms, which was a far cry from any Application Development Framework we know today. Then came Oracle Forms 4.0, which was the first Oracle “Internet Computing” tool, around 1994. From that point on, EBS converted and expanded with this GUI tool. Every EBS customer still has Forms-based applications in their systems. As a matter of fact, some of the most popular EBS modules, such as G/L, Accounts Payable, and Accounts Receivable continue to be Forms-based. It’s probably one of the reasons Oracle, thankfully, is keeping Forms up to date. But, Forms is no longer the development platform of choice for the newer generations of EBS.
Towards Web-based development in E-Business Suite
The change from Forms-based development began when Oracle introduced a way to develop web pages in EBS. This came up in early 2000 with EBS version 11i (11.5.1). With the introduction of Oracle Application Framework (OAF). One of the first modules to have web pages was Self-Service Human Resources. Then, many others appeared, like iProcurement, iStore, etc. Thus, Oracle began veering development away from the PL/SQL Forms-based platform to the Java-based Platform that is OAF. Suddenly, many Forms programmers felt they had to learn Java and deal with Object-oriented instead of declarative development and PL/SQL.
Development using OAF
For example, when EBS R12 was first released in 2007, extending or modifying web pages would go through OAF, the application framework that runs E-BusinessSuite’s web-based content. It was extremely confusing. Having experienced it firsthand, I would even call it a horrible adventure.
First (this is still true), you need the right version of JDeveloper to match OAF in your EBS instance. OAF has its own special relationship with JDev! You may even have to downgrade your existing version since OAF was developed and remains with old Java versions. Then, developing in an object-oriented paradigm is quite different than the structured SQL and PL/SQL concept that Oracle database developers are used to.
I think these complexities are why I’ve not met many EBS developers using OAF on a regular basis.
Development with ADF
When the ADF framework became a recommended solution for EBS development, it was described as “an end-to-end development framework…offering unparalleled productivity to application developers”. More powerful than OAF, it enables you to build applications from scratch. Oracle actually used ADF to build Fusion Applications. But, I’ve often heard it has a very steep learning curve. As I’ve never worked with ADF, I can’t pass judgement on it, but no companies I’ve worked with have adopted it.
Interestingly, Oracle recommended ADF for things like “building a Mobile UI for EBS”, creating “a rich dashboard with lots of interactive graphs” or to build a system that “brings together data from both EBS as well as other sources of data”. These are all things that another application development platform can handle with ease.
Using Oracle Application Express (APEX)
If you’re not familiar with Oracle APEX at all, I recommend you start by reading this web page that explains APEX. Or this blog post on the 5 top questions people ask about APEX.
Oracle APEX is a Low-Code, Rapid Application Development framework that’s easy to learn and easy to work with. Since it is a no-cost feature of the Oracle Database, it can be used with no additional licencing fees.
It’s an Ideal tool to create Forms or EBS extensions like interactive reports, Forms, dashboards, etc. I’ll get more into detail on that in a later blog.
In APEX you can create responsive mobile applications as well. You can very easily consolidate your data from Excel spreadsheets or other sources to enable data validation, removal of multiple versions and increased safety.
APEX’s Interactive Reports allows users to customize reports on the fly, using real-time access to most any data they’d like.
What’s more, APEX is a declarative drag-and-drop development environment. It enables you to work very quickly and get down to the essentials of the business problem. Since you aren’t bogged down by the development and design processes, you can put together a proof of concept incredibly quickly.
The Proof of Concept
I’ve found the best way to get a prospective customer to understand the value of an APEX solution for E-Business Suite is to quickly provide a proof of concept. The same can apply to an EBS developer working with APEX and looking for project approval within his company.
I’ve presented proof of concepts to business Analysts and Functional Analysts. For example, when I’ve shown interactive reports, a reaction I often get is “That must have taken you a lot of time”. My answer is invariably “No.” I then explain that what takes up the most time is putting the SQL script together. That takes care of all the report parameters. Then, they just need to be fed.
Because SQL language is a native to the database and directly accesses it, clients can proceed to filter columns, create new ones etc., on the spot. There’s no other development needed as everything is there by default.
If there are adjustments, they are usually minor. In fact, they are more to optimize performance or to make the interface more user-friendly. But this requires little effort.
I find proofs of concept take away a lot of the need to explain, nuance, correcting perceptions and misunderstandings. It gives the solution credibility and fires up their imaginations on how they’ll be able to use it.
We can Help
Want to read more on APEX for EBS? How about learning the Top 5 reasons to use Oracle APEX to Build EBS Extensions?
Would you like to see APEX first hand? Do you have an E-Business Suite proof of concept you need to develop for a project? We’d be happy to help!