In one of my previous blogs, I already told we grouped the different QA-checks-you-want-to-perform in a single Apex application.
A special attention point is that this application needs to be imported in the workspace where the application resides that you want to control. This is due to the way the apex_ repository views are designed: you only see those applications where the different schemas assigned to the workspace have access to.
Since the last blog, we changed a little bit our approach. At that time, we had the idea tho group all related qa-checks in one UNION’ed view, containing ALL the queries for the different controls.
The main disadvantage of this implementation is that each time you want to add an extra check, you need to modify the view; this means doing some DDL.
Therefore, we decided to store the SQL-statements in a separate column related to each different control. Following screenshot, shows you the page that is used to add/modify a pre-defined control:
The sample query is used to check whether the Report Column Headings are always aligned the same way: Left, Right or Center. As you can see we do not hardcode one of those possible options in the where clause; but retrieve the standard-alignment-for-the-columns via a function call (Pck$QA_APEX_Standards.heading_alignment).
Therefore we created a separate table where we define all kind of parameters of which the value can differ from applicaton to application. The following screenshot shows the page where the parameter “heading_alignment” is defined with his default value.
If you want to differ from this default value for a given application, we have foreseen the possibility (via a second table), to store for a specific application (GWI in the example) the standard-value we agreed on with our end-users. This permits to have different standards for different apex-applications in the same workspace.