Creating Software Packages
Creating Software Packages
Due to the fact that not all required operations for creating Software Packages are implemented by the SOAP interface, the creation of Software Packages becomes a multi level procedure.
First the necessary database objects are created by exploiting the SOAP interface. Then, in a second step, the parts of a Software Package that are residing in the file system have to be created. Together with the database objects this results in a minimal, but valid Software Package.
1. Creating Database Objects
|
Hint: The execution of these examples requires a connected PowerShell drive. |
The cmdlet New-EmdbSoftwarePackage is used to create Software Packages. The cmdlet expects the path of the Software Package in the Global Software Library, the type of the Software Package and the repository that should hold the data of the package as input parameters. In the following example a Software Package named "MyEscriptPackage" is created in the folder "Application Library". The package is created in the master repository:
|
$MyRepository = "Master" $MyPackagePath = "emdb:\rootDSE\Global Software Library\Application Library\MyEScriptPackage" $MySoftwarePackage = New-EmdbSoftwarePackage -Path $MyPackagePath -PackageType eScriptPackage -RepositoryID $MyRepository |
After invoking the cmdlet, a warning message indicating that the Software Package does not exist in the file system yet and is therefore not complete resp. valid, occurs. If this message is answered in a positive manner, the database objects representing this Software Package are created. You can refer to the DSMC to proof this. However, viewing the package directory results in an error message. This is obvious, because of the lack of the file system objects of the newly created Software Package.
The next example is slightly changed:
|
$MyRepository = "Master" $MyPackagePath = "emdb:\rootDSE\Global Software Library\Application Library\MyEScriptPackage" $MySoftwarePackage = New-EmdbSoftwarePackage -Path $MyPackagePath -PackageType eScriptPackage -RepositoryID $MyRepository -CustomDepotManagement |
The additional switch parameter -CustomDepotManagement suppresses the warning message and prepares the Software Packages for the second step.
2. Creating File System Objects
|
Hint: Starting with DSM 2017 specifying the Fileset-version is mandatory, if filesystem content should be used. Therefore, the following lines must be added to the above examples: |
|
$MySoftwarePackage.FilesetVersion = 1 $MySoftwarePackage.Update() |
In this second step, the file system operations that are not implemented by the SOAP interface are performed. In the simplest case, creating an eScript Package, only the empty file "Script.inc" has to be created. To illustrate the behaviour in this example a additional message box is implemented.
First the path of the file system objects has to be determined. The path consists of a UNC path describing the DSM$ share, the work directory, the Id of the choosen repository and the Id of the Software Package. Next this path and the file "Script.inc" will be created in the file system:
|
$MyDSMShare = "\\CHISV01\DSM$" $MyWorkPath = "$MyDSMShare\Work\$($MySoftwarePackage.RepositoryID)\Projects\$($MySoftwarePackage.PackageId)" $MyScriptInc = "MsgBox`r`n Hello World!`r`nEndProc" New-Item -ItemType directory filesystem::$MyWorkPath New-Item -ItemType file -Path "filesystem::$MyWorkPath\Script.inc" -Value $MyScriptInc |
Now the Software Package is complete and valid and it can be executed locally or distributed and assigned to its targets.