Showing posts with label Build option. Show all posts
Showing posts with label Build option. Show all posts

Friday, January 23, 2015

Apex multilingual applications and build options

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

Just a quick reminder for those who are devoloping Apex multilingual applications:

Build options' state is propagated to translated applications at the time of seeding, so you need to be careful when changing the state of a build option in the primary language because you may end up with translated applications having a different build option state.

For example, say you have a "production" build option attached to an application process whose goal is to run some PL/SQL code only if the application is deployed in the production environment.
Of course at some point during development you need to verify it it works so you turn on the build option (state = "include"). You seed and publish your mapped applications in order to verify if it works also when the user changes language. Then you turn off the build option (state="exclude") but you forget to seed and publish again the translated applications.
The result is you end up with a mixed situation with the primary application having "production" off and translated applications with "production" on (or viceversa) and you are probably starting to see some odd behaviour when you change language.
Even worse if you seed and publish a subset of translated applications, the situation may become really confusing.

The rule of thumb when you change a build option's state in a multilingual application is to always seed and publish immediately all translated applications for consistency.

At any rate, you can quickly assess build option states for all the translated applications by running the following query as the schema owner (or sysdba):


select application_id, build_option_name, build_option_status 
  from apex_application_build_options
 where application_id in (select b.translated_application_id 
                            from apex_application_trans_map b 
                           where b.primary_application_id = :APPLICATION_ID
                             and b.workspace = :WORKSPACE)
    or application_id = :APPLICATION_ID
 order by build_option_name, application_id;
 
 
100 production Include
134 production Include
144 production Include 

I am not quite sure if this should be regarded more as a feature or as a problem, I could not really figure out a situation where you might actually desire to have a primary application whose build options' state needs to be different from the state of its translated counterparts.

Wednesday, February 16, 2011

Avoiding the flash chart security warning in Apex with EPG

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

If you host multiple web sites on the same apex server (using Apache as proxy and EPG) and some of these applications display flash charts, you might incur in the annoying problem of the security warning:


Flash Security Error:
AnyChart can not be launched due to Flash Security Settings violation.
Please refer to Security Error Article in AnyChart Documentation to fix this issue.
There are at least two possibilities to fix this problem (see at the bottom of this post for an interesting update):
1. as per AnyChart documentation, by placing a policy file placed in the domain root folder.
2. by replacing the substitution string #HOST# with a valid and stable URL prefix in the flash chart region source.

As i couldn't implement the first solution due to inexplicable problems with the cumbersome flash security settings, i was left alone with the other option. I always feel very frustrated when I can't get to the bottom of a problem but after spending four hours trying to figure out what the hell the flash player is expecting and without any evidence of progress, no matter how hard I tried, I simply gave up in favor of the second strategy, which took five minutes to be done.



What is happening is easily explained:
if you inspect the page source at run time, you'll find out that apex is replacing the string #HOST# with the values taken from a couple of CGI environment variables called 'HTTP_HOST' and 'SCRIPT_NAME':
BEGIN
dbms_output.put_line ( 'http://'
|| OWA_UTIL.get_cgi_env ('HTTP_HOST')
|| OWA_UTIL.get_cgi_env ('SCRIPT_NAME')
|| '/');
END;
Unfortunately the content of these variables change with the http access conditions.
For instance in my case there is Apache acting as proxy server and I get different values depending on whether I access the site through the proxy server at port 80 or directly through port 8080. In the former case HTTP_HOST will contain 127.0.0.1:8080, in the latter www.somedomain.com:8080.
In other words, if I access the page containing the flash chart via apache I'll get the flash security message otherwise it will work correctly.

As the correct way of accessing the apex page for the end-user is via the proxy server on port 80, the valid and stable URL prefix that I need to specify in the apex chart region source is http://www.somedomain.com/apex matching the URL prefix of the page being displayed in production.

So one might be tempted to hard-code the URL in the chart source region but this not an ideal choice for a variety of reasons, starting from the fact that in this fashion our application won't display the charts in our test or development environment because the chart source region will refer to the production site.
My solution is to create an application item called BASE_URL that is initialized with the right URL basing on the setting of a build option. As i am already used to have a PRODUCTION build option in all applications enabling certain features like visitor tracking and google ads when its status is include, I simply created a couple of mutually exclusive application computations that run "on new instance" and update the value of BASE_URL with the static value http://www.somedomain.com/apex when PRODUCTION's status is include or the PL/SQL expression
'http://' || owa_util.get_cgi_env('HTTP_HOST') || owa_util.get_cgi_env('SCRIPT_NAME') || '/'

when the status is exclude.

May be this is not the panacea for all possible situations, but it worked out pretty well until now and it doesn't even require any action on your part if you chose "include" as default value on export for the build option.

Updated February 16 after David's comment
While i was writing this posting I was thinking of doing a little modification in my Apache server configuration, then I published the article without doing the test first. David's comment reminded me that I still had to do that task to complete my job.
I modified the configuration of Apache where it is instructed to forward the requests received against apex on to IP 127.0.0.1:8080, a typical configuration that you will find in several examples in the Apex OTN forum.
# previous config
# ProxyPass http://127.0.0.1:8080/apex
# ProxyPassReverse http://127.0.0.1:8080/apex

# new config
ProxyPass http://www.somedomain.com:8080/apex
ProxyPassReverse http://www.somedomain.com:8080/apex
Then i reverted the chart region source to its original version with the #HOST# string and to my surprise the chart was displayed without reporting the "infamous" security message.
As a further step I also added the web domain to /etc/hosts as an alias for 127.0.0.1 just to avoid some unnecessary roundtrip between the DNS server and the web server.

In the end, it looks like we can work around the problem by manipulating Apache's configuration and without the need of crossdomain.xml or changes in chart source regions, at least for "simple" architectures like this.

Tuesday, May 12, 2009

A view for tracking build options usage in Apex

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

Did you ever need to find out where a certain build option was specified inside an apex application?

Build options are a useful feature of Oracle Application Express that allows a developer to enable or disable certain functions or components by simply changing the value of the associated flag (Include/Exclude).
In other words build options allow you change the configuration of an application without modifying the metadata.

Unfortunately, unlike other components, Apex doesn't help much the developer with a report on the usage of build options throughout the application and given their ubiquity it is really useful to run a single query that summarizes the information.

Follow the link to download the source code of APX_BUILD_OPTION_USAGE view.


While testing the view i realized also that there was a bug in view APEX_APPLICATION_PAGE_REGIONS.
In the picture above, all page regions build options are reported as {Not production}, but the real build option value is Production.
After checking the source code of the view i can confirm that BUILD_OPTION is returning the wrong value owing to a mistake in a subquery, so in the particular case of this view you should consider only the presence of the build option name, not its reported inclusion or exclusion.
This bug affects Apex 3.2, 3.1.2 and probably earlier versions.

See more articles about Oracle Application Express or download tools and utilities.

yes you can!

Two great ways to help us out with a minimal effort. Click on the Google Plus +1 button above or...
We appreciate your support!

latest articles