Best Practices Using NoetixViews Workbench for Customization Management – Part 2

By Bryan Walton, Director, Engineering at Noetix

Today we continue our three part series featuring best practices for those using NoetixViews Workbench for customization management.  In Part 2 below, we discuss some common mistakes and ways to avoid them.  We encourage you to contact us at with questions.   Happy Holidays!

  1. Scripts you get from “Test: Get Scripts” in the View Picker are not meant to be staged.  They exist only so that you can see what the script will look like when it’s generated.  When a package is staged there are other supporting scripts and SQL statements that are generated, which are not generated from “Test: Get Scripts.”  This feature is not supported in the next version of Workbench.
  2. Use legacy customization scripts ONLY WITH EXTREME CAUTION to modify a managed view.
    1. When a view is managed, revision zero is created from the template tables, which consists of the original view from Noetix plus any legacy customizations to that view.  Revision zero is never updated again. Workbench creates customization scripts by comparing the packaged revision against revision zero.  If you change the legacy script, revision zero will not match the template tables at the appropriate time during stage 4 and the generated scripts will be wrong.  If you must change the legacy scripts, you must unmanage the view first.
    2. Only make changes to columns, tables, or where clauses that are not already modified by Workbench.
    3. Once you’ve used a legacy customization in this fashion to modify one of these items, you must not use Workbench to modify it again.  Workbench does not capture these secondary legacy customizations and you will get the wrong hookscript.
    4. If you must fix metadata from the views and it violates the criteria specified, you can only safely do this by unmanaging the view in Workbench, applying your legacy customizations, and recreating your Workbench customizations.  This would be a good time to consider not applying the legacy customizations at all, retiring them instead and creating them solely using Workbench.
    5. Legacy hookscripts that are added manually must be called from WNOETXU2_LEGACY, not WNOEXTU2!  Wnoetxu2.sql is generated by Workbench and any changes you make to it will be overwritten the next time you stage.  You may edit wnoetxu2_legacy.sql from within Workbench.
  3. Staging from an environment to an installs folder for a different Noetix-Sys schema is not recommended.  Use Promote first, then stage from the environment you promoted to.  Otherwise, you might have a compatibility mismatch.
  4. NoetixViews Workbench generated scripts should not be captured or imported.  Capture ignores these scripts by design and you should not rename the scripts to get around this protection. Capturing or importing will turn easy-to-customize Workbench customizations into hard-to-manage legacy customizations.
  5. Changes introduced by editing scripts generated by NoetixViews Workbench will not be picked up by Workbench as they will be overwritten the next time you stage.
  6. Although it is possible to override compatibility checks in import and promote by checking the checkboxes next to the incompatibility warnings, it should be done only with extreme caution.  If you are not careful, you may create a situation where you break your stage 4.  For example, if you promote a revision from an application that is installed in the source but not in the target.

Part 1 in this series discusses several proactive steps you can take to optimize your customizations environment.  Stay tuned for Part 3, which will address changes and enhancements available in the newest release of NoetixViews Workbench.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply