This discussion is archived
12 Replies Latest reply: Apr 12, 2012 11:31 AM by tc*441059*in RSS

APEX Limitation: Sharing pages across multiple APEX applications

attis Newbie
Currently Being Moderated
I was hoping if someone with a bit more APEX architect experience could comment on some of the limitations I am seeing and if I am making good decisions working around the problem.

Any suggestions are most welcome.

One limitation I have seen is how APEX handles applications and pages. Each application seems like an island, it has its own set of pages, login processes, templates, CSS, JS references etc. As for CSS and Javascript you can have it defined in a central location, but each new APEX application developed still has to be configured to make use of your “standard”.

More traditional web solutions view each web page as standalone and any web page can call/reference any other page and pass session information between them.

However with APEX this does not seem to be the case.

One solution would be to simply have one huge APEX application, where all the pages are owned by this single application.

Unfortunately, we use APEX and EBS R11 (& R12) together; all APEX applications are started from the EBS menus. I had designed a single sign on solution between the two (without using oracle SSO). However each APEX application is unique, like little modules rather than full applications. In other words, we tend to use APEX as an alternative for Oracle Forms - each APEX application being a standalone program.

Still I wanted to be able to enforce the same login process and look & feel across all new APEX application that we write.

So the way I went about it was meticulously creating a “template” APEX application. Imbedded in this template application are all our shared CSS, JS and templates that enforce website look and feel. It also contains our custom library single sign on code and custom debug logger (think log4j but for APEX).

So whenever a developer starts work on a new APEX application, they start by cloning the template and automatically inherit all the functionally and website look and feel.

My concern is if this is really the best way of doing it, or if I am missing something?

I also worry going forward that whenever I want to institute look and feel change across all our web applications that I have to touch each and every APEX application since inception. I am trying to mitigate this by ensuring that nearly all the programming logic is contained in PL/SQL packages, and that the CSS and Javascript are external to the APEX application and only referenced. But this still does not help with templates, or with logic that is imbedded in the actual APEX pages etc.

At least APEX allows you to easily enough copy pages between applications, but this simply does not compare to have a single page shared between all APEX applications.

Is there a better way of going about this?
  • 1. Re: APEX Limitation: Sharing pages across multiple APEX applications
    Sc0tt Expert
    Currently Being Moderated
    The best way is to use the subscription functionality to create a "master" application that contains all of your templates. Create a 2nd application that "subscribes" to the master's theme/templates. Whenever you create a new application, just create a copy based on the subscription app, and the subscriptions should carry through.

    Then just update the master application and publish the changes. All subscribing templates automatically pick up the new changes.

    I think it was detailed in John Scott's Apex book from a few years ago, and I used it for a few apps and it worked nicely. You can read the guides for more info about how to do subscriptions.
  • 2. Re: APEX Limitation: Sharing pages across multiple APEX applications
    Patrick Wolf Employee ACE
    Currently Being Moderated
    Hi attis,

    I think you can't really compare a Forms module with an APEX application. I would not suggest to create an APEX application each time when you would have created a Forms module in the past.
    A Forms module just correlates to a few pages in an APEX application. So you should definitely have more then a few pages in an APEX application. But granted, one huge application is also not the way to go, but I would group them for example by logical areas like HR, logistics, ordering, ...

    As Sc0tt already mentioned you should use the "Subscribe" mechanism of shared components to make it easier to refresh all of your applications with template updates. But there is more, you should also share your login and just have it in one place and use the "simple APEX based SSO" which allows that all applications within a workspace can share the same session. You just have to set the same "Cookie Name" in your authentication for all your applications and when you link from one application to another and include a valid session id you will not be required to login again and you are also able to set session state in that other application.

    So here is what I would do

    1) Create a master application which contains
    a) your theme and other shared components which you want to share
    b) It should also have some base navigation lists to navigate between your applications, ...
    c) create an authentication with the name "Redirect to main login app" and type APEX accounts (it doesn't really matter) where you set the "Cookie Name" to "MySSO" and the invalid session URL to the login page of your to be created "Main login app". For example: f?p=9999:101:&SESSION.

    2) Create a template application which is a copy of the master application but where you change the "Subscription" of all your templates, authentication scheme and shared components to the master application. This will be used by your App developers if they want to create a new application.

    3) Create your "Main login app" (eg. app id 9999) by
    a) copying your new template application
    b) delete the authentication scheme in it (this is just done for this main login app)
    c) create a new one of the type you want to use. But important: Set the "Cookie Name" to "MySSO". This will make sure that all applications have the same session cookie.
    d) if you use APEX 4.1.1 you will automatically be redirected to the calling application after successful login.

    4) Start creating new applications by copying your "template" application which contains all the subscriptions.

    5) If you run that app, it will automatically redirect to your main login app if the current session is not valid. This will avoid that you have the same authentication logic in all your apps.

    6) If you have to modify your templates or shared components you just have to do that in the "master" application and click the "Publish" button to push the changes to all your applications.

    But still, try to avoid to many small applications, I think that will make the handling just unnecessary complicated. It's fine that an APEX app has a few hundred pages. For example our APEX Builder app (app 4000) has more than 1260 pages.

    Regards
    Patrick
    -----------
    My Blog: http://www.inside-oracle-apex.com
    APEX Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf
  • 3. Re: APEX Limitation: Sharing pages across multiple APEX applications
    attis Newbie
    Currently Being Moderated
    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.
  • 4. Re: APEX Limitation: Sharing pages across multiple APEX applications
    bjarkekr Newbie
    Currently Being Moderated
    Patrick> Any reason not to create one huge apex application?

    Im right now working on an application with more than 600 pages and I dont see any problems with that yet?
  • 5. Re: APEX Limitation: Sharing pages across multiple APEX applications
    Patrick Wolf Employee ACE
    Currently Being Moderated
    Hi attis,

    it might also be a good idea to get one of the top known APEX gurus as a consultent for a few hours to discuss and review this topic with you. As you said, it's important architectural work and you definitely benefit in your long term development.

    Regards
    Patrick
    -----------
    My Blog: http://www.inside-oracle-apex.com
    APEX Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf
  • 6. Re: APEX Limitation: Sharing pages across multiple APEX applications
    Patrick Wolf Employee ACE
    Currently Being Moderated
    Hi bjarkekr,

    there is no limit within APEX which restricts you on the number of pages. A reason to have smaller junks could be project management reasons to have independent release and deployment cycles for different parts of your application. If you having one huge application you have to coordinate all your different development teams to agree to the same milestones because you don't want to get untested or unfinished code if you have to deploy everything as one application. If you split up your application into applications for the different areas you are more independent. But as I said, it's really a management/project management issue and not a technical restriction.

    Regards
    Patrick
    -----------
    My Blog: http://www.inside-oracle-apex.com
    APEX Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf
  • 7. Re: APEX Limitation: Sharing pages across multiple APEX applications
    attis Newbie
    Currently Being Moderated
    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
  • 8. Re: APEX Limitation: Sharing pages across multiple APEX applications
    RodWest Guru
    Currently Being Moderated
    Hi Attis,

    Getting the architecture right is important to ensure you have a secure Apex/EBS solution. I have run Apex on EBS installations for about 5 years now and here are my (two cents worth of) suggestions:

    1. You definitely should install Apex as runtime only on TEST and PROD. It is also worth granting APEX_ADMINISTRATOR_ROLE to APPS then you can run all you Apex installation scripts on production as the APPS user.

    2. Your Apex workspace should not be associated with the APPS schema. Giving Apex access to the APPS schema opens up all the EBS APIs to the Apex processes. It more secure to create your own schema e.g. APPS_APEX and use this as the parsing schema. This schema does not need to have any privileges and can be a locked account. You then grant access on APPS objects to this schema as needed by the Apex applications.

    3. It is a good idea to create a single Apex logon application which authenticates the EBS users. You can then redirect to other Apex applications using a shared cookie. How many Apex applications you use is really down to whether you want have one or more developent cycles, similar security, look and feel etc. Generating a secure passward and securing other data with the MD5 function is safe provided that the key you use in the MD5 function is secure and changed regularly.

    4. The Apex application should access all the EBS data through views and that data security is built into these views. If the user manipulates the URL it is these views that should ultimately stop the user seeing any restricted data. You can use the EBS secure views but in my experience they are designed for the single session forms environment and do not perform well in, for example, an Apex reporting application. Initialising fnd_globals for every page is also quite an overhead and is prone to errors because depending on the responsibility it will initialise other application packages and run custom initialisations. We have implemented are own secure views using a VPD policy based on the EBS contexts. This was quite easy to do and performs well.

    5. It is useful to set up authorisation schemes that are based on EBS responsibilities. You can then easily implement give users access to different parts of the application based on the current responsibility.

    6. If users are logging into the Apex applications with different responsibilities then you need to remember that, by default, user preferences (eg. report sorting) and saved interactive reports are stored against the user. Hence if the user is seeing different data because of the change in responsibility then some things may not work.

    7. Finally you need remember that although the users logging once with SSO the EBS and Apex have different sessions with potentially different timeouts. So unless you implement a single sign off then users can get confused if they then logoff in Apex or EBS and find that the other applcation is still active.

    There are lots of options, what's best depends on exactly what you want to do.
    Rod West
  • 9. Re: APEX Limitation: Sharing pages across multiple APEX applications
    bjarkekr Newbie
    Currently Being Moderated
    Thanks Patrick

    That was what I thought. Just wanted to be sure that I had not missed anything :)

    On this project we are only 2 developers, so its possible to manage a release.
  • 10. Re: APEX Limitation: Sharing pages across multiple APEX applications
    Luis Cabral Pro
    Currently Being Moderated
    Sorry, I have nothing to add to this thread but I wanted to bump it because I am very much interested on the answer for this question:
    attis wrote:
    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?
    That is a very interesting question, and based on some basic tests I've done, it seems that subscriptions are lost when you export applications to other environments.

    In other words, if you change your "master" application templates and publish the changes to the subscribed applications, the only way to deploy those changes to another environment seems to be to deploy each subscribed application individually.

    Any clarification on this would be great!

    Thanks
    Luis
  • 11. Re: APEX Limitation: Sharing pages across multiple APEX applications
    attis Newbie
    Currently Being Moderated
    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.
  • 12. Re: APEX Limitation: Sharing pages across multiple APEX applications
    tc*441059*in Newbie
    Currently Being Moderated
    Depending on the number of changes that you've done you can always use the component export to promote changes from one environment to another. Whenever I update a small handful of pages, breadcrumbs, lists, templates, etc. I just use the component export to push them to production. This is easier and faster and generally more efficient than doing the whole application. The one caveat to this is that the last updated recognition for list updates doesn't always work, so you'll want to make sure that you capture any lists that you've updated and not rely on the last updated date in this case.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points