How Smart Materials determines the Keystore - Intergraph Smart Materials - Version 2020 (10.0) - Installation & Upgrade - Hexagon

Intergraph Smart Materials Installation (2020)

Language
English
Product
Intergraph Smart Materials
Subproduct
Classic
Search by Category
Installation & Upgrade
Smart Materials/Smart Reference Data Version
2020 (10.0)

In the cloud, the license admin can create a list of client configurations, using the Licensing Portal (web page). Each client configuration holds information which licenses can be used by an ISL client.

Basically, a client config is a list of ISL projects. An ISL project is a means of grouping and ordering keystores. Each project points to an ordered list of keystores. Think of an ISL project as a set of keystores or keystore-group specific to a client configuration.

One project can be defined as the default/fallback in a client config. Smart Materials makes heavy use of it because the project names in Smart Materials normally will not match the names of projects in Smart Licensing. Thus, it will fall back to the default. If there is no fallback project defined, the license request fails.

A client configuration is made available to the client by loading the reference to it (cci-file) into an ISL client. The license webservice talks to the ISL client to get a seat of a specific license tag. ISL knows where to get a configuration based on the loaded connection file. The file defines the location of the configuration server and the ID of the configuration to use. ISL knows where to get licenses based on the license admin’s configuration of project and keystores in the client configuration.

The contents of the client configuration can be changed in the cloud (projects/keystores) Changes in the config are automatically downloaded to the ISL client (regular interval or refresh). As long as the ISL client works with the same config, he does not need to load a new cci-file.

There are three types of attaching a cci-file to an ISL client. First is to load a cci file to be valid for the whole machine. The second type is to load a cci file for the currently logged in OS user. This way you can have different cci-files for different Windows users. This might be interesting for client/server architecture, but it is not used for Smart Materials and Smart Reference Data because the license service will run with the same OS user. The third way is to load a client config for a Smart Materials/Smart Reference Data user. This way you can have different cci-files for different application users. This can be helpful for customer hosted licensing scenario. By creating different client configs for different application users, they can be directed to different keystores. Each license request will submit the application user name, so the correct client config can be picked up. If the provided application user has no specific cci file loaded in the ISL client, it will use the system-wide cci file.

The next level of control is determining the ISL project. As already mentioned, an ISL project is a pointer to an ordered list of keystores. A client config contains one or more ISL projects.

Each license request will automatically submit the actual logged in Smart Materials/Smart Reference Data project/product group. To support customer hosted licensing scenarios, the ISL project name can be submitted instead (similar as it was possible to determine the SPLM Servers in previous versions). This is done in A.60.81 / A.20.05. If this option is used, those entered values will be sent as project name to ISL client instead of the Smart Materials project (proj_id). To make customer hosted licensing work with this option, this requires that an ISL project with the same name exists in the loaded client config (case sensitive).

For more information see Configure ISL Client and Define SBCS Settings.

The internal workflow is as following:

Each call to ISL to get a license seat will transmit the currently connected Smart Materials user and the ISL project name.

To determine the project name to transmit, the software will check if a project name is specified in Keystores field on A.20.05 (equal to User Keystores field in A.60.81). The value found is sent to ISL as project name. If the field is empty, it will look for the Keystores field in A.60.81. The value found is sent to ISL as project name. You can use this fact to determine the keystore by creating a project in the client config with a name that matches those values.

If the Keystores field in A.60.81 is empty as well, software sends the SMat project/product group name (proj_id) to ISL.

When the get-license request arrives at the ISL client, the client will read the transmitted Smart Materials user name, and it will check if ISL client has a user specific cci-file loaded for the same user name. If not, it will refer to the device-level cci-file.

You can use this fact to determine the keystore by loading a specific cci-file for one or more Smart Materials users.

After the cci-file was selected, the ISL client will look if it finds a project in the related client config, which matches the project name (transmitted with the request). If yes, it will use this project to determine the keystore. If no matching project was found, it will check if there is a project in the client config marked as 'fallback'. If yes it will go with this trying to get a seat. If not, it will reject the request.

It is possible to add "Custom fields" and corresponding "Custom values" to a project in ISL Portal. These fields and values are visible and selectable in the ISL Client. But our products do not use this information. These values do not change the behavior of our product. Our products are also not able to edit these "Custom values" by environment variables.