Previous Article: Best Practices Series: Make Your Junos Automation Scripts More Robust
Next Article: Making Scripts Robust: Handling Routing Engine Switchovers
NOTE: This applies to SLAX version 1.0 and higher.
Checking Status
"We have met the enemy and he is us.” – Walt Kelly
When you write a Junos automation script, you will likely find that checking the return status from functions or RPC invocations to be boring and tedious. Failure to do so, however, is probably the most common source of unexpected errors, as well as incorrect data. You have probably experienced the same thing as I: there is usually a time constraint to get results, so when something looks like it’s working and you’re getting the data you requested, the natural thing is to move on to the next bit of code. That approach may serve you well until your code gives you something you didn’t expect. So if you want to prevent about 80% of your script errors from becoming bugs later on, examine the result error elements.
For example, when your query returns $result, remember to also stop and check$result//self::xnm:error. A little coding now will save you some debugging later.
Curtis Call wrote an excellent article on that very topic: SLAX: Error Detection. This article is well worth your time if you’re creating any SLAX-based Junos automation.
One final note on status checking: just because you can detect an error response, that does not mean your script will always be able to recover from it. But, you can always try to deal with the error message appropriately. For example,
- It might be possible for you to retry the operation
- You might need to roll back or invalidate some previously-collected data
- In the worst case, you may only be able to emit the SNMP or syslog equivalent of an error or failure, so that someone (or something) can detect the message and respond in a timely fashion
Written by Douglas McPherson
Solutions Consultant at Juniper