Introduction
 | In the past year we have completed two large APEX projects with significant E-Business Suite integrations. These projects involved multiple developers, weekly sprint releases, ORDS REST services for native iOS applications, complex Oracle EBS integrations and multiple languages. Added to that, both systems had high visibility to the organization, and are being used by hundreds of users in over 40 locations across the US and Canada. In this post I want to focus on some of the features of APEX that helped make these projects successful and what it is about APEX that makes projects like this possible that just could not be done with other frameworks. |
Architecture
In order to understand the scope of the project, it may help to start with a quick overview of the application architecture.
ORDS and REST
As I mentioned above, we have an iOS App. This App is running outside the firewall, talking to the Oracle Database via ORDS and REST web services. The REST services are secured using OAUTH2. There is also an added layer of security which is that the web service must pass along an SSL certificate which the firewall validates to allow entry to the network.
APEX
As of the time of this Blog, the APEX users are inside the firewall but there are plans to externalize it. The APEX applications authenticate users using their EBS credentials. Functionality within the Apps (authorization) is governed by a user's access to EBS responsibilities and menu options.
Tomcat and ORDS
The https connection is terminated with Tomcat which has ORDS running as a container, handling all of the APEX and ORDS requests.
ORDS and REST
As I mentioned above, we have an iOS App. This App is running outside the firewall, talking to the Oracle Database via ORDS and REST web services. The REST services are secured using OAUTH2. There is also an added layer of security which is that the web service must pass along an SSL certificate which the firewall validates to allow entry to the network.
APEX
As of the time of this Blog, the APEX users are inside the firewall but there are plans to externalize it. The APEX applications authenticate users using their EBS credentials. Functionality within the Apps (authorization) is governed by a user's access to EBS responsibilities and menu options.
Tomcat and ORDS
The https connection is terminated with Tomcat which has ORDS running as a container, handling all of the APEX and ORDS requests.
Build Options
Now that I have set the scene, let's jump into the first feature that helped us out a lot. Both projects featured two-week sprints with the goal of delivering real functionality every two weeks. These sprints were feature-packed functionality bombs! Of course, not matter how hard we peddled, we did not always finish every feature by the end of every sprint. So, how do we handle deploying the App with pieces of incomplete functionality? This is where build options came to the rescue (Shared Components > Build Options). Build options allow you to tag APEX objects (menu options, pages, regions, buttons, fields etc.) with a specified build option. You can then toggle the build option on or off which in turn toggles on or off the related objects.
The killer feature here is that you can configure how the build option behaves when it is exported. This means you can have the build option turned on in DEV but have it automatically turned off when exporting the App for deployment to TEST and PROD. As long as you take care of your PL/SQL code also, your incomplete features can safely travel to the next instance safe in the knowledge that they will not be exposed to your users.
The killer feature here is that you can configure how the build option behaves when it is exported. This means you can have the build option turned on in DEV but have it automatically turned off when exporting the App for deployment to TEST and PROD. As long as you take care of your PL/SQL code also, your incomplete features can safely travel to the next instance safe in the knowledge that they will not be exposed to your users.
When you have completed the feature, and you are ready to deploy, you can simply delete the build option. It will be removed from all of the objects related to that build option.
Top Tip: You can also enable/disable build options using the PL/SQL API:
APEX_UTIL.SET_BUILD_OPTION_STATUS
Top Tip: You can also enable/disable build options using the PL/SQL API:
APEX_UTIL.SET_BUILD_OPTION_STATUS
Globalization
One of the aforementioned projects required translations for Spanish and French Canadian, the other just French Canadian. Translating web applications using APEX is not all that difficult. Having said that, translating an APEX application is not a decision you should take lightly.
Once you start translating an application, there are certain obligations you must fulfill over the life of that application. The initial translation of buttons, labels, regions headers etc. can be onerous but there are tools out there that make it manageable. What you need to be prepared for is that every time you change a button label, add a field, build a new page etc. you must translate all of these objects. Every change or new feature on your Sprint Board should come with a companion task to handle the translation to make sure you don't forget. Even if you decide to only translate certain pages, you must still perform the Seed and Publish step to ensure the translated 'Shadow Application' receives any code changes made to the primary application.
This may not seem like much of an advertisement for translating applications in APEX. Overall, however, APEX does a good job of handling translations and it is certainly far easier than managing this yourself.
Top Tip: Following best practices helps. If you routinely use APEX Text Messages instead of hard coding into your PL/SQL and JavaScript, then translation becomes a lot easier. All you have to do is create a version of the Text Message in the desired language and the code will pick it up.
Let's not forget the globalization tools that APEX provides, all of which would involve developing custom code on other platforms:
Feature Request for the Oracle APEX Development Team: A packaged translation application would be helpful. This App would allow you to pull everything that needs to be translated in a given App into the translation App. You could then assign translation tasks to different translators based on language. Those folks could then see what is left to translate, apply common translations (maybe even translations used in other Apps) and feed these translations back into the APEX App being translated. Something similar to https://www.xtra4o.eu/ but in the same APEX instance so you don't have to bother with XLIFF files etc.
Once you start translating an application, there are certain obligations you must fulfill over the life of that application. The initial translation of buttons, labels, regions headers etc. can be onerous but there are tools out there that make it manageable. What you need to be prepared for is that every time you change a button label, add a field, build a new page etc. you must translate all of these objects. Every change or new feature on your Sprint Board should come with a companion task to handle the translation to make sure you don't forget. Even if you decide to only translate certain pages, you must still perform the Seed and Publish step to ensure the translated 'Shadow Application' receives any code changes made to the primary application.
This may not seem like much of an advertisement for translating applications in APEX. Overall, however, APEX does a good job of handling translations and it is certainly far easier than managing this yourself.
Top Tip: Following best practices helps. If you routinely use APEX Text Messages instead of hard coding into your PL/SQL and JavaScript, then translation becomes a lot easier. All you have to do is create a version of the Text Message in the desired language and the code will pick it up.
Let's not forget the globalization tools that APEX provides, all of which would involve developing custom code on other platforms:
- Determining the user's language preference based on their browser settings.
- Getting the user's local time zone.
- Setting date and time formats based on the user's location.
Feature Request for the Oracle APEX Development Team: A packaged translation application would be helpful. This App would allow you to pull everything that needs to be translated in a given App into the translation App. You could then assign translation tasks to different translators based on language. Those folks could then see what is left to translate, apply common translations (maybe even translations used in other Apps) and feed these translations back into the APEX App being translated. Something similar to https://www.xtra4o.eu/ but in the same APEX instance so you don't have to bother with XLIFF files etc.
Feedback
The 'Feedback' feature of APEX seems pretty basic at first glance. In my experience, however, it is an essential tool in supporting APEX applications with large numbers of users. When a user submits feedback, not only does it store the user's entered problem description, it also sends a wealth of diagnostic information such as:
- The complete session state at the time the user submitted feedback.
- The user agent string (important for discovering the user's browser and OS).
- The problem information entered by the user.
Monitoring
When you have upwards of 500 hundred unique users and more than 30,000 page views per day, you need to stay ahead of errors and performance issues. The monitoring pages within the App Builder provide a wealth of information on the state of your APEX environment. If you only checked the 'Application Errors' and the 'By Weighted Page Performance' reports every day, you would learn a lot about how users are using your application (and what issues they are having). You would be surprised by the reaction you get when you reach out to a user asking them about an issue they were having with your App before they even reported it.
Feature Request for the APEX Development Team: Again, a packaged application would be very useful here. This would give customers the ability to give users access to monitoring functionality without also allowing them access to the APEX developer tools.
Conclusion
In this post, I have touched on four features that helped us scale APEX to over four hundred users across forty locations in two countries. I can't imagine the development and administrative effort we would have had to spend if any one of these features were not available. If you are not using these features then I strongly suggest you look into utilizing them in your projects today.
RSS Feed