Wednesday, December 17, 2014
One interesting question came up during the conversation about Dynamics NAV provisioning on Azure in Office 365 with one of our Dynamics partners recently: Does the Cloud always mean that a multitenant setup should be used for Microsoft Dynamics NAV? The definitive answer to this question was “no.” Partners can also deploy single tenant Microsoft Dynamics NAV environments on the Cloud and they work wonderfully. We then reversed the question: Should Multitenancy in NAV always be deployed on the Cloud? This is a more interesting question, and the answer is “almost always.” There may be situations where Microsoft Dynamics NAV Partners and customers could benefit from multitenant Microsoft Dynamics NAV deployment in an on-premise environment, but many of our peers in the IT industry regard Multitenancy as an important feature of Cloud computing.
As Multitenancy is a hot topic among Microsoft partners today, in this blog post, I would like to give you a short overview of:
- Multitenancy benefits for Microsoft Partners
- Multitenancy architecture and set-up guidelines
Let’s take a look.
Multitenancy benefits for Partners
What is Multitenancy? In general, the multitenant architecture of Microsoft Dynamics NAV allows Partners to use the same application codebase while separating customer business databases on the same NAV application server instance. This makes maintaining the application code and functionality much simpler, while still splitting customer data into separate databases.
What benefits does a multitenant deployment provide to the Partners and their customers? The main benefits are:
- Partners can start selling their repeatable solutions on the Cloud: The primary idea for Multitenancy is for Partners to be able to start selling their repeatable solutions in an easier and more manageable way.
- Start selling to smaller customers: Multitenancy on the Cloud allows Partners to decrease hardware costs for smaller customers, since these costs can be shared among several or even hundreds of customers.
- Decrease implementation time: Implementation time for small customers can be decreased since there is no need to set up separate hardware, install the NAV application, or install an SQL server.
- Easily maintain codebase: Codebase is shared among tenants, so functionality changes have to be made only once; changes are then replicated across all multitenant customers.
- Increase solution performance with a large number of companies: For large scale on-premise installations, Multitenancy can significantly increase performance and make maintenance easier.
- Roll out hundreds of demo environments for customers: Since new customers want to try the software before purchasing or renting it, multitenant architecture is very attractive to Partners who want to deploy multiple demo environments without significant investment in hardware.
Multitenant deployment architecture introduced some changes to the way the Microsoft Dynamics NAV application server instance works and handles databases.
The graphic below shows how single tenant architecture works: Every customer has a dedicated Microsoft Dynamics NAV application server instance, and every instance uses a separate Microsoft SQL server database for that particular customer.
On the other hand, multitenant deployment looks a little different: There is a separate application database which is used by the application server instance, and then there are multiple business data (tenant) databases for the customers. All requests from different customers are handled on the same Microsoft Dynamics NAV application server instance, as shown in the graphic below.
In general, Microsoft Dynamics NAV multitenant architecture allows Partners to use the same application codebase while keeping customer business data databases separate on the same NAV application server instance. This makes maintenance of the application code and functionality much simpler, while maintaining separate databases for all customers.
Multitenancy traces in Microsoft Dynamics NAV SQL databases
From the architecture above, it is clear that there are some differences between single tenant and multitenant SQL databases and tables. One might think that, since there is a separate “application” database, all system tables are moved to that one database, but this is not true. Some system tables like “User” or “Company” are left in the business data (often called “tenant”) database to provide more flexibility and security in multitenant environments. A complete list of system tables showing which databases go in which table after migrating to Multitenancy can be found here.
Another interesting element is the new $ndo$tenantproperty table. For single tenant databases this table still exists, but the “tenantid” field in this table has value “default.” When you migrate to multitenant architecture, this table is moved to the business data or “tenant” database, and “tenantid” field should be set to the actual id of the tenant.
Separating multitenant application databases
As it is becoming more and more common for Microsoft Dynamics NAV to prepare multitenant databases from a single tenant database, you would have to use Windows PowerShell to separate a multitenant application database. First of all, you should prepare the application database that contains the application codebase. To do this, use Export-NAVApplication cmdlet, available in Microsoft Dynamics NAV management module. This cmdlet creates a new application database and extracts all the necessary tables from the existing single tenant database to the newly created multitenant application database.
Configuring NAV application server instance for Multitenancy
After you have the application database prepared, you can start configuring the application server instance to point to the new database, and also to start operating in multitenant mode. There are only two things that you have to do:
a) Change database name for the particular instance to the application database name
b) Click the multitenant checkbox
After you restart the application server instance, it will operate in multitenant mode and you may start mounting tenants for this particular instance. However, you should first prepare a business data database.
Creating tenant database from existing company in single tenant database
Microsoft provides a “NAVMultitenancySamples” module on installation media of Microsoft Dynamics NAV to help Partners easily understand how Multitenancy could be set up. The module can be found in the WindowsPowerShellScripts\Multitenancy folder of installation media. This module consists of several “HowTo” functions, one of which is HowTo-MoveCompanyToTenant. Since “HowTo” is an unapproved verb for PowerShell, you should rename the function if you plan to use it often in the future. This function can be used to copy or move Microsoft Dynamics NAV company tables, as well as some of the required system tables, from a single tenant database to a multitenant business database. There is one parameter of this function that can sometimes confuse Partners – DatabaseServer. Please make sure that you provide both SQL server name and SQL server instance name as this parameter.
This function will also use Mount-NAVTenant cmdlet to mount the new tenant on your existing NAV application server instance, so you would not have to do manual tenant mounting.
Connecting to Multitenant solution
To connect to the running Microsoft Dynamics NAV multitenant solution, you should add the tenant ID at the end of the server address, URL, or Microsoft Dynamics NAV Tablet client link, like this:
- For Microsoft Dynamics NAV Windows client, the Server Address should be in the form of: <host>:<port>/<server instance>/<tenant id>
- For Microsoft Dynamics NAV Web client, the URL should be in the form of: https://<host>:<port>/<server instance>/Webclient/?tenant=<tenant id>
- For Microsoft Dynamics NAV Tablet client, the link should be in the form of: ms-dynamicsnav://<host>:<port>/<server instance>/?tenant=<tenant id>
If you would like to dive more deeply into Multitenancy in Microsoft Dynamics NAV, please write us at firstname.lastname@example.org.