Creating and Responding to Crystal Enterprise Alerts

Crystal Enterprise generally provides a successful platform for building and delivering reports over the Web. Although successful implementations and wide user adoption are always a good thing, one of the challenges that comes with that is that as more reports get published to the system, it becomes more of a challenge to wade through the mounds of information to quickly find the answers users need. A trend that has recently been growing faster than ever is dashboards. A dashboard is typically a page or series of Web pages that provide a summary of many different measures and metrics defined inside a business. One of the most popular ways to represent information on a dashboard today is in the form of alerts. An alert is a flag that is triggered when a value falls above or below a threshold. Typical examples of this could be headcount rising above a certain number, sales weekly revenue dropping below a certain level, or average call center wait times rising above a preferred level. An alert is defined inside a Crystal Report template and when scheduled, any alerts that are triggered surface themselves through the Crystal Enterprise Object Model. Typically, a user would boot up her computer in the morning and visit the dashboard page to see any alerts that she needs to respond to. This section describes how to provide this list of alerts.

Finding Triggered Alerts

Alerts are triggered during a scheduled report job. This means that when querying for alerts, you should query only report instances. The following query returns the name and corresponding triggered alerts from any report instances that have at least one triggered alert:

SELECT SI_NAME, SI_ALERTS FROM CI_INFOOBJECTS WHERE SI_ALERTS != NULL

The only type of object that can have an alert is a report, so when including a condition like SI_ALERTS != NULL, there is no need to filter on SI_PROGID as well. Figure 36.3 shows the output of the previous query when run in the Query Builder application.

As you can see, the SI_ALERTS property is a hierarchical property. It has a subproperty called SI_NUM_ALERTS and then depending on the number of alerts triggered, it has an SI_ALERT1 property, SI_ALERT2 property, and so on. That property is another hierarchical property that contains the alert name and message in the SI_ALERT_NAME and SI_ALERT_MESSAGE properties, respectively.

Displaying Alerts

One of the things you will find right away is that although there is a way to get all the reports that have run and had alerts triggered, there is no way to determine what alerts are defined on reports that have not been triggered yet. So instead of providing a "triggered/not triggered" type of interface, you can only present a list of alerts that have been triggered. A good way to do this is to simply create a listing called "Alerts of the day" and display the SI_ALERT_MESSAGE value. Because this is attached to an InfoObject, you know the corresponding ID of the report, so it would be a good idea to make the message a hyperlink to the report itself. This enables the user to click on the alert to drill to the detail of what happened.

Also, if a report runs every day you don want duplicate alerts so you would want to filter for any alerts fired that day. Lets say the scheduled reports run at 2 a.m. each morning. You might use the following query to only retrieve the alert for the current day:

SELECT SI_NAME, SI_ALERTS, SI_ENDTIME FROM CI_INFOOBJECTS WHERE SI_ALERTS != NULL AND SI_ENDTIME >= 2004/02/29.2.00