Deploying monitor models

You can deploy monitor models using the fast path method or using the detailed method, which allows you to modify monitor model settings during the deployment. You can 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. Indicate how you want to deploy the monitor model application, using the Fast Path or the Detailed path.
   • Select the Fast Path - Prompt only when additional information is required check box, and then click Next. Use the Fast Path option to quickly deploy a new monitor model, or to deploy a new version of an existing monitor model, with default settings and a minimum amount of monitor model customization. You can also use the Fast Path option in a development or test environment.
     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. The Fast Path includes these steps:

     1. Step 1: Select installation options

        Complete this page, and then click any of the following optional steps in the left column. Step 3, Configure security for the monitor model, requires input when application security is enabled.

        To deploy a new version of a monitor model, change the name of the monitor model in the Application name field.

        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, CEI distribution 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 CEI distribution mode of inactive (event queue recoverable) are processed by the new version before it processes events on its own event queue.

     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 monitor model, you can also map an Enterprise JavaBeans™ (EJB) module to a cluster. In a 7.5 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 Update.
          3. Click Update.
          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 Update.
          6. Click Update.
        • For 7.5 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 Update.
          3. Click Update.
     3. Step 3: Configure security for the monitor model

        Input is required 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. Select an existing resource group or create a new resource group for the monitor model you are deploying.

     4. Step 4: Summary

        To complete the deployment steps, verify that all information is correct, and click Finish.

     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.

   • Select the Detailed - Show all installation options and parameters check box, and then click Next.
     Tip: 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. The Detailed deployment path includes these steps:

     1. Step 1: Select installation options

        Complete this page, and then click any of the following optional steps in the left column. Step 14, 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 on 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, CEI distribution 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 CEI distribution mode of inactive (event queue recoverable) are processed by the new version before it processes events on its own event queue.

     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 monitor model, you can also map an Enterprise JavaBeans™ (EJB) module to a cluster. In a 7.5 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 Update.
          3. Click Update.
          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 Update.
          6. Click Update.
        • For 7.5 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 Update.
          3. Click Update.
     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 entry 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: 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 CEI 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 undeployment

              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.

     12. Step 12: Select to publish Cognos cube package

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

     13. Step 13: Select Monitor model CEI options.

         Use this page to select the common event infrastructure (CEI) options for a monitor model. You can also configure these options later using the Change CEI Configuration page. Before selecting options, ensure that you have configured either the table-based or queue-based method of event management. See the topic "Receiving events from CEI" in the related links for more information.

         1. Select a Location option:
            • For standalone servers, select Local if CEI is installed on this IBM Business Monitor server. For network deployment servers, select Local if CEI is installed in the same cell as IBM Business Monitor.
            • For standalone servers, select Remote if CEI is installed on a different server. For network deployment servers, select Remote if CEI is installed in a cell other than the cell that contains IBM Business Monitor. If you selected the Remote option, complete the following fields:
              1. In the Host name field, enter the host name of either the stand-alone server or the deployment manager where CEI is installed. The host name may be localhost if the CEI server is installed on the same physical machine as the IBM Business Monitor server.
              2. In the RMI port field, enter the RMI port number of either the stand-alone server or the deployment manager where CEI is installed.
         2. In the Security section, select either Disabled or Enabled. Selecting Enabled means that security is enabled on the remote CEI server. If you select Enabled, enter a user ID and password that is valid for this IBM Business Monitor server. The user ID must also exist on the remote CEI server, although the password can be different on the remote server.
            If you enable security, make sure that the following tasks have been completed. You might have completed these one-time setup tasks previously when you initially set up the table-based or queue-based communication with the remote CEI server. Refer to the linked tasks in the related links for more information.

            • Administrative security must be enabled on the IBM Business Monitor server.
            • Server-to-server trust (SSL) must be enabled between the IBM Business Monitor server and the remote CEI server.
            • LTPA keys must be shared across the local cell and the remote cell.
            • The Use identity assertion setting must be enabled in the local cell and the remote cell.
            • The server identity must be configured.
         3. Select the Event group profile list name that the model should use. If this location is remote, ensure that the host name, the RMI port, and security, if required, are entered, and click Refresh to see the event-group list names for that server.
         4. In the Distribution mode section, select the appropriate method of distribution:
            • Active: during deployment, configure CEI to distribute events.
            • Inactive: configure CEI later. Use this option if you are creating your schema manually. After the application is deployed, wait until the schema is created before making the distribution active. You can proceed when the monitor model version details page has a green check box next to the create schema step.

            If you choose to configure CEI later, you must select the table-based or queue-based method for receiving events from the inbound CEI server. The table-based method performs better than queue-based because processed events are distributed directly into the event database tables. Table-based event delivery can also distribute work among multiple cluster members. For more information about choosing the method and how to configure each choice, refer to the topic "Receiving events from CEI" in the related links.

     14. Step 14: Configure security for the monitor model. Input is required 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.

         If you are working in a secured environment with a remote queue-based CEI, you must add a user to the Sender role of the corresponding foreign bus and destination before the monitor model is ready for deployment. See the topic "Completing the installation of a monitor model in a secured queue-based environment" for more information.

     15. Step 15: Summary

         To complete the deployment steps, verify that all information is correct, and click Finish.

     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.