Syntax for Rules of Access
Rules of access are defined using the following simplified syntax:
on <condition> {
[use "<license-pool-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 contains the business-unit:engineering key-value pair—access to the named license pool engineering is granted:
on dictionary("business-unit" : "engineering") {
use "engineering"
accept
}
The following subsections provide more information about configuring rules of access:
| • | Conditions Syntax—Describes how to configure a condition in simple terms. |
| • | AND, OR, and NOT Operators—Describes how to combine conditions within a rule of access. |
| • | Basic Keywords and Their Actions—Explains the keywords accept, deny, and continue. |
| • | 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 of access 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 of access 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 of access.
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 of access in the appendix Model Definition Grammar for Named License Pools 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 |
Basic Keywords and Their Actions
The following table explains the keywords accept, continue, and deny and their actions. For additional keywords and directives, see Advanced Keywords and Directives.
|
Keyword |
Action |
|
accept |
If the conditions of the rule of access are met and the rule ends with accept, the feature request is granted. No further rules of access are evaluated. |
|
continue |
The continue keyword causes rules of access on subsequent lines to be evaluated, allowing multiple rules of access that match a single request. The continue keyword therefore allows clients to accumulate counts from more than one license pool. For a use case example, see Use Case: Accumulating Counts from Multiple Named License Pools (“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 of access 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 of access are evaluated. If the conditions of the rule of access are not met and the rule ends with deny, the next rule is evaluated. |
When a feature request does not satisfy any of the rules of access in the model definition, an on any() condition is expected that either denies or allows access to a license pool. If no such on any() condition is provided, the default is that the feature will be served from the default license pool (if features are available). This behavior is equivalent to the following code:
on any() {
use "default"
accept
}
The examples in this