Kundencustomizing-Deployment

Info

• Das Customizing-Deployment dient dem Ausrollen des Customizings, z.B. aus einem Entwicklungssystem beim Kunden in dessen Produktivsystem. Hierbei wird u.a. das Customizing im Zielsystem unter Verwendung des Datenbank-Exports/-Imports vollständig durch einen Export aus dem Quellsystem ersetzt.

Voraussetzungen

• Quell- und Zielsystem müssen kongruent sein, d.h.

  • der Programmstand beider Systeme muss identisch sein und alle Migrationspakete müssen denselben Stand haben

  • das Datenbankschema des Zielsystems muss auf dem Stand des Quellsystems sein

Ein Customizing-Deployment besteht grundsätzlich aus folgenden Elementen:

• SQL-Dateien (Beispiel: sql_planta_1_1.sql)

• Python-Verzeichnis des Servers (Beispiel: py.zip)

• Customizing-Deployment-Dateien (Beispiel: cu_deployment_2015_02_04.zip)

Vorgehensweise beim Export

Der Export-Schritt ist notwendig, wenn Sie das Deployment intern selbst durchführen. Bei Fragen hierzu wenden Sie sich bitte an ihren PLANTA-Consultant.

Information

• Für den Export gibt es eine Parameterdatei, die alle notwendigen Daten bereitstellt.

  • Die Datei befindet sich im Customizing-Image unter config/export/customizing_deployment_venus.par.

  • Sie ist vom Server zugänglich über das transfer volume unter /mnt/transfer/config/export/customizing_deployment_venus.par.

Beispiel docker compose für einen Export

services:
  manager:
    image: registry.planta.services/project/manager:latest
    environment:
      - "SKIP_INIT=1"
      - "planta__server__ppms_license=<lizenz nummer>"
      - "planta__server__hibernate__connection__url=<db url>"
      - "planta__server__hibernate__connection__username=<db user>"
      - "planta__server__hibernate__connection__password=<db password>"
    command: ["export", "@/mnt/transfer/config/export/customizing_deployment_venus.par --output-file /var/planta/export/cu_deployment.zip"]
    depends_on:
      customizing:
        condition: service_completed_successfully
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:ro
      - ./export:/var/planta/export:rw

  worker:
    image: registry.planta.services/project/worker:latest
    restart: unless-stopped
    environment:
      - "SESSION_LINK=manager:54242"
    depends_on:
      manager:
        condition: service_healthy
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:rw

  customizing:
    image: registry.planta.services/project/customizing:latest
    environment:
      - LOG_LEVEL=INFO
    volumes:
      - transfer:/mnt/transfer:rw

networks:
  internal:
volumes:
  transfer:

Vorgehensweise beim Import

Informationen

• Für den Import sind mehrere Schritte erforderlich.

• Die zugehörigen Parameterdateien befinden sich im Customizing-Image im Unterverzeichnis config/import/customizing_deployment.

• Sie sind vom Server zugänglich über das transfer volume unter /mnt/transfer/config/import/customizing_deployment/*.

Schritt 1: To-do vor Deployment

• Den PLANTA-Dienst stoppen.

Schritt 2: Ausführen der SQL-Dateien

• Gelieferte SQL-Datei(en) in einem Datenbankmanagement-tool ihrer Wahl ausführen

Schritt 3: Import von Customizing-Deployment-Dateien

• PLANTA liefert ein ZIP-Archiv mit den Customizing Deployment-Dateien (Beispiel: cu_deployment_2015_02_04.zip).

  • Dieses ZIP-Archiv muss nicht entpackt werden. Das Entpacken wird durch das Import-Verfahren von PLANTA automatisch durchgeführt.

• Das Zip-Archiv unter /var/planta im manager container mounten.

• Die docker compose muss mehrmals hintereinander ausgeführt werden, mit dem jeweiligen Schritt einkommentiert:

Beispiel docker compose für einen Import

services:
  manager:
    image: registry.planta.services/project/manager:latest
    environment:
      - "SKIP_INIT=1"
      - "planta__server__ppms_license=<lizenz nr>"
      - "planta__server__hibernate__connection__url=<db url>"
      - "planta__server__hibernate__connection__username=<db user>"
      - "planta__server__hibernate__connection__password=<db password>"
    command: [ "import", "@/mnt/transfer/config/import/customizing_deployment/01_replace_q1b_q2b.par --input-file /var/planta/export/cu_deployment.zip" ]
    #command: [ "import", "@/mnt/transfer/config/import/customizing_deployment/02a_replace_module_variants.par --input-file /var/planta/export/cu_deployment.zip" ]
    #command: ["import", "@/mnt/transfer/config/import/customizing_deployment/02b_add_module_variant_itexts.par --input-file /var/planta/export/cu_deployment.zip"]
    #command: [ "import", "@/mnt/transfer/config/import/customizing_deployment/03_replace_interfaces_venus.par --input-file /var/planta/export/cu_deployment.zip" ]
    #command: ["import", "@/mnt/transfer/config/import/customizing_deployment/04_replace_process_models.par --input-file /var/planta/export/cu_deployment.zip"]
    depends_on:
      customizing:
        condition: service_completed_successfully
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:ro
      - ./export:/var/planta/export:rw

  worker:
    image: registry.planta.services/project/worker:latest
    restart: unless-stopped
    environment:
      - "SESSION_LINK=manager:54242"
    depends_on:
      manager:
        condition: service_healthy
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:rw

  customizing:
    image: registry.planta.services/project/customizing:latest
    environment:
      - LOG_LEVEL=INFO
    volumes:
      - transfer:/mnt/transfer:rw

networks:
  internal:
volumes:
  transfer:

Schritt 4: Einspielen neuer Dateien in das Python-Verzeichnis des Servers

• Das Zip-Archiv mit dem Python-Verzeichnis entpacken.

• Alle Unterverzeichnisse des neuen "py"-Verzeichnisse in das gemountete "py"-Verzeichnis des Servers kopieren.

  • Wurde ein individuelles Image gebaut entfällt dieser Schritt

Schritt 5: To-do nach Deployment

• Den PLANTA-Dienst starten.

  • Das target-Verzeichnis wird mit aktuellen POJO-Klassen neu generiert.

Hinweise

• Werden beim Import die Inhalte der Datentabellen übertragen, die eine Autonummer besitzen, deren Zählerstände jedoch nicht, müssen die Zählerstände anschließend manuell angepasst werden.

• Werden beim Import History-Datentabellen (_HIS) übernommen, muss die HIBERNATE_SEQUENCE im Zielsystem manuell auf den höchsten Stand der in den History-Tabellen vorhandenen Daten gesetzt werden.

• Werden die Schnittstellen-Daten getauscht, gehen die archivierten Schnittstellen-Konfigurationen verloren.

  • Dies schließt sämtliche Logging-Daten, Parameter, sowie Pool-Datensätze ein!

• Der PLANTA-Import löscht keine Schnittstellen-Mappings, sondern importiert nur neue bzw. aktualisiert vorhandene Mappings. Die betroffenen Mappings müssen nach dem Import manuell gelöscht werden.

• Wenn beim Import Fehler aufgrund von Datenkorruptionen auftreten, kann das Modul Datenbank-Konsistenz überprüfen zur Prüfung bzw. Korrektur genutzt werden.