Deploying monitor models using the detailed method

You can deploy monitor models using the detailed method. With the detailed method, you can modify monitor model settings during deployment. You use the WebSphere® Application Server administrative console to modify the monitor model settings and customize your deployment of a new monitor model or a new version of an existing monitor model.

1. From the WebSphere Application Server administrative console, click Applications > Monitor Models. The table that is displayed lists all of the currently deployed monitor models.
2. Click Install.
3. Specify the location of the EAR file you want to deploy, and then click Next.
4. From the Install New Applications page, select Detailed - Show all installation options and parameters, and click Next. If an Application Security Warning is displayed, click Continue. This warning is for informational purposes.

   The Install New Application page is displayed. This page has a column on the left that you can use to navigate to the deployment steps that you need.

   1. Step 1: Select installation options

      Complete this page, and then click any of the following optional steps in the left column. Step 15, Configure security for the monitor model requires input when application security is enabled. When you have modified all the settings that you want to customize, click Summary.

      To deploy a new version of a monitor model, change the name of the monitor model in the Application name field. For more information about any of the other fields and options in this page, click the More information about this page link in the Help column.

      If you are deploying a new version of an existing monitor model, the version time stamp must be more recent than any previously deployed versions of that model. When you deploy a new version, the previous version is automatically configured to process events associated with existing monitoring-context instances only (meaning, version consumption mode of Active). New monitoring-context instances are created only by the new version. Also, events associated with any previous versions that were configured with a event consumption mode of Inactive are processed by the new version before it processes events.

   2. Step 2: Map modules to servers

      If you want to take advantage of workload management throughout a cluster for your 6.1, 6.2, or 7.0 monitor model, you can map Enterprise JavaBeans (EJB) modules to different servers or clusters. The moderator EJB module can use a cluster for high availability only and the model logic EJB module can use a cluster for high availability and for scalability. If you do not want to take advantage of workload management, there is no benefit in deploying to separate targets.

      If you want to take advantage of workload management throughout a cluster for your 7.5 or 8.0 monitor model, you can also map an Enterprise JavaBeans (EJB) module to a cluster. In a 7.5 or 8.0 monitor model, the model logic EJB module can use a cluster for high availability and for scalability.

      When mapping the modules of a monitor model application, the target cluster must meet the following requirements in order to host the modules:

      • The cluster members of the target cluster must reside on nodes that have been augmented with the IBM® Business Monitor profile template.
      • When creating the first cluster member of the target cluster, you must have selected a server template containing the text defaultWBM in the name.

      For additional information about the benefits of mapping EJB modules to servers in a distributed environment, see the topic "EJB modules mapped to distributed servers" in the related links.
      • For 6.1, 6.2, and 7.0 monitor models:
        1. Select the moderator module from the list of modules. The name ends with "Moderator."
        2. From the Clusters and servers list, select the target cluster for the moderator module and click Apply.
        3. Click Apply.
        4. Select the model logic module from the list of modules. The name ends with "ModelLogic."
        5. From the Clusters and servers list, select the target cluster for the model logic module and click Apply.
        6. Click Apply.
      • For 7.5 and 8.0 monitor models:
        1. Select the model logic module from the list of modules. The name ends with "ModelLogic."
        2. From the Clusters and servers list, select the target cluster for the model logic module and click Apply.
        3. Click Apply.
   3. Step 3: Map shared libraries

      Use the Shared library mapping page to specify URI identifiers for shared libraries. The shared libraries are referenced by the modules in an enterprise application.

   4. Step 4: Map shared library relationships

      Use the Shared library relationships mapping page to specify asset or composition unit ID names for shared libraries.

   5. Step 5: Provide JNDI names for beans

      Use this page to view and modify the Java Naming and Directory Interface (JNDI) names of non-message-driven enterprise beans in your application or module.

   6. Step 6: Map EJB references to beans

      Use this page to view and modify the Enterprise JavaBeans (EJB) references to the enterprise beans. References are logical names used to locate external resources for enterprise applications.

   7. Step 7: Map resource references to resources

      Each resource reference that is defined in your application must be mapped to a resource. Use this page to designate how the resource references map to the actual resources that are configured for the application.

   8. Step 8: Map resource environment references to resources

      Use this page to designate how the resource environment references of application modules map to remote resources, which are represented in the product as resource environment entries.

   9. Step 9: Correct use of system identity.

      Use this page to manage the system identity properties for the Enterprise JavaBeans (EJB) method in your application.

   10. Step 10: Metadata for modules

       Use this page to instruct a Java Platform, Enterprise Edition (Java EE) 5 enterprise bean (EJB) or web module deployment descriptor to ignore annotations that specify deployment information. If the metadata-complete attribute is set to true, annotations that specify deployment information are ignored.

   11. Step 11: Deploy module build IDs Use this page to view the build identifier of a module in a Java Platform, Enterprise Edition (Java EE) enterprise archive (EAR file).
   12. Step 12: Select Monitor model options

       Use this page to select the database, runtime, and KPI migration options for a monitor model. You can also change some of the monitor model default options by selecting the appropriate database options to create the schema, enable data movement services, or delete the schema. See the topic "Managing monitor model database schemas in a secured database" in the related links to understand these steps and options. If the server is in development mode, the database options are disabled. In development mode, the model schema is created automatically when the model is deployed, and Data Movement Service is disabled.

       The following information applies when you run scripts to create the schema and enable data movement:

       • During deployment, if you change the table spaces, be sure to also change the table space names in the model .ddl file to be consistent.
       • If you choose not to run the scripts during deployment, they can still be run after the monitor model is deployed. However, if you do run these scripts during deployment, there is no need to run these scripts again later.
       • If you create the schema later, set the event distribution to Inactive during monitor model deployment and switch it to Active later.
       • Running the scripts automatically from the WebSphere Application Server administrative console is not supported for z/OS®. For z/OS, these scripts must be exported and run manually.
       • If you are using Oracle as your database, manually export and run the database scripts to create or to delete the schema. These scripts include commands that create and drop tables and views and are not transactional with Oracle. If the scripts fail to complete successfully, the database administrator must perform any required cleanup because rollback is not supported. DB2® is fully transactional and use of the automatic running of these scripts is recommended. For additional information about using Oracle, see the topic "Database considerations for Oracle" in the related links.
         Note: Although a model schema can be automatically created for an Oracle database during model deployment, it is generally recommended that you manually create the schema. The reason for this recommendation is that the automated database scripts include commands that create and drop tables and views and these commands are not transactional with Oracle. If the scripts fail to complete successfully, any resulting problems must be manually fixed because rollback is not supported for Oracle databases. However, if you fully understand the potential problems of having model schema automatically created for an Oracle database and you can arrange for any problems to be manually fixed, there may be situations where you can tolerate the risk for the sake of productivity. For example, in a development environment where problems are more easily tolerated and fixed, you may choose to have the schemas automatically created to save you time. However, in a production environment, problems cannot be tolerated and any problems that are encountered must be rapidly resolved by the database administrator. For this reason, it is strongly recommended that you manually create the model schemas for any production environment.
       • The server database user must have administrative privileges to create database objects. For more information, refer to the topic "Securing the monitor model database create schema" in the related links.
       1. Select one or more of the following database options:
          • Run script to create the schema (default)
            • After running the script, stop and start the monitor model so that the monitor model application picks up the new database tables.
            • For more information on running the script, see the topic "Exporting the create schema script" in the related links.
          • Run scripts to enable data movement service
            • If you enable data movement service when you deploy the model, data will be moved at regular intervals from the operational tables to the reporting tables and terminated instance data will be removed, improving reporting performance. However, if performance is not a concern, you can perform a simpler deployment and choose not to enable data movement service during deployment.
            • Once enabled, data movement service cannot be disabled.
          • Run script to delete the schema during uninstallation

            If you do not choose this option during deployment, you can do so later from the Manage Schema page.

       2. Under Runtime options, select a processing strategy:
          • 6.0.2 emulation
          • Scalable

          Optional: Select Enable event reordering. This option is not available for 6.0.2 emulation and is optional for the scalable option.

          See the topic "Processing strategies for monitor models" in the related links for more information about these options.

       3. Enable KPI merge:
          Select Enable KPI merge from previous version to perform the following actions for a new monitor model version:

          • Copy any key performance indicators (KPIs) that were created in the previous version using the dashboard.
          • Restore any KPI display preferences that were defined in the previous version.
       4. Enable Business Situations merge:

          Select the Enable Business Situations merge from previous version option to copy all of the dynamic alerts from the previous monitor model version to the new version.

       5. Specify dashboard-generation options:
          Select Generate dashboard during monitor model installation if you want a dashboard to be automatically generated for this monitor model.

          Note: If you select this option for the monitor model at authoring time, the same dashboard name and user credentials are used during monitor model deployment.
          If you select Generate dashboard during monitor model installation, you can also specify values for the following fields:

          • Dashboard user. You use this field to specify the user who can view the dashboard, in addition to the current user. If you do not provide a value, only the current user can view the generated dashboard.
          • Dashboard name. If you do not enter a name, model_name.model_version is used.

          Tip: If you uninstall a monitor model that was deployed with the Generate dashboard during monitor model installation option, the generated dashboards are not removed from your Monitor dashboard space. You must remove them manually.
   13. Step 13: Select to publish Cognos cube package

       Select Publish Cognos cube package if you want to create Cognos cubes during model installation.

   14. Step 14: Select event sources
       Use this page to select the event sources for a monitor model. The local cell where IBM Business Monitor is running is selected by default. When a new version of a monitor model is installed, the event sources from the previous version are preselected for you. However, you can add or remove event sources for the new version as needed. To modify your event source selection at a later time, use the Change Event Source Configuration page.

       Important: If your monitor model emits events that it also consumes, ensure that, in addition to any needed remote event sources, the local business monitor's event source is added to the list of event sources.
   15. Step 15: Configure security for the monitor model.

       Input is required for this step if application security is enabled.

       For a monitor model to be visible to users, it must be added to a resource group and users must be assigned a role within that resource group. A resource group is a logical grouping of models that provides for easy administration of data access permissions. Select an existing resource group, or create a new resource group, for the monitor model you are installing.

       • Click Select an existing resource group, then select the radio button next to the resource group that you want to use.
       • Click Create a new resource group, then enter a name and a description for the new resource group.
   16. Step 16: Summary To complete the deployment steps, verify that all information is correct, and click Finish.
5. To review the model deployment information, click Review changes before saving or discarding, or to save the model, click Save directly to the master configuration.