Keywords

The following tables list the keywords used in Unlang. These keywords implement the "flow control" of the policies.

Flow Control Keywords

The flow control keywords allow if / then / else checks, simple looping, etc.

Table 1. Flow Control
Keyword	Description
break	Exit early from a `foreach` loop.
case	Match inside of a `switch`.
catch	catch an error from a previous "try"
else	Do something when an `if` does not match.
elsif	Check for condition when a previous `if` does not match.
foreach	Loop over a list of attributes.
if	Check for a condition, and execute a sub-policy if it matches.
return	Immediately stop processing a section.
switch	Check for multiple values.
transaction	Group operations into a transaction which can be reverted on failure.
try	try / catch blocks

Attribute Editing Keywords

The attribute editing keywords allow policies to add, delete, and modify attributes in any list or packet.

Table 2. Attribute Editing
Keyword	Description
map	Map database fields to server attributes.
editing	Creating, modifying, and deleting attributes.
update	DEPRECATED - v3 compatible attribute editing.

Grouping Keywords

The grouping keywords allow policies to be organized into groups, including fail-over, load-balancing, limits, etc.

Table 3. Grouping and Limits
Keyword	Description
group	Group a series of statements.
load-balance	Define a load balancing group without fail-over.
limit	Limit the number of requests in a section
redundant	Define a redundant group with fail-over.
redundant-load-balance	Define a redundant group with fail-over and load balancing.
timeout	Enforce a timeout for processing a section

Parent-Child Keywords

The parent-child keywords allow for creation of parent-child relationships between requests.

For example, it is possible to create a child request, edit its attributes, and then proxy that packet to an external destination. This process must be specified manually, unlike in version 3, the child was created automatically when the proxy list was used.

The benefit of these new keywords is that it is now possible to control when child requests are created. It is also possible to control whether or not the parent waits for the child to finish, or operates independently of the child. It is also finally possible to have multiple child requests via the parallel keyword.

These new keywords can unfortunately make some simple configurations more complex than they would have been in version 3. The trade-off is that many complex configurations now become trivial, where they were impossible to create before.

Table 4. Parent-Child
Keyword	Description
call	Call one virtual server from another
caller	Check if the request is from a parent `call`
detach	Detach a child from a parent
parallel	Create multiple parallel child requests
subrequest	Create a child request

Module Keywords

The module keywords refer pre-packaged libraries that implement specific functionality, such as connecting to SQL, LDAP, etc. The name used here is not the literal string module. Instead, it is the name of an instance of a pre-packaged module such as sql, or ldap, or eap.

The documentation below describes how to reference modules. That is, how to use sql, etc. in the policies. Please see the module configuration and the configuring modules howto pages for information on configuring and using the modules.

Table 5. Modules
Keyword	Description
<module>	Execute a named module, e.g., `sql`.
<module>.<method>	Execute a particular method of a named module, e.g., `pap.authorize`
reject	Built-in modules, e.g., `reject`, or `ok`, etc.