0 
0 Finally, I have attended to one of my long running frustrations with CDM RuleFrame: the Business Rule Design Transformer, that key Headstart utility that takes Business Rule definitions in Oracle Designer and transforms them to Business Rule Design Definitions, composed of a Table Trigger with associated PL/SQL Definition, has always generated invalid code in the PL/SQL Definition. At last, I have made the teeny weenie change that is required to have it generate code that can immediately be compiled in the database. The code that comes out of the BRDT looks something like:
/*********************************************************************
Purpose De som van de aanneembedragen van alle regels in geautoriseerde machtigingen voor hetzelfde element mag niet groter zijn dan het bedrag van het element
Remarks
Input parameters available in the validation code:
Revision History
When Who
Revision What
----------------------------------------------------------------------
14-11-2005 LUCAS
1.0 Using utility HSU_BRTR (revision 6.5.3.4AMIS)
*********************************************************************/
l_rule_ok boolean := true;
begin
trace('br_mtg021mtg_ier (f)');
-- for instructions, see the Headstart User Guide
l_rule_ok :=
return l_rule_ok;
exception
when others
then
qms$errors.unhandled_exception(PACKAGE_NAME||'.br_mtg021mtg_ier (f)');
end br_mtg021mtg_ier;
That code is NOT valid. The line that says “l_rule_ok:= “ is not complete. I think looking back on the discussions we had in our team while first developing CDM RuleFrame, that we thought it valuable that CAPI packages could not be generated rightaway without the developer actually implementing the validation logic. Thus we ensured that developers could not be fooled into believing that they had completed a business rule while all they had done was run the Headstart Utilities. However, the consequence of this somewhat paternalistic approach is that a Business Rule Design Definition is always incomplete after running the BRDT. That in turn means that if you have created say a dozen business rules around the same entity and have run the Business Rule Design Transformer, you have a dozen invalid PL/SQL definitions. If you start implementing the first one, generating and compiling the CAPI will result in an invalid package, as the other eleven business rules will still have invalid implementations. You will have to amend all eleven PL/SQL Definitions before you can even compile the generated CAPI. And all of that for your own good.
I got really tired of this. What I want is for the Business Rule Design Transformer to create code that will compile. And by having it always generate code that returns false from the Business Rule validation function, I will have plenty of warning that something is amiss with my business rule. Just a tiny change is required in the HSU_CRBR package – whose source you will find in the HEADSTART_HOME\hsu\scripts\pb directory. Line 153 in version 6.5.3.3 of this package holds the definition of the constant DEFAULT_CODE. This constant has the code that is generated in each Business Rule PL/SQL Definition. By changing this constant’s definition, we can alter the generated code. I change the lines
||chr(10)||' -- for instructions, see the Headstart User Guide'
||chr(10)||' l_rule_ok := '
||chr(10)
||chr(10)||' return l_rule_ok;'
To
||chr(10)||' -- for instructions, see the Headstart User Guide'
||chr(10)||' l_rule_ok := false;'
||chr(10)
||chr(10)||' return l_rule_ok;'
And I recompile the package. One frustration down, zillion more to go.
Related posts:
Anydata and Collections Death of the End Date – How LAG and LEAD help fight redundancy 
Aspect Oriented Programming (AOP) in PL/SQL – Is it hot? Is it cool? Or utterly useless? Dynamic SQL Pivoting – Stealing Anton’s Thunder Putting Analytical Functions to good use – find tables with multiple foreign keys to the same referenced table
