Package: Install

Package release archives created with the module pm.Build can be installed in any client with this module. The installation consists of serveral steps.

Designation

Name

pm.Install

Aliases

Deploy, PackageDeploy, Install, pm.PackageInstall

Configuration

Optionen

Package Release File (zip-file)

Absolute path to the Package release file

Skip installation of configuration objects (no-config)

If set alle configuration objects will not be installed and the old version will be kept

force import of connection objects (force-import-conn)

forces the import of connection objects under certain conditions even if it exists already

Custom Metadata Entries (custom-metadata-entries)

A list of additional metadata entries which will be added to the metadata variable of the package. Each entry of the list consists of the key and a value separated by an equal sign

Storage Object for Credentials (credential-storage)

storage object containing the credentials

Connection (credential-source)

Connection for the storage object containing the credentialsMögliche Werte: <TabItem b4A Verbindungen>

Description

The phases of an installation are defined in the following list and are run through in the following order.

• Unpacking the package archive in a temporary directory

• Check whether a previous version is installed. If necessary, the old version is moved to the base folder of the new version

• If necessary, remove schedule tasks from the previously installed version

• Import the objects

  • Import the object

    • Restore access data for LOGIN and CONN objects if necessary
    • Restore the object authorizations, if available

• Import the configuration variables and, if necessary, the client configurations

  • Restore access data for LOGIN and CONN objects if necessary
  • Restore the object authorizations, if available

• Recalculate calendar objects for which there were problems after the import due to dependencies on calendar terms that do not yet exist

• Create runtime variables if they do not yet exist in the client

• Marking the obsolete objects (Details)

• Adding user-defined metadata entries

• Add schedule tasks if necessary

There are a few exception rules when importing objects

• If the type or subtype of the object has changed compared to the currently installed version, the object is marked as obsolete before importing.
• If an object is located in a different folder in the current version than in the new version, it will be moved beforehand.
• If an object has a type that is contained in the configuration setting pm-createonly-objecttypes, the object is only installed if it is still available. the object is only installed if it does not yet exist.

When importing the configurations, there are a few additional actions depending on the object type

• When importing objects of the Schedule (JSCH) type, the definition is automatically reloaded when the period changes. is triggered
• When importing objects of type Calendar (CALE), a recalculation is automatically triggered

Obsolete objects

When installing a package that is already installed in another version, the system checks whether there are obsolete objects. This means that the system checks whether the previously installed version contains objects that are no longer included in the new version. If such objects exist, they are moved and renamed. The pattern for the new name of the objects is stored in the configuration setting pm-depcreated-pattern and can contain the following b4A expression attributes:

• object_name - old object name
• timestamp - a timestamp at the current time
• counter - a counter that starts at 0.

If an object with the name already exists, the pattern for the new name is extended by the ending -%(counter) (if counter is not yet included) and the counter is increased by one. This process is repeated until a name is found that does not yet exist in the client. The objects are then moved to the folder defined in the configuration setting pm-deprecated_folder. A folder structure is created below the folder that corresponds to the previous location of the objects.

There is a special rule for objects of type HOSTG. As these objects must be significantly shorter, they are marked as obsolete using a different procedure. Moving follows the same algorithm. However, the renaming is carried out on the basis of the configuration setting pm-deprecated-agentgroup-pattern. The default value does not contain the object name, only a counter is used. To ensure that the old object name is not lost, this is entered in Archive Key 1.

Old	Old folder	Type	New name	New folder
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

If both objects with the new names already existed, they would be named as follows instead.

Old	Old folder	Type	New name	New folder
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

Examples

Simple installation of a package release

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

Installation of a package release with the use of a storage object for access data

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

Add custom metadata entries when installing a package release

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