Automation
Automation

Scripting How-To: Use event and op script boilerplates

by Cordelia on ‎08-08-2015 06:19 PM - edited on ‎09-11-2017 05:07 PM by Administrator Administrator (494 Views)

Use event and op script Boilerplates

 

 

For SLAX version 1.0 and higher, you can use new script boilerplates with SLAX 1.1 in Junos OS 12.2 Release and later.
 
Event and op scripts have a more significant change to their boilerplates used to simplify future scripts:

 

01	version 1.1;
02	 
03	ns junos = "http://xml.juniper.net/junos/*/junos";
04	ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
05	ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
06	 
07	import "../import/junos.xsl";
08	 
09	template junoscript() {
10	    /* Insert code here */
11	}
 
The version statement has changed, just like for commit scripts, but the initial template has changed as wellfrom match / in the SLAX 1.0 boilerplate to template junoscript() in the new one.
 
Why the change? Well, first let's talk about the result. In SLAX 1.0 op scripts, you had to manually include the top-level <op-script-results>result tree element within your script code, but with the new boilerplates you no longer have to do so because, as long as you use the initial template junoscript() template, the<op-script-results> result tree element will now encapsulate any result tree elements that your script outputs (just like commit scripts automatically add the <commit-script-results> element).
 
The same improvement is available for event scripts that use the new boilerplate, although they add <event-script-results> to the result tree instead of <op-script-results>.

 

How is this accomplished? It all comes from an improvement in the match / template that is imported from the junos.xsl file.

 

Here is the new code, translated into SLAX:

 

01	match / {
02	 
03	    /* Commit Scripts - use /commit-script-input/configuration as context */
04	    if (commit-script-input) {
05	        <commit-script-results> {
06	            apply-templates commit-script-input/configuration;
07	        }
08	    } else if (event-script-input) {
09	        <event-script-results> {
10	            call junoscript();
11	        }
12	    } else {
13	        <op-script-results> {
14	            call junoscript();
15	        }
16	    }
17	}

The logic is simple: when a script starts it will have a source tree with a single top-level node, depending on the script type: <commit-script-input>, <event-script-input>, or <op-script-input>. So, when the script processor begins executing the script, it starts within the match / template (which is imported from the junos.xsl import file) and immediately checks the top-level node to determine what type of script is running.

 

The script processor then uses that knowledge to write the correct top-level element to the result tree, based on the script type. In addition, within that top-level element, it invokes the starting template for that type of script. This is done for commit scripts by using the apply-templates statement and digging into the provided configuration, and, as a result, the context node changes from / to /commit-script-input/configuration, making location paths more convenient. Op and event scripts, however, have no reason to change their context node, which remains as /, so they simply call the named template junoscript().

 

A final word on backward compatibility. This change to junos.xsl does not interfere with existing op and event scripts due to the import precedence that causes any match templates imported into a script to be superseded by match templates in the calling script. In other words, the prior boilerplate placed match / into the actual script file, causing the match /that is imported from junos.xsl to be completely ignored by the script processor. It is only when you replace match / with template junoscript() in your script that the processor begins to pay attention to the match / template imported by junos.xsl.

 

 

NOTE: As a reminder, this is a Junos OS 12.2 Release feature. If your platform is running on a special branch, then you maybe need to wait a while for this feature. In particular, I don't think that SRX devices will get this boilerplate improvement—or any other SLAX 1.1 enhancementuntil the end of 2013 (Junos 13.3 OS Release).