Rediger

Del via

Reporting Services data alerts

  • Artikkel

Applies to:  SQL Server Reporting Services (2016) ❌ SQL Server Reporting Services (2017)  SharePoint ❌ Power BI Report Server

For content related to previous versions of SQL Server Reporting Services (SSRS), see What is SQL Server Reporting Services?

SQL Server Reporting Services data alerts are a data driven alerting solution that helps you be informed about report data that is interesting or important to you, and at a relevant time. By using data alerts you no longer have to seek out information, it comes to you.

Data alert messages are sent by email. Depending on the importance of the information, you can choose to send messages more or less frequently and only when results change. You can specify multiple email recipients and this way keep others informed to enhance efficiency and collaboration.

Note

Reporting Services integration with SharePoint is no longer available after SQL Server 2016.

Data alerts architecture and workflow

The following list summarizes the key areas of Reporting Services data alerts:

  • Define and save data alert definitions-you run a report, create rules that identify interesting data values, define a recurrence pattern for sending the data alert message, and specify the recipients of the alert message.

  • Run data alert definitions-Alerting service processes alert definitions at a scheduled time, retrieves report data, creates data alert instances based on rules in the alert definition.

  • Deliver data alert messages to recipients-Alerting service creates an alert instance and sends an alert message to recipients by email.

In addition, as a data alert owner you can view information about your data alerts and delete and edit your data alert definitions. An alert has only one owner, the person who created it.

Alerting administrators, users with SharePoint Manage Alerts permission, can manage data alerts at the site level. They can view lists of alerts by each site user and delete alerts.

Reporting Services data alerts are different from SharePoint alerts. You can define SharePoint alerts on any document type, including reports. SharePoint alerts are sent when the document changes. For example, you add a column to a table in a report. In contrast, data alerts are sent when the data shown in a report satisfied rules in the alert definitions. The rules typically reference the data that displays in a report.

By creating data alerts on reports, you can monitor changes in report data and send data alert messages by email when report data follow rules that define data of interest to you and others, and at intervals that meet your business needs. You can also run data alerts on demand. If you have SharePoint Create Alert permission, you can create alerts on any report that you have permissions to view. You can create multiple alerts on a report and multiple users can create the same or different alerts on a report. To collaborate with others, you can specify them as the recipients of alert messages in data alert definitions that you create.

The following diagram shows the workflow of creating and saving a data alert definition, creating a SQL Agent job to begin processing an instance of the data alert, and sending data alert messages that contain the report data that triggered the alert to one or more recipients by email.

Diagram of the data alerts architecture and workflow.

Reports supported by data alerts

You can create data alerts on all types of professional reports that are written in the report definition language (RDL) and created in Report Designer or Report Builder. Reports that include data regions such as tables and charts, reports with subreports, and complex reports with multiple parallel column groups and nested data regions. The only requirements are the report includes at least one data region of any type and the report data source is configured to use stored credentials or no credentials. If the report has no data regions, you can't create an alert on it.

You can't create data alerts on reports created with Power View.

Note

Power View support is no longer available after SQL Server 2017.

When you install Reporting Services in native mode or SharePoint mode or use the standalone version of Report Builder, you can save reports to a report server, your computer, or a SharePoint library. To create data alerts on reports, the reports must be saved or uploaded to a SharePoint library. This means that you can't create alerts on reports saved to a report server in native mode or your computer. Also, you can't create alerts embedded in custom applications.

Reporting Services supports various credential types in reports. You can create data alerts on reports with data source configured to use stored credentials, or no credentials. You can't create alerts on reports configured to use integrated security credentials or prompt for credentials. The report is run as part of processing the alert definition and the processing fails without credentials. For more information, see the following resources:

Run reports

The first step in creating a data alert definition is to locate the report you want in the SharePoint library, and then run the report. If a report contains no data when you run it, you can't create an alert on the report at that time.

If the report is parameterized, you specify the parameter values to use when you run the report. The parameter values are saved in the data alert definitions that you create on a report. The values are used when the report is rerun as a step in processing the data alert definition. If you want to change the parameter values, you need to rerun the report with those parameter values and create an alert definition on that version of the report.

Create data alert definitions

The Reporting Services data alerts feature includes the Data Alert Designer, which you use to create data alert definitions.

To create a data alert definition, you run the report and then open Data Alert Designer from the SharePoint Report Viewer Actions menu. The report data feeds for the report are generated and the first 100 rows in the data feed display in a data preview table in Data Alert Designer. All the data feeds from a report are cached as long you're working on the alert definition in Data Alert Designer. The caching enables you to switch quickly between data feeds. When you reopen an alert definition in Data Alert Designer, the data feeds are refreshed.

Data alert definitions consist of rules and clauses that report data must satisfy to trigger a data alert message, a schedule that defines the frequency to send the alert message and optionally the dates to start and stop sending the alert message, information such the Subject line and a description to include in the alert message, and the recipients of the message. After you create an alert definition, you save it to the SQL Server alerting database.

Save data alert definitions and alerting metadata

When you install Reporting Services in SharePoint mode, the SQL Server alerting database is automatically created.

Data alert definitions and alerting metadata are saved in the alerting database. By default, this database is named ReportingServices<GUID>_Alerting.

When you save the data alert definition, alerting creates a SQL Server Agent job for the alert definition. The job includes a job schedule. The schedule is based on the recurrence pattern you define on the alert definition. Running the job initiates the processing of the data alert definition.

Process data alert definitions

When the schedule of the SQL Server Agent job starts the processing of the alert definition, the report is run to refresh the report data feeds. The alerting service reads the data feeds and applies the rules that the data alert definitions specify to the data values. If one or more data values satisfy the rules, a data alert instance is created and a data alert message with the alert results is sent to all recipients by email. The results are rows of report data that satisfied all rules at the time the alert instance was created. To prevent multiple alert messages with the same results, you can specify that messages are sent only when the results change. In this case, an alert instance is created and saved to the alerting database, but no alert message is generated. If an error occurs, the alert instance is also saved to the alerting database and an alert message with the details about the error is sent to recipients. The Diagnostics and Logging section later in this article has more information about logging and troubleshooting.

Send data alert messages

Data alert messages are sent by email.

The From line contains a value provided by the Reporting Services email delivery configuration. The To line lists the recipients that you specified when you created the alert in Data Alert Designer.

Besides the email Subject line, which you specify in Data Alert Designer, the data alert message includes the following information:

  • The name of the person who created the data alert definition.

  • If you provided a description in the alert definition, it displays at the top of the email text.

  • The alert results, consisting of the rows in the report data feed that satisfy the rules specified in the alert definition.

  • A link to the report that the alert definition is built upon.

  • The rules in the alert definition.

  • The parameters and values that you used to run the report.

  • The contextual values from report items that are outside of the report data regions.

If a data alert instance or data alert message can't be created, an error message is sent to all recipients. Instead of the alert results, the message includes an error description.

For more information, see Data alert messages.

Install data alerts

The data alerts feature is available only when Reporting Services is installed in SharePoint mode. When you install Reporting Services in SharePoint mode, setup automatically creates the alerting database that stores data alert definitions and alerting metadata, and two SharePoint pages for managing alerts and adds Data Alert Designer to the SharePoint site. There are no special steps to perform or options to set for alerting during installation.

If you want to learn more about installing Reporting Services in SharePoint mode, including the Reporting Services shared service that is new in SQL Server 2012 (11.x) and Reporting Services service application that you must create and configure before you can use Reporting Services features, see Install Reporting Services SharePoint Mode for SharePoint 2010 in MSDN library.

As the diagram earlier in the article shows, data alerts use SQL Server Agent jobs. To create the jobs, SQL Server Agent must be running. You might have configured SQL Server Agent to start automatically when you installed Reporting Services. If not, you can start SQL Server Agent manually. For more information, see Configure SQL Server Agent and Start, stop, pause, resume, restart the Database Engine, SQL Server Agent, or SQL Server Browser Service.

You can use the Provision Subscriptions and Alerts page in SharePoint Central Administration to find out whether SQL Server Agent is running and create and download customized Transact-SQL scripts that you then run to grant permissions to SQL Server Agent. It can also generate the Transact-SQL scripts by using PowerShell. For more information, see Provision subscriptions and alerts for SSRS service applications.

Configure data alerts

Starting in SQL Server 2012 (11.x) the settings for Reporting Services features, including data alerts, are distributed between the report server configuration file (rsreportserver.config) and a SharePoint configuration database whenever you install Reporting Services in SharePoint mode. When you create the service application as a step in installing and configuring Reporting Services, the SharePoint configuration database is automatically created. For more information, see RsReportServer.config configuration file and Reporting Services configuration files.

The settings for Reporting Services data alerts include the intervals for cleaning up alerting data and metadata and the number of retries when sending data alert messages by email. You can update the configuration file and the configuration database to use different values for data alert settings.

You update the report server configuration file directly. You update the SharePoint configuration database by using Windows PowerShell cmdlets.

The following table lists the configuration elements for data alerts, their default values, descriptions, and locations.

Setting Default Value Description Location
AlertingCleanupCycleMinutes 20 Number of minutes between starts of the cleanup cycle. Report Server Configuration File
AlertingExecutionLogCleanupMinutes 10080 Number of minutes to keep execution log entries. Report Server Configuration File
AlertingDataCleanupMinutes 360 Number of minutes to keep temporary data. Report Server Configuration File
AlertingMaxDataRetentionDays 180 The number of days until alert execution metadata, alert instances, and execution results is deleted. Report Server Configuration File
MaxRetries 3 Number of times to retry processing of data alerts. Service Configuration Database
SecondsBeforeRetry 900 Number of seconds to wait before each retry. Service Configuration Database

By default, the MaxRetries and SecondsBeforeRetry settings apply to all events that data alerts fire. If you want more granular control of retries and retry delays, you can add elements for any event handlers that specify different MaxRetries and SecondsBeforeRetry values.

Event handlers and retry

The event handlers are:

Event Handler Description
FireAlert You select Run in Data Alert Manager to initiate immediate processing of an alert definition.
FireSchedule SQL Server Agent launches the job schedule for an alert definition.
CreateSchedule You create a data alert definition and a SQL Server Agent job schedule is created based on the frequency interval specified in the alert definition.
UpdateSchedule You update the frequency interval of the data alert definition and the SQL Server Agent job schedule is updated.
DeleteSchedule You delete the data alert definition and its SQL Server Agent job is deleted.
GenerateAlert The alerting runtime processes the report data feed, applies the rules specified in the data alert definition, determines whether to create an instance of the data alert, and if needed creates an instance of the data alert.
DeliverAlert The runtime creates the data alert message and sends it to all recipients by email.

The following table summarizes the event handlers and when retry fires:

Error Category / Event Type FireAlert FireSchedule CreateSchedule UpdateSchedule DeleteSchedule GenerateAlert DeliverAlert
Out of memory X X X X X X X
Thread abort X X X X X X X
SQL Agent is not running X X X X
Transient. Mostly due to connections problems, timeouts, and locks. X X X X X X X
IOException X
WebException X
SocketException X
SMTPException (*) X

(*) SMTP errors that trigger a retry:

  • SmtpStatusCode.ServiceNotAvailable

  • SmtpStatusCode.MailboxBusy

  • SmtpStatusCode.MailboxUnavailable

Disable data alerts

If you want to disable the data alert feature, you update the Service section of the configuration file. The following code shows Service section of the configuration file.

<Service>

<IsSchedulingService>True</IsSchedulingService>

<IsNotificationService>True</IsNotificationService>

<IsEventService>True</IsEventService>

<IsAlertingService>True</IsAlertingService>

...

</Service>

To disable alerting, change True to False in <IsAlertingService>True</IsAlertingService>.

Permissions for data alerts

Before you can create data alerts on reports, you must have permission to run the report and create alerts on the SharePoint site. To learn more about report permissions, see the following articles.

Reporting Services data alerts support two permission levels: information worker and alerting administrator. The following table lists the related SharePoint permissions and user tasks.

User Type SharePoint Permission Task Description
Information worker View Items

Create Alerts		 View items such as reports and create data alerts on the reports. Edit and delete alerts.
Alerting administrator Manage Alerts View a list of all data alerts saved on the SharePoint site and delete alerts.

Diagnostics and logging

Data alerts provide many ways to help information workers and administrators keep track of alerts and understand why alerts failed and help administrators make use of logs to learn which alert messages were sent to whom, number of alert instances sent, and so forth.

Data Alert Manager

Data Alert Manager lists alert definitions and error information that help information workers and alerting administrators understand why the failure occurred. Some common reasons for failure include:

  • The report data feed changed and columns that are used in the data alert definition rules are no longer included in the data feed.

  • Permission to view the report was revoked.

  • The data type in the underlying data source changed and the alert definition is no longer valid.

Logs

Reporting Services provides many logs that can help you learn more the reports that are run when processing data alert definitions, the data alert instances that are created, and so forth. Three logs are particularly useful: the alerting execution log, the report server execution log, and the report server trace log.

For information about other Reporting Services logs, see Reporting Services log files and sources.

Alerting execution log

The alerting runtime service writes entries in the ExecutionLogView table in the alerting database. You can query the table or run the following stored procedures to get richer diagnostic information about the data alerts saved to the alerting database.

  • ReadAlertData

  • ReadAlertHistory

  • ReadAlertInstances

  • ReadEventHistory

  • ReadFeedPollHistory

  • ReadFeedPools

  • ReadPollData

  • ReadSentAlerts

You can use SQL Agent to run the stored procedure on a schedule. For more information, see SQL Server Agent.

Report server execution log

Reports are run to generate the data feeds that data alert definitions are built upon. The report server execution sign in the report server database captures information each time the report is run. You can query the ExecutionLog2 view in the database for detailed information. For more information, see Report Server ExecutionLog and the ExecutionLog3 View.

Report server trace log

The report server trace log contains highly detailed information for report server service operations, including operations performed by the report server Web service and background processing. Trace log information might be useful if you're debugging an application that includes a report server, or investigating a specific problem that was written to the event log or execution log. For more information, see Report server service trace log.

Performance counters

Data alerts provide their own performance counters. All but one performance counter is related to an event that is part of the alerting runtime service. The performance counter related to the event queue tells the length of the queue of all active events.

Event or Event Queue Performance Counter
ALERTINGQUEUESIZE Alerting: event queue length
FireAlert Alerting: events processed - FireAlert
FireSchedule Alerting: events processed - FireSchedule
CreateSchedule Alerting: events processed - CreateSchedule
UpdateSchedule Alerting: events processed - UpdateSchedule
DeleteSchedule Alerting: events processed - DeleteSchedule
GenerateAlert Alerting: events processed - GenerateAlert
DeliverAlert Alerting: events processed - DeliverAlert

Reporting Services provides performance counters for other Reporting Services features. For more information, see Performance counters - ReportServer Service, performance objects, Performance counters MSRS 2016 Native Mode, performance objects, and Performance counters MSRS 2016 SharePoint Mode, performance objects.

Support for TLS

Reporting Services can use the HTTP SSL service to establish encrypted connections to a report server or SharePoint site. Transport Layer Security (TLS) was previously known as Secure Sockets Layer (SSL).

The alerting runtime service and data alerts user interface support TLS and works similarly whether you use TLS or HTTP. However, there are some subtle differences. When the data alert definition is created using and TLS connection, the URL that links back to the SharePoint library from the data alert message also uses TLS. You can identify the TLS connection because it uses HTTPS instead of HTTP in its URL. Likewise, if the data alert definition was created using an HTTP connection, the link back to the SharePoint site uses HTTP. Whether the alert definition was created using TLS or HTTP, the experience for users and alerting administrators are identical when using Data Alert Designer or Data Alert Manager. If the protocol (HTTP or TLS) should change between the time that the alert definition was created and then updated and resaved, the original protocol is kept and used in link URLs.

If you create a data alert on a SharePoint site that is configured to use TLS and then remove the TLS requirement the alert continues to work on the site. If the site is deleted, the default zone site is used instead.

Data alert user interface

Data alerts provide SharePoint pages for managing alerts and a designer for creating and editing data alert definitions.

Globalization of data alerts

Certain script such as Arabic and Hebrew are written right to left. Data alerts support right-to-left scripts and left-to-right scripts. Data alerts detect culture and alter the appearance and behavior of the user interface and the layout of data alert messages accordingly. The culture is derived from the regional setting of the operating system on the user's computer. The culture is saved each time you update and then resave the data alert definition.

The culture in the alert definition can affect whether data satisfies the rules in the alert definition. String comparisons are most commonly affected by culture specific rules.

Determining whether report data satisfies the rules in the alert definition can be affected by the culture in the alert definition. This event most commonly occurs in of strings. For example, in an alert definition with the German culture, a rule that compares the English letter "o" and the German letter "ö" wouldn't be satisfied. In the same alert definition using the English culture the rule would be satisfied.

Data formatting is also based the culture of the alert definition. For example, if the culture uses a period as the decimal symbol, then the value displays as 45.67; whereas a culture that uses a comma as the decimal symbol, displays 45,67.

Depending on which data alert user interface you use, the support for right-to-left varies. Data Alert Designer supports right-to-left script in text boxes, but the layout of the designer isn't right to left. Its layout is left to right like other tools. In an alert definition created with right-to-left text orientation and then edited in a left-to-right environment, the right-to-left text orientation is preserved when you save the alert definition. Data Alert Manager behaves the same as a SharePoint page. Its layout is right-to left, just like other SharePoint pages. Data alert messages that are based on right-to-left data alert definitions, display message text right to left and the message layout is left to right.

Related content