- 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, 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.
- 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:
- Select the moderator module from the list of modules. The name
ends with "Moderator."
- From the Clusters and servers list, select the target cluster
for the moderator module and click Apply.
- Click Apply.
- Select the model logic module from the list of modules. The name
ends with "ModelLogic."
- From the Clusters and servers list, select the target cluster
for the model logic module and click Apply.
- Click Apply.
- For 7.5 and 8.0 monitor models:
- Select the model logic module from the list of modules. The name
ends with "ModelLogic."
- From the Clusters and servers list, select the target cluster
for the model logic module and click Apply.
- Click Apply.
- 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.
- Step 4: Map shared library relationships
Use the Shared library relationships mapping page to specify
asset or composition unit ID names for shared libraries.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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 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.
- Select one or more of the following database options:
- Under Runtime options, select a processing strategy:
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.
- 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.
- 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.
- Specify dashboard-generation options:
Select Generate
dashboard during monitor model installation if you want
a dashboard to be automatically generated for this monitor model.
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.
- Step 13: Select to publish Cognos cube package
Select Publish Cognos cube package if
you want to create Cognos cubes during model installation.
- Step 14: 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.
Important: When a monitor model version emits outbound events
that are self-consumed by that same monitor model version and the
monitor model version is deployed in a multiple-cell environment,
you must configure Common Event Infrastructure (CEI) in the IBM Business
Monitor cell by following Step 4 in the topic
Manually configuring additional remote
CEI servers for a single model. The following are examples
of cases in which a monitor model version self-consumes outbound events:
- The Global Monitoring Context wizard was used to create a global
monitoring context.
- The monitor model contains modeled alerts.
- 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:
- 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.
- In the RMI port field, enter the RMI port
number of either the stand-alone server or the deployment manager
where CEI is installed.
- 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.
- 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 List to see the event-group list
names for that server.
- 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.
- 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.
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.
- Step 16: Summary To
complete the deployment steps, verify that all information is correct,
and click Finish.