CU-Tausch Bis S 39.5.12

Beschreibung für Versionen ≥ S 39.5.12

Voraussetzungen

• Auf dem System, auf dem der CU-Tausch durchgeführt wird (typischerweise der Applikationsserver), muss
  • Java installiert sein (JDK/JRE mindestens in Version 1.7 oder neuer)
  • zusätzlich die Umgebungsvariable JAVA_HOME gesetzt werden, die den Pfad der Java-Installation enthält
  • Pentaho PDI (Kettle) vorhanden sein (mindestens in Version 4.1.3)
  • außerdem die Umgebungsvariable KETTLE_DIR gesetzt werden, die den Pfad zum Pentaho-Verzeichnis enthält
• Quell- und Zielsystem müssen auf dem gleichen Stand sein, inklusive Changeset-Nr. (Hotfix)
• Alle neuen DIs, die man in der Quell-Datenbank angelegt hat, müssen auch in der Ziel-Datenbank angelegt werden. Die Missachtung dieser Regel führt beim CU-Tausch zum Absturz.
• Bezüglich Modulvarianten
  • Sollen bei einem CU-Tausch von einem Entwicklungssystem (Quelle) auf ein Test-/Schulungs- oder Produktivsystem (Ziel) auch Modulvarianten aus dem Schema Q3B berücksichtigt werden, muss vorab organisatorisch folgendes gewährleistet werden, um Konflikte zu vermeiden (Dies wird vom CU-Tausch selbst nicht gelöst):
    • die Autonummern der Modulvarianten (DT500) und I-Nummern/Texte (DT544) im Schema Q3B in den beiden Systemen müssen aus unterschiedlichen Nummernkreisen kommen, um Konflikte zu vermeiden.
      • Vorschlag: Im Entwicklungssystem das Präfix der Autonummern der DT500 und DT544 auf Kundenlizenz + 1 setzen.
        • Voraussetzung hierbei ist, dass die Daten in den entsprechenden Tabellen auf dem gleichen Stand sind.
        • Dies ist nur am Anfang, wenn die Quelle als Kopie des Ziels neu aufgesetzt ist, oder nach einem zwischenzeitlichen CU-Tausch der Fall.
        • Da beim CU-Tausch auch diese Einstellung von der Quelle in das Ziel übertragen wird, wird ausserdem ein Skript benötigt, das anschließend im Zielsystem die beiden Autonummern-Präfixe wieder auf den Standardwert zurücksetzt (s.u., Inactive-/Epilogue-Ordner).
          • Wenn ohne diese Maßnahme Modulvarianten zwischen Ziel- und Entwicklungssystem voneinander abweichen, dürfen die Q3B-Daten nicht übertragen werden.
            • In diesem Fall und auch, wenn generell auf die Übertragung der Modulvarianten verzichtet werden soll, sind die entsprechenden Zeilen (Tabelleneinträge DT500, DT501, DT502, DT503, DT545) vor dem CU-Unload (dem Entladen der Daten aus dem Entwicklungssystem) aus der Liste der zu übertragenden Tabellen zu löschen (siehe Datentabellenliste) bzw. falls schon entladen wurde, auch die entsprechenden Tabellendateien aus dem Unloads-Ordner zu löschen.

Details

• Der CU-Tausch liegt auf dem Arbeitssystem in einem beliebigen geeigneten Unterverzeichnis Migration vor.
• Der Ordner Migration enthält unter anderem mindestens folgende für den CU-Tausch notwendigen Ordner und Dateien:

Datei/Ordner	Bedeutung
common	enthält gemeinsam verwendete Komponenten
conf	Konfigurationsordner, enthält u.A. die Konfigurationsdatei update.conf mit den entsprechend zu modifizierenden CU-Tausch-Parametern (s.u.)
CUunload	enthält das Verfahren zum Entladen der Daten aus der Quelle
CUexchange Prologue Epilogue Inactive	enthält das Verfahren zum Tausch der Daten im Ziel Unterordner zur Ablage von kundenspezifischen SQL-Skripten zur Ausführung vor CU-Tausch Unterordner zur Ablage von kundenspezifischen SQL-Skripten zur Ausführung nach CU-Tausch Unterordner zur Ablage und Sammlung von kundenspezifischen SQL-Skripten, die aktuell nicht ausgeführt werden
log	Das Log-Verzeichnis, in dem die Logdateien abgelegt werden, die bei Entladen und Tausch geschrieben werden
setVar.bat setVar.sh	Skript zum Setzen der Umgebungsvariablen JAVA_HOME (Pfad zur Java JDK- oder JRE-Installation) und KETTLE_DIR (Pfad zum Pentaho PDI/Kettle Verzeichnis) (Windows/Linux)
CUunload.bat CUunload.sh	Startskript zum Entladen der Quelldaten (Windows/Linux)
CUexchange.bat CUexchange.sh	Startskript für den Tausch der CU-Daten im Ziel (Windows/Linux)

Einstellungen

Informationen

• Der CU-Tausch ist konfigurierbar über die Parameter-Datei update.conf im Unterverzeichnis conf.
• Für den CU-Tausch sind die folgenden Parameter relevant und müssen entsprechend angepasst werden:

Parameter	Wert
planta.update.license	dreistellige Kundenlizenz (z.B. 123); im Fall mehr als eine Lizenz auf dem System aktiv sein sollte, sind diese durch Komma getrennt anzugeben (z.B. 123,456)
planta.unload.data_dir	Pfad, unter dem die Quelldaten abgelegt werden
planta.cu_exchange.type	Typ des CU-Tauschs Mögliche Werte: ALL = muss in der Konstellation Entwicklungs- zu Produktivsystem eingestellt sein, denn die Schemas Q1B/Q2B werden komplett getauscht STANDARD = muss gesetzt sein im Fall eines abschließenden CU-Tauschs am Ende einer Migration eines Kundensystems, hier werden nur die zum Standard gehörenden Datensätze getauscht, die Datensätze mit Kundenlizenz bleiben unangetastet
planta.db.source.type	Quell-DBMS Mögliche Werte: MSSQL ORACLE POSTGRESQL
planta.db.source.access	Quell-Zugriffsmethode Mögliche Werte: Native ODBC
planta.db.source.name	Quell-DB-Name (bei Oracle die SID)
planta.db.source.host	Quell-Server (auf dem das DBMS residiert)
planta.db.source.user	Quell-DB-Benutzer
planta.db.source.pass	Quell-DB-Benutzerpasswort
planta.db.source.port	Üblicherweise einer der folgenden Werte, sofern nicht anders gesetzt: 1521 (Oracle) 1433 (MSSQL) 5432 (PostgreSQL)
planta.db.destination.type	Ziel-DBMS Mögliche Werte: MSSQL ORACLE POSTGRESQL
planta.db.destination.access	Ziel-Zugriffsmethode Mögliche Werte: Native ODBC
planta.db.destination.name	Ziel-DB-Name (bei Oracle die SID)
planta.db.destination.host	Ziel-Server (auf dem das DBMS residiert)
planta.db.destination.user	Ziel-DB-Benutzer
planta.db.destination.pass	Ziel-DB-Benutzerpasswort
planta.db.destination.port	üblicherweise einer der folgenden Werte, sofern nicht anders gesetzt: 1521 (Oracle) 1433 (MSSQL) 5432 (PostgreSQL)

Prozessablauf

Information

• Ein CU-Tausch dauert ca. zwei Stunden.

Todo

• Kunde
  • Sicherstellen, dass sich keine User mehr auf der Zielumgebung befinden.
  • Backup der Ziel- und Quelldatenbank
  • Abnahme nach erfolgreichem CU-Tausch
• PLANTA
  • Vorbereiten des CU-Tausches
  • Server stoppen
  • Unload der Ziel- und Quellumgebung
  • Load in die Zielumgebung
  • Server starten
  • Testen
  • Freigeben zur Abnahme durch den technischen Projektleiter des Kunden

Prozessablauf

Prozessschritt	Verantwortlicher
Information an Nutzerkreis über die geplante Wartungsarbeit	technischer Projektleiter des Kunden
Sicherstellen, dass kein Mitarbeiter des Kunden mehr auf dem System arbeiten	Betrieb
Backup der Produktiv-DB	Betrieb
Unload der Customizing-Daten von der Testumgebung und Produktivumgebung	PLANTA
Load in die Produktivumgebung	PLANTA
Testen der Nachtjobs	PLANTA
Freigabe	durch PLANTA an den technischen Projektleiter des Kunden
Abnahme	durch den technischen Projektleiter des Kunden

Detaillierter Ablauf

Vorgehensweise

• Ein Kommandozeilenfenster öffnen und in den Migrationsordner wechseln.
• Überprüfen, dass die Voraussetzungen stimmen (und speziell die Umgebungsvariablen gesetzt sind).
• Die Parameter der Konfigurationsdatei (~conf/update.conf) prüfen/setzen. Falls später keine Datenbankverbindung zustandekommt, speziell hier die Verbindungsparameter überprüfen, dabei beachten, dass je nach Infrastruktur auch andere als die Standard-Portnummern verwendet werden.

CU-Unload

• Je nach System CUunload.bat (Windows) oder Cuunload.sh (Linux) aufrufen.
  • Damit wird das Customizing des Quellsystems in Dateien unter dem im Parameter planta.unload.data_dir angegebenen Pfad abgelegt.
• Die Skriptausgabe auf erfolgreiche Ausführung überprüfen.
  • Eine genauere Prüfung erlaubt die Protokolldatei CUunload.txt im Unterverzeichnis log.

CU-Exchange

• Vor dem Tausch darf kein Anwender mehr das System im Einsatz haben.
• Ist dies gewährleistet, den PLANTA-Applikationsserver des Zielsystems stoppen.
• Ein Backup der Datenbank bzw. des Users durchführen.
• Die Verzeichnisse CUexchange/Prologue und Epilogue überprüfen.
  • Hier können kundenspezifische SQL-Batchskripte abgelegt werden, die vor (Prologue) bzw. nach (Epilogue) dem CU-Tausch ausgeführt werden sollen.
  • z.B. können Schemaänderungen im Quellsystem durch Ablage der entsprechenden DDL-Skripte in Prologue für das Zielsystem nachgezogen werden,
  • In Epilogue können z.B. Skripte abgelegt werden zum Setzen des Aktualisierungsdatums nach erfolgtem Tausch, für das Rücksetzen des Autonummern-Templates für Modulvarianten und I-Texte auf das im Zielsystem verwendete, etc.
  • Vorübergehend nicht benötigte Skripte können nach Inactive verschoben werden.
    • Speziell Skripte zur Schemaänderung sollen i.d.R. nur einmal ausgeführt werden und müssen bei wiederholter Verwendung des CU-Tausches nach der Ausführung wieder aus Epilogue entfernt werden.
• Je nach System CUexchange.bat (Windows) oder CUexchange.sh (Linux) aufrufen.
  • Damit wird das Customizing des Zielsystems durch die Daten aus dem planta.unload.data_dir-Pfad ersetzt.
• Die Skriptausgabe auf erfolgreiche Ausführung überprüfen.
  • Eine genauere Prüfung erlaubt die Protokolldatei CUunload.txt im Unterverzeichnis log.
• Auf gleichen Versionsstand von Server und Client achten
  • Ein geändertes Customizing beinhaltet i.d.R. auch geänderte Python-Skripte (server- und/oder clientseitig). Daher ggf. auch die Python-Verzeichnisse des Zielsystems durch die des Quellsystems ersetzen.
• Den PLANTA-Applikationsserver des Zielsystems starten.

Datentabellen

Hinweis

• Folgende Datentabellen, bei denen es sich im wesentlichen um Tabellen der Schemas Q1B und Q2B (sowie die mit Modulvarianten zusammenhängenden Tabellen aus Q3B) handelt, werden bei einem CU-Tausch ausgetauscht (Liste aus ~/conf/CUtables.txt):
  • DT030
  • DT031
  • DT032
  • DT033
  • DT035
  • DT036
  • DT037
  • DT055
  • DT316
  • DT320
  • DT321
  • DT333
  • DT339
  • DT340
  • DT341
  • DT342
  • DT343
  • DT346
  • DT348
  • DT349
  • DT354
  • DT390
  • DT391
  • DT392
  • DT395
  • DT396
  • DT397
  • DT404
  • DT405
  • DT406
  • DT407
  • DT408
  • DT409
  • DT410
  • DT411
  • DT412
  • DT414
  • DT415
  • DT416
  • DT417
  • DT419
  • DT420
  • DT421
  • DT424
  • DT425
  • DT428
  • DT429
  • DT432
  • DT433
  • DT434
  • DT435
  • DT439
  • DT440
  • DT441
  • DT444
  • DT445
  • DT447
  • DT449
  • DT452
  • DT453
  • DT454
  • DT456
  • DT458
  • DT500
  • DT501
  • DT502
  • DT503
  • DT510
  • DT512
  • DT513
  • DT514
  • DT515
  • DT519
  • DT520
  • DT521
  • DT522
  • DT545