Reflections on Noetix Views with an Emphasis on the Inventory Module

What has Noetix brought us?


-A security framework that reflects our ledger/legal entities/operating units that is robust.

-Breadth of views. Usually these views are not exactly what our users want. They get a little frustrated and then someone from our user group submits a request to have a modification.

-A means to stay current with Oracle Applications.

Today I want to reflect on the Noetix Views regarding the Inventory module.

There are about 16 views we use with some frequency. Most views which are used have at least some modifications.

Here they are:

INV_Item_Onhand_By_Lot, INV_Onhand_Quantities, INV_Customer_Items, INV_Item_Purchasing_Attribut, INV_Onhand_Period_End, INV_Category_COSTING, INV_Item_Onhand_By_Lot_Loc, INV_Lot_Details, INV_Manufacturer_Item_Detail, INV_Category_Inventory, INV_Item_Planning_Attributes, INV_Item_Revisions,
INV_Batch_Transactions, INV_Customer_Items, INV_Item_Cross_References,
INV_Lot_Status_History

Some of these views are custom views (clonings and some home grown creations):

INV_Onhand_Period_End, INV_Lot_Status_History, INV_Item_Onhand_By_Lot_Loc, INV_Batch_Transactions, INV_Lot_Status_History

The point of this post is to step back and reflect. What has Noetix done for us as it pertains to this module? If you look at all the views that we do use, one can immediately conclude that Noetix has provided a spectrum of views based on historical needs. Not only this, we can feel good about the software development lifecycle of these views. Specifically, we know that Noetix does a good job of designing and testing their views.

While a spectrum of views has been provided, it is not complete. 4 out 16 of these views are custom views. Also, of the 12 views remaining (that are heavily used), more than ½ of them needed to be customized. Around here, I heard someone say, “Noetix provides about 80% of our needs.” In this module, Noetix has only met about 75% of our needs. In addition to this, when we say 80%, we mean that a given view has about 80% of what we need and the remainder of what we need, we need to customize.

Is this disparaging? No. Nobody is that good that they can sell you an off the shelf software package with no need for customizations. Noetix has done a good job and most people here feel good about Noetix. It is robust. Their views provide breadth. Their views are well designed and provide us with some peace of mind that they are well thought out.

Step by Step Creating a New View

The sequence of DML statements needed to create a new view follow an order determined by the foreign key constraints set-up in the template tables.


First enter your N_VIEW_TEMPLATES DML statements.  Prior to creating a DML statement to insert records to this template table, it would be advisable to look at the foreign key constraints.

Here we query for the foreign key constraints with this table.

select
constraint_name, r_constraint_name
from
all_constraints
where 1=1
and owner = 'NOETIX_SYS_TEST'
and table_name = 'N_VIEW_TEMPLATES'
and constraint_type = 'R'
/*this is a foreign key constraint*/;

Here are the results:

constraint_name,                         r_constraint_name

N_VIEW_TEMPLATES_FK1 N_APPL_OWNER_TEMPLATES_PK
N_VIEW_TEMPLATES_FK2 N_PROFILE_OPTION_TEMPLATES_PK

When composing this statement, be mindful that the N_VIEW_TEMPLATES_FK1 requires that your application label exist. Also, if the profile option is not null, then N_VIEW_TEMPLATES_FK2 requires that the option be set-up in N_PROFILE_OPTION_TEMPLATES. If you look at the example below, I am creating a custom view associated with our custom Trucking and Shipping Delivery application (TADS). I used ‘OE’ application because this is logical place for me to place our “Trucking and Shipping Delivery“ custom application view (from a role perspective).

INSERT INTO N_VIEW_TEMPLATES
(view_label
, application_label
, description
, profile_option
, essay
, keywords
, product_version
, include_flag
, export_view
, security_code
, special_process_code
, sort_layer
, freeze_flag
, created_by
, creation_date
, last_updated_by
, last_update_date
, original_version
, current_version
)
VALUES
( 'OE_CS_Tads_Loads_Details' --view_label
,'OE' -- application_label
, TO_CHAR(NULL) --description
, TO_CHAR(NULL) --profile_option
, 'This table will be used to track loads that are created '
'within the TADS system when a truck driver signs in.' --essay
,'K{\footnote Tad Load Details}' --keywords
,'*' --product_version
,'Y' --include_flag
,'Y' --export_view
, TO_CHAR(NULL) --security_code
,'XOPORG' --special_process_code
, TO_NUMBER(NULL) --sort_layer
,'Y' --freeze_flag
,'bob' --created_by
, SYSDATE --creation_date
,'bob' --last_updated_by
, SYSDATE --last_update_date
, '6.0.0.849' --original_version
, '6.0.0.849' --current_version
);
COMMIT;

Now that a view template record exists, I can then add arguments to insert records to the N_ROLE_VIEW_TEMPLATES table. Why this table?

Records added to this table require that an N_VIEW_TEMPLATES record exist for the view we are creating.

Again, we check constraints on the table which we want to insert records.
select
constraint_name, r_constraint_name
from
all_constraints
where 1=1
and owner = 'NOETIX_SYS_TEST'
and table_name = 'N_ROLE_VIEW_TEMPLATES'
and constraint_type = 'R'
/*this is a foreign key constraint*/;

Here are the results:

constraint_name,      r_constraint_name
N_ROLE_VIEW_TEMPLATES_FK1 N_ROLE_TEMPLATES_PK
N_ROLE_VIEW_TEMPLATES_FK2 N_VIEW_TEMPLATES_PK


If you look at my insertion argument, you will see that I have used an existing role and my new view:

INSERT INTO N_ROLE_VIEW_TEMPLATES
( role_label
, view_label
, product_version
, include_flag
, created_by
, creation_date
, last_updated_by
, last_update_date
)
VALUES
( 'ORDER_ENTRY' --role_label
,'OE_CS_Tads_Loads_Details' --view_label
,'*' --product_version
,'Y' --include_flag
,'bob' --created_by
, SYSDATE --creation_date
,'bob' --last_updated_by
, SYSDATE --last_update_date
);

COMMIT;


Next, records need to be added to the N_VIEW_QUERY_TEMPLATES table. We look at the foreign key constraints on this table:

select
constraint_name, r_constraint_name
from
all_constraints
where 1=1
and owner = 'NOETIX_SYS_TEST'
and table_name = 'N_VIEW_QUERY_TEMPLATES'
and constraint_type = 'R'
/*this is a foreign key constraint*/;

Here are the results:

constraint_name,  r_constraint_nam
N_VIEW_QUERY_TEMPLATES_FK1 N_VIEW_TEMPLATES_PK
N_VIEW_QUERY_TEMPLATES_FK2 N_PROFILE_OPTION_TEMPLATES_PK


If you look at the foreign key constraints on this table, you will see that the view you are adding has a record in the N_VIEW_TEMPLATES and a record (if not null) in the N_PROFILE_OPTION_TEMPLATES table.


Here is my insertion argument to this table:


INSERT INTO N_VIEW_QUERY_TEMPLATES
(
view_label
, query_position
, union_minus_intersection
, group_by_flag
, profile_option
, product_version
, include_flag
, view_comment
, created_by
, creation_date
, last_updated_by
, last_update_date
)
VALUES
( 'OE_CS_Tads_Loads_Details' --view_label
,1 --query_position
, TO_CHAR(NULL) --union_minus_intersection
,'N' --group_by_flag
, TO_CHAR(NULL) --profile_option
,'*' --product_version
,'Y' --include_flag
,TO_CHAR(NULL) --view_comment
, 'bob' -- created_by
, SYSDATE --creation_date
,'bob' --last_updated_by
, SYSDATE --last_update_date
);

COMMIT;


We are finally in familiar territory when we get to the N_VIEW_TABLE_TEMPLATES table (from a documentation perspective).

With this table, there is no shortage of foreign key constraints so it is imperative that the other records were added prior to this step. Here they are:

select
constraint_name, r_constraint_name
from
all_constraints
where 1=1
and owner = 'NOETIX_SYS_TEST'
and table_name = 'N_VIEW_TABLE_TEMPLATES'
and constraint_type = 'R'
/*this is a foreign key constraint*/;

The results of this query are:

constraint_name, r_constraint_name

N_VIEW_TABLE_TEMPLATES_FK1 N_VIEW_QUERY_TEMPLATES_PK
N_VIEW_TABLE_TEMPLATES_FK2 N_APPL_OWNER_TEMPLATES_PK
N_VIEW_TABLE_TEMPLATES_FK3 N_PROFILE_OPTION_TEMPLATES_PK
N_VIEW_TABLE_TEMPLATES_FK4 N_VIEW_TEMPLATES_PK

If you look at this DML statement, you will see that our previous commands have allowed us to run this without throwing a foreign key constraint error. In looking at other ‘OE’ application views, I see that they include the OE_OU_ACL_MAP_BASE views. This is a key component to maintain consistency with other ‘OE’ Noetix Views, so I add this table first.


INSERT INTO N_VIEW_TABLE_TEMPLATES
(view_label
, query_position
, table_alias
, from_clause_position
, application_label
, table_name
, product_version
, base_table_flag
, subquery_flag
, gen_search_by_col_flag
, created_by
, creation_date
, last_updated_by
, last_update_date
)
VALUES
('OE_CS_Tads_Loads_Details' --view_label
,1 --query_position
,'XMAP' -- table_alias
,1.1 --from_clause_position
,'OE' -- application_label
,'OE_OU_ACL_MAP_BASE' --table_name
,'*' --product_version
,'Y' --base_table_flag
,'N' --sub_query_flag
,'Y' --gen_search_by_col_flag
,'bob' --created_by
, SYSDATE --created_date
,'bob' --last_updated_by
, SYSDATE --last_updated_date
);

COMMIT;

After adding this table, I proceed to add additional tables. From a foreign key constraint perspective, one needs to add records first to the N_VIEW_WHERE_TEMPLATES table and then to the N_VIEW_COLUMNS_TEMPLATES table. The steps to do this as well as methodology are well documented.

My biggest concerns when I venture into creating a new view are the following:

1. Just because a new view can be created and one can leverage the Noetix View Administrator to regenerate views (and leverage its strengths and the consistency from an end user perspective), should you?

2. Is this really in the best interest of my company from a support perspective? Sometimes it is and sometimes it is not and one needs to really weigh the pros and cons. Who will maintain this?

3. Some components of this view set-up require are not obvious nor documented. My methodology is to pick a view that is as similar as possible and it really needs to be from the same Noetix role because one wants these components to behave like the “out of the box” Noetix Views for that role .

4. Are you prepared to support your view as the Noetix Views evolve?

5. Perhaps a clone of Noetix View would better suit your company’s best interest. At some future time I can describe how a clone could be created and weigh the pros and cons of this effort.

That is all for now.

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:

select
application_label
from
noetix_sys_test.n_application_owner_templates
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.

Adding Custom Tables to a Noetix View

Suppose one is adding a custom table’s column(s) to a view.  Again, one has checked to make sure that this does not change the views granularity.  Are there any additional steps needed to insure that this modification will work successfully?

1.        Of course run the script, get_data_tmpl.sql, which gives you a good perspective of the query blocks applicable for your version of Oracle Applications.

2.       In addition to this, it is important to be cognizant that a select grant with grant option is given from the table’s owner to the Noetix_Sys database account.

Why is step two necessary?

Part of the view security setup is to grant select to the Noetix Roles (these are actually database roles). 

If one peruses the results of this query, this granting that occurs through the NVA can be seen:

select

 *

 from

 dba_tab_privs

 where

 owner = 'NOETIX_SYS'

 and grantee = &favorite_Noetix_Role;

If a column from a custom table is added to a Noetix View, it is important to grant select (with grant option) to this custom table to the Noetix Sys database account. 

A query like this can reveal that this privilege has been granted  (here the custom table is 'XXMES_WIP_ONHAND' and its owner is 'XXMESXFER') :

select

 *

 from

 DBA_TAB_PRIVS

 where

 owner = 'XXMESXFER'

 and table_name = 'XXMES_WIP_ONHAND'

and grantee = 'NOETIX_SYS'

and grantable = ‘YES’

This will enable the Noetix Sys database account to grant select to various Noetix roles.

Expedient XU2/XU5 Script Development

Well, you have taken the Noetix Certification Course. You want to develop xu2/xu5 scripts, but the method to uncover syntactical/table constraint generated errors is very inefficient.

Specifically, if one runs stage 2 through 4 of the Noetix View Administrator, it will take greater than 20 minutes to run a re-generation against an Oracle Applications ERP environment.

Like all programming, syntactical errors are the lowest level of errors. One can have no syntactical errors, but still create some really bad design or logical errors that are not caught.

How can I speed-up checking for syntactical/table constraint generated errors (not logical errors)? Here are three methods I have used to help me uncover errors quickly.

1. Run the script (excluding the commit) against the noetix_sys account using SQL Plus (or your favorite querying tool). After the script has completed, look for any errors being thrown. In any event, perform a “rollback” when done. This works well for both xu2 and xu5 scripts.

2. Run stages 2 to 4 in the NVA (specifically stop at the point where there is a prompt for the APPS login information during stage 4). If an error has been thrown with the xu2 script, opt to not enter the APPS password and select "Cancel". This method does not work very well for xu5 scripts (I would recommend method 1 above for xu5).

The key here is to check the corresponding generated spool file(s) for any Oracle errors being thrown. I watch the SQL Loader statistics and I know the xu2 scripts are ran immediately afterwards. I then look for the spool file(s). Within about 5 minutes, I know if my script has syntactical/table constraint errors.

Again, to do this properly, I will not enter the stage 4 prompt for the APPS password until I have performed a check of the spool file(s).

3. Identical to approach 2 (which is usually best), but use Windows command mode to search for errors instead of manually opening spool files. Typically, one is only working on one script at a time. Suppose you are working on multiple scripts at once (probably not advisable). Use a search string command like this within the base directory:

findstr /s “ORA-“ *.lst>error_check.txt

/* I am using Microsoft’s Windows Server 2003 R2 */

Translation of this search command: find a matching string of the form “ORA-“ in any spool file in this directory and redirect the output to the file, “error_check.txt”

I usually use method two to uncover syntactical and constraint related errors.

6.01 Noetix Views Post Regeneration Check List

Last night I performed my first regeneration of the 6.01 Noetix Views since we went live with them in February. I realized I should have a formal procedure to review the success of a regeneration.

Here is my first draft of this procedure.

1. Make sure security is behaving properly. My method is to sample the business areas and check the sharing.

2. Make sure all custom objects exist.

3. Make sure the wnoetx_gseg_flex_kff_cols.sql script exposes the pre-kff segment values. With the 6.01 Noetix Views, key flexfiled segment vales are exposed using the key flexfield cache table construct in lieu of the old methodology.

4. Review the file,” listcnfg.lst”, to confirm how the regeneration was done.
5. Makes sure that the security manager is working correctly. Run this query to view activity:

select
*
from
noetix_sys.n_sm_messages
where
trunc(creation_date) = trunc(sysdate);

I was obtaining errors associated with the concurrent programs set-up to maintain the security data cache (cf page 205 of the 6.01 Noetix Views Administrator Guide). I spooled this script and then ran it using the Noetix System account:

select
'grant execute on ' || object_name ||' to apps; '
from
all_objects
where
owner = 'NOETIX_SYS'
and object_type = 'PACKAGE'
order by 1;

6. Check to see if the KFF cache tables received their initial loading.

Query tables of the form, N_KFF%, and lookover records.

7. Check to see which concurrent programs were created in step 4:

select program_name from n_f_kff_flex_source_pgms

8. Schedule the "Enable Incremental Refresh-(NOETIX_SYS[UID-noetix_database_user_id])' concurrent program.

9. Schedule the key flexfiled cache table concurrent programs to correspond with the refresh approach decided on. The present configuration is that all incremental refresh programs are scheduled to run once a day (except the system item table which runs every 15 minutes). 

10. Check to see which concurrent programs are running:

select
pgms.program_type,
pgms.program_name,
rns.run_id,
rns.request_id,
rns.refresh_to_date,
rns.status, rns.message,
to_char(rns.creation_date,'dd-mon-yyyy hh:mm AM') created, to_char(rns.last_update_date,'dd-mon-yyyy hh:mm AM') updated
from
n_f_kff_program_runs rns,
n_f_kff_flex_source_pgms pgms
where
rns.program_id = pgms.program_id
--and pgms.program_type = 'INCREMENTAL'
--and rns.last_update_date >= sysdate - 1
order by updated

Here is similar information from an applsys perspective:

select
cp.concurrent_program_name,
p.request_id,
to_char ( p.actual_start_date,'dd-mon-yyyy hh:mm AM' ) start_date,
to_char(p.actual_completion_date,'dd-mon-yyyy hh:mm AM') end_date
from
applsys.fnd_concurrent_requests p,
applsys.fnd_concurrent_programs cp
where
cp.concurrent_program_id = p.concurrent_program_id
and trunc(p.actual_start_date) >= trunc(sysdate-1)
and cp.concurrent_program_name like 'N_KFF%'
order by
p.request_id desc

11. Check the N_KFF% tables to make sure incremental updates are occuring.

12. Update my Custom script repository and PVCS to correspond with any new scripts and make sure they are synchronized.

Other Noetix Bloggers

It is encouraging to see that Sumita is blogging about Noetix here. The Noetix community is rather small, but there are a lot features that a developer/administrator need to learn and an active community is quite valuable.