The views expressed in this blog and completely my own and do not reflect those of Beyond Systems Ltd. All content is provided for informational purposes only, and you are solely responsible for how you use this on your own or others systems. We accept no liability for any losses or damages caused.
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
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.
- Embedded PL/SQL Gateway (EPG)
- REST Listener
- Oracle Apache HTTP Server
- 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.
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.
- Application launched from a menu function within EBS (uses existing EBS session for authentication).
- Application has separate login but uses EBS credentials and API to authenticate.
- Application has seprate login (i.e. APEX user accounts) but queries EBS data.
|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.|
Once you start developing, be sure to check out my Best Practices blog.