Welcher Eigentümer von Immobilien wünscht sich das nicht? Viele verschiedene Mieter(innen), die sich gegenseitig nicht in die Quere kommen, keinen Streit haben und sich nicht in die Wohnungen schauen oder möglicherweise neidisch auf anderer Leute Wohnungen sind? Und dann auch noch alle im ersten Stock. Hoch genug, so dass niemand von der Straße hinein sehen kann, aber nicht zu hoch, so dass der Weg in die Wohnung nicht beschwerlich ist.
Genau das liefert Ihnen Dynamics NAV Multi-Tenancy!
multi-tenancy (comp.): Mandantenfähigkeit.
Als mandantenfähig (auch mandantentauglich) wird Informationstechnik bezeichnet, die auf demselben Server oder demselben Software-System mehrere Mandanten, also Kunden oder Auftraggeber, bedienen kann, ohne dass diese gegenseitigen Einblick in ihre Daten, Benutzerverwaltung und Ähnliches haben.
Wann und warum benötigt man aber dieses Feature? Nun, es gibt viele Szenarien, in denen Multi-Tenancy nützlich ist. Speziell beim Hosting war es in der Vergangenheit schwierig, eine Trennung, speziell der übergreifenden Daten, sicherzustellen. Auch die Skalierbarkeit spielt eine große Rolle, denn ein kleineres Unternehmen benötigt unter Umständen nicht eine große Benutzerzahl von 100 oder mehr Benutzern, die ein Dynamics NAV Dienst nun bedienen kann. Hier wäre es sinnvoll, die Nutzer mehrerer, ggf. auch rechtlich getrennter Firmen, ebenfalls auf diesem Dienst arbeiten zu lassen und mit diesem einen Dienst viele Firmen und auch Datenbanken zu bedienen. Das spart Ressourcen!
Sicherlich gibt es noch andere Anwendungsfälle. Ich werde aber generell im Folgenden die Überführung einer klassischen Datenbank mit mehreren Mandanten in den Multi-Tenant-Betrieb, mit mehreren Daten-Datenbanken und einer Applikationsdatenbank.
![image]( "image")
Dabei wird von folgender bestehender Einrichtung und Lage ausgegangen:
- Sie sind mit einem Windows-Benutzer angemeldet, der mit administrativen Rechten ausgerüstet ist, also mindestens der lokalen Gruppe der Administratoren angehört.
- Auf dem SQL Server ist Ihnen die Rolle sysadmin zugewiesen.
- Sie haben den Ordner Multitenancy aus dem Dynamics NAV 2013 R2 Installations-Order auf Laufwerk C: kopiert.
- Zum “spielen” sind mindestens zwei Mandanten in der Quelldatenbank vorhanden. Haben Sie derzeit nur eine, können Sie in der Mandantenübersicht bestehende Mandanten kopieren.
![image]( "image")
Öffnen Sie nun die Microsoft Dynamics NAV 2013 R2 Administration Shell oder die PowerShell ISE (Integrated Scripting Environment, siehe http://technet.microsoft.com/de-de/library/dd759217.aspx) als Administrator und importieren Sie dort die Dynamics NAV Admin Tools und das Multi-Tenancy Beispiel-Modul mit folgenden Befehlen. Hinweis: Selbstverständlich können Sie alle Befehle (die sogenannten CmdLets) auch in der ISE als PS1-Datei speichern und dann komplett an einem Stück ausführen.
Set-ExecutionPolicyunrestricted-Force
Import-Module'C:\Program Files\Microsoft Dynamics NAV\71\Service\NavAdminTool.ps1'
Import-Module'C:\Multitenancy\NAVMultitenancySamples.psm1'
Um nicht alle Werte immer wieder angeben zu müssen, setzen wir einige Variablen. Für weiterführende Informationen zu Variablen innerhalb von PowerShell, schauen Sie sich bitte den folgenden Artikel an: Windows Powershell - The Power of Variables. Vergessen Sie aber nicht, auch diese Zeilen auszuführen, damit die Werte entsprechend vorbelegt werden.
$databaseServerName="sqlservername" # Name des Datenbankservers
$sourceDatabaseName="Demo Database NAV (7-1)" # Name der bestehenden Quelldatenbank mit einem oder mehreren Mandanten
$appDatabaseName="Demo Database NAV (7-1) App" # Name der (neuen) Applikationsdatebank.
$serverInstanceName="DynamicsNAV71" # Instanzname des Dynamics NAV Servers
$serviceAccount="DOMAIN\ServiceUser" # Benutzer unter dem der Dynamics NAV Dienst ausgeführt wird
$tenantsConfigFile="C:\Program Files\Microsoft Dynamics NAV\71\Service\tenants.config"
Mit den folgenden Befehlen wird sichergestellt, dass eine eventuell bestehende tenants.config-Datei, in der Informationen zu den Daten-Datenbanken hinterlegt sind, vorab gelöscht wird. Die letzte Zeile beendet den Dynamics NAV Serverdienst.
If (Test-Path$tenantsConfigFile) {
Remove-Item$tenantsConfigFile
}
Set-NAVServerInstance$serverInstanceName-Stop
Jetzt soll es aber endlich losgehen: Überführen wir also die Applikation in eine (neue) Datenbank, die Applikationsdatenbank. Ist dieser Schritt abgeschlossen (und ggf. geprüft), kann die bestehende Applikation aus der ursprünglichen Datenbank entfernt werden.
Nebenbei: Das Zeichen “`” wird unter PowerShell verwendet, um einen Befehl in mehrere Zeilen aufzuteilen.
Export-NAVApplication `
-DestinationDatabaseName$appDatabaseName `
-DatabaseName$sourceDatabaseName `
-DatabaseServer$databaseServerName `
-ServiceAccount$serviceAccount
Remove-NAVApplication `
-DatabaseName$sourceDatabaseName `
-DatabaseServer$databaseServerName `
-Force
Mit obigen Befehlen wird die bestehende Datenbank, wie unten zu sehen ist, aufgeteilt, so dass die gemeinsame Applikation und die Tenant-Datenbanken getrennt werden. Mit den ehemals mandantenübergreifenden System-Tabellen (DataPerCompany=No), wird verfahren, wie in der folgenden Grafik zu sehen.
![image]( "image")
Um dem Dynamics NAV Server letztendlich beizubringen, dass dieser sich nun im Multi-Tenant-Betrib befindet, wird in der Konfigurationsdatei CustomSettings.config im Serververzeichnis der Name der Datenbank gelöscht und das Flag MultiTenant gesetzt. Der Name der Datenbank wird entfernt, da die Namen der Tenant-Datenbanken fortan in der Datei tenants.config im Serververzeichnis verwaltet werden. Anschließend wird der Serverdienst neu gestartet. Das passiert mit den folgenden drei Befehlen.
Set-NAVServerConfiguration-ServerInstance$serverInstanceName-KeyNameDatabaseName-KeyValue""
Set-NAVServerConfiguration-ServerInstance$serverInstanceName-KeyNameMultiTenant-KeyValue"true"
Set-NAVServerInstance$serverInstanceName-Start
Um nun die tenants.config tatsächlich zu schreiben – sprich die Applikations- und die Tenant-Datenbank anzumelden, sind folgende zwei Befehle notwendig. Sie sehen hier, dass die Quelldatenbank zunächst als Tenant-Datenbank (ID: default) herhält, in der nach wie vor zwei Mandanten liegen. Um eine eventuell bestehende alte Tenant-ID zu überschreiben, nutze ich hier OverwriteTenantIdInDatabase.
Mount-NAVApplication `
-DatabaseServer$databaseServerName `
-DatabaseName$appDatabaseName `
-ServerInstance$serverInstanceName
Mount-NAVTenant `
-Iddefault `
-DatabaseServer$databaseServerName `
-ServerInstance$serverInstanceName `
-DatabaseName$sourceDatabaseName `
-OverwriteTenantIdInDatabase
Das große Finale naht! Die folgende Kombination von PowerShell-Befehlen ermittelt zunächst die in der Quelldatenbank (nun Default-Tenant) vorhandenen Mandanten (Get-NAVCompany) und führt für jeden gefundenen Mandanten (ForEach) das Beispielscript HowTo-MoveCompanyToTenant aus. Dieses wiederum erstellt neue Datenbanken sofern notwendig, legt entsprechend Benutzer automatisch an und verschiebt die bestehenden Daten durch Nutzung eines SQL Server T-SQL Scripts (Transact-SQL) in eine neue Tenant-Datenbank.
Der neue Tenant-Name wird aus dem bestehenden Mandantennamen gebildet, indem Leerzeichen entfernt werden. Am Ende wird noch der nun nicht mehr benötigte default-Tenant abgemeldet und die Quelldatenbank ist nun nicht mehr in Benutzung.
Get-NAVCompany-ServerInstance$serverInstanceName-Tenantdefault|
ForEach {
HowTo-MoveCompanyToTenant `
-ServerInstance$serverInstanceName `
-FromDatabase$sourceDatabaseName`
-CompanyName$_.CompanyName `
-OldTenantNamedefault `
-NewTenantName$_.CompanyName.Replace(" ","") `
-DatabaseServer$databaseServerName`
-ServiceAccount$serviceAccount `
-RemoveCompanyWhenMoved `
-Force
}
Dismount-NAVTenant-Tenantdefault-ServerInstance$serverInstanceName-Force
Info ==> $_: Was hat es hiermit auf sich? Unter Automatic Variables kann man sich über alle automatischen Variablen informieren. Kurz: PowerShell ist objektorientiert und $_ enthält das aktuell in der ForEach-Schleife durchlaufene Objekt. Somit kann man per $_.XXX auf die Eigenschaft XXX eines Objekts zugreifen. Im Fall unten z.B. auf den Mandantennamen ($_.CompanyName) für jeden Mandanten der durch Get-NAVCompany ermittelt wurde.
Nun existieren auf dem SQL Server folgende Datenbanken:
![image]( "image")
Ein Ausschnitt aus der neuen tenants.config:
![image]( "image")
Das Ergebnis ist nun ein Dynamics NAV Server der drei aktive Datenbanken bedient. Die Applikationsdatenbank "Demo Database NAV (7-1) App” und zwei Tenant-Datenbanken mit nach Mandanten getrennten Daten “CONTOSOAG” und “CRONUSAG”. Nur die Applikationsdatenbank lässt sich aus der Entwicklungsumgebung auswählen, da nur diese die eigentliche Applikation enthält:
![image]( "image")
Der Start des Windows Clients wird zunächst mit einer Fehlermeldung quittiert, welche aussagt, dass kein Tenant angegeben wurde.
![image]( "image")
Das ist auch völlig korrekt, da ein bestimmter Tenant nun folgendermaßen angesprochen und adressiert wird: navservername:port/navinstanz/tenantid
![image]( "image")
Um diese Struktur nun wieder zurückzubauen, habe ich ein PowerShell-Script angehängt, welches die nun bestehenden Struktur wieder in den Ausgangszustand mit nur einer Datenbank mit zwei Mandanten und der Applikation überführt.
Wichtig: Selbstverständlich können verschiedenen Tenant-Datenbanken auch auf verschiedenen SQL Server Instanzen, auch auf verschiedenen Servern liegen, so lange der Dynamics NAV Dienst-Account Zugriff auf diese hat. Die Überführung muss allerdings manuell oder mit selbst erstellten PowerShell-Scripts geschehen, da wir hierfür (noch) nichts vorgefertigtes mitliefern. Beachten Sie dabei aber, dass derzeit die Sortierung (Collation) der Datenbanken durchgängig die gleiche sein muss. Aber, wie immer: Wir arbeiten daran!
Carsten Scholling
Microsoft Dynamics Germany
Microsoft Global Business Support (GBS) EMEA
Email: cschol@microsoft.com
Microsoft Connect: http://connect.microsoft.com
Online Support: http://www.microsoft.com/support
Sicherheitsupdates: http://www.microsoft.de/sicherheit
Microsoft Deutschland GmbH
Konrad-Zuse-Straße 1
D-85716 Unterschleißheim
http://www.microsoft.de
![]()
