WINDOWS AZURE SQL REPORTING

Transcription

1 WINDOWS AZURE SQL REPORTING BY HERVE ROGGERO

2 INTRODUCTION This white paper introduces you to Windows Azure SQL Reporting, a feature of the Azure platform allowing you to manage and run reports in the cloud with built-in security and scalability. As you will see in this paper, deploying and using Windows Azure SQL Reporting is very simple and only requires a few clicks to get going. WHY USE WINDOWS AZURE SQL REPORTING? Windows Azure SQL Reporting (WASR) is one of the key services provided by Windows Azure allowing customers to run reporting services in a hosted environment. Because WASR is designed for scalability, you do not need to spend time on advanced configuration settings for performance or high availability. As a DBA or developer you no longer need to worry about the configuration details of your reporting infrastructure. For example, you do not need to determine whether you need to scale up your report server or use additional report servers as a scale out model. You do not need to worry about your catalog either and whether or not it should be hosted on a remote server, or how to best configure your reporting servers on multiple processors, how to configure web gardens for delivering reports, creating cached snapshots or data, or even how much memory is needed on which servers. And the list goes on ABOUT THE AUTHOR Herve Roggero, SQL Azure MVP, is the founder of Blue Syntax Consulting, a company specialized in cloud computing products and services. Herve s experience includes software development, architecture, database administration and senior management with both global corporations and startup companies. Herve holds multiple certifications, including an MCDBA, MCSE, MCSD. He also holds an master s in business administration from Indiana University. Herve is the co-author of PRO SQL Azure from Apress. The primary advantage of WASR is its trivial configuration, allowing you to focus on delivering higher business value to your projects and concentrate on more important tasks. In turn, this allows developers to be up and running in minutes giving the business more flexibility to request new reports and make timely decisions. Using WASR will remove typical infrastructure headaches associated with complex reporting environments and deliver new reports faster. Another important benefit of WASR is its pay-for-what-you-use financial model, which is typical for cloud computing services. In other words, the more you run reports, the more you pay. Keep in mind however that there is a minimum charge for running a reporting server; even if you are not running reports, you may still incur charges for hosting a reporting server.

3 CONFIGURING WINDOWS AZURE SQL REPORTING As mentioned previously, provisioning and configuring WASR is simple and generally involves the following steps: Create a new reporting service Publish reports Configure security CREATE A NEW REPORTING SERVICE To create a new reporting service in the cloud, you first need to open a Windows Azure account 1 if you do not already have one. Once you have a Windows Azure account, go to the Windows Azure management portal 2 to view your services. The next screen asks you for the user name and password of the administrative account of the SQL Reporting service you are creating including a strong password as shown in Figure 2. The administrator account cannot be admin, administrator, sa, root, guest, dbmanager or loginmanager for security reasons. Click Finish to provision the Windows Azure Reporting Server. To create a new reporting service, select Reporting and click on Create a New SQL Reporting Server. You will need to select your subscription and the region where the server will be located, as shown in Figure 1, then click Next. Figure 2: Creating a new SQL Reporting Server (step 2) At this point you have created a reporting server in the cloud in which you can deploy reports and manage access control. PUBLISH A REPORT Let s take an existing report that was created with Visual Studio 2008 Reporting Services 3. Before publishing the report, you will need to make certain modifications. The following assumes that you already have a database published in Windows Azure SQL Database (SQL Database in short) that the report can connect to. Figure 1: Creating a new SQL Reporting Server You can also convert reports created in Report Builder 3.0. However at this point you can only publish reports in WASR using Report Builder.

4 PROJECT CONFIGURATION The first thing to change is the reporting project configuration; right-click on the reporting project solution and select Properties. This brings up the project s property page as seen in Figure 3. SHARED DATA SOURCES You also need to determine if your shared data sources need to be changed as seen in Figure 4. WASR does not support data sources other than SQL Databases (set the connection type to Microsoft SQL Azure) and requires SQL authentication. You also need to ensure that the Initial Catalog is provided as part of the connection string, otherwise your report will connect to the master database. Figure 3: Changing the Reporting Project Settings Target Server URL This property contains the WASR service URL, which should look like this: reportserver Target Server Version Change the target version to Microsoft SQL Azure 4. CUSTOM EXTENSIONS The next task is to remove any extensions that may exist in your report. Because you cannot deploy DLLs in WASR, your report cannot use custom extensions; this includes data, processing, rendering and any other type of extension. 4 Depending on your environment, Microsoft SQL Azure may not be available. If this is the case, select SQL Server 2008 R2. Figure 4: Data Source Configuration On the Credentials tab, you can select from one of the following options (the other two options, Use Windows Authentication and Do not use credentials, are not supported against SQL Databases): Use this user name and password This setting allows you to embed the user name and password of your SQL Database connection inside this data source. Prompt for credentials This setting will ask the user for the database credentials when the report is rendered.

5 REPORT DATA SOURCES The data source provided within a report can point to a shared data source or be embedded inside the report. Embedding a data source in the report is possible but can make maintenance more difficult over time if the data source needs to be changed. If you are using embedded data sources, make sure you apply the same considerations that are discussed in the Shared Data Sources section above. DEPLOY THE REPORT Now that the report has been modified appropriately, you are ready to deploy it. You may want to run it locally to make sure you can connect to the SQL Database specified in the data source. Right-click on it and choose Deploy to publish the report in Azure. If the server URL was correctly set, a login screen will show. Enter your administrator user id and password created previously, as shown in Figure 5. Once the report is deployed, you will see the report in the Windows Azure SQL Reporting portal along with a Data Sources folder that contains the shared data source. You can change the shared data source in the portal directly if needed. USER ACCESS CONTROL Now that the reports have been deployed they are ready to be run. Because reports deployed in Azure are secured, we need to authorize users to run our report. Although we could use the administrator account created previously to run our report, it is good security practice to create another account for running reports. To do so, click the Manage icon on the User tab on top of the Windows Azure SQL Reporting management portal and create a new user, as shown in Figure 6. Figure 5: Deploy the Report Figure 6: Adding a User

6 RUNNING THE REPORT At this point you are ready to run the report. Navigate to the folder containing your report and click on it. A login page will appear that represents the first security layer for WASR. Enter the credentials of the user created previously (user1) and click on Sign In. In order to run a report from an application (web application or windows application), your code will need to connect to WASR with a service account. You create a service account like any other user account; just limit the use of this login account to the application. The code can then set specific report parameters that are valid for the current user and launch the report in the report viewer. If you need further details on how to programmatically access reports, see the Getting Started Guide for Application Developers 5. CURRENT LIMITATIONS Windows Azure SQL Reporting has several limitations worth mentioning. Note that limitations in any cloud provider are bound to evolve over time, so make sure to check the Guidelines and Limitations for Windows Azure SQL Reporting MSDN article. Figure 7: Running the Report Because the report uses a shared data source with embedded database credentials, no further logins are required. However, if you did not save the database credentials as part of the shared data source or embedded data source, another login screen would appear asking for database credentials. DIRECT VERSUS APPLICATION ACCESS We previously discussed security in the context of user access allowing individuals to run reports directly in the cloud. As long as a user can provide credentials to login, the user can run reports from anywhere. Alternatively, you may have to limit access to reports based on the user, or pre-fill report parameters that filter data for the user currently viewing the report. If filtering data is a security requirement, you may need to prevent users from connecting directly to the report and require access through an application. Some of the limitations apply to the reporting engine itself, to the security configuration, support for existing tools and more. Here are some of the limitations to consider: As mentioned previously, WASR requires a SQL Database connection to work with; it does not currently support a SQL Server database connection Users must be defined in the WASR management portal itself; you cannot link your existing security infrastructure with WASR Custom extensions and custom assemblies are not supported as mentioned previously; you cannot add custom code in the Code element of a report Although you can build reports for Azure with Report Builder 3.0, you can only deploy them using BI Development Studio projects Only the native mode is supported; SharePoint integrated mode is not currently supported Report images need to be embedded; they cannot link to an external resource. However you can include databases stored in a database that are no more than 1MB is size 5

7 CONCLUSION Windows Azure SQL Reporting shines in its simplicity and automatic scalability. As discussed previously you can easily deploy existing reports and create new ones in minutes and make them available to any interested party either by providing links to those reports, or by embedding them in your web or windows applications. As usual the key in using a web service successfully is to understand its current limitations to avoid surprises during deployment. Windows Azure SQL Reporting is now available commercially and a fully supported Azure service. ABOUT IDERA Idera provides systems and application management software for Windows and Linux Servers, including solutions for performance monitoring, backup and recovery, security and compliance and server administration. Our market leading product suites provide 360 degree management solutions for the Microsoft SQL Server and SharePoint platforms as well as high performance backup and recovery for server operating systems. Whether you have ten servers or ten thousand, we give you the best performance and value with products that are easy to install and deploy and that deliver real and measurable ROI. Idera is headquartered in Houston, TX with offices in London and Melbourne. US EMEA APAC MEXICO BRAZIL WEB TWITTER FACEBOOK LINKEDIN GO IDERA ( ) +44 (0) (55) (11)