Thanks Patrick and Scott, great information guys.

I am a big believer in getting the initial design right first time, which is allot easier than trying to fix or institute change once it had gone live.

Now I am sorry I did not ask this question earlier!

Fortunately we have not gone live on our APEX installation yet, but the deadline is creeping up fast.

Hi Patrick,

1)     I’ve read up and started playing with the subscription functionality. I am running some tests to check some of my assumptions, but would like to ask:

In our TEST and PROD environments we (developers) don’t access to the APEX admin webpages, for that matter the web admin component is not even installed in TEST/PROD APEX envs. We deploy any new APEX applications, files, templates, layouts etc. using the export functionality and then have our DBAs apply new code changes using SQL/PLUS.

My concerns with the push/pulls are for example is if we make changes to the templates in the master application and then push those changes to the subscriber application in DEV. For deployment to TEST/PROD do I then have to export ALL the applications that had subscribed to the master application and have those reapplied, or just the master application?

2)     Regarding your Login/Authentication suggestions:

Great information, thank you and I will surely be following your suggestions regarding having a master application house the LOGIN logic too (though I may have to phase that in).

I would like to elaborate a bit about our own implementation. I guess I am not really asking a question here, maybe just to elicits some comments or maybe it helps someone else who stumbles on this thread.

Our APEX solution is only going to be used from the Oracle eBusiness Suit (R11 and R12). Never externally. However for some of the applications we may allow users to directly access APEX via direct URL, other applications we may block that functionality. EBS security is tightly coupled with the EBS security views and tied to user responsibilities (all setup in EBS). At a very high level the authentication model I had created allows for single sign-on (without using Oracle SSO) from Oracle eBusiness to our APEX applications. I created OA framework based JSP pages that securely passes user id (and other EBS session information) between EBS and APEX. Authentication from EBS is then accomplished by generating a secure password and secure (MD5 based) session hash (the hash also has a time component, so it’s only valid for brief period of time). Direct URL access to APEX would directly authenticate users using the EBS user name/password. Also worth mentioning is that I had run into some challenges where the EBS application was in one domain and the APEX application in another (but that’s a whole different conversation). So in summary I very much followed a similar approach suggested by various people in these forums, I believe you had even answered a couple related questions for me (much appreciated).

I think you may see where I am going with this. So access to any new APEX applications are governed by their EBS responsibilities (and EBS security). Each new apex “application” we write can only be accessed by users with specific responsibilities – security is maintained exactly like how you would limit access to forms/reports and other EBS applications via the menus. EBS also utilizes secure VIEWS, so with every APEX page hit we ensure that the EBS security session information is set (if for some strange reason fnd_gloabls is not set the user gets kicked out to a login screen). Having the EBS fnd_global set ensure that every user is also restricted as to what data they can query. My security concern with having only a few “large” APEX applications (example one for HR, OAB, Finance etc) and then deploying “applications” to it as sets of pages inside the larger APEX application is that users could easily manipulate the APEX URL to gain access to pages that they should not have access to.

I actually quite like the way we have it currently. If a user hits any APEX application/page the single sign on information gets passed to it. If they don’t have the correct authentication credentials and responsibility they are kicked back to a login screen allowing them to authenticate. Even if they have the correct credentials/responsibility data access is still limited by VIEWS as per EBS security (fnd_globals). So security is pretty tight.

The downside is we’ll end up with smaller APEX applications, and as you pointed out this makes maintaining all of them a bit more challenging.

Setting up a master application for templates, authentication etc. will greatly reduce this overhead.

Further, I could use my single sign on model to allow users to seamlessly call APEX applications from one another that would re-authenticate and set their EBS security without user input (if their session is still active). Maybe that’s a bit clunky, but I see no reason why it would not work.

I guess the question is larger APEX applications with more pages inside them vs. more APEX applications with fewer pages in them.

Edited by: attis on Mar 22, 2012 9:16 AM

Hi Luis, I have not found a good answer to that concern I had raised. But if you had, it would be great to hear :)

With my own testing I have pretty much concluded that if we make a change in our development environment to the “master” application that houses the templates that we then have to manually push the changes into the subscribed applications. Next, when we promote the changes to TEST/PROD not only do we have to export and promote the master application but also all the subscribers. Else, the changes simply won’t move.

I have resigned myself to the fact that this is what we’ll have to do.

The whole subscribe push/pull architecture seems to imply that each applications metadata is independent of the other.

I can very much understand that designing the whole code promotion architecture (DEV -> TEST -> PROD) was quite a challenge. The more tightly they connect various applications metadata dependencies to each another, the trickier it gets allowing code promotion of individual applications.

Maybe this was a tradeoff.

The more I get to learn about APEX, the more it seems the general idea is that you would have fewer applications that each houses many pages, rather than many applications with a few pages :)

Fewer applications mitigate the issue somewhat.

What I don’t like about the concept of fewer applications (more pages) is that if a developer makes changes to only one page that it looks like you have to export the whole application and reimport it into other environments to promote the change (reminds me of J2EE deployments). Nothing wrong with this, I am just saying that the way we are using APEX that I am not fond of the idea.

I am probably still going to stick with more smaller applications and deal with the challenges associated with that like shared components, or having to publish changes to the subscribers. I think once we have our templates and layouts nailed down, it would a rare change. However development of more “smaller” applications would be an ongoing thing. Even though APEX has great team-development/admin tools that can help pinpoint developer code changes, I would hate to see unintentional changes to an old piece of code get promoted to production accidentally. This seems easier to happen with the fewer applications but with more pages approach.

This is just my current opinion, I am not an expert :) I think every APEX implementation is quite unique depending on how a company chooses to use APEX. That’s really the beauty of it too IMO. I very much like the refreshing different lightweight approach APEX has taken to web development compared to say J2EE - though they are very different animals.