New release to correct an issue with the use of mapped drives in the CastGlobalSettings.ini file on an AIP Node.
New release to correct an issue with the synchronization of authorizations between AIP Console and integrated dashboard when LDAP security mode is enabled.
New release to correct an issue with storage path syntax in the aip-node-app.properties file preventing the AIP Node from functioning correctly.
|Assessment Model||List of Health Factors, Technical Criteria and Quality Rules available at application level providing the ability to search the rules, modify the weight, enable/disable specific rules etc.|
|Architecture Checker Studio|
Architecture Studio is a new and dedicated environment in AIP Console where users can manage Architecture Models. Standard Templates and predefined sets and layers are there to help user to design models. It is accessible via the Admin Menu.
|Architecture Models at application level|
At application level, only models attached to applications are visible. User can only attach valid models created and managed in Architecture Checker Studio. User can also detach, check and download the attached models.
|Split delivery folder per application||Delivery folder is automatically split per application, DMT plugins lifecycle is restricted to a specific application|
|Setup wizard in UI||A setup wizard in UI allows user to configure the license, first admin user, extend settings when launching Console the first time after fresh installation, the installer has been simplified, the bootstrap mode of console is removed.|
|Measurement backup can now be actioned in the Admin Center.|
|Settings improvement in admin space||Extend settings and measurement settings in admin space|
|Integrated dashboards updated to 1.13.1||-|
|Duplicated Analysis unit for JEE source code containing eclipse and maven files|
OR-Combination block for ( Architecture Checker - TCC Rules ) Free definition editor can not be used for now.
|Limitation on Microsoft Edge : When trying to upload models / templates - List of Files types displayed in Windows File Explorer are not filtered on .castArchitect Extension.|
Download attached models from Application/Configuration/Architecture is not working if the file is not located on AIP Console-Node level.
These Models were attached in AIP -CASTMS.
They will still be computed if the models file are accessible (on the same host than Application's Node host).
However It is recommended to upload them in Architecture Studio and reattach them again to the application.
To create a new rule in TCC the user should add properties ( view properties ) when an empty Editor gets open. While before the properties such as name and activation was to be set before entering into editor.
When checking a model out of the editor against an application, which has not been analyzed, a message inform the user !This operation requires the 'TEST' application to have analysis results. while under editor the check against the same application won't display the message to inform the user.
When upgrading to 1.13.x from a previous release of AIP Console, you should take note of the following information:
Delivery folder split
In AIP Console 1.13.x the Delivery folder (located on each AIP Node) will be split so that each Application has its own dedicated Delivery folder (previously, the Delivery folder was global to all Applications). This process is actioned automatically during an upgrade to 1.13.x as described below.
Why will this split occur?
- To allow each Application to have dedicated (DMT) plugins and to therefore avoid a "collision" of plugins across the Applications.
- Possibility to have multiple versions of plugins running on different Applications
- Easier to backup and restore the Delivery folder for one Application
New delivery folder structure
The Delivery folder location will become the parent of all the "application delivery folders". By default the Delivery folder is located at AipNode\data\delivery on each AIP Node (this default location has not changed) and the following structure will now be used:
|Before upgrade||Post upgrade - each folder corresponds to an Application|
Inside each Application specific subfolder, you will find the exact same folder structure as used in Delivery folder before upgrade:
When is the split actioned?
The Delivery folder split will be actioned during an upgrade to AIP Console 1.13.x:
- When the installer detects that the delivery folder is in the "old" structure, the split tool will be launched automatically:
Click to enlarge
- The installation continues after the split tool has successfully executed, otherwise there will be a popup error
- After installation of 1.13.x, in the original location, you will have the same delivery folder with the new structure and a backup of the original one:
- Existing Applications will continue to work in AIP Console as before.
Situations that require manual migration before installing AIP Console
You will need to manually execute the split tool before installation of the new release of AIP Console in the following situations:
- Where you have multiple AIP Nodes with multiple CAST Storage Servers/PostgreSQL instances, but only one shared Delivery folder
- Where you are using a mapped drive for your Delivery folder such as R:\
The manual migration process is as follows:
The split tool can be found in <AIPNode>/bin/dmt-migration-tool. Configure the config.json file with the correct settings: if you have multiple multiple CAST Storage Servers/PostgreSQL instances, you need to enter each one into this file (as shown below). Run the migration.bat file to complete the split. Then proceed with the upgrade.
Reorganization of Architecture Model files
This documentation applies to AIP Console users who are currently using a version < 1.13.x, have used Architecture Checker features, and have upgraded their version of AIP Console to 1.13.x or 1.14.x.
Below is described how folders containing Architecture files (models, templates, and library sets/layers) are organized before/after upgrade of AIP Console to 1.13.x, and what are the actions that will be automatically performed by the "upgrade process" during switch from the old to the new organisation of these folders.
Organization of Architecture models, templates, library sets/layers in versions ≤ 1.12.x
All AIP Console Architecture Checker related files are located only on AIP Nodes, and files of a given Node are only visible to the end-user in the context of the Applications that are hosted by that Node. Below are, per AIP Node, the folders for the various files according to their type:
- models: AipNode\data\upload\AC\models
- templates (user-defined): AipNode\data\upload\AC\templates
- library sets and layers (product/standard and user-defined): AipNode\data\upload\AC\libraries
- Product/standard templates are read from the folder "configuration\ACTemplate" in the installation directory of the version of AIP used by AIP Console
- in addition, there are two folders "AipNode\data\upload\architecture_models" and "AipConsole\data\upload\architecture_models", but they have never been used so should just be ignored.
- two folders will be created on the fly when AIP Console Architecture Checker features will be used for the first time: one for models, and one for templates. Hence this is normal that these folders don't exist just after having installed the whole AIP Console or else just a new AIP Node.
Organization of Architecture models, templates, library sets/layers in versions ≥ 1.13.x
As of AIP Console 1.13 with the introduction of the Architecture Studio, the AIP Console Architecture Checker related files become distributed in folders hosted by:
- the 1 to many AIP Nodes where Architecture files used to exist before
- the (unique) AIP Console where Architecture models, templates, and library sets/layers are now centralized
A model that used to exist on a AIP Node in version <= 1.12 will stay there, initially in the same folder as before (namely AipNode\data\upload\AC\models), because still the full file path of the model remains stored in the CAST-MS configuration of the Application(s) to which this model has been attached thus this path should not change. Note: as of AIP Console 1.13, models that will become attached to Application(s) will be in folder AipNode\data\drive_upload\architecture\models, instead of in AipNode\data\upload\AC\models.
Below are, on the AIP Console, the folders for the various files according to their type:
- models: AipConsole\data\upload\architecture\models
- user-defined templates: AipConsole\data\upload\architecture\templates
- user-defined library sets and layers: AipConsole\data\upload\architecture\libraries
- standard templates: AipConsole\data\standard\architecture\templates
- standard library sets and layers: AipConsole\data\standard\architecture\libraries
Why and when of the migration process
Since all Architecture models, templates, and library sets/layers are now centralized on the AIP Console instead of being spread across AIP Nodes, it is necessary to also bring in all the corresponding files from the Node(s) which used to host them up until now. The Architecture Models and user-defined templates whose transfer was successful will then be presented on the Architecture Studio main page, whereas the user-defined library sets/layers whose transfer was successful will be presented in a drop-down list in the models/templates editor.
The movement of Architecture files will not happen during the upgrade of the AIP Console version by the Installer tool, but rather each time an AIP Node will become available (i.e. accessible and enabled) when:
- the whole AIP Console application is (re-)started, whether the two .bat files are launched, or the two Windows Services are (re-)started: in this case, all available AIP Nodes will have their Architecture files migrated during the initialization steps (those executed before a user can connect)
- an AIP node that was accessible but disabled becomes enabled again, typically following the below user action in the Administration Center - Nodes page:
Neither Architecture standard/product templates nor standard/product library sets/layers files are affected by this move of files, because even though their folders will also have their paths changed, new versions of these files will be installed in new folders (both located under AipConsole\data\standard\architecture) on the AIP Console during execution of the Installer tool.
Situations and corresponding migration messages (levels = DEBUG, INFO, WARN, ERROR)
All messages related to the Architecture files migration are sequentially logged into AipConsole\data\logs\webi.log, and unless the user observes that the expected models, etc. are not visible in the Architecture Studio main page, there is no need at all to inspect this file. If this file needs to be inspected, all messages related to Architecture files migration will be between these two lines:
If no message is visible at all, it means that no migration was necessary: either the AIP Node did not host any Architecture Checker file, or else they have all been already migrated.
Once AIP Console has started, or a formerly disabled AIP Node has become enabled again, it is necessary to wait around 30 seconds to be absolutely certain sure that synchronization of the AIP Node will have occurred since the migration of Architecture files which is a part of it. Otherwise, launching AIP Console services, logging in, and then rushing to the Architecture Studio home page will almost certainly display none of the models and templates expected to have been migrated.
The migration process is the same whichever type of Architecture file is being migrated, and every message will indicate the file type for clarity. Below are the situations and the corresponding messages and severity levels, taking the example of an Architecture model file:
- The model is migrated for the first time and no file with the same filename already exists:
- In the Architecture Studio, there already exists a model whose filename is 'MyModel.CASTArchitect', whether this file exists because it was created from scratch by the user or else results from a previous migration:
If the model has, on its AIP Node, exactly the same content (binary comparison) as the file existing on AIP Console, then nothing will happen because it serves no purpose to migrate that file:
Otherwise (i.e. content found on the AIP Node is different), then the formerly existing AIP Console file is left untouched and the migrated file will have its base part suffixed, between parentheses, by the name of the AIP Node from which it comes from (characters '\', '/', ':', '*', '?', '"', '<', '>', '|' disallowed in Windows filenames being replaced by underscores as is the case in the example warning below):
The model file doesn't exist any longer on its AIP Node, or its folder cannot be accessed, or the AIP Node suddenly became unavailable (for e.g. because of a power shutdown):
After all Architecture files found on the AIP Node currently of interest will have been processed, one line per type of file will be logged regarding migration success or failure. Below is an example showing the only two sorts of messages that can occur:
INFO - All 5 Architecture custom_template files could be migrated from AIP Node 'local node' at http://localhost:8082.
WARN - Only 4 of 6 Architecture model files could be migrated from AIP Node 'local node' at http://localhost:8082.
WARN - Only 0 of 3 Architecture custom_layer files could be migrated from AIP Node 'local node' at http://localhost:8082.
The migration process has been designed so that any AIP Node knows which of its Architecture files haven't yet been migrated. If the migration process is abruptly interrupted, then files that couldn't yet be migrated will be attempted to be processed again once their AIP Node will have been restarted or has become available again. However, in no case any Architecture model file that hasn't successfully been migrated will be deleted on the file system of its AIP Node whether it is, in the case of models, attached to any Application, or to none.
If some Architecture files have definitively become unavailable for migration (because for example they have been deleted on the file system of their AIP Node), warnings will endlessly be logged in the migration report, each time the migration process will be re-executed, until this process will have disappeared from AIP Console.
Architecture Models with identical IDs
As part of the upgrade process, Architecture Model files will be automatically moved from storage on AIP Nodes to storage on the AIP Console (see note above). Since it is possible for Architecture Models on different AIP Nodes to use identical Metric IDs, after the upgrade and when one of the Architecture Model is subsequently edited in AIP Console a warning message will be displayed when model is saved as shown below. The Metric ID field will be editable so that a new metric ID can be assigned to the model. The model cannot be saved until the duplicate metric ID issue is resolved.
How to report issues and feedback
Please report and issue or feedback to the product manager, Damien Charlemagne (firstname.lastname@example.org).