CU-Tausch Bis S 39.5.12

warning Hinweis

  • Das hier beschriebene Verfahren zum Austausch des Customizings gilt nur bis Server-Version < S39.5.12. Haben Sie eine Server-Version >= S39.5.12 im Einsatz, gehen Sie bitte zum Topic CustomizingDeployment.

more 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.
        • tip 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).
            • stop 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.

note 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
folder common enthält gemeinsam verwendete Komponenten
folder conf Konfigurationsordner, enthält u.A. die Konfigurationsdatei update.conf mit den entsprechend zu modifizierenden CU-Tausch-Parametern (s.u.)
folder CUunload enthält das Verfahren zum Entladen der Daten aus der Quelle
folder CUexchange
line_urfolder Prologue
line_urfolder Epilogue
line_urfolder 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
folder log Das Log-Verzeichnis, in dem die Logdateien abgelegt werden, die bei Entladen und Tausch geschrieben werden
bat setVar.bat
sh 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)
bat CUunload.bat
sh CUunload.sh
Startskript zum Entladen der Quelldaten (Windows/Linux)
bat CUexchange.bat
sh CUexchange.sh
Startskript für den Tausch der CU-Daten im Ziel (Windows/Linux)

Einstellungen

info 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
note 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
note Mögliche Werte:
  • MSSQL
  • ORACLE
  • POSTGRESQL
planta.db.source.access Quell-Zugriffsmethode
note 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
note Mögliche Werte:
  • MSSQL
  • ORACLE
  • POSTGRESQL
planta.db.destination.access Ziel-Zugriffsmethode
note 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

info Information
  • Ein CU-Tausch dauert ca. zwei Stunden.

more 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
more 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

more 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.
more 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.
    • tip Eine genauere Prüfung erlaubt die Protokolldatei CUunload.txt im Unterverzeichnis log.

more 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.
      • warning 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.
    • tip 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

warning 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
Topic revision: r19 - 2015-10-22 - 17:56:25 - MileneMelicias








 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten