- play_arrow Overview
- play_arrow Junos Automation Scripts Overview
- play_arrow Junos XML Management Protocol and Junos XML API Overview
-
- play_arrow Automation Scripting Using XSLT
- play_arrow XSLT Overview
- play_arrow Standard XPath and XSLT Functions Used in Automation Scripts
- play_arrow Standard XSLT Elements and Attributes Used in Automation Scripts
-
- play_arrow Automation Scripting Using Python
- play_arrow Python Overview
- Understanding Python Automation Scripts for Junos Devices
- Requirements for Executing Python Automation Scripts on Junos Devices
- Overview of Python Modules on Junos Devices
- How to Use Python Interactive Mode on Devices Running Junos OS
- How to Use the psutil Module to Retrieve Process and System Information on Devices Running Junos OS
- How to Use the Requests Library for Python on Devices Running Junos OS
- IPv6 Support in Python Automation Scripts
- How to Specify the Routing Instance in Python 3 Applications on Devices Running Junos OS Evolved
-
- play_arrow Automation Script Input
- play_arrow Global Parameters in Automation Scripts
-
- play_arrow Extension Functions and Named Templates for Automation Scripts
- play_arrow Extension Functions for Automation Scripting
- play_arrow Extension Functions in the jcs and slax Namespaces
- base64-decode() Function (SLAX)
- base64-encode() Function (SLAX)
- break-lines() Function (SLAX and XSLT)
- close() Function (SLAX and XSLT)
- dampen() Function (Python, SLAX, and XSLT)
- document() Function (SLAX)
- emit_error() Function (Python)
- emit_snmp_attributes Function (Python)
- emit_warning() Function (Python)
- empty() Function (SLAX and XSLT)
- evaluate() Function (SLAX)
- execute() Function (SLAX and XSLT)
- first-of() Function (SLAX and XSLT)
- get-command() Function (SLAX)
- get-hello() Function (SLAX and XSLT)
- get-input() Function (SLAX and XSLT) and get_input() (Python)
- get-protocol() Function (SLAX and XSLT)
- get-secret() Function (SLAX and XSLT) and get_secret() (Python)
- get_snmp_action() Function (Python)
- get_snmp_oid() Function (Python)
- hostname() Function (Python, SLAX, and XSLT)
- invoke() Function (SLAX and XSLT)
- open() Function (SLAX and XSLT)
- output() Function (Python, SLAX, and XSLT)
- parse-ip() Function (SLAX and XSLT) and parse_ip() (Python)
- printf() Function (Python, SLAX, and XSLT)
- progress() Function (Python, SLAX, and XSLT)
- regex() Function (SLAX and XSLT)
- set_routing_instance() Function (Python)
- sleep() Function (SLAX and XSLT)
- split() Function (SLAX and XSLT)
- sysctl() Function (Python, SLAX, and XSLT)
- syslog() Function (Python, SLAX, and XSLT)
- trace() Function (Python, SLAX, and XSLT)
- play_arrow Named Templates for Automation Scripting
- play_arrow Named Templates in the jcs Namespace
-
- play_arrow Manage Automation Scripts
- play_arrow Store and Enable Scripts
- play_arrow Configure a Remote Source for Scripts
- play_arrow Configure the Session Protocol for Scripts
- play_arrow Control Execution of Scripts
- play_arrow Synchronize Scripts Between Routing Engines
- play_arrow Convert Scripts Between SLAX and XSLT
-
- play_arrow Commit Scripts
- play_arrow Commit Scripts Overview
- play_arrow Create and Execute Commit Scripts
- Required Boilerplate for Commit Scripts
- XML Syntax for Common Commit Script Tasks
- Design Considerations for Commit Scripts
- How to Avoid Potential Conflicts When Using Multiple Commit Scripts
- Line-by-Line Explanation of Sample Commit Scripts
- Control the Execution of Commit Scripts During Commit Operations
- Control the Execution of Commit Scripts in the QFabric System
- Configure Checksum Hashes for a Commit Script
- How to Process Large Configurations Against Commit Scripts
- Example: Retrieve the Pre-Inheritance Candidate Configuration in a Commit Script
- play_arrow Generate a Custom Warning, Error, or System Log Message Using Commit Scripts
- Overview of Generating Custom Warning, Error, and System Log Messages
- Generate a Custom Warning, Error, or System Log Message in Commit Scripts
- SLAX and XSLT Commit Script Tag Elements to Use When Generating Messages
- Example: Generate a Custom Warning Message
- Example: Generate a Custom Error Message
- Example: Generate a Custom System Log Message
- play_arrow Generate Persistent or Transient Configuration Changes Using Commit Scripts
- Overview of Generating Persistent or Transient Configuration Changes Using Commit Scripts
- Generate a Persistent or Transient Configuration Change in SLAX and XSLT Commit Scripts
- Generate a Persistent or Transient Configuration Change in Python Commit Scripts
- SLAX and XSLT Commit Script Tag Elements to Use When Generating Persistent and Transient Configuration Changes
- Remove a Persistent or Transient Configuration Change Using Commit Scripts
- Example: Generate Persistent and Transient Configuration Changes Using Commit Scripts
- play_arrow Create Custom Configuration Syntax with Commit Script Macros
- Overview of Creating Custom Configuration Syntax with Commit Script Macros
- Create Custom Configuration Syntax with Commit Script Macros
- Create a Commit Script Macro to Read the Custom Syntax and Generate Related Configuration Statements
- Example: Creating Custom Configuration Syntax with Commit Script Macros
- play_arrow Commit Script Examples
- Example: Adding a Final then accept Term to a Firewall
- Example: Adding T1 Interfaces to a RIP Group
- Example: Assign a Classifier Using a Commit Script
- Example: Automatically Configure Logical Interfaces and IP Addresses
- Example: Configure Administrative Groups for LSPs
- Example: Configure a Default Encapsulation Type
- Example: Configure Dual Routing Engines
- Example: Configure an Interior Gateway Protocol on an Interface
- Example: Control IS-IS and MPLS Interfaces
- Example: Control LDP Configuration
- Example: Create a Complex Configuration Based on a Simple Interface Configuration
- Example: Impose a Minimum MTU Setting
- Example: Limit the Number of ATM Virtual Circuits
- Example: Limit the Number of E1 Interfaces
- Example: Load a Base Configuration
- Example: Prepend a Global Policy
- Example: Prevent Import of the Full Routing Table
- Example: Require Internal Clocking on T1 Interfaces
- Example: Require and Restrict Configuration Statements
- play_arrow Junos XML and XSLT Tag Elements Used in Commit Scripts
- play_arrow Troubleshoot Commit Scripts
-
- play_arrow Op Scripts
- play_arrow Op Scripts Overview
- play_arrow Create and Execute Op Scripts
- Required Boilerplate for Op Scripts
- Map Operational Mode Commands and Output Fields to Junos XML Notation
- How to Use RPCs and Operational Mode Commands in Op Scripts
- Declare and Use Command-Line Arguments in Op Scripts
- Configure Help Text for Op Scripts
- Define Operational Mode Commands to Allow in an Op Script
- Enable an Op Script and Define a Script Alias
- Configure Checksum Hashes for an Op Script
- Execute an Op Script on the Local Device
- Execute an Op Script from a Remote Site
- Disable an Op Script
- play_arrow Op Script Examples
- Change the Configuration Using SLAX and XSLT Scripts
- Example: Change the Configuration Using SLAX and XSLT Op Scripts
- Example: Change the Configuration Using Python Op Scripts
- Example: Customize Output of the show interfaces terse Command Using an Op Script
- Example: Display DNS Hostname Information Using an Op Script
- Example: Find LSPs to Multiple Destinations Using an Op Script
- Example: Restart an FPC Using an Op Script
- Example: Export Files Using an Op Script
- Example: Import Files Using an Op Script
- Example: Search Files Using an Op Script
- play_arrow Provision Services Using Service Template Automation
- play_arrow Troubleshoot Op Scripts
-
- play_arrow Event Policies and Event Scripts
- play_arrow Event Policy Overview
- play_arrow Event Policy Triggers
- Use Correlated Events to Trigger an Event Policy
- Trigger an Event Policy Based on Event Count
- Example: Trigger an Event Policy Based on Event Count
- Use Regular Expressions to Refine the Set of Events That Trigger a Policy
- Example: Controlling Event Policy Using a Regular Expression
- Generate Internal Events to Trigger Event Policies
- Use Nonstandard System Log Messages to Trigger Event Policies
- Junos Logger Utility
- play_arrow Event Policy Actions
- Configure an Event Policy to Execute Operational Mode Commands
- Configure an Event Policy to Change the Configuration
- Example: Changing the Configuration Using an Event Policy
- Example: Changing the Interface Configuration in Response to an Event
- Execute Event Scripts in an Event Policy
- Change the Configuration Using an Event Script
- Configuring an Event Policy to Pass Arguments to an Event Script
- Configure Event Policies to Ignore an Event
- Example: Ignore Events Based on Receipt of Other Events
- Overview of Using Event Policies to Raise SNMP Traps
- Example: Raise an SNMP Trap in Response to an Event
- Understanding the Event System Log Priority in an Event Policy
- Example: Configuring the Event System Log Priority in an Event Policy
- Example: Limit Event Script Output Based on a Specific Event Type
- play_arrow Configure Event Policy File Archiving
- play_arrow Configure Event Policy Privileges
- play_arrow Event Scripts Overview
- play_arrow Create and Execute Event Scripts
- play_arrow Troubleshoot Event Policies and Event Scripts
-
- play_arrow SNMP Scripts
- play_arrow SNMP Scripts Overview
- play_arrow Create and Execute SNMP Scripts
- play_arrow SNMP Script Example
- play_arrow Troubleshoot SNMP Scripts
-
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
SLAX Templates Overview
A SLAX script consists of one or more sets of rules called templates. Each template is a segment of code that contains rules to apply when a specified node is matched.
Version 1.2 of the SLAX language, which is supported in Junos OS Release 14.2 and later releases, supports SLAX elements as arguments to both templates and functions.
There are two types of templates, named and unnamed (or match), described in the following sections.
Unnamed (Match) Templates
Unnamed templates, also known as match templates, contain a match
statement with an XPath expression to specify the criteria for nodes upon which the template
should be invoked. In the following commit script sample, the template
matches the top-level element in the configuration hierarchy:
match configuration { /* ...body of the template goes here */ }
By default, the processor recursively traverses the entire document hierarchy, inspecting each node and looking for a template that matches the current node. When a matching template is found, the contents of that template are evaluated.
The apply-templates
statement can
be used inside an unnamed template to limit and control the default,
hierarchical traversal of nodes. This statement accepts an optional
XPath expression, which is equivalent to the select
attribute in an <xsl:apply-templates>
element. If an optional XPath expression is included, only nodes
matching the XPath expression are traversed. Otherwise, all children
of the context node are traversed.
If the XPath expression is included but does not match any nodes,
nothing is traversed and nothing happens.
In the following example, the template rule matches the <route>
element in the XML hierarchy. All the nodes
containing a changed
attribute are processed.
All route
elements containing a changed
attribute are replaced with a new
element.
match route { <new> { apply-templates *[@changed]; } }
The XSLT equivalent:
<xsl:template match="route"> <new> <xsl:apply-templates select="*[@changed]"/> </new> </xsl:template>
Using unnamed templates allows the script to ignore the location
of a tag in the XML hierarchy. For example, if you want to convert
all <author>
tags into <div class="author">
tags, using templates enables
you to write a single rule that converts all <author>
tags, regardless of their location in the input XML document.
Named Templates
Named templates operate like functions in traditional programming languages. When the complexity of a script increases or a code segment appears in multiple places, you can modularize the code and create named templates. Like functions, named templates accept arguments and run only when explicitly called.
In SLAX, the named template definition consists of the template
keyword, the template name, a set of parameters,
and a braces-delimited block of code. Parameter declarations can be
inline and consist of the parameter name, and, optionally, a default
value. Alternatively, you can declare parameters inside the template
block using the param
statement. If a default
value is not defined, the parameter defaults to an empty string.
The following example creates a template named my-template
and defines three parameters, one of which
defaults to the string false
, and one of
which defaults to the contents of the element node named name
that is a child of the current context node. If
the script calls the template and does not pass in a parameter, the
default value is used.
template my-template ($a, $b = "false", $c = name) { /* ... body of the template ... */ }
An alternate method is to declare the parameters within the
template using the param
statement. The
following code is identical to the previous example:
template my-template { param $a; param $b = "false"; param $c = name; /* ... body of the template ... */ }
In SLAX, you invoke named templates using the call
statement, which consists of the call
keyword and template name, followed by a set of parameter bindings.
These bindings are a comma-separated list of parameter names that
are passed into the template from the calling environment. Parameter
assignments are made by name and not by position in the list. Alternatively,
you can declare parameters inside the call
block using the with
statement. Parameters
passed into a template must match a parameter defined in the actual
template; otherwise the parameter is ignored. Optionally, you can
set a value for each parameter. If you do not define a value for the
parameter in the calling environment, the script passes in the current
value of the parameter if it was previously initialized, or it generates
an error if the parameter was never declared. For more information
about passing parameters, see SLAX Parameters Overview.
In the following example, the template my-template
is called with the parameter c
containing
the contents of the element node named other-name
that is a child of the current context node:
call my-template { with $c = other-name; }
In the following example, the name-servers-template
declares two parameters: name-servers
and size
. The size
parameter is given a default value of zero. The match template,
which declares and initializes name-servers
, calls the name-servers-template
three
times.
The first call to the template does not include any parameters.
Thus name-servers
will default to an empty
string, and size
will default to a value
of zero as defined in the template. The second call includes the name-servers
and size
parameters,
but only supplies a value for the size
parameter.
Thus name-servers
has the value defined
by its initialization in the script, and size
is equal to the number of name-servers
elements in the configuration hierarchy. The last call is identical
to the second call, but it supplies the parameters using the with
statement syntax.
match configuration { param $name-servers = name-servers/name; call name-servers-template(); call name-servers-template($name-servers, $size = count($name-servers)); call name-servers-template() { with $name-servers; with $size = count($name-servers); } } template name-servers-template($name-servers, $size = 0) { <output> "template called with size " _ $size; }
The XSLT equivalent is:
<xsl:template match="configuration"> <xsl:variable name="name-servers" select="name-servers/name"/> <xsl:call-template name="name-servers-template"/> <xsl:call-template name="name-servers-template"> <xsl:with-param name="name-servers" select="$name-servers"/> <xsl:with-param name="size" select="count($name-servers)"/> </xsl:call-template> <xsl:call-template name="name-servers-template"> <xsl:with-param name="name-servers" select="$name-servers"/> <xsl:with-param name="size" select="count($name-servers)"/> </xsl:call-template> </xsl:template> <xsl:template name="name-servers-template"> <xsl:param name="name-servers"/> <xsl:param name="size" select="0"/> <output> <xsl:value-of select="concat('template called with size ', $size)"/> </output> </xsl:template>