Partitions
You can define one or more named partitions under the optional partitions element. (If you do not specify a partition, all feature counts are placed in the default partition.) For each partition, you need to specify a name followed by one or more features that the partition should contain. For each feature, you need to specify the feature name, feature version, and feature count. The feature count can be expressed as a number or as a percentage of the overall feature count that is available on the license server.
Example
partitions {
partition "p1" {
"f1" 1.0 50
"f1" 2.0 25
"f2" 1.0 100
}
}
For information about how the license server allocates feature counts to partitions, see Server Behavior When Distributing Feature Counts to Partitions.
Allocating Remaining License Counts
The remainder keyword can be used to allocate any remaining license counts to a specified partition. This keyword is particularly useful in preventing the situation where integer rounding would cause left-over counts to remain in the default partition when trying to configure partitions summing up to a count of 100%.
Using the remainder keyword is equivalent to specifying 100%, which allocates all available license counts. Any partition later in the model defition than the one specifying the remainder keyword (or 100%) in the model definition (including the default partition) receives zero counts for that feature. For an example demonstrating its use, see the Use Case: Partition Receiving Entire Remaining Feature Count.
Example
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 partitions based on variables specified in the vendor string. After use, feature counts are returned to their original partition.
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 partition 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.