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.