Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Generating a Custom Warning, Error, or System Log Message

1. At the start of the script, include the Extensible Stylesheet Language Transformations (XSLT) or Stylesheet Language Alternative Syntax (SLAX) boilerplate from Required Boilerplate for Commit Scripts. It is reproduced here for convenience:

   XSLT Boilerplate

   <?xml version="1.0" standalone="yes"?>
   <xsl:stylesheet version="1.0"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
       xmlns:junos="http://xml.juniper.net/junos/*/junos" 
       xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm" 
       xmlns:jcs="http://xml.juniper.net/junos/commit-scripts/1.0">
       <xsl:import href="../import/junos.xsl"/>
    
       <xsl:template match="configuration">
           <!-- ... insert your code here ... -->
       </xsl:template>
   </xsl:stylesheet>

   SLAX Boilerplate

   version 1.0;
   ns junos = "http://xml.juniper.net/junos/*/junos";
   ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
   ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
   import "../import/junos.xsl";
    
   match configuration {
       /*
        * insert your code here
       */
   }

2. At the position indicated by the comment “Insert your code here,” include one or more XSLT programming instructions or their SLAX equivalents. Commonly used XSLT constructs include the following:

   • <xsl:choose> <xsl:when> <xsl:otherwise>—Conditional construct that causes different instructions to be processed in different circumstances. The <xsl:choose> instruction contains one or more <xsl:when> elements, each of which tests an XPath expression. If the test evaluates as true, the XSLT processor executes the instructions in the <xsl:when> element. The XSLT processor processes only the instructions contained in the first <xsl:when> element whose test attribute evaluates as true. If none of the <xsl:when> elements’ test attributes evaluate as true, the content of the <xsl:otherwise> element, if there is one, is processed.
   • <xsl:for-each select="xpath-expression">—Programming instruction that tells the XSLT processor to gather together a set of nodes and process them one by one. The nodes are selected by the Extensible Markup Language (XML) Path Language (XPath) expression in the select attribute. Each of the nodes is then processed according to the instructions contained in the <xsl:for-each> instruction. Code inside an <xsl:for-each> instruction is evaluated recursively for each node that matches the XPath expression. The context is moved to the node during each pass.
   • <xsl:if test="xpath-expression">—Conditional construct that causes instructions to be processed if the XPath expression in the test attribute evaluates to true.

     For example, the following programming instruction evaluates as true when the source-route statement is not included at the [edit chassis] hierarchy level:

     <xsl:if test="not(chassis/source-route)">

     In SLAX, the if construct looks like this:

     if (not(chassis/source-route))

   For more information about how to use programming instructions, including examples and pseudocode, see XSLT Programming Instructions Overview. For information about writing scripts in SLAX instead of XSLT, see SLAX Overview.
3. Include a <xnm:warning>, <xnm:error>, or <syslog> element with a <message> child element that specifies the content of the message.

   For warning and error messages, you can include several other child elements, such as the jcs:edit-path and jcs:statement templates, which cause the warning or error message to include the relevant configuration hierarchy and statement information, as shown in the following examples.

   This <xnm:warning> element:

   <xnm:warning>
       <xsl:call-template name="jcs:edit-path">
           <xsl:with-param name="dot" select="chassis"/>
       </xsl:call-template>
       <message>IP source-route processing is not enabled.</message>
   </xnm:warning>

   emits this output when you issue the commit command:

   [edit]user@host# commit

   [edit chassis]
       warning: IP source-route processing is not enabled.
   commit complete

   This <xnm:error> element:

   <xnm:error>
       <xsl:call-template name="jcs:edit-path"/>
       <xsl:call-template name="jcs:statement"/>
       <message>Missing a description for this T1 interface.</message>
   </xnm:error>

   emits this output when you issue the commit command:

   [edit]user@host# commit

   [edit interfaces interface t1-0/0/0]
       'interface t1-0/0/0;'
       Missing a description for this T1 interface.
   error: 1 error reported by commit scripts
   error: commit script failure

   Note: If you are including a warning message in conjunction with a script-generated configuration change, you can generate the warning by including the message parameter with the jcs:emit-change template. The message parameter causes the jcs:emit-change template to call the <xnm:warning> template, which sends a warning notification to the CLI. (For more information, see Overview of Generating Persistent or Transient Configuration Changes.)

   For system log messages, the only supported child element is <message>:

   <syslog>
       <message>syslog-string</message>
   </syslog>

   For a description of all the XSLT tags and attributes you can include, see Tag Elements to Use When Generating Messages.

   For SLAX versions of these constructs, see Example: Generating a Custom Warning Message, Example: Generating a Custom Error Message, and Example: Generating a Custom System Log Message.

4. Save the script with a meaningful name.
5. Copy the script to either the /var/db/scripts/commit directory on the hard drive or the /config/scripts/commit directory on the flash drive. For information about setting the storage location for commit scripts, see Storing Scripts in Flash Memory.

   If the device has dual Routing Engines and you want the script to take effect on both of them, you must copy the script to the /var/db/scripts/commit or the /config/scripts/commit directory on both Routing Engines. The commit synchronize command does not copy scripts between Routing Engines.

6. Enable the script by including the file statement at the [edit system scripts commit] hierarchy level:

   [edit system scripts commit]file filename;
   where filename is the name of the script.