Friday, April 22, 2011

More on XU2 Scripts Associated with Custom Tables: What Application Label Should be Used?

We have a materialized view that was created to aid in creating BOM explosions (we have implemented Oracle OPM). This was created by our APEX staff. For performance reasons, this materialized view is the most reasonable object to use for a Noetix View I am creating.

Presently, I am faced with the issue of how do I add this custom owned object in the table, N_VIEW_TABLE_TEMPLATES?

The most difficult problem with adding an insert statement to the N_VIEW_TABLE_TEMPLATES table is to identify an acceptable application label for this custom object.

What does one enter for the application label column in the N_VIEW_TABLE_TEMPLATES? First, there is a foreign key constraint on the N_VIEW_TABLE_TEMPLATES (see below). Specifically, the parent table associated with this constraint is N_APPLICATION_OWNER_TEMPLATES and the column associated with this key is the APPLICATION_LABEL column. Consequently, we need to select an application label that is already set-up based on our Noetix profile. Of course, Noetix does not anticipate our need to do this and include application labels for our custom applications.

Presently, the custom table is in a custom schema, XXAPEX.

For curiosities sake, I could run this query (to no avail) to see what application labels are seeded:

order by 1;

I do notice that I could select ‘NOETIX’ and ‘APPS’ as the application label that will be used. It is important to be aware that the NVA then associates the table_name which I provide in the N_VIEW_TABLE_TEMPLATES insertion statement with the Noetix database account or APPS when regenerating views. Consequently, a synonym will be needed (and select grants with grant options) to either the Noetix or Apps database account.

While our Apex staff chose not to create a synonym of this materialized view in APPS, we are left with the question of where to place a synonym, either APPS or NOETIX_SYS.

While NOETIX_SYS is acceptable solution, I anticipate that I might not be the only consumer of this materialized view, so I create scripts to place a synonym in APPS:

grant select on custom_owner.custom_object_name to APPS with grant option;
grant select on custom_owner.custom_object_name to NOETIX_SYS with grant option;
create synonym apps.custom_object_name for custom_owner.custom_object_name;

This seems to be the most reasonable approach.

Consequently, my solution is to creates a synonym in APPS associated with my materialized view owned by the Apex account and indicate in the XU2 script that APPS is the application_label.

Now I am ready to finish creating my xu2 script.


  1. First of all, I truly appreciate your efforts share knowledge with Noetix admin community.

    I have following questions,
    1. Have you developed entirely new view for the BOM explosion ?
    2. Are you guys using Oracle APEX with Noetix views ? I am curious to know.

    Best Regards,

  2. Hi Firenze,

    Yes, I have created an entirely new view for the BOM explosion. We are in an Oracle Process Manufacturing environment which is a far less mature product than Discrete (and there is nothing like this in Apps or Noetix to address this need).

    As I have mentioned in previous posts, Noetix does not support this (see early posts on the choices available here).

    I have previously posted on how to do this (very carefully) and you own it all (in terms of moving to newer Oracle Application versions).

    This is not for everyone, but I like having Noetix Help/Search files and not having to create custom Discoverer business areas with custom views (not owned by Noetix) to manage. Also, it is nice being able to leverage Noetix’s strengths (like exposing DFFs). Lastly, it allows me to provide a consistent end user experience.

    With respect to APEX, all I can say is that our APEX staff created an application to augment OPM Development requirements associated with analysis (e.g. mostly statistical analysis of test results to help development staff understand our capabilities).

    One of the objects created by the APEX staff was a materialized view associated with our BOM (this is in its own schema within our Oracle Applications production database). I am just leveraging the work that was already done to create a view of our BOM that is far more scalable than de-normalizing OPM formula detail information recursively.