Inside
License deployment model
Two types of references can be used:
|
References
|
Extract of Megasite.ini (example)
|
Comment
|
|
Direct reference
|
[Must licence]
Path=\\server001\Apps\Licenses
|
The Must license folder (\\server001\Apps\Licenses) is configured in the file Megasite.ini of the HOPEX Installation
|
|
Cluster reference
|
[Lan]
ClusterRoot=\\mega\data\config
|
The file Megasite.ini of the HOPEX installation refers to a shared configuration folder (\\mega\data\config) containing another file Megasite.ini. This file contains a direct reference to the Must license folder (\\server001\Apps\Licenses).
This type of reference must be used for Citrix/TSE deployment
|
When HOPEX is run by user U0001:
1. A configuration file (megasite.ini) is read to identify the license folder.
2. The license folder can be referenced directly (local configuration) or indirectly (shared configuration).
3. The license folder is read to identify the authorized license file for this user.
4. The Must license configuration is read to identify the products authorized for this user.
5. Connection is made if tokens are available for the authorized products.
License execution
License execution is homogenous through Front-Ends or Windows Administration Console.
Windows Front-End
Context | Must license checked | Storage product checked (1) | Tokens requested | Command line considered |
HOPEX.exe | Yes | Yes (2) | One token per Product One token LAN | Yes |
Administration.exe | Yes | Yes (2) | One token LAN One token SUP | No |
HOPEX.exe with HOPEX Power Studio (MTS2) | Yes | Yes (2) | One token LAN One token MTS2 | Yes |
API component (3) | Yes | Yes (2) | One token per Product One token LAN | Yes |
(1) RSQ or RSO
(2) Unless GBMS storage is used.
(3) Administration component creating a running instance of HOPEX (mgwmapp.exe)
Web Front-End
Context | Must license checked | Storage product checked (1) | Web Front-end product (2) | Tokens requested | Command line considered |
HOPEX Product (multi front-end) | Yes | Yes | No | One token per Product One token LAN | Yes |
HOPEX Product (controlled multi front-end) | Yes | Yes | Yes | One token per Product One token LAN | Yes |
HOPEX Solution | Yes | Yes | No | One token per Solution One token LAN | Yes |
HOPEX Explorer portal | Yes | Yes | No | One token HEXP | No |
SSP component | Yes | No | No | No token (3) | - |
(1) RSQ or RSO
(2) ANW
(3) When running the SSP component, must license is checked but no token is requested. SSP is used systematically with HOPEX Web Front-End. It can also be used by Windows Front-End.
File access
File access in the license folder should be similar to that of accessing a HOPEX repository data file. Contact MEGA Support if you encounter problems.
Connection process
The connection process proceeds as follows:
• The system determines the appropriate license file for user U0001.
• The system determines the command line set for U0001 (list of token requests).
• For each product token requested in the command line that can login to this Front-end:
o The system determines if U0001 can be a possible user, given the number of possible users available:
If 'Yes', U0001 becomes a possible user and the connection process can continue.
If 'No', U0001 cannot become a possible user. The connection process will stop with a warning.
o The system determines if U0001 can log in, given the number of tokens available:
If 'Yes', U0001 logs in.
If 'No', U0001 cannot log in. However, U0001 is still set as a possible user.
• If no command line is set, one token is request for each product of the license that can login to this Front-end.
When working with the Must license, it is important to distinguish between the following notions of users:
• User connected to a product (token): a login set as a possible user is currently connected to the HOPEX using a Must license.
o Example: user U0001 is connected to the HOPEX Logical Data product with the Must license located on \\Srv002\License\HOPEX\License-001.must.
• Possible user of a product: a login was set as a possible user (candidate) of a product for a license file. This configuration is mandatory for dedicated licenses and is generally recommended. This does not mean that a token is always available for this product.
o Example: users U0001, U0002 and U0003 are possible users for the HOPEX Logical Data product with the Must license located on \\Srv002\License \HOPEX\License-001.must.
• User assigned to a license: a login is explicitly assigned to a specific license file. This configuration is recommended. If several license files are used, this configuration is mandatory to decide which license is used by the user. A user can only be assigned to one license at most.
o Example: user U0001 of is configured to use the Must license located on \\Srv002\License\HOPEX\License-001.must.
Token distribution
The Must network license offers concurrent access to different HOPEX products. Its behavior varies with several elements:
• How (dedicated or shared) products are programmed.
• If/how possible users are configured.
• How many license files exist.
• If a command line (/RW, /RO) is specified for users.
Several scenarios based on are described below for comprehension.
In these scenarios, the changes regarding product HOPEX User (LAN), Repository Storage (SQL Server) (RSQ) or Repository Storage (Oracle) (RSO) are not detailed.
Use case1: shared network licenses without configuration
Typical example: all products are configured as shared, possible users are not configured beforehand, 1 license file, command line is empty for users. Possible users of the tokens are not identified beforehand for products.
License-001.must definition:
• HOPEX IT Architecture (ARC): 3 tokens for 4 possible users (not configured)
• HOPEX Risk Mapper (ERML): 2 tokens for 5 possible users (not configured)
• HOPEX Logical Data (DMO): 1 token for 2 possible users (not configured)
• HOPEX User (LAN): 6 tokens for 12 possible users (U0001, U0002… U0012).
• Repository Storage (SQL Server) (RSQ): enabled
Notes:
• Explicit configuration of possible users is not mandatory but recommended. Otherwise, the system will set this information itself: the first user requesting a token for a product becomes a possible user for the product.
• Users are only able to log on to the requested products if tokens are available for these products.
Scenario:
• User U0045 tries to log in. As the command line is empty, a token is requested for each product of the license. U0045 becomes a possible user for ARC, ERML and DMO. As tokens are available, U0045 can log in to ARC, ERML and DMO.
• User U0038 tries to log in. As the command line is empty, a token is requested for each product of the license. U0038 becomes a possible user for ARC, ERML and DMO. As no tokens are available for DMO, U0038 can login to ARC and ERML.
• User U0045 logs out. U0045 is still a possible user for ARC, ERML and DMO. 1 token is freed for each of the ARC, ERML and DMO products.
• User U0003 tries to log in. As the command line is empty, a token is requested for each product of the license. U0003 becomes a possible user for ARC and ERML but cannot be a possible user for DMO because U0045 and U0038 are 2 possible users. As tokens are available, U0003 can log in to ARC and ERML.
• User U0038 logs out and tries to log in again. As a token is now available for DMO, U0038 can now log in to ARC, ERML and DMO.
• User U0064 tries to log in. As the command line is empty, a token is requested for each product of the license. U0064 becomes a possible user for ARC and ERML but cannot be a possible user for DMO because U0045 and U0038 are 2 possible users. U0064 can log in to ARC and ERML.
Use case2: dedicated network licenses
Typical example: all products are configured as dedicated, possible users are not configured beforehand, 1 license file, command line is empty for users. All users of the tokens are identified for products.
License 002.must definition:
• HOPEX IT Architecture (ARC): 3 tokens for 3 possible users (U0001, U0002, U0003)
• HOPEX Logical Data (DMO): 2 tokens for 2 possible users (U0001, U0002)
• HOPEX Power Supervisor (SUP): 1 token for 1 possible user (U0001)
• HOPEX User (LAN): 6 tokens for 10 possible users (U0001, U0002… U0010).
• Repository Storage (SQL Server) (RSQ): enabled
Notes:
• Configuration of possible users is mandatory.
• Configured users are always able to log in to the requested products.
Scenario:
• User U0001 tries to log in. As the command line is empty, a token is requested for each product of the license. U0001 is configured as a possible user for ARC, PRO and SUP. As tokens are available for ARC, PRO and SUP, U0001 can log in to ARC, PRO and SUP.
• User U0002 tries to log in. As the command line is empty, a token is requested for each product of the license. U0002 is configured as a possible user for ARC and PRO. As tokens are available for ARC and PRO, U0002 can log in to ARC and PRO.
• User U0003 tries to log in. As the command line is empty, a token is requested for each product of the license. U0003 is configured as a possible user for ARC. As a token is available for ARC, U0003 can log in to ARC.
• User U0064 tries to log in. As the command line is empty, a token is requested for each product of the license. As no possible user seats are available, U0064 can be a possible user for ARC, PRO and SUP and cannot log in.
Use case3: shared network licenses
Typical example: all products are configured as shared, possible users are not configured beforehand, 1 license file, command line is empty for users. Possible users of the tokens are identified for products.
License 003.must definition:
• HOPEX IT Architecture (ARC): 3 tokens for 4 possible users (U0001, U0002, U0003, U0004)
• HOPEX Logical Data (DMO): 2 tokens for 5 possible users (U0001, U0002, U0003, U0004, U0005)
• HOPEX Power Supervisor (SUP): 1 token for 2 possible users (U0001, U0002)
• HOPEX User (LAN): 6 tokens for 12 possible users (U0001, U0002… U0012).
• Repository Storage (SQL Server) (RSQ): enabled
Notes:
• Configuration of possible users is not mandatory provided there is only one license file or a default licence is configured.
• Configured users are only able to log in to the requested products if tokens are available for these products.
Scenario:
• User U0001 tries to log in. As the command line is empty, a token is requested for each product of the license. U0001 is configured as a possible user for ARC, DMO and SUP. As tokens are available for ARC, DMO and SUP, U0001 can log in to ARC, DMO and SUP.
• User U0002 tries to log in. As the command line is empty, a token is requested for each product of the license. U0002 is configured as a possible user for ARC, DMO and SUP. As tokens are available for ARC and DMO, U0002 can log in to ARC and DMO.
• User U0003 tries to log in. As the command line is empty, a token is requested for each product of the license. U0003 is configured as a possible user for ARC and DMO. As a token is available for ARC, U0003 can log in to ARC.
• User U0004 tries to log in. As the command line is empty, a token is requested for each product of the license. U0004 is configured as a possible user for ARC and DMO. As no tokens are available for ARC or DMO, U0004 cannot log in.
• User U0005 tries to log in. As the command line is empty, a token is requested for each product of the license. U0005 is configured as a possible user for DMO. As no tokens are available for DMO, U0005 cannot log in.
• User U0006 tries to log in. As no possible user seats are available, U0006 cannot be a possible user for ARC, DMO and SUP and cannot log in.
Use case4: Windows Administration Console
Typical example:
License 004.must definition:
• HOPEX IT Architecture (ARC): 3 tokens for 4 possible users (U0001, U0002, U0003, U0004).
• HOPEX Logical Data (DMO): 2 tokens for 5 possible users (U0001, U0002, U0003, U0004, U0005).
• HOPEX Power Supervisor (SUP): 1 token for 2 possible users (U0001, U0002).
• HOPEX User (LAN): 6 tokens for 10 possible users (U0001, U0002…U0010).
• Repository Storage (SQL Server) (RSQ): enabled;
As recommended, a specific administration login 'adminlogin' is configured to avoid using the default administration login 'system'.
Notes:
• Configuration of possible users is not mandatory provided there is only one license file or a default licence is configured.
• If the default administration login 'system' is used instead of specific administration login 'adminlogin', tokens will be create for 'system'.
Scenario:
• The administrator user runs Administrtation.exe. No token is requested.
• The administrator user opens the environment with 'adminlogin'. A token is requested for 'LAN' and 'SUP'. 'adminlogin' is configured as possible user for these products. No token is requested for ARC, DMO.
• The administrator user closes the environment. His tokens requested for 'LAN' and 'SUP' are released. 'adminlogin' is still configured as possible user for these products.
Use case5: HOPEX Explorer
Typical example:
License 005.must definition:
• HOPEX IT Architecture (ARC): 3 tokens for 4 possible users (U0001, U0002, U0003, U0004).
• HOPEX Logical Data (DMO): 2 tokens for 5 possible users (U0001, U0002, U0003, U0004, U0005).
• HOPEX Power Supervisor (SUP): 1 token for 2 possible users (U0001, U0002).
• HOPEX Explorer (HEXP): 10 tokens for 20 possible users (U0001, U0002… U0020).
• Repository Storage (SQL Server) (RSQ): enabled.
• HOPEX User (LAN): 1 token (minimum)
Two logins 'hopexlogin01' and 'hopexlogin02' are configured with a HOPEX explorer role or profile (Explorer reader, Explorer writer)
Notes:
• Configuration of possible users is not mandatory provided there is only one license file or a default licence is configured.
Scenario:
• A first user tries to log in to HOPEX Web Front-end with login 'hopexlogin01'. A token is requested for 'HEXP'. 'hopexlogin01' is configured as possible user for this product. No token is requested for ARC or DMO.
• A second user tries to log in to HOPEX Web Front-end with login 'hopexlogin02'. A token is requested for 'HEXP'. 'hopexlogin02' is configured as possible user for this product. No token is requested for ARC or DMO.
• The first user logs out of HOPEX Web Front-end with login 'hopexlogin01'. His token 'HEXP' is released. 'hopexlogin01' is still configured as possible user for this product.
• The second user logs out of HOPEX Web Front-end with login 'hopexlogin02'. His token 'HEXP' is released. 'hopexlogin02' is still configured as possible user for this product.
Use case5: configuration with several licensing modes
Typical example:
License 006.must definition:
• HOPEX IT Architecture (ARC_F) in concurrent mode: 2 tokens for any possible user.
• HOPEX Logical Data (DMO) in concurrent mode: 3 tokens for any possible user.
• HOPEX Power Supervisor (SUP) in dedicated mode: 1 token for 1 possible users (U0001).
• HOPEX User (LAN) in dedicated mode: 1 token for 1 possible users (U0001).
• HOPEX User (LAN_F) in concurrent mode: 4 token for any possible user.
• Repository Storage (SQL Server) (RSQ): enabled
Command ligne for profile 'Architect'
/RW'LAN_F,ARC_F,DMO'
Scenario:
• A first user tries to log in to HOPEX with profile profile 'Architect'. A token is requested for LAN_F, ARC_F and DMO. User can login to LAN_F, ARC_F and DMO. No token is requested for SUP and LAN.
• A second user tries to log in to HOPEX with profile profile 'Architect'. A token is requested for LAN_F, ARC_F and DMO. User can login to LAN_F, ARC_F and DMO. No token is requested for SUP and LAN.
• A third user tries to log in to HOPEX with profile profile 'Architect'. A token is requested for LAN_F, ARC_F and DMO. User can login to LAN_F and DMO. No token is requested for SUP and LAN.
• At any time, user U0001 can login to Windows Administration Console. A token is requested and used for SUP.
