APEX 4.2.5: Standards Tracker

I blogged about the Application Standards Tracker packaged application when it was initially released with APEX 4.2.4. Doing so, however, reminded me of several limitations that I knew existed–I was there from its creation, after all–but had been willing to put up with for the first pass. And, well, we couldn’t let it stand at that, so we took some time and made it better. You’re welcome. 😉

The core idea of the application is the same as before: “since APEX applications are all built/driven off of the metadata in the database–and since that metadata is exposed in the APEX Data Dictionary views–we can check that metadata for potential issues.” But we weren’t happy about how all of the automated tests were simple “Pass/Fail”–either the application totally met the requirements of the test, or there was something wrong, somewhere, but it was up to you to go find it. So we introduced a new “Report” type of automated test (and made it the default, though you can still use a pass/fail test if that’s what makes sense). The SQL for Report automated tests is mostly flexible, allowing you to include whatever information you feel is necessary/helpful in determining what needs to be fixed, but there are two requirements:

  1. The first column must be a Y/N value to indicate whether the test is passed by that particular component.
  2. The second column should be the ID of the component in the application (and is not displayed to the user).

The reason for this second requirement is to enable the main new functionality of the application: you can now view the report of all of the components that are tested, and if you’ve got an active developer session in the APEX Builder, you’ll be presented with edit links which will take you directly to the relevant component.


A common issue is to have a page item that has help text, but which doesn’t use an item label template that exposes the help to the user. You can find these using the data dictionary, looking at APEX_APPLICATION_PAGE_ITEMS and APEX_APPLICATION_TEMP_LABEL:

select case when upper(tl.theme_class) like '%WITH HELP%' then 'Y' else 'N' end as pass_fail,
 pi.page_id||'. '||pi.page_name page,
 pi.display_as item_type,
from apex_application_page_items pi,
 apex_application_temp_label tl
where pi.application_id = <APPLICATION_ID>
 and pi.display_as_code != 'NATIVE_HIDDEN'
 and pi.item_help_text is not null
 and pi.item_label_template_id = tl.label_template_id
 and pi.application_id = tl.application_id

An example Automated TestThis query gives us a list of all (non-hidden) page items with help text for the given application (put what you want in place of the <APPLICATION_ID> placeholder). If the label template doesn’t fall into one of the “with help” templates, it’s flagged as not passing. As noted above, the first column is a simple Y/N; the second is the page item’s ID, so we can use this for the automated test in Standards Tracker, as shown in the screenshot on the right (click for a bigger, easier to read version). Note that the Type is set to Report, and we’re linking to a Page Item. The only other change is that we’re using a bind variable for the application id; I tend to stick with the default :APP_ID.

The Standards screen with the Automated TestOnce this is set up as a test linked to the appropriate application(s), you should see something like this second screenshot. For convenience, I’ve collapsed the Automated Tests region and toggled the “Show Only” field (another new feature, by the way) to only include the test we’ve been talking about. You’ll note that the Status column shows a variety of progress bars; some applications are at 100%, one is at 0%, and one is somewhere around 80%. Again, we’re not limited to “this application passed or failed as a whole” like we were in the first release. Incidentally, if there are no items in the application which match the test–so, in our case, no page items with help text–then the application shows as 100%, since there’s nothing to fix.

The dialog of automated test statusesClicking on the “View Details” button to the right of the status bar opens up a dialog showing the completion percentage for that application, for all of the automated tests in the current standard. This is just another way to view the data, and useful if you’re looking at a standard with multiple automated tests. But the real fun comes next.

The report view of an automated testClicking on the “View” button next to the automated test in the dialog takes you to this report page. You can change the Application via the select box, if you want to quickly toggle through all of the relevant applications, and you can toggle whether the report shows only the items that pass, only those that fail, or all items; when I’m working, I tend to prefer the “Only Failures” option (as shown), because those are the ones that need to be fixed. And you’ll notice the yellow pencil icons next to each of the entries–those appear because I logged into the APEX Builder prior to loading the page, and thus have an active session.

From the report, clicking on the Edit button brings you to the APEX BuilderClicking on one of the pencils launches a new window–specifically, an instance of the APEX Application Builder using your current session, loaded directly to the application and component from the report. You can edit the component, hit Apply Changes, and then toggle back to the Standards Tracker window; clicking on the next pencil icon will redirect the new window to the next component. This makes it very easy to quickly update your applications to meet the standards.

Other Builder Integration Features

Shot of the new buttons on the Application Details pageThere are also two new buttons on the Application details page (either click on an application from the Applications tab, or click on an application name from the Standards details page), as seen here. The first, labeled “Edit Application”, launches a new window (or re-uses the one opened above, if it’s still active) loaded onto the main APEX Application Builder page for the application. The second, labeled “APEX Advisor”, directs the window to the APEX Advisor for that application. The Advisor is a nice tool, and will help you identify potential issues in your applications prior to your users being bothered by them, so I highly recommend running it against your applications periodically; the biggest problem is that it can be hard to find–you have to open an application in the APEX Builder, then click on Utilities, and then click on Advisor in the lower left corner. This button is a bit more convenient, at least if you’re already using the Application Standards Tracker.


  1. says

    Hi David,

    Thanks for this second post on the Application Standards Tracker and congrats on the application, it’s very nice!

    I am currently looking into this application to streamline the development process of our APEX team.
    While going through the application, I was wondering whether it is possible to export the standards and tests you’ve created?

    We have lots of development standards in our team which we would like to check through the application.
    Some can vary for a single project but about 80% is the same in every project.
    It would be nice to define the standards and tests in 1 instance of the application, export them and import them again in another instance of the application in another workspace. This way, we wouldn’t have to input every standard over and over again.

    I might have missed it, but I don’t think it is currently available.
    Any ideas on this feature?

    Thanks a lot in advance for your follow-up!

    Kind regards,

    Bart Peeters

    • says


      You’re right, we don’t have an export/import system built at this point. We probably ought to take some time and design a solid solution that we can use across all of our packaged applications; I’ll add it to our list.

      Until then, though, you should be able to take an export of the data in the EBA_STDS_STANDARDS and EBA_STDS_STANDARD_TESTS tables and import them into your new instance. If you include EBA_STDS_TYPES and EBA_STDS_STANDARD_TYPE_REF, that will simplify things as well, but if you’re using different application types on the different instances, you’ll want to just populate the reference table yourself (or edit each standard after loading).

      Hope that helps!

Leave a Reply

Your email address will not be published. Required fields are marked *