OWB Map Testing

Final-phase production releases leave no room for error, making meticulous map testing a high-stakes necessity. When individual rows go missing in complex mappings, you need a surgical approach to troubleshooting rather than a total tear-down. Discover how to leverage OWB’s granular code generation to isolate issues and ensure your data lands exactly where it belongs.

Testing the OWB Map

I am still overseas working on a OWB project for a client. We are now into that final phase of checking everything before we promote the first release to the production system. Each OWB map for the first release is redeployed on the development system and then test data run through the map - we then check that the right number of rows (and content too!) appears at the right target. This is painstaking, but necessary work. Where we have problems we track them down, resolve (redeploy if we need to alter the mapping) and then repeat the test until the problem goes. When we get all of the code in the first release working, we go through the loop again for all of the maps to see the affects of using the SCD2 functionality in the dimension load plug-in (and yes, we have applied that patch to remove the horrendous "compare effective dates as text strings" coding that somehow crept into OWB) We are looking to make sure that execution times don't go off on the update rather than pure insert operations of the first round of testing

Which brings me to a nice OWB 10.2 feature in trouble-shooting complex maps. The ability to generate code for individual mapped object input or output groups; Click on the code generator icon on the map editor and click on a drop down on the code window to change the mode then click on a mapped objects grouping bar. If I loose one or two rows in a mapping (or even all of them) I just cut and paste the generated code into SQLDeveloper and check that each output is doing the right thing

Ready to ensure your complex data migrations are production-ready?