Architectural Considerations for Integrating Oracle APEX Applications with E-Business Suite

Traditionally the development strategy for customisations within an organisation using Oracle E-Business Suite has been roughly the following.

• Data Entry – OA Framework or Oracle Forms
• Transactional Reporting – Oracle XMLP or Oracle Reports, FSG’s
• Ad/Hoc and Analytic – OBIEE or Discoverer

More and more organisations are now realising however the power of Oracle APEX to deliver all this and more within the low-code, highly capable framework. Beautiful, user-friendly, mobile-ready applications can be quickly delivered, fully integrated, secure, and scalable.

Standaone APEX developments are generally quite straightforward, however when building atop of an existing ERP environment there are several important considerations to make prior to beginning any development. If you are looking for how to technically do this then you should visit my other blog posts such as Extending E-Business Suite with Oracle Application Express (APEX) and Best Practices – Extending E-Business Suite with Oracle Application Express (APEX). In this post I will be concentrating on a higher level architectural view.

Doc ID 1306563.1 is an excellent whitepaper to use for detailed integration steps. This blog post is intended to summarise the information provided therein and build upon it from experience of the different deployments I’ve worked across different clients.

The first consideration to make is the APEX HTTP Listener configuration. Standalone you have three options.

1. Embedded PL/SQL Gateway (EPG)
2. REST Listener
3. Oracle Apache HTTP Server

The whitepaper available on Doc ID 1306563.1 mades various recommendations based on your architecture and E-Business Suite release, however a few important points to note.

• For R12.1 and above, using the Oracle HTTP server configured for E-Business Suite is not supported.
• For R12.2 it is not certified to install REST Data Services into the Oracle Weblogic Server(s) utilized by E-Business Suite.
• Use of the EPG is not supported for Production environments.

Next is the parsing schema for the applications. Whilst it is possible to set the parsing schema as Apps, and this would make development somewhat quicker, this is not a supported or suggested configuration. It is recommended to use a custom parsing schema with the appropriate grants (from apps) on objects required. Ideally, no direct table grants will be defined – instead, views should be created and granted, and any updates performed using custom packages which call the standard API’s or Instead Of triggers defined on the views if standard row processing functionality is to be used.

Finally, it must be decided how the application is going to be integrated with the ERP system. Generally this will be one of the following.

1. Application launched from a menu function within EBS (uses existing EBS session for authentication).
2. Application has separate login but uses EBS credentials and API to authenticate.
3. Application has seprate login (i.e. APEX user accounts) but queries EBS data.

Personally I would say option (2) is redundant because if you are using EBS credentials then there is no real reason not to just go with option (1). There are pro’s and con’s of each approach.

Menu within EBS	Separate login, EBS Credentials	Separate login and Credentials
All user management is undertaken within EBS.	All user management is undertaken within EBS.	Necessitates a separate user access management system.
Fully integrated experience for users.	Users may be reluctant to sign on multiple times.	Users need to remember and sysadmin need to maintain another account. If user uses only this application, their login isn’t recorded in EBS and thus account will look to be unused.
E-Business Suite context can be easily passed across.	E-Business Suite context not passed across. Can however be developed.	E-Business Sutie context cannot be used.
Can be difficult to manage multiple pages requiring different access levels within a single application. Often leads to multiple applications.	Must build authorisation into the application.	Standalone authorisation required.
Integration development is more difficult than standalone applications.	Easy to get develop.	Easy to develop however significant overhead in additional user management.

It is worth mentioning that just because a user isn’t logging into your application in options (2) and (3), that doesn’t mean you don’t need the appropriate licences. You should consult with your account manager prior to making any licencing decisions based on your architecture.

Once you start developing, be sure to check out my Best Practices blog.