Skip to main content

Thinkwise Deployment Center

The Thinkwise Deployment Center ('Deployer') is created to make the deployment of Thinkwise products easier.

Products that are currently supported for deployment by the Thinkwise Deployment Center include:

  • Intelligent Application Manager
  • Software Factory
  • Customer applications (starting from the Software Factory/IAM v2019.1 and Deployer v1.8.0)
  • Universal GUI (starting from Deployer v2.0.0)
  • Indicium Service Tiers
  • Windows GUI
  • Web GUI
note

Remote Universal GUI, Web GUI and Indicium deployment is currently only available through use of the Microsoft IIS Administration API.

The Thinkwise Deployment Center is available as a GUI application (twdeployerGUI.exe) or as a commandline tool (twdeployer.exe). It is currently not possible to download these tools from TCP separately. Instead, both are included when downloading an installation package from TCP.

note

Both versions require that .NET Framework 4.6.1 or higher is installed on the computer that runs the deployer tool.

Manifest

The manifest is a JSON or YAML configuration file that describes the structure of deployable products inside an installation package to the deployer. This mostly includes the types of products contained in the package and the location of the files needed to deploy them.

Schema

The schema specification version of the manifest dictates the way the deployer translates the contents to deployable products.

Version 1 was created to support installation packages that are downloaded from TCP. When the schema specification version is not declared inside a manifest the deployer will assume that the schema of said manifest corresponds to version 1.

A schema specification version 2 has been introduced in version 1.8.0 of the deployer to support the creation of manifests for custom applications. It is not recommended to use version 1 to create custom installations.

Starting from the 1.8.0 release of the deployer, manifests using schema 1 are considered deprecated. Support for these manifests has been removed in version 2.0.0.

Schema specification (v2)

This section describes the structure and properties of a manifest that uses schema specification V2/2.

Root properties

PropertyValueDescriptionRequired
schema2 or "V2".Declares the schema version that the manifest file uses. If absent or set to value other than 2/"V2" the deployer assumes schema version 1 is used.โœ“
defaultPathAn absolute file path.Gives the deployer a default directory root path for the following:

  • The directory of the database application files
  • The directory to install a Mobile/Windows GUI to.
productsA collection of products.โœ“

Products

PropertyValueDescriptionRequired
typeA string with one of the following values:

Declares the type of product that is being described to the deployer.

Depending on the value different properties are expected.
โœ“

Database products

Database products are used for applications generated by a Software Factory.

Valid types for database products are:

  • IAM
  • SF
  • Application
PropertyValueDescriptionRequired
projectId"MY_APP"A string corresponding to the application's project ID in the Software Factory that generated the installation/upgrade files.Application
version"2018.2", "2019.1", "2019.1", "1.00", "1.10" etc.The version of the application contained in the installation package.โœ“
metaVersion"2019.1", "2019.1" etc.A string corresponding to the IAM/SF version an application is targeting.

Note: For SF and IAM types this value is considered equal to the version property and is therefore ignored.
Application
projectFolder"D:\\SoftwareFactory\\Applications"An absolute file path that should be equal to the project's project folder specification value that was used when generating the installation scripts, WITHOUT the project ID and version parts.

Used to update imported IAM models with the path that the deployer used during installing or upgrading a database product.
โœ“
dependenciesSee Database dependency valuesA collection of strings that indicate pre-conditions that the database or database engine must satisfy before an install or upgrade can be performed.
packagesA collection of database packages.Describes which actions the deployer can perform for this database product.โœ“

Database dependency values

ValueChecked duringDescriptionSupported in deployer
CompatibilityLevel100
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 100 (SQL Server 2008 (R2)) or higher during an upgrade or installation.

Note: This is the minimum level for scripts generated by SF/IAM installations from 2017.1 until 2019.1.
>= 1.8.0
CompatibilityLevel110
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 110 (SQL Server 2012) or higher during an upgrade or installation.

Note: This is the minimum level for scripts generated by 2019.1 SF/IAM installations and onwards.
>= 1.8.0
CompatibilityLevel120
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 120 (SQL Server 2014) or higher during an upgrade or installation.>= 1.11.0
CompatibilityLevel130
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 130 (SQL Server 2016) or higher during an upgrade or installation.>= 1.11.0
CompatibilityLevel140
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 140 (SQL Server 2017) or higher during an upgrade or installation.>= 2.0.0
CompatibilityLevel150
  • Install
  • Upgrade
Checks if the targeted database (engine) compatibility level is set to 150 (SQL Server 2019) or higher during an upgrade or installation.>= 2.0.0
FullTextSearch
  • Install
  • Upgrade
Checks if the Full-Text Search feature is installed on the targeted SQL Server instance.>= 1.9.0
Invalid
  • Install
  • Upgrade
Represents an unrecognized dependency which will always block deployment.

If you encounter one of these please check if the dependency value you are trying to use is correctly spelled inside the manifest and supported by the deployer version that is being used.

Database packages

Database products are only considered full products when they declare at least one package property value.

PropertyValueDescriptionRequired
type
  • Install
  • Upgrade
  • Hotfix
The database product sub-type that the package is declaring.

Note: The hotfix sub-type is mostly used in conjunction with the IAM and SF product types. Users wishing to use the hotfix sub-type with the Application product type must adhere to certain rules for the deployer to properly execute such a combination. Please contact Thinkwise Product Innovation for more information about these rules.
โœ“
path
  • "IAM\\Install"
  • "D:/installation_packages/IAM/Install"
  • etc.
A directory path to the root of a generated database application package.

Relative paths are considered relative to the location of the manifest file.
โœ“
defaultDatabaseName"THINKWISE_IAM"A default database name to use during an Install package.

Note: Only used in the deployer GUI.
supportedVersionsA collection of supported upgrade version properties.Describes upgrade paths that the deployer can use to upgrade to the current product version.Upgrade

Supported upgrade versions

These properties are used to describe upgrade paths that the deployer can use when upgrading to the version that a database product declares.

PropertyValueDescriptionRequired
version"2017.1", "2019.1", "1.00" etc.The current version of the database product that is targeted for the upgrade.โœ“
upgradesTo"2019.1", "1.10" etc.The version that the database product which is targeted for an upgrade will have when all files have been executed.

This is then the next version that the deployer will look for in the supported upgrade version properties to find further upgrade files.

This process continues until the next upgradesTo version is equal to the product's declared version.

Having an incomplete or looping upgrade path results in an invalid Upgrade product.
โœ“
filesA collection of path strings.Absolute or relative path values to the files needed to perform the upgrade from the current version to the upgradesTo version.

Files are executed by the deployer in the order that they are inserted into the collection.

Relative paths are considered relative to the computed value of the database package's path property.
โœ“

GUI/Indicium products

These are the properties for all products that aren't a database application product.

Valid types for these products are:

  • Universal
  • Indicium
  • Windows
  • Web
  • Mobile
PropertyValueDescriptionRequired
path
  • "GUI\\Windows"
  • "D:/installation/GUI/Web"
  • etc.
A directory path to the root of the product files.

Relative paths are considered relative to the location of the manifest file.
โœ“
shortcutName"My_mobile_viewer"Mobile only and optional.

Provides a name for the shortcut to the viewer executable. If not provided the shortcut's name will be "Thinkwise".

Examples

note

These examples use the same structure that an installation package downloaded from TCP would use.

Installation packages downloaded from TCP always include a JSON manifest, click the YAML tab to see the equivalent in YAML.

Universal/Indicium/Win/Web/Mobile

{
"schema": 2,
"defaultPath": "D:\\SoftwareFactory",
"products": [
{
"type": "Universal",
"path": "GUI/Universal"
},
{
"type": "Indicium",
"path": "GUI/Indicium"
},
{
"type": "Windows",
"path": "GUI/Windows"
},
{
"type": "Web",
"path": "GUI/Web"
},
{
"type": "Mobile",
"path": "GUI/Mobile",
"shortcutName": "THINKWISE"
}
]
}

IAM

{
"schema": 2,
"products": [
{
"type": "IAM",
"version": "2021.3",
"projectFolder": "T:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel130"
],
"packages": [
{
"type": "Install",
"path": "IAM/Install",
"defaultDatabaseName": "THINKWISE_IAM"
},
{
"type": "Upgrade",
"path": "IAM/Upgrade",
"supportedVersions": [
{
"version": "2021.1",
"upgradesTo": "2021.2",
"files": [
"2021.2\\020_Upgrade.sql",
"2021.2\\030_Checks.sql",
"2021.2\\040_Constraints.sql",
"2021.2\\050_Indexes.sql",
"2021.2\\060_Functions.sql",
"2021.2\\065_Table_valued_functions.sql",
"2021.2\\070_Views.sql",
"2021.2\\080_Procedures.sql",
"2021.2\\090_Instead_of_triggers.sql",
"2021.2\\100_Triggers.sql",
"2021.2\\110_Tasks.sql",
"2021.2\\120_Defaults.sql",
"2021.2\\130_Layouts.sql",
"2021.2\\140_Contexts.sql",
"2021.2\\145_Badges.sql",
"2021.2\\150_Processes.sql",
"2021.2\\999_Apply_roles_on_database.sql",
"2021.2\\999_Manual.sql"
]
},
{
"version": "2021.2",
"upgradesTo": "2021.3",
"files": [
"2021.3\\020_Upgrade.sql",
"2021.3\\030_Checks.sql",
"2021.3\\040_Constraints.sql",
"2021.3\\050_Indexes.sql",
"2021.3\\060_Functions.sql",
"2021.3\\065_Table_valued_functions.sql",
"2021.3\\070_Views.sql",
"2021.3\\080_Procedures.sql",
"2021.3\\090_Instead_of_triggers.sql",
"2021.3\\100_Triggers.sql",
"2021.3\\110_Tasks.sql",
"2021.3\\120_Defaults.sql",
"2021.3\\140_Contexts.sql",
"2021.3\\150_Processes.sql",
"2021.3\\999_Apply_roles_on_database.sql",
"2021.3\\999_Manual.sql"
]
}
]
},
{
"type": "Hotfix",
"path": "IAM/Hotfixes"
}
]
}
]
}

SF

{
"schema": 2,
"products": [
{
"type": "SF",
"version": "2021.3",
"projectFolder": "T:\\Product Innovation\\Applications",
"dependencies": [
"CompatibilityLevel130",
"FullTextSearch"
],
"packages": [
{
"type": "Install",
"path": "SF/Install",
"defaultDatabaseName": "THINKWISE_SF"
},
{
"type": "Upgrade",
"path": "SF/Upgrade",
"supportedVersions": [
{
"version": "2021.1",
"upgradesTo": "2021.2",
"files": [
"2021.2\\020_Upgrade.sql",
"2021.2\\030_Checks.sql",
"2021.2\\040_Constraints.sql",
"2021.2\\050_Indexes.sql",
"2021.2\\060_Functions.sql",
"2021.2\\065_Table_valued_functions.sql",
"2021.2\\070_Views.sql",
"2021.2\\072_History_Functions.sql",
"2021.2\\074_History_Views.sql",
"2021.2\\080_Procedures.sql",
"2021.2\\081_Data_Procedures.sql",
"2021.2\\090_Instead_of_triggers.sql",
"2021.2\\100_Triggers.sql",
"2021.2\\110_Tasks.sql",
"2021.2\\120_Defaults.sql",
"2021.2\\130_Layouts.sql",
"2021.2\\140_Contexts.sql",
"2021.2\\145_Badges.sql",
"2021.2\\150_Processes.sql",
"2021.2\\999_Manual.sql"
]
},
{
"version": "2021.2",
"upgradesTo": "2021.3",
"files": [
"2021.3\\020_Upgrade.sql",
"2021.3\\030_Checks.sql",
"2021.3\\040_Constraints.sql",
"2021.3\\050_Indexes.sql",
"2021.3\\060_Functions.sql",
"2021.3\\065_Table_valued_functions.sql",
"2021.3\\070_Views.sql",
"2021.3\\072_History_Functions.sql",
"2021.3\\074_History_Views.sql",
"2021.3\\080_Procedures.sql",
"2021.3\\081_Data_Procedures.sql",
"2021.3\\090_Instead_of_triggers.sql",
"2021.3\\100_Triggers.sql",
"2021.3\\110_Tasks.sql",
"2021.3\\120_Defaults.sql",
"2021.3\\130_Layouts.sql",
"2021.3\\140_Contexts.sql",
"2021.3\\145_Badges.sql",
"2021.3\\150_Processes.sql",
"2021.3\\999_Manual.sql"
]
}
]
},
{
"type": "Hotfix",
"path": "SF/Hotfixes"
}
]
}
]
}

Application

{
"schema": 2,
"defaultPath": "D:\\SoftwareFactory",
"products": [
{
"type": "Application",
"projectId": "MY_APP",
"version": "1.10",
"metaVersion": "2021.3",
"projectFolder": "D:\\SoftwareFactory\\DevApplications",
"dependencies": [
"CompatibilityLevel130"
],
"packages": [
{
"type": "Install",
"path": "MY_APP/Install",
"defaultDatabaseName": "MY_APP"
},
{
"type": "Upgrade",
"path": "MY_APP/Upgrade",
"supportedVersions": [
{
"version": "1.00",
"upgradesTo": "1.10",
"files": [
"1.10\\020_Upgrade.sql",
"1.10\\030_Checks.sql",
"1.10\\040_Constraints.sql",
"1.10\\050_Indexes.sql",
"1.10\\060_Functions.sql",
"1.10\\070_Views.sql",
"1.10\\080_Procedures.sql",
"1.10\\090_Instead_of_triggers.sql",
"1.10\\100_Triggers.sql",
"1.10\\110_Tasks.sql",
"1.10\\120_Defaults.sql",
"1.10\\130_Layouts.sql",
"1.10\\140_Contexts.sql",
"1.10\\145_Badges.sql",
"1.10\\150_Processes.sql",
"1.10\\999_Apply_roles_on_database.sql"
]
}
]
}
]
}
]
}

Creating a custom application package

This section aims to guide developers through the process of using the SF and IAM to generate their installation/upgrade files and then creating a manifest that the deployer CLI or GUI can use to deploy them.

This guide assumes that the developer is familiar with the development process of the SF, knows how to synchronize a model into an IAM and has an existing project to use for both.

note

Installation packages for the Software Factory, IAM, Universal/Windows/Web/Mobile GUI, and Indicium should mostly be downloaded through TCP.

Generating the deployment package

The deployment package for the Deployment Center can be generated from the Deployment package screen in the Software Factory using the Create deployment package task.

After using the task, the contents of the chosen directory should look similar to the one below.

Deployer task result Result contents

note

The task always generates an Upgrade directory even if the project version that was generated doesn't have a previous version. If that is the case just delete this directory.

The final step to complete the database packages is to include the files needed by the application.

Add a directory named Applicaties at the same level as Install, Upgrade and MetaModel. Then add a sub-directory with the same name as the project ID to the Applicaties directory and after that a sub-directory with the version number to the project ID directory. Copy any files that the application needs from the project folder to this application folder. This might include application icons, report files, etc.

note

In this guide's example the full path to this directory would then be "D:\deployer_example\Applicaties\TEST_SSRS\1.10".

Customizing the manifest

A manifest.json file, based on the following specification, is put in the same directory as the generated installation package.

The manifest will be using schema version 2.

{
"schema": 2
}

Next, the default location for the application files (like reports, images etc.) is set using the defaultPath property.

{
"schema": 2,
"defaultPath": "D:\\SoftwareFactory"
}

Which product types are in the manifest is declared with the products property. Base type Application is used, since this will be an installation package for a Software Factory application, which is neither the SF itself or IAM.

{
"schema": 2,
"products": [
{
"type": "Application"
}
]
}

Now that the deployer knows this product is an application it requires that the project's ID, version, project folder specification and meta version of the application. In this example these would be TEST_SSRS for the ID, 1.10 for the version, S:\Software_fabriek\Applicaties for the project folder and lastly 2019.1 as the meta version since it was generated by a 2019.1 IAM/SF installation.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.10",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties"
}
]
}

Optionally you can also declare some dependencies that the application requires to make the installation or upgrade succeed, for example the SQL Server 2012 CompatibilityLevel110 dependency. This would make sure that the deployer doesn't run the scripts on databases or database engines that don't support features added in SQL Server 2012.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.10",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel110"
]
}
]
}

Now that the basic application details have been defined, the types of packages that should be made available to the deployer are declared. In this guide's example these are the Install and Upgrade package types.

For the Install package only the type and path to the directory containing the generated installation scripts have to be declared. Optionally you can also include a default database name for your product to save some input time when using the deployer GUI.

note

For the path property, relative values are considered relative to the location of the manifest file. In the case of this guide this would be D:\deployer_example. This means Install/1.10 gets computed to D:\deployer_example\Install\1.10.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.10",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel110"
],
"packages": [
{
"type": "Install",
"path": "Install\\1.10",
"defaultDatabaseName": "TEST_SSRS"
}
]
}
]
}

Just like with the Install package, a type and path value for the Upgrade package are declared.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.10",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel110"
],
"packages": [
{
"type": "Install",
"path": "Install\\1.10",
"defaultDatabaseName": "TEST_SSRS"
},
{
"type": "Upgrade",
"path": "Upgrade\\1.10"
}
]
}
]
}

Next the upgrade path for databases that are currently at a previous version of the application are described. This is done using the supportedVersions property.

The deployer uses this property to determine which files are needed to perform the upgrade and in which order they should be executed. In this guide we generated files for our installation package to upgrade from version 1.00 to 1.10 so those are used as the values for version and upgradesTo properties respectively.

As a rule of thumb when adding the file paths, always follow the number ordering that the SF used when generating your files.

note

Once again these paths may be relative but instead of being relative to the location of the manifest file they're relative to the product's computed path value. This means that a computed product path value of D:\\deployer_example\\Upgrade and a file value of 1.10\\020_Upgrade.sql would become D:\\deployer_example\\Upgrade\\1.10\\020_Upgrade.sql.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.10",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel110"
],
"packages": [
{
"type": "Install",
"path": "Install\\1.10",
"defaultDatabaseName": "TEST_SSRS"
},
{
"type": "Upgrade",
"path": "Upgrade\\1.10",
"supportedVersions": [
{
"version": "1.00",
"upgradesTo": "1.10",
"files": [
"020_Upgrade.sql",
"030_Checks.sql",
"040_Constraints.sql",
"050_Indexes.sql",
"060_Functions.sql",
"070_Views.sql",
"080_Procedures.sql",
"090_Instead_of_triggers.sql",
"100_Triggers.sql",
"110_Tasks.sql",
"120_Defaults.sql",
"130_Layouts.sql",
"140_Contexts.sql",
"145_Badges.sql",
"150_Processes.sql",
"999_Apply_roles_on_database.sql"
]
}
]
}
]
}
]
}

It is recommended to put all the upgrade scripts in a project version folder so upgrades from multiple versions are supported in one deloyer package.

{
"schema": 2,
"products": [
{
"type": "Application",
"projectId": "TEST_SSRS",
"version": "1.20",
"metaVersion": "2019.1",
"projectFolder": "S:\\Software_fabriek\\Applicaties",
"dependencies": [
"CompatibilityLevel110"
],
"packages": [
{
"type": "Install",
"path": "Install\\1.20",
"defaultDatabaseName": "TEST_SSRS"
},
{
"type": "Upgrade",
"path": "Upgrade",
"supportedVersions": [
{
"version": "1.00",
"upgradesTo": "1.10",
"files": [
"1.10\\020_Upgrade.sql",
"1.10\\030_Checks.sql",
"1.10\\040_Constraints.sql",
"1.10\\050_Indexes.sql",
"1.10\\060_Functions.sql",
"1.10\\070_Views.sql",
"1.10\\080_Procedures.sql",
"1.10\\090_Instead_of_triggers.sql",
"1.10\\100_Triggers.sql",
"1.10\\110_Tasks.sql",
"1.10\\120_Defaults.sql",
"1.10\\130_Layouts.sql",
"1.10\\140_Contexts.sql",
"1.10\\145_Badges.sql",
"1.10\\150_Processes.sql",
"1.10\\999_Apply_roles_on_database.sql"
]
},
{
"version": "1.10",
"upgradesTo": "1.20",
"files": [
"1.20\\020_Upgrade.sql",
"1.20\\030_Checks.sql",
"1.20\\040_Constraints.sql",
"1.20\\050_Indexes.sql",
"1.20\\060_Functions.sql",
"1.20\\070_Views.sql",
"1.20\\080_Procedures.sql",
"1.20\\090_Instead_of_triggers.sql",
"1.20\\100_Triggers.sql",
"1.20\\110_Tasks.sql",
"1.20\\120_Defaults.sql",
"1.20\\130_Layouts.sql",
"1.20\\140_Contexts.sql",
"1.20\\145_Badges.sql",
"1.20\\150_Processes.sql",
"1.20\\999_Apply_roles_on_database.sql"
]
}
]
}
]
}
]
}

Using the example manifest above, when the deployer encounters a version 1.00 database it'll first upgrade the database to 1.10 and then, since the database is now at version 1.10, it can upgrade to 1.20.

note

To avoid deployment failures please make sure the upgrade path always ends at a supported version whose upgradesTo value is equal to the product's declared version.

Customizing the application model import (Advanced)

note

Customizing an application's model import script requires knowledge about IAM's application model and SQL.

When in doubt please contact your Thinkwise consultant before running queries against an IAM model.

The basic options to customize the import model script inside the package creation task provide a way to import said model in a similar way to SF and IAM installations. This is a decent default for most applications but you might want to be able to differ slightly from certain options.

For example, instead of removing all other project versions using the Remove other project versions option, you might also want to keep the most recent version and set it to inactive instead.

To make this customization work we first need to create a query that removes all other project versions except the current and directly previous ones. In this case we can use the query that the Remove other project versions generates as a starting example.

note

The following example uses the same project that was used during the rest of the guide. It also assumes that the final installation package was created while the mentioned task options were left unchecked.

/****************************************************
* Remove old project version
****************************************************/

declare @d_project_vrs_id project_vrs_id
declare c_project_vrs cursor local fast_forward read_only for
select project_vrs_id
from project_vrs
where project_id = 'TEST_SSRS'
and project_vrs_id <> '1.10'

open c_project_vr
fetch next from c_project_vrs
into @d_project_vrs_id

while (@@fetch_status <> -1)
begin
if (@@fetch_status = 0)
begin
exec task_delete_project_vrs
@project_id = 'TEST_SSRS',
@project_vrs_id = @d_project_vrs_id
end
fetch next from c_project_vrs
into @d_project_vrs_id
end
close c_project_vrs
deallocate c_project_vrs

As shown, the query creates a cursor for records inside the project_vrs table that match our application's project_id ('TEST_SSRS') and the latest project_vrs_id ('1.10'). For each of the records that were found it then calls the task_delete_project_vrs stored procedure (which is part of the IAM application model) to delete the project versions from IAM.

To get the desired result we can modify the cursor's select statement to also exclude the project's previous version:

    declare @d_project_vrs_id project_vrs_id
declare c_project_vrs cursor local fast_forward read_only
for
select project_vrs_id
from project_vrs
where project_id = 'TEST_SSRS'
and project_vrs_id <> '1.10'
and project_vrs_id <> '1.00'

-- Rest omitted

Or alternatively if you can ensure that application versions are always imported chronologically:

    declare @d_project_vrs_id project_vrs_id
declare c_project_vrs cursor local fast_forward read_only
for
select project_vrs_id
from project_vrs
where project_id = 'TEST_SSRS'
and project_vrs_id not in (select top 2 project_vrs_id
-- top 2 instead of 1 since the first of those is the current version that was just imported.
from project_vrs
where project_id = 'TEST_SSRS'
order by insert_date_time)

-- Rest omitted

Now that the previous/most recent version is no longer deleted it just has to be set to inactive. Once again we can use one of the default option scripts, Activate application, as a base example.

/****************************************************
* Activate application
****************************************************/

update gui_appl
set active = 1
where project_id = 'TEST_SSRS'
and project_vrs_id = '1.10'
and gui_appl_id = @gui_appl_id

As shown this simply updates the active column inside the gui_appl table for the imported project version and sets it to 1 (true). So to set the previous version to inactive we need to update the value of this column to 0 (false).

What you may have noticed is that this script uses a variable, @gui_appl_id, to search for a specific application id to activate. This variable is filled in another part of the generated import script which, as explained later, we don't have access to.

However if our goal is to simply deactivate the remaining applications for the project we don't really need to know the gui_appl_id of those. Instead we could simply invert the project_vrs_id condition to target all applications that do not belong to the version that was just imported:

/****************************************************
* Deactivate applications
****************************************************/

update gui_appl
set active = 0
where project_id = 'TEST_SSRS'
and project_vrs_id <> '1.10'

Now that we have the SQL statements for our scripts they need to be added to the installation package. Navigate to the directory where you put the generated installation package and look for the MetaModel directory. In here you should see a sql file similar to the one below.

Meta Model

note

This is the generated application model import script WHICH YOU SHOULD NOT MODIFY.

Create another sql file and give it a name that results in it getting sorted later alphabetically than the generated file. This ensures that the deployer will execute the generated script before our custom one. In this example the name Import_TEST_SSRS_model_2.sql is used.

Meta Model

Next put the customized scripts into the file which, for this example, would be the following:

/****************************************************
* Remove project versions
****************************************************/

declare @d_project_vrs_id project_vrs_id
declare c_project_vrs cursor local fast_forward read_only
for
select project_vrs_id
from project_vrs
where project_id = 'TEST_SSRS'
and project_vrs_id <> '1.10'
and project_vrs_id <> '1.00'
-- Or the one based on insert_date_time depending on which you prefer.

open c_project_vrs
fetch next from c_project_vrs
into @d_project_vrs_id

while (@@fetch_status <> -1)
begin
if (@@fetch_status = 0)
begin

EXEC task_delete_project_vrs
@project_id = 'TEST_SSRS',
@project_vrs_id = @d_project_vrs_id

end
fetch next from c_project_vrs
into @d_project_vrs_id

end
close c_project_vrs
deallocate c_project_vrs
go

/****************************************************
* Deactivate applications
****************************************************/

update gui_appl
set active = 0
where project_id = 'TEST_SSRS'
and project_vrs_id <> '1.10'

Then save it using Western Windows-1252 encoding and you'll be done.

caution

Windows-1252 is used by the SF and IAM as the encoding for generated scripts.
Due to this the deployer also assumes this encoding is used when reading the scripts.

Please do not use UTF-8 or similar encodings when saving/editing the customized scripts to avoid unexpected errors when deploying your application.