Great questions! I see this done incorrectly all the time inside of Oracle. A person new to Application Express (APEX) will create an application or install a Productivity Application, run it, copy the full URL, and include the full URL in an email. I encountered this today in an email, for me to complete a Global Tax Survey via an APEX application (let the good times roll!). The URL provided was:
https://server/ords/f?p=23828:2:113570213685366:::::
Wow, that sure looks complex! However, it's unnecessarily complex.
The syntax for the entry points into the APEX engine is well documented. Interpreting the above URL and the colon-separated arguments, it means:
- 23828 - Application ID
- 2 - Page ID
- 113570213685366 - APEX Session ID
- ::::: - null values for the rest of the arguments in the URL
However, let's evaluate each one of these values in reverse order and assess their necessity:
- ::::: - Utterly not necessary. The argument values will default to null anyway.
- 113570213685366 - Also utterly not necessary. Assuming the application requires authentication, the APEX Session ID is specific to you, and only you, and only at a specific moment in time. You'll notice that if you give this URL to someone else, they'll be prompted to authenticate, and then get an entirely new APEX Session ID. Why include it if it's going to change anyway?
- 2 - There is a Home URL to every application, so if you're including the starting Page ID in the URL, then it's redundant to include the Page ID again. It's not necessary. Additionally, if this is not the same Page ID which is specified in the Home URL, and you have Deep Linking disabled (the default), your end users are going to end up accessing your application via the Home URL anyway. This is another reason not to include the Page ID in the URL which you share with others.
- 23828 - This is the only value that is absolutely necessary. This is the ID of the application you wish to share.
Thus, the URL that I received in email could have been provided simply as:
https://server/ords/f?p=23828
Great post Joel - I'm sure it will help many people.
ReplyDeleteMaybe an addition, if they specified an alias for their app, they could even share the app with the alias instead of the app id.
e.g. https://server/ords/f?p=GLOBAL_TAX_SURVEY
Hi Dimitri - thanks. I thought about including that. And for most cases, that should work fine. However, there is a fatal flaw with the alias implementation in APEX. If you're using a multitenant environment, someone else in a different workspace and use the same alias for their application, and now your URL with the alias no longer works (because it's not unique).
ReplyDeleteIt's one of those things that is always on the list to fix, but then something else usually takes higher priority.
Joel
Just need to specify the workspace, like this: https://apex.oracle.com/pls/apex/f?p=ZXCVBN&c=JK64
ReplyDeleteJeff,
ReplyDeleteRight. Thanks. And now we're back to a complex looking URL.
Joel
More important than aesthetics is that the URL is less likely to go out of date; I'm not intending to change my workspace; and the alias means I am not dependent on keeping the same application ID.
DeleteThis is web server specific, but if using Apache you could also make the starting URL friendlier by adding a redirect in the httpd.conf file (or better, in a separate apex.conf file).
ReplyDeleteIf you add the following
RedirectMatch ^/myapp/$ /ords/f?p=123
then users will be able to go to the app just by entering:
http://server/myapp
- Morten
+1 for Morten's reply. We put friendly URLs into our load balancer, that redirect to the proper URL. Much easier for people to remember.
ReplyDeleteCheers
Tim...
It is nice article. btw we can use mod_rewrite or urlfilter lib for makibg friendly url. It will boost seo also
ReplyDeleteHi Jeff,
ReplyDeleteAgreed, and excellent points. The alias is very much a "soft" reference and not tied to an application ID. Thanks for mentioning this.
Joel
It really doesn't matter at all, most users don't care, it's all Greek... So to speak, they simply look for the hyperlink, and 9/10 create their own shortcut in the browser. ... whole address discussion is a moot point.
ReplyDeleteWe use alias and we experience a lot of issues:
ReplyDelete1) Sometimes the developers set the same alias for different applications and both applications get unavailable.
2) When user access the url, Apex converts "f?p=app_alias" to "f?p=app_id". The user bookmarks the URL with the app_id. We change the version of the application, changing the app_id and keeping the app_alias. The user starts to access the bookmarked old version of application.
3) Sometimes we make old versions Unavailable and redirect to "f?p=app_alias". Some clients put urls in user tutorials like "f?p=123:12:12345678::::P12_EMP_ID:123" (we can't blame them) and when the Apex redirects, it loses the parameters.
Joel, please priorize the URL problems!
That's why I've been using an Apache (or any other web server) for a while. Like Morten Braten said, http://server/myapp is much easier to remember and type than anything f?p=....
ReplyDeleteAnd what Anderson Ferreira said is also true: the user will certainly bookmark the app_id instead of the app_alias because the URL will be converted on the first access.
Cheers
Another problem we get with the URL:
ReplyDelete4) When the developer export the app in an workspace and import in another, Apex keeps the alias and we have duplicated alias and unavailable applications