How to give multiple build options in Oracle apex

3
votes

I have two customers for our product which is developed using Oracle apex 4.2. (AU & US).

I would like to deploy same application in both of those regions but only the application features are different. it is like enable disable features.

For that i looked for Build Option provided by apex. then i created following build option,

  1. US_ready / Status: Include / Default on Export: Same as Current Status.

Questions,

  1. When deploying the application, can we set environment build option to one of above and execute the script. so that only the respective pages are added to the application .?

  2. In one page if we set build option {not US_ready} then it wont appear in runtime. is this correct ?

  3. What if we add more than 1 build options to the application ? How can we handle such situation ?

Thanks, Thusira.

1
oracleoracle-apex
I've got an application with similar requirements - it supports four different clients, and I wanted to switch components on/off independently for each. I found Apex's Build Options were too limited for this purpose. Instead, I set up an alternative system using application substitution strings, separate copies of the application for each client, and a custom import procedure for upgrades. I might write a blog article sometime about it. I like Tony's approach (below) though. – Jeffrey Kemp
Jeffrey , thanks for the input. Could you please tell me how we can use substitution strings in such place ? – Thusira Dissanayake
I'd set up an application substitution string which was then assigned to an application item by a computation on new instance. I can then refer to the application item via the normal means (e.g. :ITEM in Apex and v('ITEM') on the database). (I also copied it into an application context for use in views). – Jeffrey Kemp

1 Answers

4
votes

Yes you can have multiple build options, but each component may only be associated with a single build option. This means that you can certainly achieve your objectives, but perhaps differently from the way you had expected.

Suppose you have a page with 4 regions:

  • Region1
  • Region2
  • Region3
  • Region4

You want customer A to have only Region1 and Region2, customer B to have Region1 and Region3, Customer C to have Region3 and Region4:

  • Region1 (customers A and B)
  • Region2 (customer A only)
  • Region3 (customer B and C)
  • Region4 (customer C only)

This would require 4 build options, 1 for each "condition":

  • BO1 (which customers A and B will both have)
  • BO2 (which only customer A will have)
  • BO3 (which customers B and C will both have)
  • BO4 (which only customer C will have)

You would then assign the build options to the regions as follows:

  • Region1 = BO1
  • Region2 = BO2
  • Region3 = BO3
  • Region4 = BO4

To build customer A's application you would set BO1 and BO2 to "Include", BO3 and BO4 to "Exclude", and so on.

Of course, the names BO1, BO2 are unhelpful. Think of these as "features" that a customer may buy and name them more usefully e.g.

  • Costing
  • Planning
  • Monitoring

If a customer has paid for the "Monitoring" feature, then include the "Monitoring" build option, which will switch on the associated components (pages, regions, items, processes - whatever they may be).