Dynamic content in email

Question

hello,
does anyone notice binding variables in OWF R2? At least process name, proces duration (in body or subject) should be usefull.
In 10gR1 I was using UTL_SMTP package...
thank you
br

Answer 1

OWF is horrid for it's inability to pass context from one activity to the next. To get what you want you need to do a bit of a workaround in the OWB mappings rather than handle this inside the process flows.
We use UTL_SMTP, and reference it in a standard post-mapping process. This process constructs the message from runtime information common to all OWB mapping packages.
IF you look at mapping generated code you find several helpfull variables in the package spec. Things like:
get_runtime_audit_id
get_audit_level
get_cycle_date
get_lob_uoid
get_model_name
get_selected
get_inserted
get_updated
get_deleted
get_merged
get_errors
get_abort
get_trigger_success
get_read_success
get_status
So the next part is to figure out how to get your post-mapping process to reference them at tuntime. The first thing you might think of is to create a constant parameter type that uses these variables as their source. This is a start, however if you check to see how OWB generates a constant you see that it will be statically set to the current value at package load time. What you need is for it to be evaluated at runtime at the end of the mapping run.
How I got it to work was: In each OWB mapping I create a Constant who'se expression is defined as get_model_name.This puts the mapping name into the constant and gives us an input value to use in an expression.
So then I create an expression who's input is the constant, and who's output includes a bunch of variables that are defined as the other desired package variables such as get_Status, get_inserted, get_updated, etc. These are all passed into the post-mapping process that handles the logic to check the get_status value and fire off the email if needed, and the generated code properly references the variables when the mapping is fired at the end of the run. As far as elapsed time goes, this is handled in conjunction with a pre-mapping process that sets a variable in our audit package to store the start time which we can subtract from the current time when the post-mapping procedure fires to determine elapsed time. Both the pre-and-post mapping procedures exist in a single package to keep the time-stamp arithmatic session-specific.
A lot of work?
Well, it's a bit to set up intially, but once you get your standardized pre- and post-mappings defined and build it once, you can then set it up as a pluggable mapping to stick into all of your other mappings.
We also went this route to allow us to include per mapping run audit information in our own centralized audit info repository that holds details about every process that runs agains the warehouse - not just the mappings.
This provides a centralized location for checking the health of the warehouse by the application support people, and we were also able to build our own repository of information such as counts of inserts/updates/rejects etc inside our warehouse for a capacity planning reporting cube.
One of our problems with the Oracle runtime audit console is that it allows users to drill right down to the field-level information for a row that failed to load. This is helpfull for diagnosing the problems to be sure, but we needed to screen who gets access to that information due to the sensitive nature of our data. The first line support people needs to be able to see top-level audit information to ensure that things ran correctly, to re-run any mappings that failed for most reasons, and to perform some light troubleshooting when neccessary. But data integrity auditing is not something they are cleared to perform. Saving the get_runtime_Audit_id value into our audit tables lets approved personel quickly access the detailed data if and when needed, and also let us tag rows with this id as they are modified so we can determine which run last affected a given row.
Hope this info helped...............
Cheers,
Mike