CU-Tausch

Information

• Der CU-Tausch (Tausch des Customizings) ersetzt das Customizing des PLANTA project-Zielsystems durch das des Quellsystems.
  • Zum einen erfolgt das durch das Ersetzen von entsprechenden Datenbankinhalten, zum anderen durch den Tausch der Client- und Server-Python-Verzeichnisse.

Voraussetzungen

• Auf dem System, auf dem der CU-Tausch durchgeführt wird (typischerweise der Applikationsserver), muss
  • Java installiert sein (aktuell JDK/JRE in Version 1.6)
  • 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 die 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
  • Für die Erstellung von Modulvarianten kann es nur ein führendes System geben, sodass entschieden werden muss, ob Modulvarianten nur im Entwicklungs- oder nur im Produktivsystem erstellt werden.
  • Wird sich für das Produktivsystem entschieden, ist nichts weiter zu tun.
  • Andernfalls: 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.
      • Vorschlag: Nach der initialen Einrichtung des Entwicklungssystems bzw. nach jedem Neuaufsetzen des Entwicklungssystems als Kopie des Produktivsystems als Erstes das Präfix der Autonummern der DT500 und DT544 auf Kundenlizenz + 1 setzen, da nur dann die Daten in den entsprechenden Tabellen auf dem gleichen Stand sind.
      • Da bei jedem nachfolgenden CU-Tausch auch diese Einstellung von der Quelle in das Ziel übertragen wird, wird außerdem ein Skript benötigt, das anschließend im Zielsystem die beiden Autonummern-Präfixe in der DT439 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 (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, STANDARD 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 (ora), 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)

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 auch ggf. auch die Pythonverzeichnisse 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