Share via


Scheduling and Delivery Processor

Reporting Services includes a Scheduling and Delivery Processor component to support scheduled operations and drive the delivery extensions used to push reports to e-mail inboxes or shared folder destinations.

The Scheduling and Delivery Processor is an internal component that the report server uses to process subscriptions and report delivery, or to refresh a snapshot or set the expiration for a cached report. If you are configuring server features or troubleshooting a subscription or delivery problem, you can use the information in this topic to understand the stages of scheduled processing and the dependencies on other services and technologies. This topic also introduces the configuration settings that you can use to manage the event queue.

How Scheduling and Delivery Processing Works

The Scheduling and Delivery Processor provides the following functionality:

  • Maintains a queue of events and notifications in the report server database. In a scale-out deployment, the queue is shared across all of the report servers in the deployment.

  • Calls the Report Processor to execute reports, process subscriptions, or clear a cached report. All report processing that occurs as a result of a schedule event is performed as a background process.

  • Calls the delivery extension that is specified in a subscription so that the report can be delivered.

Other aspects of a scheduling and delivery operation are handled by other components and services that work with the Scheduling and Delivery Processor. Specifically, the Scheduling and Delivery Processor runs in the Report Server service and uses SQL Server Agent as a timer to generate scheduled events. The following step-by-step description explains how the scheduled operations work in a Reporting Services deployment:

  1. A scheduled operation is defined when a user creates a schedule. The schedule defines a date and time that will be used to trigger a subscription for report delivery, refresh a snapshot, or expire a cache.

  2. The report server saves the schedule information in the report server database.

  3. The report server creates a corresponding job in SQL Server Agent that includes the schedule information provided. The jobs are created through a stored procedure, using the existing open connection to the report server database.

  4. SQL Server Agent runs the job on the date and time specified in the schedule. The job creates an event that is added to a queue maintained by Reporting Services.

  5. The event causes a report or subscription process to occur. Events are processed when they are detected in the queue, and the report is processed or delivered accordingly.

    Before the events are processed, the Scheduling and Delivery Processor performs an authentication step to verify that the subscription owner has permission to view the report. For more information about subscriptions, see Subscription Processing.

Reporting Services maintains an event queue for all scheduled operations. It polls the queue at regular intervals to check for new events. By default, the queue is scanned at 10 second intervals. You can change the interval by modifying the PollingInterval, IsNotificationService, and IsEventService configuration settings in the RSReportServer.config file. For more information, see RSReportServer Configuration File.

Server Dependencies

The Scheduling and Delivery Processor requires that the Report Server service and SQL Server Agent are started. The Schedule and Delivery Processing feature must be enabled through the ScheduleEventsAndReportDeliveryEnabled property of the Surface Area Configuration for Reporting Services facet in Policy-Based Management. Both SQL Server Agent and the Report Server service must running in order for scheduled operations to occur.

Note

You can use the Surface Area Configuration for Reporting Services facet to stop scheduled operations on a temporary or permanent basis. Although you can create and deploy custom delivery extensions, by itself the Scheduling and Delivery Processor is not extensible. You cannot change how it manages events and notifications. For more information about turn off features, see How to: Turn Reporting Services Features On or Off.

Effects of Stopping the SQL Server Agent

Scheduled report processing uses SQL Server Agent by default. If you stop the service, no new processing requests are added to the queue unless you add them programmatically through the FireEvent method. When you restart the service, the jobs that create report processing requests are resumed. The report server does not try to recreate report processing jobs that might have occurred in the past, while SQL Server Agent was offline. If you stop SQL Server Agent for a week, all scheduled operations are lost for that week.

Note

The functionality that SQL Server Agent provides to Reporting Services can be replaced with custom code that uses the FireEvent method to add schedule events to the queue.

Effects of Stopping the Report Server Service

If you stop the Report Server service, SQL Server Agent continues to add report processing requests to the queue. Status information from SQL Server Agent indicates that the job succeeded. However, because the Report Server service is stopped, no report processing actually occurs. The requests will continue to accumulate in the queue until you restart the Report Server service. Once you restart the Report Server service, all report processing requests that are in the queue are processed in order.