Configuring Alert Persistence

The alert persistence architecture includes the following databases.

• Enterprise Manager's embedded database.

• An external database that you can use to persist alerts. The external database contains one alert table per domain.

By default, alerts are not persisted to the external database. This topic describes how to enable persistence.

Be sure to understand the behavior of the various persistence configurations.

• If persistence is disabled, then alerts are generated and sent to any monitoring instances that are currently running. The monitoring instances can include no more than one instance of Enterprise Manager, as well as any number of clients that use the Alert Management API. For detailed information about the Alert Management API, see Java CAPS Management and Monitoring APIs.

• If persistence is enabled and journaling is disabled, then the alerts are stored temporarily in the external database. The system makes a best effort to send the alerts to all monitoring instances. When the reliable client indicates that it received an alert, the alert is deleted from the database.

  There can be only one reliable client at a time. The most recent client to request reliable delivery becomes the reliable client. Enterprise Manager requests reliable delivery when you start the server. Clients that use the Alert Management API can request reliable delivery when they subscribe to the alert notification service.

  ---

  Note –

  If the reliable client is shut down, then there is no reliable client until the next request for reliable delivery is made.

  ---

• If persistence and journaling are both enabled, then alerts are stored permanently in the external database. When a client consumes an alert, the alert is not deleted from the database.

You can use any of the following database types for the external database. The Derby database is included with Sun Java System Application Server. The other database types are not included.

• DB2

• Derby

• Oracle

• PointBase

• Sybase

If you want to use a database type other Derby, then you must perform additional configuration tasks. For example, you must use Java^TM DataBase Connectivity ("JDBC^TM") software and the Java Naming and Directory Interface^TM ("J.N.D.I.") API to set up access to the database.

For all database types, you must log in to the Configuration Agent and modify the alert notification fields.

To Configure the Alert Table Name (Databases Other Than Derby)

1. Open the eventmanagement.properties file in the JavaCAPS-install-dir/appserver/domains/domain-name/jbi/config directory.

2. If necessary, change the default value of the AlertTableName property and save the file.

   You might need to change the default value to match your organization's naming conventions, or to comply with the database server's character limit for table names.

To Set Up Database Access (Databases Other Than Derby)

1. Log in to the Sun Java System Application Server Admin Console.

2. Integrate the JDBC driver.

   You can make the driver accessible to the common class loader or the system class loader.

   For detailed information about how to integrate a JDBC driver, click Help in the Admin Console.

3. In the left pane, expand the Resources node and the JDBC node, and select the Connection Pools node.

4. Click New.

5. Create the JDBC connection pool.

   For detailed information about how to create a JDBC connection pool, click Help in the Admin Console.

6. In the left pane, select the JDBC Resources node.

7. Click New.

8. Create the JDBC resource.

   You will enter the JNDI name of the JDBC resource in a later procedure.

   Set the pool name to the JDBC connection pool that you just created.

   For detailed information about how to create a JDBC resource, click Help in the Admin Console.

To Run the Database Scripts (Databases Other Than Derby)

1. Open the jbi_rt.jar file in the JavaCAPS-install-dir/appserver/jbi/lib directory.

2. Extract the SQL scripts for your database type.

3. If you are using Oracle, then create the tablespace and user that will be used to persist alerts.

   1. Open the create_event_store_user.sql script and make any changes needed to match your database configuration.

   2. Run the create_event_store_user.sql script.

4. Create the table that will be used to persist alerts.

   1. Open the create_event_store_schema.sql script and make any changes needed to match your database configuration.

      Ensure that the table name matches the value in the eventmanagement.properties file.

   2. Run the create_event_store_schema.sql script.

To Log In to the Configuration Agent

1. If the application server is not running, then start the application server.

2. In a browser, enter the following URL:

   http://hostname:portnumber/configagent

   Set the hostname to the TCP/IP host name of the computer where the application server is installed. Set the port number to the administration port number of the application server. For example:

   http://myserver.company.com:4848/configagent

   The Configuration Agent Security Gateway appears.

3. In the User ID field, enter an application server user name.

4. In the Password field, enter the corresponding password.

5. Click Login.

   The Configuration Agent appears.

To Modify the Alert Notification Fields

1. Ensure that the database is running.

2. In the Configuration Agent, click the Alert Management Configuration tab.

   

3. Select the Enabled check box to the right of the Alert Notification Persistence label.

4. If you want to enable journaling, then select the Enabled check box to the right of the Alert Notification Journal label.

5. Select the database type from the Alert Notification Database Type drop-down list.

6. If you are using a database other than Derby, then set the JNDI name to the JNDI name of the JDBC resource that you created.

7. Click Save.

8. Restart the application server domain.