The very recent Microsoft Data Amp event provided an excellent forum for the SQL Server 2017 announcement, which is due to be released at some point this year. Perhaps the most touted feature of the new version is that it will be available to be installed on Linux; an entirely inconceivable premise 10 years ago, which just goes to show how far Microsoft have changed in their approach to supporting non-Windows platforms as standard. Past the big headline announcements, there is a lot to look forward to underneath the hood with SQL Server 2017 that may act as encouragement for organisations looking to upgrade in the near future.

In this week’s post, I’ll be taking a closer look at 3 new features I am most looking forward to, that are present within the SQL Server Community Technical Preview (CTP) 2.0 version and which will form part of the SQL Server 2017 release later on this year.

Power BI in SSRS: A Match Made in Heaven

This is by far the feature I am most looking forward to seeing in action. I have been working more and more with Power BI this year, often diving into the deep-end in respect to what can be achieved with the product, and I have been impressed with how it can be used for addressing reporting scenarios that SSRS may struggle with natively. The announcement earlier this year that Power BI would be included as part of SSRS in the next major release of the product was, therefore, incredibly welcome and its inclusion as part of SQL Server 2017 is confirmed by the inclusion of Power BI reports in the CTP 2.0 release.

For those who are already familiar with Power BI, there is thankfully not much that you need to learn to get up and running with Power BI in SSRS. One thing to point out is that you will need to download a completely separate version of the Power BI Desktop App to allow you to deploy your Power BI reports to SSRS. I would hope that this is mitigated once SQL Server 2017 is released so that we are can deploy from just a single application for either Online or SSRS 2017. Users who are experienced with the existing Power BI Desktop application should have no trouble using the equivalent product for SSRS, as they are virtually identical.

The actual process of deploying a Power BI report is relatively straightforward. After making sure that you have installed the SSRS Power BI Desktop Application, you can then navigate to your SSRS homepage and select + New -> Power BI Report:

You will be greeted with a prompt similar to the below and the Power BI Desktop application will open automatically:

Now it’s time to build your report 🙂 As an example, I have used the WideWorldImporters Sample Database to build a simplistic Power BI report:

If you were working with Power BI online, then this would be the stage where you would click the Publish button to get it onto your online Power BI tenant. The option to deploy to your SSRS instance is currently missing from Power BI in SSRS application; instead, you will need to manually upload your .pbix file into Reporting Services via the Upload button. Once uploaded, your report will be visible on the home page and can be navigated to in the usual manner:

Simplified CSV Importing

Anyone who has at least some experience working with databases and application systems should have a good overview of the nuances of delimited flat file types – in particular, Comma Separated Value (.csv) files. This file type is generally the de-facto format when working with data exported from systems and, more often than not, will be the most common file type that you will regularly need to import into a SQL Server database. Previously, if you didn’t opt to use the Import Wizard/.dtsx package to straightforwardly get your .csv file imported, you would have to rely on the following example script:

BULK INSERT dbo.TestTable
FROM 'C:\Test.csv'
WITH
	(
		FIELDTERMINATOR = ',',
		ROWTERMINATOR = '\n'
	)

Now, with SQL Server 2017, you can simplify your query by replacing FIELDTERMINATOR and ROWTERMINATOR with a new FORMAT parameter, that specifies the file format we are concerned with:

BULK INSERT dbo.TestTable
FROM 'C:\Test.csv'
WITH (FORMAT = 'CSV');

Whilst the overall impact on your query length is somewhat negligible, it is nice that a much more simplified means of accomplishing a common database task has been introduced and that we now also have the option of accessing Azure Blob Storage locations for import files.

Updated Icons for SSMS

Typically, as part of any major update to the application, the “under the hood” visual side of things are generally not changed much. A good example of this can be found within CRM Online/Dynamics 365 for Enterprise within the Customizations area of the application, which has not seen much of a facelift since CRM 2011. As a result, a lot of the icons can look inconsistent with the application as a whole. As these are generally the areas of the application that we use the most day in, day out, it can be a little discouraging not to see these areas get any love or attention as part of a major update… 🙁

With this in mind, it is pleasing to see that the updated SSMS client for SQL Server 2017 has been given refreshed icons that bring the application more in line with how Visual Studio and other Microsoft products are looking these days. Below is a comparison screenshot, comparing SSMS 2014 with SSMS 2017:

Conclusions or Wot I Think

Whilst there is a lot more to look forward to with the new release that is not covered in this post (for example, the enhancements to R server and deeper integration with AI tools), I believe that the most exciting and important announcement for those with their Business Intelligence/Reporting hats on is the introduction of Power BI into SSRS. Previously, each tool was well suited for a specific reporting purpose – SSRS was great for designing reports that require a lot of visual tailoring and widely common formats for exporting, whereas Power BI is more geared towards real-time, dashboard views that marry together disparate data sources in a straightforward way. By being able to leverage SSRS to fully utilise Power BI reports, the application suddenly becomes a lot more versatile and the potential for combining together functionality becomes a lot more recognisable. So, for example, having the ability to drill down to an SSRS report from a Power BI report would be an excellent way of providing reporting capabilities that satisfy end-user consumption in 2 different, but wildly applicable, scenarios.

In summary, the SQL Server 2017 release looks to be very much focused on bringing the product up to date with the new state of play at Microsoft, successfully managing to achieve cross-platform requirements alongside bringing exciting functionality (that was previously cloud-only) into the hands of organisations who still have a requirement to run their database systems on their on-premise infrastructure. I’m eagerly looking forward to the release later on this year and in seeing the product perform in action. 🙂

A software upgrade/update always starts out with such good intentions and hopeful optimism. There are perhaps two opposing schools of thought that emerge when it comes to the merits and necessity of always ensuring you’re on the latest version of an application. The arguments for and against will generally look something like this:

In Favour

  • Having the latest version protects against potential exploits or security vulnerabilities present within an older version of the application.
  • The latest version of the application is easier to use, supports X feature etc.
  • The application will be end of life in the very near future, so we need to be proactive as opposed to reactive*

Against

  • The upgrade will take time to complete – we will have to perform in-depth testing and schedule time outside of normal business hours to carry this out.
  • As part of the XXX update, X feature is no longer available and we have to instead use Y feature instead.
  • The current version of the application works just fine – upgrading could cause us problems as a result of a bad security patch or similar.

*”very near future” is becoming more commonplace these days, particularly with Microsoft Cloud products. For example, Office 2013 is technically considered end of life for ProPlus customers at the end of this month.

Whilst I would argue strongly that keeping your important business applications up to date should always be an ultimate priority, the reality is less straightforward and even I have fallen foul of this in the past. Case in point: I recently upgraded to the Windows 10 Anniversary Edition from Windows 10, on a personal machine that had Hyper-V installed and a number of virtual images. The update went fine, but I was informed after the update that the latest version of .NET Framework needed to be downloaded. I dismissed the error message, as I was in the middle of something else, and then spent many hours later on attempting to figure out why the update had removed the Hyper-V program feature from my machine; after researching, I determined it was because of the prompt I had received when first booting up Windows and that the updated version of Hyper-V required the latest .NET Framework. I was able to get the role installed and re-configure all of my virtual images accordingly, but it did take some time and was definitely an unwelcome distraction! Suffice to say, an upgrade can never go exactly to plan, which is why I would always encourage the need for dedicated testing environments within your business for your primary IT systems. This will grant that you sufficient latitude to perform all required testing of an update and to give you the confidence that it can be deployed safely into your production environment(s).

Of course, the above does not help very much if you are upgrading your test environment and everything goes wrong there, such as what happened to me recently. The business in question was wanting to upgrade from Visual Studio 2013 to Visual Studio 2015. Their development environment was a virtualised, remote desktop server, which all of the developers logged into as their primary working environment. Development was carried out using the “out of the box” templates included in Visual Studio (C#, ASP.NET etc.) and also using SQL Server Data Tools for BIDS/SSIS development. All projects/solutions were stored in a central Git repository.

The process of installing Visual Studio 2015 and the current “production ready” 16.5 version of SQL Server Data Tools for Visual Studio 2015 went (rather too) swimmingly, and we began to run tests confirming that all Team Services projects opened without issue. We immediately came across an issue when attempting to open certain .rdl report files – Visual Studio would hang for about 10-15 minutes every time the report was opened, with the following prompt stuck on the screen and the application remaining in a non-responsive state:

The report would open fine in the end, but the issue was repeated whenever the report was re-opened.

We initially tried the following in an attempt to resolve the problem:

  • Re-cloned the repository – no joy.
  • Attempted to open the report from VS 2013 – the report opened fine without issue, so definitely a problem with VS 2015
  • Created a brand new Report Project template in VS 2015, added the report into the project (both as a copy and as a new report, with the underlying .xml definition copy + pasted) and then tried re-opening – the same issue occurred.

Being officially stumped at this juncture, I then did some further research online to see whether anyone else had encountered the same issue. Fortunately, I came across the following TechNet thread which contained the exact same symptoms we were experiencing:

https://social.technet.microsoft.com/Forums/sqlserver/en-US/ba55ce1b-0bac-4997-9e02-8748dfd38fae/opening-large-reports-in-ssrs-2016-takes-a-long-time-after-migratting-from-ssrs2012?forum=sqlreportingservices&prof=required

The thread seemed to attract some confused answers (in the sense that they didn’t grasp the underlying problem), before petering out with no apparent solution. Without holding my breath too much, I replied to the thread in the hopes of getting a definitive answer, which I received in almost record time:

Yes we did, we got a fix from Microsoft: https://go.microsoft.com/fwlink/?linkid=837939. After installing the reports where opening fine.

Not wishing to look a gift horse in the mouth at all, I did first double check the contents of the link to verify it – and it turned out to be 17.0 RC2 of SQL Server Data Tools for Visual Studio 2015. What’s worth noting is that the first hit on Google for SQL Server Data Tools Visual Studio 2015 is the download page for version 16.5 and not the following page that contains links to both versions:

https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt

Those who have already read through the TechNet thread will know how things panned out in the end, but just to summarise – installing this fixed the issue. So major credit to Erwin de Kreuk for doing all of the “hard work” to finding the solution in this unusual case and in responding so quickly to my forum post. This is definitely a great example of the old adage “You don’t ask, you don’t get” and how the wider community can often prove invaluable when resolving an especially troublesome IT issue.

So what should you do if you are planning to upgrade SSDT from Visual Studio 2013 to Visual Studio 2015?

The key takeaway from the above should be the fact that a release-candidate version of SSDT provided a resolution to the problem at hand. It would, therefore, be foolhardy to recommend a general upgrade from VS 2013 whilst 17.0 remains at a release-candidate version. Given that this version was released at the start of the year, it is highly likely to expect that a production-ready version of 17.0 will be released in the very near future. I would recommend holding off on your upgrade if your organisation works with a large number of SSRS reports, lest you also fall foul of this surprisingly strange bug.

Getting to grips with how to use Dynamics CRM/365 for Enterprise (D365E) is no easy feat. You can imagine just how difficult it is for an end user to get to grips with how the application works and functions; with more detailed knowledge around customisation and development being an entirely different ball game altogether. Compounding this problem further is the fact that the product has evolved at an increasingly more rapid pace over recent years, to the point where it is literally impossible to become a master of everything that you can do within CRM/D365E. Those venturing into the product for the first time may find their learning journey significantly simplified if they already have a good general knowledge about some of the underlying technology that powers CRM/D365E. This was certainly true in my case; I had a good background already in managing Office 365, writing SQL queries/reports and some experience with C#. This is all incredibly useful knowledge to have in your arsenal and is all directly applicable towards CRM/D365E in some way. For those who are getting to grips with the product for the first time, either without this previous experience or as part of an apprentice/graduate type role, your journey may not be as swift and issue-free. With this in mind, here’s my list of essential knowledge that you can add to your own “swiss army knife” of personal knowledge. Experience and good knowledge of these technologies will not only help you greatly in working with CRM/D365E, but present an excellent learning opportunity for Microsoft technologies more generally and something that you can add to your CV with pride:

SQL Server

What is it? : SQL Server is Microsoft’s proprietary database knowledge, based on the ANSI standard. SQL stands for Structured Query Language and is one the most widely used database programming languages on the planet.

Why Knowing It Is Useful: The underlying database technology that CRM/D365E uses is SQL Server, so having a general awareness of relational database systems work and how SQL Server differs from the standard goes a long way in understanding what is capable from a customisation/development viewpoint. For example, you can very quickly grasp which data types the application supports, as they will all ultimately be based on a supported SQL Server column data type. If you are running on-premise versions of CRM/D365E, then knowledge of SQL Server immediately moves from being a nice bonus to an essential requirement. This is because administrators will need to have good knowledge of how to manage their Dynamics CRM database instance, perform backups and also, potentially, write transact-SQL (T-SQL) queries against your database for reporting or diagnostic work.

Recommended Area of Study: Focusing your attention towards SQL Server Reporting Services (SSRS) report writing will benefit you the most. Through this, you can begin to establish good knowledge of how SQL Server databases work generally, and be in a position to write FetchXML for Online/On-Premise deployments of the application or Transact-SQL (T-SQL) based reports for On-Premise only. Having a good awareness of what is capable via a standard SQL query will also hold your good stead when working with FetchXML, as you can immediately make a number of assumptions about what is possible with FetchXML (for example, filtering results using an IN block containing multiple values and performing grouping/aggregate actions on datasets)

Office 365

What is it? : Office 365 is Microsofts primary – and perhaps most popular – cloud offering for businesses, individuals or home users. Through a wide array of different subscription offers, home and business users can “pick ‘n’ mix” the range of solutions they require – from Exchange-based email accounts to licenses for Microsoft Visio/Project, through to PowerBI.

Why Knowing It Is Useful: Although it is arguable that knowledge of Office 365 is not essential if you anticipate working with on-premises versions of the application, you may be doing yourself a disservice in the long term. Microsoft is increasingly incentivising organisations to move towards the equivalent cloud versions of their on-premise applications, meaning that as much knowledge as possible of how CRM/D365E Online works in the context of Office 365 is going to become increasingly more mandatory. If you are looking to secure a career change in the near future, and have not had much experience with Office 365, then this is definitely an area that you should focus on for future learning. From a day-to-day management point of view for the Online version of the product, some basic awareness of how to navigate around and use Office 365 is pretty much essential if you are going to succeed working with the product on a day-to-day basis.

Recommended Area of Study: Spin up a D365E trial, and you can very quickly start getting to grips with how the product sits within the Office 365 “ecosystem”. Practice licensing users, configuring security group level access to your D365E trial tenant and modify the details on Office 365 user accounts to see how these details are synced through into D365E. The Microsoft Virtual Academy also has a number of general courses related to Office 365 however, due to the frequent updates, it may not always be in-line with the current version. The official curriculum/certification paths for Office 365 may also suffer the same from this but are worthwhile in demonstrating your experience and ability to integrate D365E with the various related Office 365 services.

Active Directory

What is it? : For the rookie, intermediate and experienced IT admins, Active Directory needs no introduction. It is essentially Microsoft’s implementation of the Lightweight Directory Access Protocol (LDAP), having first being introduced in Windows Server 2000, providing a means of managing user, security and access rights for domain objects. There are now two distinct versions of Active Directory that are available – the more traditional, Windows server based, on-premise Active Directory and Azure Active Directory, which is utilised primarily by Office 365.

Why Knowing It Is Useful: User account records for both On-Premise and Online versions of CRM/D365E use Active Directory objects, with a number of important information synchronised between an Active Directory user and the equivalent User entity record. For example, as indicated in this MSDN article, the only way in which you can synchronise a user’s Job Title through to CRM/D365E is by updating the equivalent field on the Azure Active Directory. Active Directory objects are also the only way in which you can authenticate with the application via the Web Interface or other means, with no option to create a database user or other kind of authenticated user type.

Recommended Area of Study: It’s free to set up your own Azure Active Directory, so this is an excellent starting point for getting to grips with the technology. There’s also nothing preventing you from downloading a trial of Windows Server and installing the Active Directory server role on this machine. Once configured, you can then start to create users, update attributes, configure permissions and setup roles that contain collections of privileges. If you already have an Office 365 tenant with CRM/D365E Online, then you can use the Office 365 portal to manage your user accounts and test the synchronisation of attribute values from the Active Directory through to the application.

PowerShell

What is it? : A good way to remember what PowerShell is that it is essentially a blue command prompt window 🙂 . Traditionally only being relevant and important for those working extensively with Windows Server or Exchange, PowerShell is now increasingly important as part of administrating on-premise CRM/D365E, Office 365 and Azure, to name a few. Indeed, one of the major shock announcements this year was that PowerShell became open sourced and can be installed on Linux; representing the increasing demand and importance of Linux-based resources within the Microsoft cloud.

Why Knowing It is Useful: Similar to SQL Server, PowerShell is something that is instantly more applicable for on-premise CRM/D365E deployments. For example, the only way to modify the default number of Dashboard items is via executing the Get-CRMSetting cmdlet against your on-premise organisation. I would also, again, argue having a general awareness of PowerShell can help greatly when performing administration work against an Office 365 tenant that contains a CRM/D365E organisation, such as user provisioning or license assignment. If you are utilising the Azure Service Bus to integrate CRM/D365E for Azure-based applications, then PowerShell immediately becomes a desirable skill to have in your arsenal, allowing you to remotely administer, deploy or update Azure resources programmatically.

Recommended Area of Study: The fact that PowerShell is now open sourced means that there is a plethora of online tools and guides to refer to, and you can be assured that you can get it working on your platform of choice. The GitHub page for PowerShell is a great place to get started. Beyond that, you have a few options about how you can practice further. If you have spun up a D365E trial, then you can choose to hook up PowerShell to Office 365 to see what you can do from a remote management perspective (such as granting Send On Behalf permissions for a shared mailbox). Alternatively, you can run it from your local Windows machine, connect it up to a Windows Server instance or attempt to create new services in Azure and experiment that way.

This is the second part of my 2-part series, continuing our evaluation of the new Word Templates feature versus the traditional CRM/SSRS Reports route. Word Templates were recently introduced as part of CRM 2016, and are one of the big new features that has got me really excited about the future of CRM. What I am keen to discover is if they can be utilised as effectively as .rdl CRM Reports to produce high quality and professional looking documents.

Last week we took a look at the process and steps involved in setting up a Report. So now, let’s make a start and go through the step-by-step process of setting up a Word Template document on a CRM 2016 instance:

  1. From a setup point of view, there is much less that is required in order to start working with Word Templates:
    • CRM Online 2016: If you don’t have access to a CRM Online 2016 instance, you can either reset a Sandbox Instance or start a free 30 day trial. My understanding is that Word Templates have been introduced as part of 2016 On-Premise CRM, but I’m unable to confirm this.
    • Microsoft Word 2013/2016
  2. Log into your CRM instance and navigate to a supported record type. For this example, we are going to use Lead:WordTemplate_2
  3. On the Form Ribbon, click on the ellipse to expand the button Options and select ‘Word Templates‘:WordTemplate_4
  4. You will then be greeted with the ‘Create template from CRM data‘ window, enabling you to specify the template type you want to create (Excel or Word), confirm the entity data you wish to use and choose whether to upload an existing template or create one from scratch. We’ll click on Word Template and then press ‘Select Entity‘ to proceed:WordTemplate_5
  5. Finally, CRM will display an informational window which gives the user a quick summary of the different related record types and, therefore, what additional fields can be displayed on your Word Template. This can be quite useful for novice CRM users or for those who are unfamiliar with how a particular CRM system has been customised. When you are ready to continue, press ‘Download Template‘ and then save the document to your local computer:WordTemplate_6
  6. Once downloaded, open the template. You’ll be greeted with a blank Word document, similar to the below:
    WordTemplate_8

Don’t panic though! The document has everything we need to make a start, but first we need to ensure that the Developer tab is visible. To switch this on, you will need to:

  • Go to File -> Options to open up the Word Options window:WordTemplate_10
  • Go to Customize Ribbon and make sure that the Developer Tab check-box is ticked. Once this is done, press OK:WordTemplate_11
  1. On the Developer Tab, you should see a button called ‘XML Mapping Pane‘. Click this button to open up a new pane to the right of the screen:

WordTemplate_12 WordTemplate_13

  1. Under the ‘Custom XML Part’ dropdown, you should see an option similar to this (may be different depending on the entity that you are building the template for):

urn:microsoft-crm/document-template/lead/4/

Once selected, you should see all of your entity fields appear below:

WordTemplate_15

  1. With the XML Mapping configured correctly, our CRM data fields can be moved onto our Word Document. To copy across each field onto the Word Document, all you need to do is right click the field, select ‘Insert Content Control‘ and then ‘Plain Text‘. Your field will be added onto your empty Word Document into the cursor area:WordTemplate_16

WordTemplate_17

  1. Now we can start to build our report! Here’s one I made earlier, with the help of some of the existing templates that Word provides for Letters:WordTemplate_18

With our document completed, we can now save it and upload it into CRM. To do this, we first need to navigate back to the ‘Create template from CRM data‘ from step 4) and, this time, select ‘Upload‘ instead of ‘Select Entity‘ to be greeted with the document upload window:

WordTemplate_20

  1. Once we have uploaded our document, we can then select our newly uploaded document from the Word Templates button on our Lead form to download the document, populated with our specific record information:WordTemplate_21 WordTemplate_22

Conclusions

So is it time to ditch .rdl Reports in favour of Word Templates then? I would certainly say so for instances where you just want to create documents which require very little data manipulation and where the key focus is around presentation of the document. Microsoft Word is certainly a much more accessible tool than SSRS when it comes to quickly creating documents that look visually appealing. That’s not to say that .rdl Reports will not still have a role moving forward, particularly when requirements are a little more complex. For example:

  • You need to use a customised FetchXML report to return data that is filtered a certain way or is, for example, returning multiple <link-entity> fields.
  • You are wanting to develop a report that a user needs to be able to filter at report run-time.
  • You need to leverage some of the advanced functionality made available via SSRS Expressions.

I therefore do not foresee a massive exodus towards Word Templates in the near future. It is more likely instead that Word/Excel Templates become the “preferred” report building tool, whereas .rdl Reports instead are used for “advanced” scenarios. I certainly am looking forward to using Word (and indeed Excel) templates moving forward and, as part of this, ensuring that some of our CRM Super Users receive training on how to use the feature as well. Giving users the power to create their own reports, using the tools they know and use every day, is very exciting!

One observation I had in regard to Word Templates is that Word would occasionally hang on my computer for approx. 15 seconds when moving some of the fields from CRM around the document. I am guessing this delay might be caused by the fact the document is attempting to connect back to your CRM instance on regular intervals. Apart from that, there were really no issues in terms of usability and setup – everything was really straightforward, quick and familiar. These are most certainly the key experiences that Microsoft are aiming for as part of this new feature, and I am reasonably confident that any teething problems will be addressed swiftly so as to encourage as many people as possible to start using this feature moving forward.

For those who have done a lot of work previously creating bespoke document templates within CRM, the only effective way in which you would traditionally do this within CRM was via a Report. For the uninitiated, reports are .rdl files that are created within CRM (for very basic reports) or via SQL Server Data Tools (for more complex/bespoke reports).

Dynamics CRM 2016 has potentially flipped this approach on its head with the introduction of Word Templates. Now, you can use Microsoft Word to develop and customise a template that can then be populated with the information you need from a CRM record. Given that Word is a far more accessible and familiar tool for many people, this new feature could be a game changer and major boon to CRM Administrators and Developers.

Having worked myself with SSRS a lot previously to create .rdl reports (and developed quite a fondness for it as a result), I am really interested in seeing whether it is more efficient and easier to use Word Templates compared to a .rdl report. So let’s find out by creating a very basic custom introduction letter that a business could use to generate for a Lead record. We’ll attempt both methods to see the steps, effort and ease of use involved for each, and then decide which tool is the winner. Given the number steps involved, this will be split across two separate posts, with the first post focusing on SSRS,

The steps below assume that you have not previously authored any custom SSRS reports on your system and that you have a FetchXML query ready to return data from CRM. We’ll be using the following basic query to return Lead data that should work with any CRM instance:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="lead">
    <attribute name="fullname" />
    <attribute name="companyname" />
    <attribute name="telephone1" />
    <attribute name="leadid" />
    <order attribute="fullname" descending="false" />
  </entity>
</fetch>

Please note the enableprefiltering=”1” option above, if you are using your own custom FetchXML query, then this line we will need to be added to the <entity> node. Otherwise, your report will not upload correctly later on:

  1. First things first, you will need to download all of the software you need in order to build the reports. Technet has a great article that goes over what you need, the salient bits of which are as follows:

Both downloads are fairly small and shouldn’t take long to install. During the Report Authoring Extension Setup, you may be prompted to install Microsoft Online Services Sign-in Assistant, press Yes if this the case:

SSRS_1

  1. Once installed, open up SSDT using Start -> Search or in Program Files -> Microsoft SQL Server 2012:

SSRS_2 SSRS_3

  1. Once open, go to ‘File’ -> ‘New’ -> ‘Project…’ You’ll see a Window similar to below:

SSRS_4

Select the ‘Report Services Project Template’, give your Project a name and then press ‘OK’. An empty solution file will be created, with the following folders visible on the right under Solution Explorer:

SSRS_5

  1. Typically, at this point you would create your Shared Data Sources/Datasets. Unfortunately, CRM reports do not support these so we need to create our report first. Right click the Reports folder and go to ‘Add’ -> ‘New Item…’. Select Report, give it a logical name, and press ‘Add’:

SSRS_6

The report will open for you within VS:

SSRS_7

Now we can start to create our data sources 🙂

  1. On the left hand side, under ‘Report Data’, right click on the Data Sources folder and select ‘Add Data Source…’ You’ll then need to enter your CRM instance settings:
    • Tick the box where it says Embedded Connection
    • On the dropdown list for Type, select ‘Microsoft Dynamics CRM Fetch’
    • Under Connection String, enter the URL for your CRM instance. There are also two additional parameters that can be specified, but only really useful if your URL points to multiple CRM organizations and/or if you have Active Directory Federation setup.
    • Under Credentials, if you are connecting to an On-Premise CRM instance, select ‘Use Windows Authentication (integrated security)’; if your are connecting to CRM Online, then select ‘Use this user name and password’ and enter your CRM Online login details.

    We’ll test these connection string settings in a few moments

  2. Now that we have our Data Sources, we can create our Datasets (too many Data’s, eh?). Right click on Datasets and select ‘Add Dataset…’:

SSRS_8

Enter the following settings:

  • Enter a name for your Dataset, ideally something descriptive in terms of what data the report is returning
  • Tick ‘Use a dataset embedded in my report.
  • Under Data Source, select your newly created CRM Data Source
  • Ensure that under Query Type, Text is selected
  • In Query, copy + paste or (for bonus points!) manually type your FetchXML query
  • Click Refresh Fields. After a few moments, you should then be able to click on ‘Fields’ on the left pane and see all of the fields from CRM. This means its working! If you get an error message, then double check your connection string details

SSRS_9

SSRS_10

  1. Now the fun part – time to build the report! I will probably do a future blog post on some of the cool things you can do with SSRS. Suffice it to say, for the purposes of this post, we are just going to create a very basic report that displays some field data in a tablix. The report will be run from an individual record, thereby pulling in its data fields. First of all, we will add a tablix to the report. This is as simple as right clicking on the report area, selecting Insert -> Table. The tablix will then appear with a dotted line on the report area:

SSRS_11 SSRS_12

  1. Because there is only one dataset configured for the report, the tablix will automatically associate itself with this. We can therefore start to add in the field by click on the top left a column (where the small table icon appears) and then selecting each individual data field we want to add. SSRS will also add on the appropriate header text for each field you put onto the tablix:

SSRS_13

SSRS_14

For this report, we will add on the fullname, companyname and telephone1 fields. After adding on some customised text to make the report look like a letter, the report should look something like this:

SSRS_15

Very basic I know! But the report will illustrate well what .rdl reports can do within CRM.

  1. Now that the report is finished, we can upload it onto CRM. To do this, we will need to locate the .rdl file for the report first. Press “Build” on your Visual Studio solution (in order to ensure that you have the most up to date version saved to disk) and then open up your Project solution folder in Windows Explorer to find your newly created report:

SSRS_16

SSRS_17

 

  1. Moving across now into CRM, we need to either go into our target Solution or alternatively customise the system via the Default Solution (not recommended for development/Production environments!). On the left-hand bar, we will see a section called Reports. Click on it, and then on New in the centre area to open a pop-up window, which lets us start adding a report into CRM:

SSRS_18 SSRS_19 SSRS_20

It’s useful at this stage to explain what some of the different fields/options mean:

  • Report Type: There are three options here. The first is Report Wizard Report, which takes you through a wizard in CRM to enable you to create a basic report utilising Advanced Find-like filter criteria. You can even make a copy of an existing report and modify it, though you will be limited in your customisation options. The second option is Link to Webpage and enables you to specify a URL to a report that exists outside of CRM (e.g. SAP Crystal Report). The final option, and the one we will be using today, is Existing File and lets you upload a .rdl file into CRM.
  • Parent Report: Similar to what you can do within SSRS Server, you can setup Parent/Child Reports to link together similar reports (e.g. you could have a Parent Account report, that then has a Child Report which shows all of the Contact Details for the Account)
  • Categories: These are grouping options to indicate the type of report you are adding.
  • Related Record Types: Here you need to specify which CRM entities the report can be run from.
  • Display In: Indicates where the report will be visible from. You can select one or many of the options. Reports Area will display the report from the Sitemap Report area, Forms for related record types will make the report available from the Form of the entities you have specified in Related Record Types and, finally, Lists for related record types will do the same, but from the Entity View page instead.
  1. Because we want our report to run on Lead forms only, we need to ensure that the Related Record Types contains Lead, and to ensure our Display In options are configured accordingly. Finally, we need to upload a report by selecting Choose File and then populate the other details accordingly. Your pop-up window should look similar to the below when you are ready to save:

SSRS_21

  1. Save and the Publish your changes. Assuming no problems, you should now see your Report on the Run Report button on your Lead form:

SSRS_22

As you can see, creating a CRM .rdl report for the first time can be quite time consuming and then, depending on the complexity of the report you are trying to create, could take even longer on top of that. I am therefore really interested in finding out as part of next week’s blog post what the process is like for Word Templates, and whether it is a quicker and more effective means of creating reports.