Documente Academic
Documente Profesional
Documente Cultură
Since returning from KScope14, I have been spending a great deal of time and effort examining any method of
truly integrating E-Business Suite 12.2.3 (EBS) and APEX 4.2.5 (APEX). I have read the Oracle white paper,
Extending Oracle E-Business Suite Release 12 using Oracle Application Express, and I realize this is the only
supported method. But, it feels incomplete to me...
Currently our users are logged in to APEX automatically when they choose an APEX app in EBS (version 11).
From a usability standpoint I do not want my users to have to re-login to APEX after logging in to EBS (version
12).
In the following series of posts, I will post the steps we took and the issues we ran into while developing our
solution.
Custom EBS 12.2.3 to APEX 4.2.5 Integration Part 1: The obligatory listing of caveats,
gotchas, and mumbo jumbo
This part is to introduce you to what we used and why we did it this
way.
Software Versions:
Oracle E-Business Suite 12.2.3
Oracle Application Express: 4.2.5.00.08
Glassfish Server: 4.0
Oracle REST Data Services: 2.0.8.163.10.40
General Approach:
Requirements:
Users cannot log directly into APEX for EBS integrating applications
APEX applications must be assigned to Responsibilities for inclusion in Menus for those responsibilities
not to individual users or a custom APEX Responsibility. For example, an HR APEX application should
be accessible from HR specific responsibilities only.
APEX access must work in a mix of environments SSL and non-SSL. For instance, EBS uses SSL but
APEX (being a non-externally facing application) is non-SSL
EBS to APEX must not pass anything user identifiable in the URL, including responsibility IDs
Each Responsibility group must not be able to access the other responsibilities applications. In other
words, HR should not be able to access Sales applications in APEX nor see any menu items for Sales
APEX applications
Caveats:
Our code is minimal in both commenting and error handling. This is done on purpose to make it easier
to understand and for quick adaptability into your environment (should you choose to use it).
Yes we use a customized jsp based on the GWY.jsp. In order to accomplish the requirement for working
in mixed SSL and non-SSL environments, we had to make a non-secure copy of the EBS session cookie
that could be read in non-SSL APEX pages. We know, we know... we really should be full SSL
everywhere, even if it's non-externally facing.
We also realize that this solution is not supported by Oracle and any function call we make today may
not work in the future. But how is this different from any other customization we have to make in
house? Every organization is different and has different needs. We make do with what we have.
We host several APEX instances on a single Glassfish server so urls contexts may seem a little strange.
I will post how we accomplished this at a later date.
The LAST and MOST IMPORTANT thing we have to mention. Using cookies means both servers
MUST BE ON THE SAME DOMAIN. This is a strict cookie and session management requirement set
in stone many, many years ago. So if your EBS server is at abc.def.com and APEX is at ghi.jkl.com, this
method will not work. Both servers must be on the .def.com or both on the .jkl.com domain. However,
that doesn't mean all is lost. My next project is to... well that's for another post ;)
For production you would only place in the non-running or Patch file system, then compile and
wait for a patch cycle to commit to the running file system. But in our test environment we place
in both file systems
For example:
<some path>/fs1/FMW_Home/Oracle_EBS-app1/applications/oacore/html
<some path>/fs2/FMW_Home/Oracle_EBS-app1/applications/oacore/html
For Example:
cd <some path>/fs1/FMW_Home/Oracle_EBS-app1/applications/oacore/html
$FND_TOP/patch/115/bin/ojspCompile.pl --compile -s 'ZEUS_LaunchApex.jsp' flush
cd <some path>/fs2/FMW_Home/Oracle_EBS-app1/applications/oacore/html
$FND_TOP/patch/115/bin/ojspCompile.pl --compile -s 'ZEUS_LaunchApex.jsp' --flush
Restarting Weblogic Server
admanagedsrvctl.sh stop oacore_server1
admanagedsrvctl.sh start oacore_server1
The Cookie Variables explained:
String ebsCookieName = "VIS"; - this is the name of the EBS cookie, there are several
articles on the internet that show you how to locate this value either in your browser or in your
database.
String apexCookieName = "VISAPEX"; - this is the name of the cookie for which APEX
will be looking in the browser. In the APEX application this is a substitution string setting (don't
forget to set it)
String apexPath = "/"; - another parameter that isn't required but could be set to an
undesirable value by your webserver due to any number of ways defaults/non set values are
handled, so explicitly setting is a good idea.
boolean isCookieSecure = false; - If both servers are using SSL, change this to true.
Otherwise leave alone.
Full listing for our LaunchApex.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%-/*===========================================================================+
|
|
|
+===========================================================================+
|
|
FILENAME
GWY.jsp
|
|
|
DESCRIPTION
|
|
|
DEPENDENCIES
|
|
HISTORY
01-AUG-2009
|
raghosh
created
+===========================================================================*/
--%>
<%@ page contentType="text/html;charset=windows-1252"%>
<%@ page import="java.util.Map"%>
<%@ page import="java.util.HashMap"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Oracle Applications External Gateway - Custom Launch Apex 20140801 - 5</title>
</head>
<body>
<%
while(paramNames.hasMoreElements()) {
String param = paramNames.nextElement();
String paramVal = request.getParameter(param);
if (!(paramVal == null || "".equals(paramVal)))
paramVal = paramVal.trim();
params.put(param, paramVal);
}
//if (debugMode) {
//
//
while (iter.hasNext()) {
//
//
out.println(String.valueOf(aPair.getKey()) + "=" +
String.valueOf(aPair.getValue()) + "<br>");
//
//}
// COOKIE VARIABLES
String ebsCookieName = "VIS";
String apexCookieName = "VISAPEX";
String apexDomain = ".YOURDOMAIN.com";
String apexPath = "/";
boolean isCookieSecure = false;
manager.doForward(params, false);
manager.releaseResources();
%>
</body>
</html>
Custom EBS 12.2.3 to APEX 4.2.5 Integration Part 3: EBS Function and Menu Setup
The following steps were done while logged into EBS with the System Administrator responsibility.
note: The System Administrator menus are used as references. The same techniques can be used to create menu
entries under other responsibilities as well.
Function Name
Description
Description - optional
Notes:
You can set up multiple Form Functions. We use one for each application. For example, HR and Sales
each have different Form Functions and menu entries.
On the APEX side we have completely separate applications for each group. Therefore we can
completely separate responsibilities and groups that are affected with changes in any applications.
Multiple APEX listeners, one Application Server using Oracle REST Data Services (ORDS)
Oracle REST Data Services (ORDS) gives us the capability us to deploy multiple versions of the APEX
listeners to a single Glassfish instance. This is great for centralizing resources on a single server in our nonproduction environments. This short post will show you how quick and painless it is to setup.
<some path>/apptest
<some path>/appdev
<some path>/apptest/ords_apptest.war
<some path>/appdev/ords_appdev.war
Run the war config process on each war using your specific setup info for each app
cd <some path>/apptest
cd <some path>/appdev
Configure the "Listener Administrator" user with your specific setup info for each app
cd <some path>/apptest
enter password
confirm password
cd <some path>/appdev
enter password
confirm password
cd <some path>/apptest
cd <some path>/appdev
ords_apptest.war
i_apptest.war
ords_appdev.war
i_appdev.war
Note: if you have already chosen /i/ as the images context during setup (instead of specifying /i_apptest/ or
/i_appdev/), run the reset_image_prefix.sql in <apex installation folder>/utilities and specify the correct context
for your image files. This might take some time to finish so be patient.
Conclusion
There you have it, a down and dirty, quick and easy setup of multiple listeners for your different APEX
installations on a single Glassfish install.
Create a view in your own schema that selects everything from the view in the apps schema.
We do that so that the views are a one-on-one mapping between schema's, but they show up in the APEX
wizards.
create view apex_per_people_vw as select * from apps.apex_per_people_vw
Create an Interactive Report on top of the view
This first examples shows how you can view data from EBS in your own APEX application. We can now create
a calendar, charts etc. in APEX based on the data coming from EBS. In the next post I will show how you can
edit this data.