Schedules
Reporting Services provides shared schedules and report-specific schedules to help you control processing and distribution of reports. The difference between the two types of schedules is how they are defined, stored, and managed. The internal construction of the two types of schedules is the same. All schedules specify a type of recurrence: monthly, weekly, or daily. Within the recurrence type, you set the intervals and range for how often an event is to occur. The type of recurrence pattern and how those patterns are specified is the same whether you create a shared schedule or a report-specific schedule.
In this topic:
What you can do with Schedules
You can use Report Manager in Native mode and SharePoint site administration pages in SharePoint mode to create and manage your schedules. You can:
Schedule report delivery in a standard or data-driven subscription.
Schedule report history so that new snapshots are added to report history at regular intervals.
Schedule when to refresh the data of a report snapshot.
Schedule when to refresh the data of a shared dataset
Schedule the expiration of a cached report or shared dataset to occur at a predefined time so that it can be subsequently refreshed.
You can create a shared schedule if you want to use the same schedule information for many reports or subscriptions. Shared schedules are defined separately, and then referenced in reports, shared datasets, and subscriptions that need schedule information.
When you create a schedule, the report saves the schedule information in the report server database or for SharePoint mode, the service application database. The report server also creates a SQL Server Agent job that is used to trigger the schedule. Schedule processing is based on the local time of the report server that contains the schedule. The time format follows the Microsoft Windows operating system standard.
For details on how to create and manage schedules, see Create, Modify, and Delete Schedules.
Note
Schedule operations are not available in every edition of SQL Server. For a list of features that are supported by the editions of SQL Server, see Features Supported by the Editions of SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).
Comparing Shared and Report-Specific Schedules
Both types of schedules yield the same output:.
Shared schedules are portable, multipurpose items that contain ready-to-use schedule information. Because shared schedules are system-level items, creating a shared schedule requires system-level permissions. For this reason, a report server administrator or content manager typically creates the shared schedules that are available on your report server. Shared schedules are stored and managed on the report server by using Report Manager or SharePoint site settings.
In contrast with specific schedules that you define through report, shared dataset, or subscription properties, shared schedules are easier to manage and maintain for the following reasons:
Shared schedules can be managed from a central location, making it easier to compare schedule properties and adjust frequency and recurrence patterns if scheduled operations are running too close together or conflicting with other processes on your server.
Allows you to quickly adapt to changes in the computing environment. For example, suppose you have a set of reports that run at 4:00 A.M. after a data warehouse is refreshed. If the data refresh operation is rescheduled or is delayed, you can easily accommodate that change by updating the schedule information in a single shared schedule.
If you use only shared schedules, you know precisely when scheduled operations occur. This makes it easier to anticipate and accommodate server loads before performance issues occur. For example, if you decide to schedule computer backups at a specific hour, you can adjust shared schedules to run at different times.
Report-specific schedules are defined in the context of an individual report, subscription, or report execution operation to determine cache expiration or snapshot updates. These schedules are created inline when you define a subscription or set report execution properties. You can create a report-specific schedule if a shared schedule does not provide the frequency or recurrence pattern that you need. To prevent a report from running, you must edit a report-specific schedule manually. Report-specific schedules can be created by individual users.
Configure the Data Sources
Before you can schedule data or subscription processing for a report, you must configure the report data source to use stored credentials or the unattended report processing account. If you use stored credentials, you can only store one set of credentials, and they will be used by all users who run the report. The credentials can be a Windows user account or a database user account.
The unattended report processing account is a special-purpose account that is configured on the report server. It is used by the report server to connect to remote computers when a scheduled operation requires the retrieval of an external file or processing. If you configure the account, you can use it to connect to external data sources that provide data to a report.
To specify stored credentials or the unattended report processing account, edit the data source properties of the report. If the report uses a shared data source, edit the shared data source instead.
Store Credentials and Processing accounts
How you work with a schedule depends on tasks that are part of your role assignment. If you are using predefined roles, users who are Content Managers and System Administrators can create and manage any schedule. If you use custom role assignments, the role assignment must include tasks that support scheduled operations.
| To do this | Include this task | Native Mode Predefined roles | SharePoint mode Groups |
|---|---|---|---|
| Create, modify, or delete shared schedules | Manage shared schedules | System Administrator | Owners |
| Select shared schedules | View shared schedules | System User | Members |
| Create, modify, or delete report-specific schedules in a user-defined subscription | Manage individual subscriptions | Browser, Report Builder, My Reports, Content Manager | Visitors, Members |
| Create, modify, or delete report-specific schedules for all other scheduled operations | Manage report history, manage all subscriptions, manage reports | Content Manager | Owners |
For more information about security in Native mode Reporting Services, see Predefined Roles, Granting Permissions on a Native Mode Report Server and Tasks and Permissions. For SharePoint mode, see Compare Roles and Tasks in Reporting Services to SharePoint Groups and Permissions
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. SharePoint mode utilizes timer jobs to .
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:
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.
The report server saves the schedule information in the report server database.
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.
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.
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.
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. SharePoint mode also uses the RSreporserver.config for these settings and the values apply to all Reporting Services service applications. 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 the Scheduled Events and Delivery section of 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.
See Also
Create, Modify, and Delete Snapshots in Report History
Subscriptions and Delivery (Reporting Services)
Data-Driven Subscriptions
Caching Reports (SSRS)
Report Server Content Management (SSRS Native Mode)
Cache Shared Datasets (SSRS)