Rule Syntax
Rules are defined using the following simplified syntax:
on <condition> {
[use "<partition-name>"]
[accept|deny|continue]
}
where <condition> specifies one or more conditions that must be matched.
Example
If the condition dictionary("business-unit" : "engineering") evaluates to true—that is, the capability request's vendor dictionary containes the business-unit:engineering key-value pair—access to the engineering partition is granted:
on dictionary("business-unit" : "engineering") {
use "engineering"
accept
}
The following subsections provide more information about configuring rules:
| • | Conditions Syntax—Describes how to configure a condition in simple terms. |
| • | AND, OR, and NOT Operators—Describes how to combine conditions within a rule. |
| • | Keywords and their actions—Explains the keywords accept, deny, and continue. |
| • | Letting Server Specify Counts—Explains how to use the without requested features directive, to let the server allocate feature counts. |
| • | Default Behavior—Describes how feature counts are served when a feature request does not meet any of the conditions in the model definition. |
This section describes the syntax for defining conditions in simple terms. For detailed information, see Model Definition Grammar and Syntax—EBNF.
The following shows a simplified conditions syntax:
[NOT]<condition_type>(<parameter_list>) [AND|OR [NOT] <condition_type>(<parameter_list>)]
where <condition_type> is replaced with a condition type (hostid, hostname, hosttype, dictionary, or any), followed by a value or value/type pair that qualifies the condition.
Optionally, additional conditions—<condition_type>(<parameter_list>)—can be chained on using an AND, OR, or optional NOT operator.
The syntax supports the AND, OR, and NOT operators to combine conditions within a rule to create a more complex rule. The operators have synonyms that are familiar to C and Java programmers:
|
Operator |
Synonym |
|
AND |
&& |
|
OR |
|| |
|
NOT |
! |
The syntax for combining conditions within a rule using these operators is illustrated in detail in section Model Definition Grammar and Syntax—EBNF. You may also find it helpful to review the provided sample rules.
Precedence Considerations
The AND and OR operators have left-to-right associativity; NOT has right-to-left associativity. NOT has a higher precedence than AND and OR.
Parentheses are not supported. An expression like this:
on hosttype("tv") and not hostname("xyz") || hostid("h1")
is interpreted as :
OR(
AND(hosttype("tv"), NOT(hostname("xyz"))),
hostid("h1")
)
The following sample rules in the appendix Model Definition Grammar for Partitions illustrate the use of operators:
| • | 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 Combined hosttype and hostname Properties |
The following table explains the keywords and their actions.
|
Keyword |
Action |
|
accept |
If the conditions of the rule are met and the rule ends with accept, the feature request is granted. No further rules are evaluated. |
|
continue |
The continue keyword causes rules on subsequent lines to be evaluated, allowing multiple rules that match a single request. The continue keyword therefore allows clients to accumulate counts from more than one partition. For a use case example, see Use Case: Accumulating Counts from Multiple Partitions (“Continue” Action). This is the default behavior if no other keywords are present. The lack of an accept or deny action also means that the on any clause (see Default Behavior, below) will be in scope to be matched. |
|
deny |
If the conditions of the rule are met and the rule ends with deny, the feature request is refused. No counts are acquired and any previously held counts are returned to the server. No further rules are evaluated. If the conditions of the rule are not met and the rule ends with deny, the next rule is evaluated. |
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 partition. To achieve this, combine without requested features with the all from "partitionName" instruction. Replace partitionName with the name of the partition whose entire list of features, as specified in the model definition, should be allocated. Note that if the specified partition does not have sufficient counts to satisfy the request, counts are allocated from subsequent partitions listed in the rules (provided that the client has access to those partitions). 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.
When a feature request does not satisfy any of the rules in the model definition, an on any() condition is expected that either denies or allows access to a partition. If no such on any() condition is provided, the default is that the feature will be served from the default partition (if features are available). This behavior is equivalent to the following code:
on any() {
use "default"
accept
}
The examples in this