Handle an Error or Warning in Junos XML Protocol Sessions

In a Junos XML protocol session with a device running Junos OS, a client application sends RPCs to the Junos XML protocol server to request information from and manage the configuration on the device. The Junos XML protocol server sends a response to each client request. If the server encounters an error condition, it emits an <xnm:error> element containing child elements that describe the error.

The syntax of the <xnm:error> element is as follows:

The attributes are as follows:

• xmlns—The XML namespace for the <xnm:error> child tag elements that do not have a prefix in their names (that is, the default namespace for Junos XML tag elements). The value is a URL of the form http://xml.juniper.net/xnm/version/xnm, where version is a string such as 1.1.

• xmlns:xnm—The XML namespace for the <xnm:error> tag element and child tag elements that have the xnm: prefix in their names. The value is a URL of the form http://xml.juniper.net/xnm/version/xnm, where version is a string such as 1.1.

The set of child tags enclosed in the <xnm:error> element depends on the operation that server was performing when the error occurred. An error can occur while the server is performing any of the following operations, and the server can send a different combination of child tag elements in each case:

• Processing an operational request submitted by a client application

• Opening, locking, changing, committing, or closing a configuration as requested by a client application

• Parsing configuration data submitted by a client application in a <load-configuration> tag element

Client applications must be prepared to receive and handle an <xnm:error> tag at any time. The information in any response tag elements already received and related to the current request might be incomplete. The client application can include logic for deciding whether to discard or retain the information.

If the Junos XML protocol server encounters a less serious problem, it can emit an <xnm:warning> tag element instead. The usual response for the client application in this case is to log the warning or pass it to the user and to continue parsing the server’s response.