Condition Types
This section describes the following condition types:
| • | Hostid Condition |
| • | Hostname (Device Name) Condition |
| • | Hosttype (Device Type) Condition |
| • | Vendor Dictionary Condition |
| • | User Identifier Condition |
These condition types can be combined using AND, OR, and NOT, to form more complex rules of access. For more information, see AND, OR, and NOT Operators.
Note that in this section, the syntax describing each condition has been simplified. For a detailed syntax description, refer to Model Definition Grammar and Syntax—EBNF.
When a client requests a license from the license server, the client includes the unique hostid in the request to which the license server binds the licenses sent in the response. The hostid condition enables you to allocate licenses from a specified license pool to one or more client devices that are identified by a hostid.
The hostid is specified as a value/type pair (for example, 7200014f5df0/ETHERNET). If a hostid condition does not specify the hostid type, it is assumed that the hostid is of type string.
hostid_condition = 'hostid', '(', parameter_list, ')' ;
Example
The following hostid condition allows any feature requests with hostid h1 or h2 to use features from the named license pool p1.
on hostid("h1", "h2") {
use "p1"
accept
}
Tip:For examples that demonstrate the use of the hostid condition, see the following use case sections:
| • | Use Case: Simple Allow List |
| • | Use Case: Simple Block List |
| • | Use Case: Exclusive Use of Feature Counts for Business Unit With Exception of Specific Clients |
| • | Use Case: Exclusive Use of Feature Counts for Business Unit and Specified Clients from other Business Units |
Hostname (Device Name) Condition
Your software producer can set a host name on a client device. (This host name is also sometimes referred to as a device name.) A host name is a human-readable “alias”—in contrast to the hostid—which can optionally be included in a capability request. For information about host names that might be available, contact your software producer.
Syntax
hostname_condition = 'hostname', '(', parameter_list, ')' ;
Example
The following host name condition allows any feature requests with host name ABC to use features from the named license pool p2.
on hostname("ABC") {
use "p2"
accept
}
Note that the host name is case sensitive.
Tip:For examples that demonstrate the use of the hostname condition, see the following use case sections:
| • | Use Case: Assigning Features Based on Combined hosttype and hostname Properties |
| • | Use Case: Using Regular Expression to Allocate License Counts |
| • | Use Case: Letting Server Specify Counts |
Hosttype (Device Type) Condition
Your software producer can set a host type on a client device. (This host type is also sometimes referred to as a device type.) A host type can optionally be included in a capability request. For information about host types that might be available, contact your software producer.
Syntax
hosttype_condition = 'hosttype', '(' parameter_list, ')' ;
Example
The following host type condition allows any feature requests with host type device to use features from the named license pool p3.
on hosttype("device") {
use "p3"
accept
}
Note that the host type is case sensitive.
Tip:For examples that demonstrate the use of the hosttype condition, see the following use case sections:
| • | Use Case: Assigning Features Based on Combined hosttype and hostname Properties |
| • | Use Case: Device-specific Handling—Sharing Feature Counts Based On Hosttype |
The vendor dictionary enables the software producer to send custom data in a capability request (in addition to the FlexNet Embedded–specific data) to the license server and vice-versa. Basically, the vendor dictionary provides a means to send information back and forth between the client and server for any producer-defined purposes, as needed; FlexNet Embedded does not interpret this data.
Vendor dictionary data is stored as key–value pairs. The key name is always a string, while a value can be a string or a 32-bit integer value. (In certain cases, the value can also be an array of a string and/or 32-bit integer.) Keys are unique in a dictionary and hence allow direct access to the value associated with them.
For information about whether the vendor dictionary supports arrays and the data that might be available, contact your software producer.
Syntax
vendor_dictionary_condition = 'dictionary', '(', keyword_parameter_list, ')' ;
Example
The following vendor dictionary condition allows any feature requests from the engineering business unit (as defined in the vendor dictionary) to use features from the named license pool p4.
on dictionary("business-unit" : "engineering") {
use "p4"
accept
}
Tip:For examples that demonstrate the use of the vendor dictionary condition, see the following use case sections:
| • | Use Case: Sharing Counts Between Business Units |
| • | Use Case: Assigning Extra Counts To Business Unit |
| • | Use Case: Exclusive Use of Feature Counts for Business Unit |
| • | Use Case: Exclusive Use of Feature Counts for Business Unit With Exception of Specific Clients |
| • | Use Case: Exclusive Use of Feature Counts for Business Unit and Specified Clients from other Business Units |
| • | Use Case: Assigning Features Based on Vendor String Property |
| • | Use Case: Using Regular Expression to Allocate License Counts |
| • | Use Case: Making Feature Counts Available to Multiple Business Units |
| • | Use Case: Accumulating Counts from Multiple Named License Pools (“Continue” Action) |
The user identifier condition is useful when access to software features is granted based on individual user identities. To track a unique user across multiple device, every access request must include a user identifier in the userIdentifier field.
The benefit of the user identifier condition is that it allows license administrators to create more granular license allocation policies by applying rules at the user level, in combination with existing conditions such as host identifiers and vendor dictionary metadata.
Syntax
user_identifier_condition = 'userIdentifier', '(', parameter_list, ')' ;
Examples
The following user identifier condition allows any feature requests with user identifier alice, james, or umi to use features from the named license pool p5.
on userIdentifier("alice", "james", "umi"){
use "p5"
accept
}
Tip:For examples that demonstrate the use of the user identifier condition, see the following use case sections:
| • | Use Case: Restrict Access to a License Pool for a Specific User |
| • | Use Case: Allow Specified Users Access to Specified License Pool |
Best Practices and Limitations
When using user-based conditions for named license pools, license administrators should follow these best practices to ensure predictable behavior and optimal performance.
| • | License administrators must not create a large number of license pools on a per-user basis. Creating a separate license pool for each user does not scale and can lead to excessive rule complexity and performance degradation. For an example of users sharing licenses from the same pool, see Use Case: Allow Specified Users Access to Specified License Pool . |
| • | License administrators should limit the number of license pools per Cloud Licensing Service (CLS) instance or local license server to a maximum of 1200. |
| • | Individual rule updates per user or per model are likely to exceed the effective limits of the /rules endpoint, which can negatively impact system performance. To protect system stability, after each rule update, the local license server enforces a lock and does not accept another rule update for 120 seconds. |