Best Practices for Using NoetixViews Workbench
This topic discusses some of the best practices that will help you optimally use the features provided by the Noetix Views Workbench (NoetixViews Workbench).
To optimally use the NoetixViews Workbench, follow these guidelines:
Maintain separate environments for development, testing, and production as follows:
Maintain a development environment to add and customize views. In the same environment, you should test all customizations and fix all customizations-related issues. After finalizing the customizations, promote the customizations from the development environment to the test environment. Before you promote the customizations, delete all the managed views in the test environment so that the view revisions match in the source and target environments.
Maintain a test environment to validate the new and customized views. If you notice any issues during view generation or if you want to edit the customizations, use the development environment to make the required changes. You must not use the target environment to edit view customizations or fix customizations-related issues because this will result in conflict with the view revisions in the development environment. After testing and finalizing the views in the test environment, promote them to the production environment. Before promoting the views, ensure that the test environment has the latest revisions, and delete all the managed views from the production environment so that the view revisions match in the source and target environments.
Maintain a production environment for only integrating the finalized view customizations with the underlying NoetixViews schema. The production environment must be used for only applying the finalized NoetixViews Workbench customizations to the underlying NoetixViews schema.
For registering the test and production environments, you can use a NoetixViews schema for which at least Stage 4 has been completed till the Get Passwords wizard is displayed. Stage 4 does not need to be run for such environments because you will need to run it in any case after the customizations are promoted from the development environment.
For using legacy customization scripts along with the NoetixViews Workbench, follow these guidelines:
Remove all unwanted legacy scripts from the installation folder of the underlying NoetixViews schema of an environment so that they are not captured by the NoetixViews Workbench.
After you have customized a view through the NoetixViews Workbench, insigihtsoftwarerecommends that you make no more customizations to the view using legacy scripts. The NoetixViews Workbench creates Revision zero of the view from its template table settings before the view customizations are created. If you use a legacy script to modify the view's template table settings, they will no longer match Revision zero.
If you must use legacy customization scripts, follow these steps to achieve correct results:
Remove the view from any packages that contain it.
Unmanage the view.
Stage the package.
Run Stage 4.
Apply legacy customizations.
Capture or import the new legacy customizations.
Stage the package.
Run Stage 4.
Recreate the NoetixViews Workbench customizations.
If you must use legacy customization scripts and do not want to retire them, use them to make changes to only columns, tables, and WHERE clauses of a view that are not yet modified by the NoetixViews Workbench. After you make the changes, do not modify these objects again using the NoetixViews Workbench. If you want these legacy customizations to coexist with the NoetixViews Workbench customizations, they should be managed appropriately using the NoetixViews Workbench. After you start managing view customizations through the NoetixViews Workbench, the wnoetxu2.sql script that is available in the NoetixViews schema schema installation folder will be replaced with the wnoetxu2.sql script generated by the NoetixViews Workbench. Therefore, the scripts corresponding to the legacy customizations that you do not want to retire must be called through the wnoetxu2 legacy.sql script that is part of the legacy package in the NoetixViews Workbench. You can modify the wnoetxu2 legacy.sql script in the NoetixViews Workbench or in the NoetixViews schema folder after staging a package.
The customizations corresponding to the view revisions in packages staged from one environment must be applied in the underlying NoetixViews schema. If you apply the customizations to an incorrect NoetixViews schema, Stage 4 may fail or views may be incorrectly generated. However, if you want to apply the NoetixViews Workbench customizations available in a package to a different NoetixViews schema, you must promote the package to the environment of that NoetixViews schema.
The following steps enable you to create an environment, for example, NV6.5Repository New, as a clone of an existing environment, for example, NV6.5Repository Old:
Run Stages 1 to 4 (till the Get Passwords wizard is displayed) to complete a partial setup of your NoetixViews schema.
Register an environment, for example, NV6.5Repository New, in the Noetix Enterprise Manager (Noetix Enterprise Manager) using the schema that you created in step a.
NOTE:You can register environments for the NoetixViews schemas for which at least Stage 4 has been completed till the Get Passwords wizard is displayed. You can only promote or import customizations to such environments.Promote a package from the existing environment, namely, NV6.5Repository Old, to the new environment, namely, NV6.5Repository New.
In the new environment, namely, NV6.5Repository New, stage the package that you promoted in step c.
Run Stage 4 for the NoetixViews schema pertaining to the new environment. The environment that you have created, namely, NV6.5Repository New now will be similar to the original environment, namely, NV6.5Repository Old.
When you make any modifications that enhances the functionality of a view, make sure that the view essay is updated to reflect the enhanced use of the view.
With respect to the scripts generated by the NoetixViews Workbench, the following guidelines must be followed:
Do not rename scripts that are generated by the NoetixViews Workbench. The scripts generated by the NoetixViews Workbench are not captured when you capture legacy customization scripts. However, if you rename these scripts, there is a possibility that the NoetixViews Workbench may capture these scripts, and, consequently, Stage 4 may fail or the view may be incorrectly generated.
Do not import scripts generated by the NoetixViews Workbench to the legacy package. This may result in generating views incorrectly or Stage 4 failure.
Do not customize views by editing the scripts generated by the NoetixViews Workbench. These scripts are overwritten every time you stage a package.
When you import customizations or promote packages from one environment to another environment, you may notice some conflicts detected during the compatibility check. If you want to override the conflicts and proceed with import or promotion, select the check boxes corresponding to each conflict. insightsoftware recommends that you proceed with the import or promotion only after resolving the conflicts. If you override the conflicts and promote the package to the target environment, it is possible that Stage 4 may fail for the NoetixViews schema of the target environment. Stage 4 will fail in situations in which the modules of Noetix Views (NoetixViews) available in the source and target are different.
If the conflict indicates that the customizations being imported or promoted are from an environment based on an earlier version of NoetixViews, and if there are no other conflicts detected, you can override the conflict. After the customizations have been migrated to the target environment, you need to run the Upgrade My Customizations wizard before performing any other tasks in the target environment.