Owbsys.wb_rt_api_exec.open fails after upgrade to OWB 11gR2

Question

The following code is used as a PLSQL wrapper to execute OWB mappings and is based on the good old run_my_own_stuff.sql. We have been mandated to use Tivoli as the corporate scheduler, meaning we do not have Workflow as a solution. We have implemented the audit_execution_id as an input parameter to all the mappings to be able to link the data to the OWBSYS audit tables, as well as return mapping performance and success info to the execution process/session. I have implemented this exact same procedure in 10gR1, 10gR2 and 11gR1 (current dev env) with no problems at all - the code ports easily. However following an upgrade (actually an export/import of the repository from 11gR1 on a 64bit solaris to 11gR2 on Exadata running enterprise linux 5) - actually the test server (I know, I know, I said the same thing!), the code now fails on the wb_rt_api_exec.open line (highlighted).
CREATE OR REPLACE PROCEDURE bi_ref_data.map (p_map_name IN VARCHAR2)
-- Procedure to execute ETL mapping package via command line call
-- Mapping names are held in the BI_REF_DATA.MAP_NAME table
-- with the mapping type and location data
AS
v_repos_owner VARCHAR2 (30) := <repository_owner>;
v_workspace_owner VARCHAR2 (30) := <workspace_owner>;
v_workspace_name VARCHAR2 (30) := <workspace_name>;
v_loc_name VARCHAR2 (30);
v_map_type VARCHAR2 (30);
v_map_name VARCHAR2 (30) := UPPER (p_map_name);
v_retval VARCHAR2 (255);
v_audit_execution_id NUMBER; -- Audit Execution Id
v_audit_result NUMBER;
v_start_time timestamp := LOCALTIMESTAMP;
v_end_time timestamp;
v_execution_time NUMBER;
v_record_rate NUMBER := 0;
v_records_selected NUMBER;
v_records_inserted NUMBER;
v_records_updated NUMBER;
v_records_deleted NUMBER;
v_records_merged NUMBER;
v_errors NUMBER;
v_failure VARCHAR2 (4000);
e_no_data_found_in_audit exception;
v_audit_exec_count NUMBER;
e_execution_id_error exception;
BEGIN
SELECT UPPER (loc_name), UPPER (map_type)
INTO v_loc_name, v_map_type
FROM bi_ref_data.owb_map_table
WHERE UPPER (map_name) = UPPER (v_map_name);
IF UPPER (v_map_type) = 'PLSQL'
THEN
v_map_type := 'PLSQL';
ELSIF UPPER (v_map_type) = 'SQL_LOADER'
THEN
v_map_type := 'SQLLoader';
ELSIF UPPER (v_map_type) = 'SAP'
THEN
v_map_type := 'SAP';
ELSIF UPPER (v_map_type) = 'DATA_AUDITOR'
THEN
v_map_type := 'DataAuditor';
ELSIF UPPER (v_map_type) = 'PROCESS'
THEN
v_map_type := 'ProcessFlow';
END IF;
-- Changed code for owb11gr2
-- owbsys.wb_workspace_management.set_workspace (v_workspace_name, v_workspace_owner);
owbsys.wb_rt_script_util.set_workspace (v_workspace_owner || '.' || v_workspace_name);
v_audit_execution_id   := owbsys.wb_rt_api_exec.open (v_map_type, v_map_name, v_loc_name);
IF v_audit_execution_id IS NULL
OR v_audit_execution_id = 0
THEN
RAISE e_execution_id_error;
END IF;
v_retval := v_retval || 'audit_execution_id=' || TO_CHAR (v_audit_execution_id);
v_audit_result := owbsys.wb_rt_api_exec.execute (v_audit_execution_id);
IF v_audit_result = owbsys.wb_rt_api_exec.result_success
THEN
v_retval := v_retval || ' --> SUCCESS';
ELSIF v_audit_result = owbsys.wb_rt_api_exec.result_warning
THEN
v_retval := v_retval || ' --> WARNING';
ELSIF v_audit_result = owbsys.wb_rt_api_exec.result_failure
THEN
v_retval := v_retval || ' --> FAILURE';
ELSE
v_retval := v_retval || ' --> UNKNOWN';
END IF;
DBMS_OUTPUT.put_line (v_retval);
owbsys.wb_rt_api_exec.close (v_audit_execution_id);
v_end_time := LOCALTIMESTAMP;
v_execution_time := bi_ref_data.get_seconds_from_interval (v_end_time - v_start_time);
v_retval := 'Execution time = ' ||
v_execution_time ||
' seconds.';
DBMS_OUTPUT.put_line (v_retval);
SELECT COUNT (w.rta_select)
INTO v_audit_exec_count
FROM owbsys.owb$wb_rt_audit w
WHERE w.rte_id = v_audit_execution_id;
IF v_audit_exec_count = 0
THEN
RAISE e_no_data_found_in_audit;
END IF;
SELECT w.rta_select,
w.rta_insert,
w.rta_update,
w.rta_delete,
w.rta_merge,
rta_errors
INTO v_records_selected,
v_records_inserted,
v_records_updated,
v_records_deleted,
v_records_merged,
v_errors
FROM owbsys.owb$wb_rt_audit w
WHERE w.rte_id = v_audit_execution_id;
v_retval := v_records_selected || ' records selected';
DBMS_OUTPUT.put_line (v_retval);
IF v_records_inserted > 0
THEN
v_retval := v_records_inserted || ' inserted';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF v_records_updated > 0
THEN
v_retval := v_records_updated || ' updated';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF v_records_deleted > 0
THEN
v_retval := v_records_deleted || ' deleted';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF v_records_merged > 0
THEN
v_retval := v_records_merged || ' merged';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF v_errors > 0
THEN
v_retval := v_errors || ' errors';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF v_execution_time > 0
THEN
v_record_rate := TRUNC ( (v_records_inserted + v_records_updated + v_records_deleted + v_records_merged) / v_execution_time, 2);
v_retval := v_record_rate || ' records/sec';
DBMS_OUTPUT.put_line (v_retval);
END IF;
IF (v_audit_result = owbsys.wb_rt_api_exec.result_failure
OR v_audit_result = owbsys.wb_rt_api_exec.result_warning)
THEN
FOR cursor_error
IN (SELECT DISTINCT aml.plain_text
FROM owbsys.owb$wb_rt_audit_messages am
INNER JOIN
owbsys.owb$wb_rt_audit_message_lines aml
ON am.audit_message_id = aml.audit_message_id
WHERE am.audit_execution_id = v_audit_execution_id)
LOOP
DBMS_OUTPUT.put_line (cursor_error.plain_text);
END LOOP;
END IF;
-- OWBSYS.wb_rt_api_exec.close (v_audit_execution_id);
COMMIT;
EXCEPTION
WHEN e_execution_id_error
THEN
raise_application_error (-20011, 'Invalid execution ID returned from OWB');
-- RAISE;
WHEN e_no_data_found_in_audit
THEN
raise_application_error (-20010, 'No data found in audit table for execution_id - ' || v_audit_execution_id);
-- RAISE;
WHEN NO_DATA_FOUND
THEN
raise_application_error (-20001, 'Error in reading data from OWBSYS tables.');
-- RAISE;
END;
Does anyone out there know if there is a difference between 11gR1 and R2 in the way that the wb_rt_api_exec function works?
Is there a simple way to retrieve the audit_id before executing the mapping, or at a push during the mapping so that we can maintain the link between the session data and the OWBSYS audit data?
Martin

Answer 1

Hi David, I have been reading some of your posts and blogs around OWB and I still have not found the answer.
OK, thereis/was a script that Oracle Support/forums/OTN sent out a while ago called "run_my_iowb_stuff" - I am sure you will be familiar with it. I based the code I uploaded on it and added additional functionality. In essence, I wanted to use the audit_id as an input parameter tot he mapping, so that I can register the audit_id in the management tables, and associate each row of loaded data with a specific mapping_id which would allow a simple link to the owbsys audit tables to complete the audit circle. To that end, I used the owbsys.wb_rt_api_exec.open procedure to register the mapping execution, and then on the execute procedure of the same package, I passed this audit_id in as a custom parameter:
<<snip>>
owbsys.wb_workspace_management.set_workspace (v_workspace_name, v_workspace_owner);
v_audit_execution_id := owbsys.wb_rt_api_exec.open (v_map_type, v_map_name, v_loc_name, 'PLSQL');
IF v_audit_execution_id IS NULL
OR v_audit_execution_id = 0
THEN
RAISE e_execution_id_error;
END IF;
v_retval := v_retval || 'audit_execution_id=' || TO_CHAR (v_audit_execution_id);
IF v_include_mapping_id > 0 -- if non-zero, submit owb execution id as an input parameter to the map process
THEN
owbsys.wb_rt_api_exec.override_input_parameter (
v_audit_execution_id,
'p_execution_id',
TO_CHAR (v_audit_execution_id),
owbsys.wb_rt_api_exec.parameter_kind_custom
END IF;
<<snip>>
The execution is closed, also by the use of the audit_id ( "owbsys.wb_rt_api_exec.close (v_audit_execution_id)" )
I can also use the audit_id to inspect the audit tables to retrieve the records processed as well as any associated error messages, and format them for the calling application (owSQL*Plus, which is normally the context of our current use).
This procedure has been working weel up to now until we moved over to 11gR2 when all of a sudden the audit_id is not returned when executing "v_audit_execution_id := owbsys.wb_rt_api_exec.open (v_map_type, v_map_name, v_loc_name);". Prior to 11gR2 this worked like a charm - now it has crashed to a halt.
As an interesting twist, I have tried to substitute a sequence number for the audit_id, and then tried to get the audit_id after the mapping completes, so that I can put both the sequence and audit id in a table so it maintains the link. However in attempting to use the owbsys.wb_rt_script_util.run_task procedure which now appears to be the only thing left working, I was astonished to see the following output in sqlplus:
SQL> exec map1('stg_brand')
Stage 1: Decoding Parameters
| location_name=STAGE_MOD
| task_type=PLSQLMAP
| task_name=STG_BRAND
Stage 2: Opening Task
| l_audit_execution_id=2135
Stage 3: Overriding Parameters
Stage 4: Executing Task
| l_audit_result=1 (SUCCESS)
Stage 5: Closing Task
Stage 6: Processing Result
| exit=1
--> SUCCESS
Execution time = .647362 seconds.
records/sec
PL/SQL procedure successfully completed.
SQL>
This output seems so identical to the "run_my_owb_stuff" that either Oracle support generated their "run_my_owb_stuff" as a lightweight owbsys.wb_rt_script_util.run_task procedure, or Oracle incorporated the "run_my_owb_stuff" script into their owbsys.wb_rt_script_util.run_task procedure! Which way round I cannot say, but it is surely one or the other! To make matters worse, I have raised this with Oracle Support, and they have the temerity to claim that they do not support the "run_my_owb_stuff" script, but think enough of it to incorporate it into their own package in a production release!
To overcome my problems, in the short term, I need to be able to access the audit_id either during or after the execution of the mapping, so that I can at least associate that with a sequence number I am having to pass in as a parameter to each mapping. In the longer term, i would like a solution to be able to access the audit_id before I execute the mapping, as I could by calling the "owbsys.wb_rt_api_exec.open " procedure. Ideally this would be solved first and I would not need to use a sequence at all.
Hope this clarifies things a bit.
Regards
Martin