Committing the Candidate Configuration

To commit the candidate configuration, a client application encloses the empty <commit-configuration/> tag in an <rpc> tag element:

We recommend that the application lock the candidate configuration before changing it and emit the <commit-configuration/> tag while the configuration is still locked. Doing so avoids inadvertent commit of changes made by other users or applications. After committing the configuration, the application must unlock it for other users and applications to be able to make changes. For instructions, see Exchanging Information with the Junos XML Protocol Server and Changing Configuration Information.

The Junos XML protocol server reports the results of the commit operation in <rpc-reply>, <commit-results>, and <routing-engine> tag elements. If the commit operation succeeds, the <routing-engine> tag element encloses the <commit-success/> tag and the <name> tag element, which reports the name of the Routing Engine on which the commit operation succeeded (re0 on devices that use a single Routing Engine, and either re0 or re1 on devices that can have two Routing Engines):

<rpc-reply xmlns:junos="URL">
    <commit-results>
        <routing-engine>
            <name>(re0 | re1)</name>
            <commit-success/>
        </routing-engine>
    </commit-results>
</rpc-reply>

If the commit operation fails, an <xnm:error> tag element encloses tag elements that describe the error. The most common causes of failure are semantic or syntactic errors in the candidate configuration.