Alerts module troubleshooting
Follow the tips in this article to find and resolve problems with alerts.
Alerts logging
When you have a problem with alerts, check the log files
to get more information.
- Portal Server/logs/SystemOut.log
- Portal Server/logs/SystemErr.log
- WEB-INF/logs/alertsEngine.txt
Turn trace logging on.
For additional details about the problem, turn trace logging on by following
these steps:
1. Add the following property
entry to the override.properties file:
bowstreet.solutions.alerting.alertsEngine.enableTracing=true
2. Restart WebSphere Portal
server or the Web application.
Problems developing or administering alerts
Problem: When I open the Alert Data builder, I see a
message "Cannot load the set of alert definitions."
Background and solution:
This is caused by using a database persistence manager during development.
You should use the XML-file persistence manager when you are developing
an application. You can use the Import Definitions portlet to migrate your
definitions to a database when you put the application into production.
Problem: Users cannot receive automated notifications
in a JSR168 application.
Background and solution:
This is a known limitation. The WebSphere Dashboard Framework 6.x alerts
scheduler works only with applications built with the WebSphere Native
API; it does not work with JSR168 applications. To use the alerts scheduler
with a JSR168 application, you must do two things:
1. Create a separate project
that contains the WebSphere Dashboard Framework - Alerts Scheduler feature
set. When you set up the deployment configuration, select "WebSphere
Native (deprecated)" as the Portlet API.
2. Set up the scheduler
project's persistence manager so that it shares values with the JSR168
application. For more details, see the WebSphere Dashboard Framework Information
Center.
Problem: The Notification page in Edit mode displays differently with a
database persistence manager than it does with an XML persistence manager.
Background and solution:
Bring all alert notifier definitions into the database and use the database
persistence manager for all alerts.
1. Log in to WebSphere Portal,
go to the Notification page, and then edit the layout of this page. Search
for a portlet named "Import Definitions" and add it to the page.
2. After the Import Definitions
portlet is loaded, click its Notifier Defintions tab, and import all the
notifier definitions to the database. Confirm that all the notifier definitions
are in the database. Each one should have a green mark with the status
"in database."
3. Rebuild the portlet WAR
file. (If you enabled auto-deployment for the project, open the MyAlertsCustomizer.model,
click the 'Generate the Current Model' button, and then save the model.)
Problem: No browser window pops up when I click "Find People..."
button in the User Authorization and Escalation page.
Background and solution:
Look for the Directory Search page for the version of WebSphere Portal
that you are using:
WebSphere Portal 6
ibm.portal.Directory.Search
WebSphere Portal 5
lotus.workplace.hiddenpage.PeoplePicker
If you cannot find the Portal page mentioned above, it means your Directory
Search functionality is damaged. Reinstall the Portal server.
Problem: Users are receiving duplicate e-mails for the
same alerts.
Background and solution:
Duplicate e-mails may be generated in a few situations.
1. You have restarted the
application several times.
The scheduler thread does not stop automatically when you shut down the
application. If scheduler threads are still running, users will receive
duplicate e-mails. Either avoid restarting the application or restart the
Portal server to stop the scheduler threads as well as the application.
2. Several applications
share the same alerts repository.
You may deploy the alerts Module on many applications, and then share the
XML-file or database persistence manager. In this situation, make sure
that only one application is running the alerts scheduler. Otherwise, each
scheduler will send out e-mail, and users will receive duplicate e-mails.
3. You are deploying application
in a cluster environment.
In a cluster environment, the alerts module should be installed on all
servers, but the scheduler must run on only one server. Otherwise, each
Alerts scheduler will send out e-mails and users will receive duplicate
e-mails.
Problems displaying or receiving alerts
Problem: A user's group information has been changed,
but the user cannot see the changes in the My Alerts portlet.
Background and solution:
A new session with the server needs to be established. The user needs to
log in again to the WebSphere Portal server to see the group information
changes.
Problem: The bookmark is missing in the alert details page.
Background and solution:
The bookmark field is invisible by default. To show it, enter Edit mode
of the My Alerts portlet and check the status for Bookmark in the Details
tab.