Blog

Release notes Thinkwise Deployment Center (2.2.0)

New

Support for deploying the Thinkwise Upcycler (GUI and CLI)

It is now possible to deploy the Thinkwise Upcycler with the Deployment Center.
Deploying the Thinkwise Upcycler through the GUI or CLI is similar to the Thinkwise Software Factory.

To deploy the Upcycler through the CLI:

twdeployer.exe upcycler auto -m ".../Manifest.json" -s ".\sqlserver" -n "THINKWISE_UPCYCLER" --iam-name "THINKWISE_IAM"

twdeployer.exe upcycler install -m ".../Manifest.json" -s ".\sqlserver" -n "THINKWISE_UPCYCLER" --iam-name "THINKWISE_IAM"

twdeployer.exe upcycler upgrade -m ".../Manifest.json" -s ".\sqlserver" -n "THINKWISE_UPCYCLER" --iam-name "THINKWISE_IAM"

twdeployer.exe upcycler hotfix -m ".../Manifest.json" -s ".\sqlserver" -n "THINKWISE_UPCYCLER"

Application model synchronization as a separate deployment option (GUI and CLI)

We have added a separate deployment option for synchronizing the meta model of an application into IAM without installing or upgrading the database.
Currently, this is available for deployment packages generated by the Software Factory if the Deployment Center detects a 'MetaModel' folder on the same directory level as an 'Install' or 'Upgrade' package.

The synchronization deployment for the Software Factory and Upcycler requires the name of a matching database due to their post-synchronization scripts. These products use the database name, for example, to create an application record inside the target IAM.
For applications other than the Software Factory and Upcycler, providing a database name is optional since the Deployment Center cannot detect if the post-synchronization scripts use it.

We are still looking into extending the manifest specification to make the model synchronization a separate package type with options to specify parameters included in the post-synchronization scripts.

*Synchronizing the meta model through the GUI*

To synchronize the meta model in the CLI:

twdeployer.exe iam sync-model -m ".../Manifest.json" -s ".\sqlserver" -n "THINKWISE_IAM"
twdeployer.exe sf/upcycler/app sync-model -m ".../Manifest.json" -s ".\sqlserver" --iam-name "THINKWISE_IAM" --db-name "THINKWISE_SF/UPCYCLER"

Skip synchronizing the application model into IAM (GUI and CLI)

You can now skip the synchronization of the application model during the installation or upgrade of a Software Factory, Upcycler, or customer app. This can be useful when a single IAM has been configured with multiple instances of the same application on different servers.

In the GUI, you can skip the synchronization step by clearing the Import application model checkbox on the new Synchronization options screen:

*Clear the Import application model checkbox to skip synchronization*

In the CLI, the auto, install, and upgrade commands for the Software Factory (sf), Upcycler (upcycler), and app (app) have been updated with a --skip-model-sync switch:

twdeployer sf/upcycler/app auto/install/upgrade ... --skip-model-sync

Note that the --iam-name option is no longer required if --skip-model-sync is used.

Settings file for the Deployment Center's GUI

We have added a settings file for the Deployment Center's GUI that you can use to store some default values for various screens during startup.

The default template is:

{
  "DbConnection": {
    "Host": "",
    "Username": ""
  },
  "IISApi": {
    "ServerUrl": "https://localhost:55539",
    "ApiKey": "",
    "Username": "",
    "TrustInvalidSSLCert": false
  },
  "Manifest": {
    "SelectionDirectory": "",
    "LoadOnStartup": [
    ],
    "HideLoadAfterLoadOnStartup": true
  }
}

DbConnection - use this section to specify a default Host and Username when making a connection to a database server, for example, when starting an install or upgrade flow.
- If Username is empty or otherwise unspecified, the GUI assumes you want to use Integrated Security instead.
- After a successful connection to a database server, the GUI will continue to load the information of the last successful connection for subsequent screens, like in previous releases.

{
  "DbConnection": {
    "Host": ".\\sql2019",
    "Username": "sa"
   }
}

*Result of DbConnection settings in the GUI*

IISApi - Use this section to specify default connection settings to a Microsoft IIS Administration API instance.

{
  "IISApi": {
    "ServerUrl": "https://localhost:55539",
    "ApiKey": "not a real key just an example",
    "Username": "tsf\\thisisausername",
    "TrustInvalidSSLCert": true
  }
}

Manifest - Use this section to indicate how manifests are loaded by the GUI at startup.
- LoadOnStartup - Use this section to specify multiple manifest files to load during startup. When you leave this unspecified or empty, the GUI will default look for a Manifest.json/yaml/yml file in the executable's directory.
- Paths are relative to the location of the executable. So, if you also want to load the default manifest locations, you must add them as well. For example:

{
  "Manifest": {
    "LoadOnStartup": [
      "Manifest.json",
      "C:\\Manifests\\Manifest_2021_2.json",
      "C:\\Manifests\\Manifest_2021_3.json",
      "C:\\Manifests\\Manifest_2022_1.json"
    ]
  }
}

*Result of Manifest settings in the GUI*

HideLoadAfterLoadOnStartup - By default, the GUI hides the separate manifest loading and selection screens if a manifest is loaded during startup. You can now change this behavior by setting it to false.

{
 "Manifest": {
   "LoadOnStartup": [
     "C:\\Manifests\\Manifest_2022_1.json"
   ],
   "HideLoadAfterLoadOnStartup": false
  }
}

*The separate manifest loading and selection screens are no longer hidden*

SelectionDirectory - Use this setting to change the file picker on the Load Manifest screen, to always try and open in the specified directory.
- If the directory does not exist or cannot be found, the file picker control will fall back on the default Windows behavior. In that case, it tries to open the last directory from which a user has selected a file.
- The directory path must be specified using Windows style path separators (backslash). Since the settings file uses JSON, this means you always need to escape it. So, use:
  - C:\\Manifests instead of C:/Manifests or C:\Manifests
  - \\\\unc_share\\directory instead of \\unc_share\directory

{
  "Manifest": {
    "SelectionDirectory": "C:\\Manifests"
  }
}

*File picker opens in specified directory*

Manifest - Specifying a directory path in a supportedVersion

When the Deployment Center was first made, the the Software Factory and IAM upgrade scripts were released with all generated scripts concatenated into one. This was more convenient because the install and upgrade scripts had to be run manually through, for example, SQL Server Management Studio. And sometimes, a separate pre-upgrade script had to be run before an upgrade.

There was no real pattern for naming these scripts. Therefore, we made a decision in the design of the deployment manifest to specify the path to each script for each supportedVersion in an upgrade package, using the files property.

Then, since the 2018.3 Thinkwise Platform release, we decided to skip the concatenating step and release the generated scripts as-is. That did not really change anything for the manifest since files could still be specified as always:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    packages:
      - type: "Upgrade"
        path: "IAM/Upgrade"
        supportedVersions:
          - version: "2021.3"
            upgradesTo: "2022.1"
            files:
              - "2022.1\\020_Upgrade.sql"
              - "2022.1\\030_Checks.sql"
              - "2022.1\\040_Constraints.sql"
              - "2022.1\\050_Indexes.sql"
              - "2022.1\\060_Functions.sql"
              - "2022.1\\065_Table_valued_functions.sql"
              - "2022.1\\070_Views.sql"
              - "2022.1\\080_Procedures.sql"
              - "2022.1\\090_Instead_of_triggers.sql"
              - "2022.1\\100_Triggers.sql"
              - "2022.1\\110_Tasks.sql"
              - "2022.1\\120_Defaults.sql"
              - "2022.1\\130_Layouts.sql"
              - "2022.1\\140_Contexts.sql"
              - "2022.1\\145_Badges.sql"
              - "2022.1\\150_Processes.sql"
              - "2022.1\\999_Apply_roles_on_database.sql"
              - "2022.1\\999_Manual.sql"

It did, however, cause the manifest to grow larger and larger with each consecutive platform release since each supported upgrade version added about 12-17 script files.

To reduce that amount, you can now use a path property to specify the directory containing the upgrade scripts:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    packages:
      - type: "Upgrade"
        path: "IAM/Upgrade"
        supportedVersions:
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"

Some rules apply when you use the path property for a supportedVersion:

Only the immediate directory is scanned for .sql files. Subdirectories will be skipped.
All .sql files inside the specified directory must adhere to the <order/sequence number>_<code file name>.sql format the Software Factory uses to generate the code files.
The path of a supportedVersion is relative to the path of the upgrade package, which in turn is relative to the location of the manifest file.
- Using the manifest above as an example: If the manifest file is located at "C:\Manifests", the path of the upgrade package resolves to "C:\Manifests\IAM\Upgrade", and the path of the 2021.3 -> 2022.1 supportedVersion resolves to "C:\Manifests\IAM\Upgrade\2022.1".

Manifest - Override the fallback encoding of script files

Due to technical reasons, the Deployment Center has always assumed that the default encoding of script files generated by the Software Factory is windows-1252.

However, the script generation process has been changed in platform release 2021.3. Since it is now run by Indicium, these reasons no longer apply.

Therefore, the V2 specification of the manifest file has been extended to allow overriding the encoding for script files. This is a backward-compatible way to change the encoding of the generated scripts in a future platform release.

The encoding property can be set at the following levels inside an IAM, Software Factory, Upcycler, or application type product:

Product level.
Package level.
supportedVersion level inside an upgrade package.

To maintain backward compatibility with previously generated manifests using the V2 specification, the default value of the encoding property is still windows-1252.

Meaning that the following manifest:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    packages:
      - type: "Install"
        path: "IAM/Install"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
      - type: "Hotfix"
        path: "IAM/Hotfixes"

is interpreted by the Deployment Center as:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "windows-1252"
    packages:
      - type: "Install"
        path: "IAM/Install"
        encoding: "windows-1252"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "windows-1252"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "windows-1252"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "windows-1252"
      - type: "Hotfix"
        path: "IAM/Hotfixes"
        encoding: "windows-1252"

When the encoding is changed at higher levels, the Deployment Center will also use that encoding at lower levels or until it encounters another override value.

Notes:

Because the meta model import is not a separate package type inside manifests using schema V2, it currently assumes the same encoding as the install or upgrade package, depending on which was used to detect the presence of the import scripts (usually the install package).
encoding specifies the fallback encoding it should use if it does not detect a BOM. This means that technically you could mix file encodings in a package as long as encoding with a defined BOM is used. But if possible, it is still best to use a single encoding.

Examples:

Change the default script encoding for the entire product to UTF-8:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
      - type: "Hotfix"
        path: "IAM/Hotfixes"

Manifest as interpreted by the Deployment Center:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
        encoding: "utf-8"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "utf-8"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "utf-8"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "utf-8"
      - type: "Hotfix"
        path: "IAM/Hotfixes"
        encoding: "utf-8"

Change the default encoding of the product to UTF-8 but leave the upgrade package at Windows-1252:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "windows-1252"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
      - type: "Hotfix"
        path: "IAM/Hotfixes"

Manifest as interpreted by the Deployment Center:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
        encoding: "utf-8"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "windows-1252"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "windows-1252"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "windows-1252"
      - type: "Hotfix"
        path: "IAM/Hotfixes"
        encoding: "utf-8"

Change the default encoding of the product to UTF-8 but leave the supportedVersion upgrade for 2021.2 to 2021.3 at Windows-1252:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "windows-1252"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
      - type: "Hotfix"
        path: "IAM/Hotfixes"

Manifest as interpreted by the Deployment Center:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
        encoding: "utf-8"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "utf-8"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "windows-1252"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "utf-8"
      - type: "Hotfix"
        path: "IAM/Hotfixes"
        encoding: "utf-8"

Change the default encoding of the product to UTF-8, leave the upgrade package at Windows-1252 but use UTF-8 again for the 2021.3 to 2022.1 supportedVersion upgrade:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "windows-1252"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "utf-8"
      - type: "Hotfix"
        path: "IAM/Hotfixes"

Manifest as interpreted by the Deployment Center:

schema: 2
products:
  - type: "IAM"
    version: "2022.1"
    projectFolder: "T:\\Product Innovation\\Applications"
    dependencies:
      - "CompatibilityLevel140"
    encoding: "utf-8"
    packages:
      - type: "Install"
        path: "IAM/Install"
        encoding: "utf-8"
      - type: "Upgrade"
        path: "IAM/Upgrade"
        encoding: "windows-1252"
        supportedVersions:
          - version: "2021.2"
            upgradesTo: "2021.3"
            path: "2021.3"
            encoding: "windows-1252"
          - version: "2021.3"
            upgradesTo: "2022.1"
            path: "2022.1"
            encoding: "utf-8"
      - type: "Hotfix"
        path: "IAM/Hotfixes"
        encoding: "utf-8"

Changed

IP validation for bindings when creating a new site (GUI)

In the GUI, the Next button will no longer be enabled when you enter an invalid IP address.

No IP address (bind to all IP addresses), Next is enabled:

Valid IP input, Next is enabled:

IP not parsable, Next is disabled:

For future releases, we are still working on:

Move Deployer CLI to .NET 6.
Check access rights on the target directory when installing Indicium to a local IIS.
A UI-assisted meta source selection for simple configuration modes during Indicium and Windows GUI flows

Would like to have:

A simple configuration mode for Windows GUI flows to make it easier to get a basic installation up and running.

New

Support for deploying the Thinkwise Upcycler (GUI and CLI)

Application model synchronization as a separate deployment option (GUI and CLI)

Skip synchronizing the application model into IAM (GUI and CLI)

Settings file for the Deployment Center's GUI

Manifest - Specifying a directory path in a supportedVersion

Manifest - Override the fallback encoding of script files

Changed

IP validation for bindings when creating a new site (GUI)

Next

Sign up

Login to the Thinkwise Software Community

Scanning file for viruses.

This file cannot be downloaded