Облачная платформа Windows Azure как модель PaaS включает в себя не только СУБД-сервис Windows Azure SQL Databases (известный под именем SQL Azure), но и сервис отчетности Windows Azure SQL Reporting. Как известно, одним из преимуществ облачного подхода (независимо от провайдера облачных услуг) выступают эластичность и pay-for-play, т.е. привлечение ресурсов по мере надобности и плата за реально потребленные ресурсы, что избавляет организацию от необходимости приобретать навороченный дорогущий сервак, который будет большую часть времени простаивать и нагружаться только при закрытии отчетного периода. «Тяжеловесные» отчеты являются хорошими кандидатами на перевод в Облако. Технологическим преимуществом облачной отчетности является ее функциональная совместимость с on-premise технологией. Для разработчика, знакомого с SQL Server Reporting Services, процесс создания отчетов для Облака не будет отличаться от традиционных отчетов.
Сделанный в предыдущей статье отчет является достаточно незамысловатым, но на его примере можно в общих чертах разобрать процесс миграции отчета в Облако. Для начала создадим облачный сервер отчетности. Заходим в портал управления Windows Azure старого образца. В том, что вышел в виде preview в начале июня 2012 г., ни Reporting, ни Data Sync еще не реализованы. Если вы поспешили согласиться на предложение попробовать новый портал, нажмите на зеленую кнопку Preview вверху и выберите Take me to the previous portal. Нажимаем Reporting слева внизу:

Рис.1

Поскольку облачных серверов отчетности в текущей подписке еще нет, будет предложено создать новый SQL Azure Reporting Server:

Рис.2

Службы отчетности доступны во всех действующих облачных датацентрах Microsoft. Я создам его в западноевропейском центре (Амстердам), поскольку там же располагается облачный SQL Server, на котором будут храниться данные, на основе которых строится отчет, а трафик в пределах датацентра бесплатный. Как и в случае создания SQL Server, имя генерируется автоматически и изменению не подлежит.

Рис.3

Также будет предложено задать имя и пароль администратора сервера:

Рис.4

после чего сервер готов к принятию и выполнению отчетов.

Рис.5

Облачные отчеты создаются теми же инструментами (Report Designer в составе SSDT, Report Builder), что и локальные. Главная особенность состоит в том, что источником данных для него должна выступать Windows Azure SQL Database (SQL Azure), тогда как локальный отчет поддерживает массу встроенных и конфигурируемых источников данных:

Рис.6

Как мы видим, среди них присутствует SQL Azure, что позволяет реализовать гибридный, или, если угодно, промежуточный сценарий, когда отчет выполняется на локальном сервере отчетности, используя при этом данные из Облака.
Несмотря на значительное пересечение по функциональности облачного и on-premise SQL Server, если данные берутся из SQL Azure, в качестве источника надлежит указывать SQL Azure, а не SQL Server. В противном случае при деплойменте получится ошибка
An error has occurred during report processing. Tracing ID is: f8806086-edd3-4a68-89b6-26bd33504f82. (rsProcessingAborted)
The execution failed for the shared data set 'DataSet1'. (rsDataSetExecutionError)
An attempt has been made to use a data extension 'SQL' that is either not registered for this report server or is not supported in this edition of Reporting Services. (rsDataExtensionNotFound)

Для начала данные, на основе которых строится отчет, следует из локальной базы перенести в SQL Azure. Это можно сделать, используя массу способов, из которых мы разбирали пять: bcp, SSIS, DACPAC, BACPAC, SQL Azure Data Sync, и их комбинаций.
Я выбираю для простоты способ Deploy Database to SQL Azure, который выполняет экспорт локальной базы в BACPAC и тут же импортит его на заданный сервер SQL Azure:

Рис.7

Рис.8

После того, как данные переехали в Облако, соединение DataSource1 в отчете нужно переделать с локального SQL Server на облачный:

Рис.9

Теперь локальный отчет будет выполняться над облачными данными, как ранее над локальными. Если вдруг выскочит ошибка, что соединение с сервером было успешно установлено, но certificate's CN name does not match the passed value, добавьте в строку соединения Рис.9 ;TrustServerCertificate=True.
Перенесем отчет с локального Report Server в Облако. Самый простой способ это сделать — продеплоить его непосредственно из инструмента разработки, в данном случае, SSDT. В свойствах проекта (Project -> <имя проекта> Properties) в качестве Target Server Url указываем имя облачного сервера отчетности, которое мы видели в Azure Management Portal (Рис.5). Как обычно, задаем названия папок, куда будут помещаться общие источники данных и датасеты. Меняем свойства OverwriteDatasets и OverwriteDatasources на true. В противном случае, если датасет/источник данных с таким именем уже существует в этой папке, он не будет продеплоен:
— Deploy started: Project: Report Project1, Configuration: Debug — Deploying to iijsstvk71.reporting.windows.net/ReportServer
Deploying data source '/Data Sources/DataSource1'.
Warning: Cannot deploy data source DataSource1 to the server because it already exists and OverwriteDataSources is not specified.
Deploying data set '/Datasets/DataSet1'.
Warning: Cannot deploy dataset DataSet1 to the server because it already exists and OverwriteDatasets is not specified.

Рис.10

В строке меню SSDT перемещаемся на пункт Build и выбираем Deploy <имя проекта>.

Рис.11

Идем в Azure Portal -> Reporting и замечаем, что по сравнению с Рис.5 на сервере отчетности образовались папки Data Sources, Datasets и Report Project1, как было заказано на Рис.10.

Рис.12

Заходим в папку Report Project1, где наблюдаем свежепродеплоенный отчет:

Рис.13

Обратите внимание на кнопку Upload в верхнем меню. Она позволяет продеплоить отчет «вручную», т.е. не обязательно для этого прибегать к SSDT/Report Builder. Источник данных можно также создать непосредственно на портале – кнопка меню Create Data Source. Кликаем на отчет, вводим логин и пароль для авторизации на сервере отчетов:

Рис.14

Далее будет предложено ввести учетную запись, от имени которой Report Server обратится к источнику данных:

Рис.15

и после ее ввода получаем уже знакомый отчет в облачном исполнении:

Рис.16

Пользователи могут обращаться к отчету непосредственно по url, который мы видим в адресной строке, например, iijsstvk71.reporting.windows.net/ReportServer/Pages/ReportViewer.aspx?/Report%20Project1/Report1. Чтобы избежать постоянного ввода учетной записи, под которой сервер Azure Reporting ходит к SQL Azure, ее можно заперсистить в свойствах источника данных. Для этого на Рис.12 заходим в папку Data Sources, кликаем на Data Source1, отмечаем, что Credentials будут stored securely in the report server и вводим их. В этом случае окно Рис.15 выдаваться не будет.

Рис.17

Если вы используете ReportViewer Control, вы можете также избежать явного ввода учетной записи для доступа к серверу Azure Reporting Рис.14 при помощи authentication cookie, как показано здесь.

Примечание.
Начиная с 1 августа 2012 г., Windows Azure SQL Reporting, находившийся в стадии бесплатного preview, будет доступен в режиме коммерческой эксплуатации, в связи с чем предлагают решить, что делать с ранее созданными серверами: удалить или перевести на платную основу.

Рис.18

Ознакомиться с расценками можно при помощи калькулятора.

Рис.19

Службы отчетности SQL Server в Облаке