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
)
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 Objektnametimestamp
- ein Zeitstempel zum aktuellen Zeitpunktcounter
- 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 |
|
|
JOBS |
|
|
|
|
HOSTG |
|
|
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 |
|
|
JOBS |
|
|
|
|
HOSTG |
|
|
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"