Writing transformations for OWB/OWF to implement bespoke error handling

Question

I have implemented mappings which perform lookup on a translation table and if the lookup is not found a suitable value is output to a column, e.g. 'ERROR' is written to the output column on an intermediate table e.g. xxx_temp. The intermediate table is then split into two streams and output to two tables, those with errors to xxx_errors and those that are valid to xxx_out. What I want to know is how to write a transformation which will count the number of errors in xxx_errors and if 0 will return 'success' and if > 0 will return 'error' - because OWB Process Flows can only seem to handle three state events. Will this example function work or are there other parameters that I must include in the function before Oracle Workflow can process it correctly.
FUNCTION etl_md_errors
RETURN NUMBER IS
lv_status NUMBER(22) := 0;
lv_count NUMBER(5) := 0;
** Cursor to count the number of errors in the mappings run
** for the Operating Unit Master Data.
CURSOR lcur_count_errors IS
SELECT c1.err_cnt + c2.err_cnt
FROM (
SELECT Count(Rowid) err_cnt
FROM t_mdo_ce_errors
) c1,
SELECT Count(Rowid) err_cnt
FROM t_mdo_cstobj_errors
) c2,
SELECT Count(Rowid) err_cnt
FROM t_mdo_vntr_errors
) c3;
BEGIN
OPEN lcur_count_errors;
FETCH lcur_count_errors
INTO lv_count;
CLOSE lcur_count_errors;
IF lv_count <= 0 THEN
lv_status := 1;
ELSE
lv_status := 3;
END IF;
RETURN lv_status;
EXCEPTION
WHEN OTHERS THEN
RETURN 3;
END etl_md_errors;
I cannot test the Process Flow deployment as Oracle Workflow 2.6.0 has been installed on an Oracle 8i schema but the Location registration version pulldown only has one entry 2.6.2
Cheers,
Phil Thomson

Answer 1

Hi,
You seem to have missed the point of the posting.
I am asking how to write a transformation which can be used in Process Flow to determine whether any lookup validation errors have occurred, e.g. to determine which e-mail to send to the system administrator's email account. I was not asking if the method of processing/validating the transactions needed revamping .. it is what the client asked for and it's what they have tested and approved. I'll give an explanation of the background to the processing.
a) we are reading in transactions from Country Data Warehouses (SAP BW) which are placed as tables in country data source schemas.
b) we want to consolidate the transactions so that they can be loaded into a European wide Data Warehouse (SAP BW) and these are placed as tables in the target country schemas ... which are consolidated in a global schema using views and dblinks.
c) as the Country Data Warehouses are using their own set of reference/look up values the transactions have the country data warehouse reference codes translated to equivalent european reference codes. Therefore in each country target schema we have sets of mapping/xref table(s) which translates one country column value to the equivalent european column value, e.g. area_ctry and area_eur. Area_ctry is the area reference code in the Country Data Warehouse and area_eur is the area reference code to be used in the European Data Warehouse.
d) when a transaction record has a reference value that does not have an equivalent european reference value we want to flag that column and record as an error, as their are several column values to be translated you do not want to only flag up the 1st validation error encountered, you want to validate the entire record and you also want to validate the entire set of transaction records. Users get a bit miffed if you fail the entire batch of transactions on the first column validation or first invalid record, they correct it then find there are other records with errors ... user has to repeat until no errror records.
e) that is the reason we use the Key Lookup operator on the mapping/xref table with the transaction column's country value in the input group and as the value for the Lookup Condition, on the Key Lookup operator's output group we set the default value for the looked up column to 'ERROR' so if no lookup is found 'ERROR' will be output as the looked up value.
f) the Split operator is then used to identify error records e.g. area_eur = 'ERROR' OR region_eur = 'ERROR' etc, and to identify valid records e.g. area_eur != 'ERROR' AND region_eur != 'ERROR' etc. The error records are output their own table and the valid records are output to their own table.
g) if their are true SQL errors e.g. tablespace exceeded, referenced procedure/function state changed then these will be handled by OWB and should be viewed vaie the OWB audit browser.
As stated in my post what is the template of PL/SQL functions that can be used as Transformations in Process Flows with their 'SUCCESS', 'WARNING' and 'ERROR' transition condition.
Hope the above explanation helps,
Cheers,
Phil Thomson