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.