Package: Installieren

Die mit dem Modul pm.Build erstellten Package-Archive können mit diesem Modul in einem beliebigen Mandanten eingespielt werden. Die Installation des Package läuft dabei in mehreren Stufen ab.

Bezeichnung

Name

pm.Install

Aliase

Deploy, PackageDeploy, Install, pm.PackageInstall

Konfiguration

Gruppe: Optionen

Package-Release-Datei (zip-file)

Absoluter Pfad zur Package-Release-Datei

Überspringe die Installation der Konfigurationsobjekte (no-config)

Ist die Option gesetzt, dann werden die Konfigurationsobjekte nicht installiert und die alten Versionen werden behalten

Erzwingen den Import des Connection-Objektes (force-import-conn)

Erzwingt den Import von Connection-Objekten unter bestimmten Bedingungen, wenn sie bereits existieren

Benutzerdefinierte Metadaten-Einträge (custom-metadata-entries)

Eine Liste von zusätzlichen Metadaten-Einträgen, die zur Metadaten-Variable des Package hinzugefügt werden. jeder Listeneintrag besteht aus dem Key und einem Wert separiert mit einem Gleichheitszeichen.

Storage-Objekt für Zugangsdaten (credential-storage)

Storage-Objekt mit den Zugangsdaten

Verbindung (credential-source)

Verbindung für das Storage-Objekt mit den Zugangsdaten

Mögliche Werte: <definierte b4A Verbindungen>

Beschreibung

Die Phasen einer Installation sind in der folgenden Liste definiert und werden nach der Reihenfolge durchlaufen.

• Auspacken des Package-Archivs in einem temporären Verzeichnis

• Überprüfung, ob eine vorherige Version installiert ist. Gegebenenfalls wird die alte Version in den Basisordner der neuen Version verschoben

• Gegebenenfalls Schedule-Aufgaben der zuvor installierten Version entfernen

• Importieren der Objekte

  • Import des Objekts

    • Bei LOGIN- und CONN-Objekten ggf. Zugangsdaten wiederherstellen

    • Wiederherstellen der Objektberechtigungen falls vorhanden

• Importieren der Konfigurationsvariablen und ggf. der Mandantenkonfigurationen

  • Bei LOGIN- und CONN-Objekten ggf. Zugangsdaten wiederherstellen

  • Wiederherstellen der Objektberechtigungen falls vorhanden

• Anlegen der Laufzeitvariablen falls diese noch nicht im Mandant existieren

• Markieren der veralteten Objekte (siehe Veraltete Objekte)

• Hinzufügen von benutzerdefinierten Metadaten-Einträgen

• Gegebenenfalls Schedule-Aufgaben hinzufügen

Beim Importieren der Objekte gibt es ein paar Ausnahmeregeln

• Hat sich der Typ oder Subtyp des Objektes gegenüber der aktuell installierten Version geändert, dann wird das Objekt vor dem Import als veraltet markiert.

• Wenn ein Objekt in der aktuellen Version in einem anderen Ordner liegt als in der neuen Version, dann wird es zuvor verschoben.

• Hat ein Objekt einen Typ, der in der Konfigurationseinstellung pm-createonly-objecttypes enthalten ist, dann wird das Objekt nur installiert, wenn es noch nicht existiert.

Beim Importieren der Konfigurationen gibt es in Abhängigkeit vom Objekttyp ein paar zusätzliche Aktionen

• Beim Import von Objekten des Types Schedule (JSCH) wird automatisch ein Neuladen der Definition beim Periodenwechsel ausgelöst

• Beim Import von Objektes des Types Kalender (CALE) wird automatisch eine Neuberechnung ausgelöst

Veraltete Objekte

Bei der Installation eines Package, das bereits in einer anderen Version installiert ist, wird geprüft, ob es veraltete Objekte gibt. Dies bedeutet, dass geprüft wird, ob die zuvor installierte Version Objekte enthält, die in der neuen Versionen nicht mehr enthalten sind. Existieren solche Objekte, dann werden diese verschoben und umbenannt. Das Muster für den neuen Namen der Objekte ist in der Konfigurationseinstellung pm-depcreated-pattern hinterlegt und kann die folgenden b4A Expression Attribute enthalten:

• object_name - alter Objektname

• timestamp - ein Zeitstempel zum aktuellen Zeitpunkt

• counter - ein Zähler, der bei 0 beginnt.

Sollte bereits ein Objekt mit dem Namen existieren, dann wird das Muster für den neuen Namen um die Endung -%(counter) erweitert (falls counter noch nicht enthalten ist) und der Zähler um eins erhöht. Dieser Vorgang wird wiederholt bis ein Name gefunden wurde, der noch nicht im Mandant existiert. Verschoben werden die Objekte anschließend in den Ordner, der in der Konfigurationseinstellung pm-deprecated_folder definiert ist. Unterhalb des Ordners wird eine Ordnerstruktur angelegt, die dem vorherigen Ort der Objekte entspricht.

Für Objekte des Typs HOSTG gibt es eine Sonderregelung. Da diese Objekte deutlich kürzer sein müssen werden diese nach einem anderen Verfahren als veraltet markiert. Das Schieben folgt dem selben Algorithmus. Die Umbenennung wird allerdings auf Basis der Konfigurationseinstellung pm-deprecated-agentgroup-pattern vorgenommen. Im Vorgabewert ist der Objektname nicht enthalten, sonder es wird nur ein Zähler genutzt. Damit der alte Objektname nicht verloren geht wird diese in den Archiv Key 1 eingetragen.

Vorher			Nachher
Name	Ordner	Typ	Name	Ordner
B4A.BASE.JOBS.TEST1	PKG/B4A.BASE/SOURCE	JOBS	DEPRECATED#B4A.BASE.JOBS@2021-06-14_153600	_DEPRECATED/PKG/B4A.BASE/SOURCE
B4A.HOSTG.LINUX	PKG/B4A.BASE/SOURCE	HOSTG	DEPRECATED#HOSTG.0	_DEPRECATED/PKG/B4A.BASE/SOURCE

Würden beide Objekte mit den neuen Namen schon existieren, dann würden sie stattdessen wie folgt benannt werden.

Vorher			Nachher
Name	Ordner	Typ	Name	Ordner
B4A.BASE.JOBS.TEST1	PKG/B4A.BASE/SOURCE	JOBS	DEPRECATED#B4A.BASE.JOBS@2021-06-14_153600-0	_DEPRECATED/PKG/B4A.BASE/SOURCE
B4A.HOSTG.LINUX	PKG/B4A.BASE/SOURCE	HOSTG	DEPRECATED#HOSTG.1	_DEPRECATED/PKG/B4A.BASE/SOURCE

Beispiele

Einfache Installation eines Package Release

./b4A pm.Install -C TEST-0001 --zip-file B4A.BASE-1.0.0.zip

Installation eines Package Release mit der Verwendung eines Storage-Objekts für Zugangsdaten

./b4A pm.Install -C TEST-0001 --zip-file B4A.BASE-1.0.0.zip --credential-storage SYS.SETTINGS.STORE.CREDS --credential-source PROD-0100

Bei der Installation eines Package Release benutzerdefinierte Metadaten-Einträge hinzufügen

./b4A pm.Install -C TEST-0001 --zip-file B4A.BASE-1.0.0.zip --custom-metadata-entries "Key1=Wert1,Key2=Wert 2"