Advanced Keywords and Directives
The following table introduces advanced keywords and directives and their usage. For a description of the keywords accept, continue, and deny, see Basic Keywords and Their Actions.
|
Keyword or Directive |
Description |
Refer to Section |
|
remainder |
Allocates any remaining license counts to a specified license pool. Useful in scenarios where integer rounding could cause left-over counts to remain in the default license pool when trying to configure license pools summing up to a count of 100%. |
|
|
vendor string matches |
Allocates feature counts to license pools based on variables specified in the vendor string. |
|
|
max |
Limits the number of feature counts that a single user or device can consume. |
|
|
without requested features |
Lets the license server specify the features that should be served to a client when a capability request lists no desired features. |
|
|
[regular expressions] |
Match patterns to reduce the number of license pools and conditions. Syntax: ~/REGEX/ |
Allocating Remaining License Counts
The remainder keyword can be used to allocate any remaining license counts to a specified named license pool. This keyword is particularly useful in preventing the situation where integer rounding would cause left-over counts to remain in the default license pool when trying to configure named license pools summing up to a count of 100%.
Using the remainder keyword is equivalent to specifying 100%, which allocates all available license counts. Any license pool later in the model definition than the one specifying the remainder keyword (or 100%) in the model definition (including the default license pool) receives zero counts for that feature. For an example demonstrating its use, see the Use Case: Named License Pool Receiving Entire Remaining Feature Count.
Example
model "exampleModel" {
partitions {
partition "p1" {
"f1" 1.0 33%
}
partition "p2" {
"f1" 1.0 33%
}
partition "p3" {
"f1" 1.0 remainder
}
}
}
Allocating Counts Based on Vendor String Property
The directive vendor string matches enables license administrators to allocate feature counts to license pools based on variables specified in the vendor string. After use, feature counts are returned to their original license pool.
To use the directive, the producer must define a vendor string in the license model when they create a line item in the back office. The vendor string can hold arbitrary producer-defined license data. Data can range from feature selectors to pre-defined substitution variables.
The directive vendor string matches is located in the partitions section of the model definition. This directive is evaluated when the license server loads the model definition.
Syntax Example
model "exampleModel" {
partitions {
partition "engineering" {
f1 1.0 75% vendor string matches "ProductName:Premium"
f2 1.0 75% vendor string matches "ProductName:Premium"
}
partition "sales" {
f1 1.0 25% vendor string matches "ProductName:Basic"
f2 1.0 25% vendor string matches "ProductName:Basic"
}
}
}
For a use case example, see Use Case: Assigning Features Based on Vendor String Property.
Limiting Checkout of Feature Counts per User or Device
Use the max keyword to limit the number of feature counts that a single user or device can consume.
max is used in the partitions section of the model definition. The following shows an example model definition which limits the consumption of features f1 and f2 to 10 and 1 counts, respectively:
Syntax Example
model "exampleModel" {
partitions {
partition "engineering" {
"f1" 1.0 100 max 10
"f2" 1.0 100 max 10
}
partition "sales" {
"f1" 1.0 5 max 1
"f1" 1.0 5 max 1
}
}
on dictionary("business-unit" : "engineering") {
use "engineering"
accept
}
on dictionary("business-unit" : "sales") {
use "sales"
accept
}
}
If max is set to 0, access to that feature from the license pool is denied.
If a client requests a feature count that is greater than the value of max, the request is denied with the error FEATURE_COUNT_INSUFFICIENT.
To allow a partial checkout, set the “partial” attribute to true. In that scenario, a client is granted access to the requested number of features up to the value of max, even if a feature count exceeding max is requested.
There might be scenarios when you want the license server to specify the features that should be served to a client. The server cannot override a capability request containing desired features coming from the client. However, if a capability request lists no desired features, the without requested features directive lets the server allocate feature counts.
You can use the without requested features directive to do the following:
| • | Allocate specific feature counts. To achieve this, list the feature counts that should be served. The following example shows the syntax: |
on hostname("myhost") {
use "p1", "default"
without requested features {
"f1" 1.0 1
}
accept
}
For a use case example, see Use Case: Letting Server Specify Counts .
| • | Allocate the entire feature count from a license pool. To achieve this, combine without requested features with the all from "license_pool_name" instruction. Replace license_pool_name with the name of the license pool whose entire list of features, as specified in the model definition, should be allocated. Note that if the specified license pool does not have sufficient counts to satisfy the request, counts are allocated from subsequent license pools listed in the rules of access (provided that the client has access to those license pools). The following example shows the syntax: |
on hostname("myhost") {
use "p1", "default"
without requested features {
all from "p1"
}
accept
}
For a use case example, see Scenario: Server-specified Counts.
Rules of access can include regular expressions to match patterns in conditions. This means that the number of license pools and conditions can be greatly reduced, simplifying management of license pools.
Regular expressions can be included in conditions using the following syntax: ~/REGEX/
For a list of supported expressions, see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html.
Full vs Partial Equality
The regular expression is generally matched against the whole value of the property on which the condition is based (that is, hostid, hostname, hosttype, or vendor dictionary string). It is not necessary to add the ^ and $ meta characters to signify the beginning and end of the expression.
Example
The following expression...
on hostname("~/[A-Z]{2}[0-9]{3}/") {
...
}
... matches the hostname AB123, but not ABCD1234.
However, when a regular expression is used in combination with the vendor string matches directive, the expression is used as a “contains” match.
Example
The following expression...
… vendor string matches "~/%%ProductName:[A-Z]{3}[0-9]{3}%%/
... matches %%ProductName:AAA111%% found anywhere inside the vendor string.
For a use case example, see Use Case: Using Regular Expression to Allocate License Counts.