Der nichtproduktive Verwendungszweck kann per CmdLet Update-SystemUsage aktualisiert werden.

Wie beim CmdLet Copy-SystemUsage werden keine Workflows aus dem Quellverwendungszweck in den Zielverwendungszweck dupliziert. Im Zielverwendungszweck werden bereits existierende Workflows vor der Aktualisierung entfernt. Die Jobs werden bei der Aktualisierung ebenfalls aktualisiert. Während der Aktualisierung werden keine neuen Jobs gestartet.

Folgende Schritte sind für die Aktualisierung durchzuführen:

• CS 2.0-Datenbank aktualisieren:
  1. Stoppen Sie die Dienste Schleupen Watchdog Monitoring Service (Überwachungsdienst) und Schleupen Jobserver Service (CS 3.0-Jobdienst) auf den CS 3.0-Servern mit der Deploymentrolle WorkflowBackend.Der Jobserver verarbeitet wegen SI auch Jobs gegen CS 2.0-Datenbanken und der Watchdog startet gestoppte Jobserverdienste. Jedoch sollten der Jobserver und Watchdog nur bei erhöhten Konsistenzanforderungen gestoppt werden.
     Dieser Schritt ist optional.
  2. Führen Sie eine Kopiesicherung der CS 2.0-Echtdatenbank auf dem SQL Server aus.
     Diese Sicherung sollte/kann im laufenden Betrieb durchgeführt werden. Sollte dies nicht der Fall sein, erzeugt der Jobserver ggf. für diesen Zeitraum Fehlermeldungen.
  3. Stellen Sie die Kopiesicherung als Testdatenbank wieder her (die alte Datenbank muss vorher gelöscht werden) oder überschreiben Sie die vorhandene Testdatenbank.
  4. Starten Sie die Dienste wieder, sofern Sie sie im ersten Schritt deaktiviert haben (Watchdog und Jobserver).
• CS 3.0 aktualisieren:
  1. Führen Sie folgendes Cmdlet auf dem CS 3.0-Server mit den aktiven RabbitMQ -Diensten durch (Produktiv ist hier der existierende Quellverwendungszweck, Test der neue Zielverwendungszweck):
     Copy Code Copied Use a different Browser

     
     Update-SystemUsage -SourceSystemUsageName Produktiv -TargetSystemUsageName Test
     

     
     Der Host-Status wird durch Update-SystemUsage nicht geändert (Dienste bzw. IIS-Anwendungspools werden nicht gestoppt). Somit kann das Cmdlet im laufenden Produktivbetrieb ausgeführt werden.
• Optionale Prüfung: Wenn das Skript erfolgreich durchlaufen ist, kann eine Anmeldung im Portal mit dem neuen Verwendungszweck durchgeführt werden.

Verwendungszweck auf getrennter SQL Server-Instanz aktualisieren

Analog zu Copy-SystemUsage kann auch die Aktualisierung auf einer anderen SQL Server-Instanz durchgeführt werden. Hierbei sind dieselben zusätzlichen Parameter anzugeben.

Update-SystemUsage -SourceSystemUsageName Produktiv -TargetSystemUsageName 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.