Working with standard configuration files (.TCCSetup)
- Introduction
- Loading the configuration files: the automatic configuration refresh process
- Enabling/disabling the automatic configuration refresh process
- Upgrade process for "old" applications using the new "Load TCC configuration files automatically" feature
Introduction
The CAST Transaction Configuration Center implements an automatic "configuration loading mechanism" based on the standard .TCCSetup files present in the CAST AIP installation folder and any installed extensions folders. TCCSetup files (standard configuration files) contain configuration parameters to automatically define Entry Points, Data Entities, End points and Excluded Items and are known as Packages.
Before computing Function Points (either in the CAST Transaction Configuration Center using the Compute option or during snapshot computation), the setup of the Application(s) will be refreshed with the content of the .TCCSetup configuration files which are present in the following locations on disk:
- <CAST AIP installation folder>\configuration\TCC
- %PROGRAMDATA%\CAST\CAST\Extensions\<extension folder>\configuration\TCC
For the loading process, we will consider all files that match the following requirements:
- Must have *.TCCSetup extension
- Must be located in <CAST AIP installation folder>\configuration\TCC
- If there are extensions installed, we will also consider the files present under %PROGRAMDATA%\CAST\CAST\Extensions\<extension folder>\configuration\TCC
After loading the configuration files, the new setup will be automatically saved.
- If an extension has been downloaded but not installed in the current triplet of schemas, its folder will be ignored (i.e. even though the %PROGRAMDATA%\CAST\CAST\Extensions\<extension folder>\configuration\TCC folder exists, it will not be taken into account).
- As core language configuration files are now located in <CAST AIP installation folder>\configuration\TCC, and every extension includes its related configuration files, the <CAST AIP installation folder>\samples\TCC directory that contained preconfigured templates files in previous releases of CAST AIP no longer exists.
Loading the configuration files: the automatic configuration refresh process
Each one of the standard configuration files (.TCCSetup) defines a package and a version attribute. This package-version pair will be used to detect when a new package version has been released, and therefore the refresh configuration process must be triggered.
The refresh configuration process will take place in two different scenarios:
- Before Function Points computation (either in the CAST Transaction Configuration Center using the Compute option or during snapshot computation)
- When we (re)connect to a specific host database in the CAST Transaction Configuration Center
During this process, we will compare the existing package-version information stored in the Management Service schema for the current Application, with the existing package-version in the files that are present at that moment in the configuration\TCC folders in the CAST AIP installation and installed extensions folders, with three possible scenarios for each package:
- If the package-version in the Management Service schema matches the package-version in the configuration file: nothing to do (package already up-to-date).
- If the package-version in the Management Service schema is different from package-version in the configuration file (upgrade/downgrade): the package will be refreshed by loading the file content, keeping the inactive status for those configuration rules of that package that had been deactivated by the user, see details below. NOTE: hereafter when we talk about a "new version", we mean "a different version number", not necessarily higher.
- If there is a new package in the configuration files which is "not known" in the the Management Service schema: the package will be loaded, and the new rules will be added with status active by default.
The scenario 2 (package upgrade/downgrade) will work as follows:
- Only the rules of the package to be updated will be impacted (custom rules and other packages' rules will remain intact).
- The upgrade process (for CAST AIp and for extensions) will remove from the application setup all the existing rules of the impacted package, and then will load the new rules from the new configuration file version.
- Each rule will be loaded with status active by default, except if the rule was present in the previous version, its definition is unchanged, and it had been manually deactivated by the user, in that case, the rule will be set to inactive as well.
Note that from CAST AIP 8.3.23, this behaviour changes as follows:
Each rule which was present in the previous version will be loaded with the same status as before, whichever the definition of this rule is the same or has changed. In this latter case, a warning will be logged to inform the user of this change, as in the example below where both the definition of an active Entry Point rule and of a deactivated End Point rule have both changed in a new version of the 'Base_HTML5' package:
WRN: -the rule "Standard Entry Point - HTML5 AspDotNet" (type='Transaction entry points') will remain active because although its definition has changed, it has the same name and type as the previously active rule "Standard Entry Point - HTML5 AspDotNet" (type='Transaction entry points'). WRN: -the rule "Standard End Point - HTML5" (type='Transaction end points') will remain deactivated because although its definition has changed, it has the same name and type as the previously deactivated rule "Standard End Point - HTML5 (type='Transaction end points').
Special considerations:
- If a certain package has been delivered via the CAST AIP installation folder and also via an extension, then the version to be considered will be always the one from the extension; i.e. the package-version delivered via an installed extension will take priority over the package-version delivered via the CAST AIP installation.
- It is not possible to have two rules with the same name in the same .TCCSetup file (i.e. in the same package). If this happens, only the first one will be loaded.
- Where an "inter-package" name collision occurs while loading a new rule (i.e. there is already a rule of the same type coming from another package or from a user definition), the new rule will be automatically renamed following CAST Transaction Configuration Center standards (i.e. by adding the suffix "(2)", "(3)", "(4)", etc.).
Please note that this refresh process involves just configuration rules/sets (i.e. associations in the TCCSetup files), the other elements in these files (i.e. prefixes and ignored tables) are out of the scope and will be ignored during this process.
Enabling/disabling the automatic configuration refresh process
To enable or disable the automatic configuration refresh process, an option exists in the computation settings dialog (see Compute) which can be accessed as follows:
- via the Calibrate > Computation Settings located on the menu bar (global to all Applications):
- via the right click menu on an Application node, specific to the Application:
By default, this setting will be enabled (YES), meaning that any new configuration package or any new version of an existing configuration package will be automatically installed into the application configuration.
However, if we decide to "freeze" the application configuration and disable the automatic configuration refresh, we can set this setting to NO. If the automatic refresh is disabled, only new packages will be installed, but the existing packages will remain in the current version, i.e. even if a new version is available, the package will not be updated.
The following table explains the different scenarios:
- | Automatic Configuration Refresh YES (default) | Automatic Configuration Refresh NO |
New version of existing package | update action | no action |
New package | update action | update action |
Upgrade process for "old" applications using the "Load TCC configuration files automatically" feature
When an "old" Application runs the new refresh configuration process for the very first time (for example following an upgrade of CAST AIP to 8.3.x or above):
- Firstly, new attributes will be added to its existing configuration rules: activation = active; package = custom; updated = false
- Then, new standard rules that will be added via the standard TCCSetup configuration files, will be added with activation = inactive (to avoid changes in the Function Point computation of the application after the upgrade)
- This behavior differs from the new applications which were created CAST AIP to 8.3.x or above. When a "new" application runs the new refresh configuration process for the very first time:
- New standard rules that will be added via standard TCCSetup configuration files, will be added with activation = active