torsdag 16 mars 2017

Install Reporting Services on another machine than the SQL Server

We have faced the question of using an SQL hotel for CRM purposes a couple of times. One problem you could be facing is that the SQL server is hosting several different CRM environments so you needed to install the CRM on a named instance, which of course is possible even with a single installation. Since the SQL server might be hosting several CRMs you needed to install the SQL Server Reporting Services on a different machine.

The Reporting Services doesn't need to be installed on the same machine that is hosting the SQL server and this is a feature that you might be interested in when you are hosting several CRM deployments on the same SQL server. It is possible to host different CRM servers on a single SQL server, although on separate instances of the SQL server, and you can also have separate instances of Reporting Services on that SQL.

The issue is that for the CRM installation you have a component called the Reporting Services Connector that you need to install on the server running the Reporting Services of the CRM system. This software can only handle one CRM server and can only be installed once on a server which means that you can only host one CRM server with a Reporting Services installation so even though you can host multiple CRM servers on one SQL server, you still need one Reporting Services installation per CRM server.
You can install the Reporting Services server on one of the servers used for CRM if you need to minimize the number of servers involved, if you do this you need to think about how your reporting is used because if you do a lot of reporting that server might be loaded and might make the system less responsive for the users.

One thing that's good to know is is that you can't run the reporting sevices service with an account that is used for the CRM installation, i.e. the same account as you're running Asynchronous service with. It is a good thing to have separate accounts for every part of the CRM system, but in this case you are not allowed to use the same account because things won't work.

To install the Reporting Services server on a different machine could also be interesting if you're doing a lot of reporting and you find that the SQL server isn't coping with the load, or you'd like to split them because you'd like to have a lot of power on your SQL server for different reasons but you also want that power to be available for database handling rather than reporting.

Rickard Norström
Developer at CRM-Konsulterna 
I’m currently building an integration plugin for a customer that uses an online ERP system that has a REST interface to communicate with the system. To use the REST endpoint in an easier way the company has provided me with a couple of connection DLLs.

This is the first time I’m using external DLLs in a plugin for an online deployment, I’ve previously only done that on premise, and it’s a couple of years ago, so this meant that I’m facing some new challenges.
The first issue is that I can’t just place stuff in the assembly folder and look happy, since it’s online everything needs to be located in the database, and well you can't just put some dlls there so ILMerge is needed to create one dll. At first I was a but curious how the sandbox in Dynamics 365 would react to the external calls that I was going to make but I really didn’t think it would be an issue, and that was a correct assumption, no problems making the calls from the sandbox, one issue out.

The next thing I thought was my salvation is that I’m able to do some testing on an on-premise Dynamics 365 and just setting the plugin to run in the sandbox. This was one issue I didn’t expect. When I ran my code in the sandbox on our server, it was working just fine but when I registered the assembly in Dynamics 365 online I got in trouble, and it’s not really amusing to troubleshoot plugins online. This one was even worse since it was five or so dlls that I had merged using ILMerge, which also was a source of concern. This proved not to be an issue, the dll that was the output from ILMerge was working as planned.

I got a bit of help by George Doubinski  and the issue was that the code I was using implicit typed variables. The reason for this is that I got code examples from the ERP provider. Don’t get me wrong here, I’m not blaming them for that, it just that I’m coming from hardware where everything is explicitly typed so my code is generally explicit typed even though the best practice for C# is to use implicit typed variables. This time however I let it be as the example code was written and since that worked in a sandboxed on-prem I didn’t really think about it.

I’m not sure what it is that makes the dynamic and var problematic here but it was very clear that in this case it did not work online.

The moral of this is that even though you have code that’s working in a sandboxed on-premise installation it might not work in an online deployment. If that happens it might be worth it to start looking at what variable types you’re using. To merge dlls together with ILmerge is working very good though, which is good.
Rickard Norström
Developer at CRM-Konsulterna