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.
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.
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.
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.
Top Tip: You can also enable/disable build options using the PL/SQL API:
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.
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.
- 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.