Oracle Fusion Applications 101: Bye, Bye PL/SQL

Starting to get hands on with Oracle Fusion Applications (OFA), one of the first clear indications that OFA is a completely different beast compared to Oracle EBS is by looking at the amount of PL/SQL packages used in EBS 12.1.3 compared to OFA 11.1.1.5.1:

-- Oracle EBS 12.1.3 --

SELECT COUNT(*)

FROM DBA_OBJECTS

WHERE OBJECT_TYPE = 'PACKAGE BODY'

and owner not in ('SYS','SYSTEM');

COUNT(*)              

----------------------

47929    

-- Oracle Fusion 11.1.1.5.1 --

SELECT COUNT(*)

FROM DBA_OBJECTS

WHERE OBJECT_TYPE = 'PACKAGE BODY'

AND OWNER NOT IN ('SYS','SYSTEM');

COUNT(*)              

----------------------

3677

In EBS 12.1.3 the majority of Business Logic was developed in PL/SQL, either in server side Packages or contained in Forms and Reports native PL/SQL. Since 11.5.10 and the introduction of OAF, allot of new Business Logic has been developed in JAVA, contained in BC4J Entity, View and Application Module objects. With Fusion Applications, the entire product is developed as a Java Enterprise Application.

As we can see from the amount of PL/SQL packages, only a small amount of business logic runs outside of JAVA, predominantly in PL/SQL for more data-intensive tasks.

#OracleFusionApplicationLesson 1 for Oracle EBS Developers: Get your JAVA on!

Oracle EBS Customization and Extension - OAF vs ADF vs APEX vs Forms

The E-Business Suite Technology Group recently released a whitepaper: Extending E-Business Suite 12.1.3 using Oracle Application Express. In summary, "This new whitepaper outlines how to extend Oracle E-Business Suite 12.1.3 (and higher) functionality using Oracle Application Express. Recommended architecture and security considerations are discussed in detail." For some time now EBS customers have used APEX to extend EBS, with the release of this whitepaper the EBS Tech group has acknowledged it's growing use and have provide recommendations and guidelines for standardised integration.

What's this all about some might ask, is Oracle moving to incorporate APEX as part of the default EBS tech stack? What about OAF? Isn’t Fusion Applications build on ADF, so what's up? Well when it comes to Oracle EBS extension and customization, OAF is still top dog, the E-Business Suite Technology Group continues to recommend OAF for EBS extensions.

Without a doubt, ADF is the future, it’s a very powerful alternative to OAF, it provides an array of new functionality and is used to develop Oracle Fusion Applications. If you are planning a stand alone application, not requiring the tight integration provided with OAF, ADF would be an excellent choice. But where Oracle EBS R11.X and R12.X is concerned, it’s always recommendable to use a tool set that is part of the current tech stack and provides tight integration i.e. security, flexfields, personalization etc.

I have to come clean here, I have never been a supporter of using APEX to extend EBS, but I am glad to see the E-Business Suite Technology Group laying down some standards and guidelines. Whatever the motivation for choosing APEX, and in my experience it’s usually a OAF skills shortage problem, it’s good to know that Oracle is bringing some order to the current free for all approach to APEX extensions.

Forms? Dead, move on.

Although ADF is the future and APEX is now "supported", the Oracle EBS UI is and will continue to be developed using OAF, it’s powerful personalization and extension framework, plus transparent upgrades and seamless integration makes OAF the number one choice in EBS extension and customization.