Um eine Kopie eines vorhandenen Verwendungszwecks zu erstellen, kann das PowerShell-CmdLet Copy-SystemUsage verwendet werden.

Kopie eines Verwendungszwecks

Beim Kopieren wird der neue Verwendungszweck angelegt und gleichzeitig alle (CS 3.0-)Datenbanken kopiert und entsprechend in die Systemstruktur eingefügt. Die im Quellverwendungszweck laufenden Workflows werden nicht dupliziert. Die Jobs werden hingegen kopiert und im Zielverwendungszweck wieder gestartet. Während des Kopiervorgangs werden keine neuen Jobs gestartet.  Die CS-Komponenten des lokalen Systems und die der anderen CS-Server werden gestoppt, damit auch die reinen CS 2.0-Server.

Bei der Neuanlage eines Verwendungszwecks wird automatisch die zugehörige Aufgabenart für die Überwachung der Message Bus Nachrichten ergänzt. Der Name ist dann CS.PI.SB: Wiederholt nicht zustellbare Nachrichten bearbeiten ([Name des Verwendungszwecks]). Wird der Verwendungszweck gelöscht, wird die Aufgabenart nicht bereinigt. Dies kann dann administrativ erfolgen, wenn der Verwendungszweck nicht mehr benötigt wird.

Die Kopien der 2.0-Datenbanken sowie die Anlage der entsprechenden Datenquellen im CS.SY_Basissystem müssen Sie manuell vornehmen.

Verwendungszweck durch Kopieren automatisch erzeugen

Sie können den Datenbankserver festlegen, auf dem die Datenbanken des neuen Verwendungszwecks angelegt bzw. auf den sie kopiert werden sollen.

Physikalische Verteilung der Datenbanken

Beim Verwalten von Systemstruktursichten, -Elementen, -Elementtypen und Verwendungszwecken wird der Name auf nicht erlaubte Sonderzeichen untersucht und in diesem Fall eine Fehlermeldung ausgegeben. Nicht erlaubte Zeichen sind: Leerzeichen, !, “, #, $,%, &, ‘, (,),*,+, ,, /, :, ;, =, ?, @, [, ], -.

Verwendungszweck durch Kopieren von Verwendungszweck Produktiv anlegen

1. Duplizieren Sie die CS 2.0-Datenbank Produktiv auf dem Datenbankserver. Tragen Sie diese in der Datenquellverwaltung (CS.SY_Basissystem) ein, und kennzeichnen Sie sie als Test.
2. Führen Sie folgendes CmdLet auf dem Rechner des CS 3.0-Systems mit der Deploymentrolle BusinessProcessServer und lokal installiertem RabbitMQ aus. Ersetzen Sie vorher CS.SY Produktivdatenquelle und CS.SY Testdatenquelle mit den bei Ihnen verwendeten Datenquellen.
   
   Copy Code
   Copied
   Use a different Browser

   
   Copy-SystemUsage -SourceSystemUsageName Produktiv -TargetSystemUsageName Test -DataSourceMapping @{'CS.SY Produktivdatenquelle' = 'CS.SY Testdatenquelle'}
   
   			

3. Nur in Cluster/Mehrrechnerumgebung: Tragen Sie auf allen weiteren Rechnern mit der Deploymentrolle BusinessProcessServer die Konfiguration (z. B. Workflow Persistence Store) in den lokalen web.config-Dateien mit folgendem CmdLet nach:
   
   Copy Code
   Copied
   Use a different Browser

   
   Sync-AppFabricPersistenceWithSystemStructure -SystemUsageName Test -IsSimpleRecoveryModel:$true
   
   			

4. Prüfung: Wenn das Skript erfolgreich durchlaufen ist, melden Sie sich mit dem neuen Verwendungszweck im Portal an.

Dabei ist:

• Produktiv der existierender Quellverwendungszweck
• Test der neue Test-Verwendungszweck
• CS.SY Produktivdatenquelle die CS 2.0-Datenquelle, die als Produktiv gekennzeichnet ist
• CS.SY Testdatenquelle die soeben manuell erstellte CS 2.0-Datenquelle, die als Test gekennzeichnet wurde.

Beim DataSourceMapping von CS 3.0 nach CS 2.0 können Sie auch mehrere Datenbankenzuordnungen angeben. Sollte der Produktiv-Verwendungszweck z.B. bei zwei Mandantenknoten im Einsatz sein, so wird in beiden Knoten eine neue Datenbank angelegt. Diese muss auch jeweils manuell kopiert und als Datenquelle im CS.SY_Basissystem 2.0 angelegt worden sein. 

Außerdem müssen beide Datenbanken im DataSourceMapping angegeben werden:

@{'CS.SY Produktivdatenquelle_Mandant_A' = 'CS.SY TestDatenquelle_Mandant_A'; 'CS.SY Produktivdatenquelle_Mandant_B' = 'CS.SY Testdatenquelle_Mandant_B'}

			

Alle automatisch angelegten Zuordnungen können nachträglich manuell korrigiert und angepasst werden.

Standardmäßig werden die erzeugten Datenbanken beim Kopieren eines Verwendungszwecks im Simple Recovery Modus erzeugt. Mit Hilfe des Parameters -FullDatabaseRecoveryModel können Sie stattdessen den Full Recovery Modus verwenden.

Verwendungszweck auf getrennter SQL Server-Instanz anlegen

Sollen die Datenbanken des neuen Verwendungszwecks (Fachdatenbanken + AppFabricPersistence) auf einer anderen SQL Server-Instanz angelegt werden, müssen zusätzlich die folgenden Voraussetzungen erfüllt sein:

• Für die andere SQL Server-Instanz müssen die administrativen Zugangsdaten mittels New-CSDatabaseServer eingerichtet sein.
• Auf beiden SQL Servern müssen Netzwerkfreigaben eingerichtet sein, auf die Sie bei der Ausführung von Copy-SystemUsage Zugriff haben, und in denen die SQL-Serverinstanzen lokal Backups ablegen können.
• Die SQL Serverversion des Zielservers muss höher oder gleich der Version des Quellservers sein.
• Auf dem Zielserver existieren für die Benutzer der Fachdatenbanken Logins mit den gleichen Namen und Passwörtern wie auf dem Quellserver.

Der Aufruf von Copy-SystemUsage erhält zusätzliche Parameter:

Copy-SystemUsage -SourceSystemUsageName Produktiv -TargetSystemUsageName Test -DataSourceMapping @{'CS.SY Autotest' = 'CS.SY Autotest_Test'} -TargetSqlServerInstance 'GPS11Framework' -SourceBackupShare '\GPS10FrameworkPackageRepository' -SourceBackupLocation 'C:PackageRepository' -TargetBackupShare '\GPS11FrameworkPackageRepository' -TargetBackupLocation 'C:PackageRepository'

			

• TargetSqlServerInstance gibt den Namen der Ziel-SQL Server-Instanz an, die zuvor per New-CSDatabaseServer eingerichtet wurde.
• SourceBackupShare ist die Netzwerkfreigabe auf dem Quellserver, in der die Backups der Originalfachdatenbanken abgelegt werden.
• SourceBackupLocation ist der lokale Pfad auf dem Quellserver, auf dem die Backups der Originalfachdatenbank  abgelegt werden; somit das physikalische Verzeichnis der Freigabe SourceBackupShare.
• TargetBackupShare ist die Netzwerkfreigabe auf dem Zielserver, von der aus die Backups der Originalfachdatenbanken eingespielt werden.
• TargetBackupLocation ist der lokale Pfad auf dem Zielserver, von dem aus die Backups der Originalfachdatenbanken auf dem Zielserver eingespielt werden; somit das physikalische Verzeichnis der Freigabe TargetBackupShare.

Im Rahmen von Copy-SystemUsage werden wie beim Kopieren zunächst Kopien der Originalfachdatenbanken auf der gleichen SQL Server-Instanz erstellt. Diese Kopien werden allerdings in der angegebenen SourceBackupLocation abgelegt. Anschließend wird eine Kopie der Backups von SourceBackupShare  auf TargetBackupShare durchgeführt. Auf der Zielinstanz wird zuletzt das Backup von TargetBackupLocation aus eingespielt und das SQL-Skript Schleupen.CS.PI.SB.SystemUsages.PostProcess.sql ausgeführt, um die Benutzer der wiederhergestellten Datenbank auf der Zielinstanz mit den Server-Logins zu synchronisieren.

Das CmdLet Copy-SystemUsage interagiert mit der Systemstatussteuerung (=SystemInstallState). Wenn das Kopieren mit Copy-SystemUsage fehlschlägt und Sie die Aktion wiederholen möchten, setzen Sie vorher den Systemstatus per Set-CSSystemInstallation -InstallState Installing –Force zurück.