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.

Going Live with 6.01 Noetix Views

Last week we went live with the 6.01 Noetix Views. Here is our high level process (our reporting tool, Discoverer, had steps included in this process as well):

1 Export Discoverer business areas and workbooks separately.

2 Using data pump, export the Noetix Administration and end user layer database schemas.

3 Run the NVA pre-update scripts.

4 Spool SQL (and run spooled file) pertaining to dropping old Noetix roles:

SELECT
'DROP ROLE '||GRANTED_ROLE || ';'
from
dba_role_privs
where
grantee IN ('NOETIX_SYS')
and granted_role not in ('CONNECT','RESOURCE')
order by 1

If these roles were not dropped, I have found that the Noetix View Administrator would throw errors during the regeneration process. This script could be potentially very bad if I am not careful that only Noetix created roles are dropped.

5 Drop the Noetix Administration and end user layer database schemas.

6 Create the end user layer user, EUL5_US and provide system grants.

7 Using the Discovere Administrator, set-up the end user layer schema, EUL5_US as a Discoverer, private EUL schema.

8 Run the eul5.sql script (utility) in EUL5_US.

9 Having access to the SYSTEM dba account, run the Noetix View Administrator, stage 1.

10 Run scripts that provides grant select to some custom objects with grant option for some. We have a lot of xu2 scripts and some of the scripts reference objects which are owned by custom schemas.

11 Complete Noetix View Administrator stages 2 through 4.

12 Run my grant execute script to APPS for Noetix Sys KFF and security packages. With the 6.01 release, the appropriate grants to invoke these packages (using corresponding concurrent programs created by the NVA) in Oracle Applications were not included. I compiled a list based on errors being thrown while attempting to run the corresponding concurrent programs.

13 Generate the EUL in the new EUL schema.

14 Create manual joins.

15 Import workbooks.

16 Test manual joins.

17 Run concurrent program which performs initial upload for KFF cache tables.

18 Schedule incremental refresh for concurrent programs which are associated with the kff cache tables.

19 Make sure the Discoverer role mapping corresponds with the mappings used in the tupd files.

20 Generate the Noetix Search file.

21 Test the top 20 workbooks to confirm that the imported workbooks can be associated with the new Noetix Administration account objects.

All in all, this was successful.