A transaction refers to an operation or a task that is performed on the service definitions, configuration parameters, and policy settings that are created for provisioning on the devices or Service Delivery Gateways (SDGs). When you create a deployment plan to define the services and policy filters that must be applied and propagated on the devices, the administrator can approve or reject a deploy plan. For each approved deploy plan, a transaction is automatically created by the Edge Services Director application.
A transaction contains a unique identifier that denotes each deployment plan associated with it. Such an automated generation of a transaction for each deploy plan enables you to track, monitor, and maintain a comprehensive record or log of events performed on the devices. For example, if you approve a deploy plan and schedule it for transferring configuration to a set of devices, you can use the Transactions page to view the history of all of the deploy plans that were created for different devices. Also, if multiple deploy plans for the same set of devices were created, the list of transactions provides a granular, in-depth account of the operations.
This level of detail and analysis pattern is useful in diagnosis, debugging, and administration of services and device settings. You can also view the configuration that exists on the device before a deploy plan propagates and applies settings, the configuration being transmitted using the deploy plan, and a differential set of the settings that are present on the device and the settings being provisioned using the deploy plan. All of the configuration is displayed in Junos OS XML API format.
The Junos OS command-line interface (CLI) and the Junos OS infrastructure communicate using XML. When you issue an operational mode command in the CLI, the CLI converts the command into XML format for processing. After processing, Junos OS returns the output in the form of an XML document, which the CLI converts back into a readable format for display. Remote client applications also use XML-based data encoding for operational and configuration requests on devices running Junos OS. The Junos XML API is an XML representation of Junos configuration statements and operational mode commands. It defines an XML equivalent for all statements in the Junos configuration hierarchy and many of the commands that you issue in CLI operational mode. Each operational mode command with a Junos XML counterpart maps to a request tag element and, if necessary, a response tag element.
Multiple transactions are generated for a single deployment plan with different, unique IDs for each transaction, when multiple devices are present in a single deployment plan. With transactions created for each of the devices for which configuration is propagated from Edge Services Director, you can quickly and easily view the status of the deployment plan pertaining to the transaction for diagnosis and rectification of configuration errors and discrepancies in the settings.
A configuration is stored as a hierarchy of configuration statements. In this mode, you enter statements to configure all properties of the device, including interfaces, general routing information, routing protocols, user access, and several system and hardware properties. When you specify configuration parameters on a device, you are actually viewing and changing a file called the candidate configuration. The candidate configuration file enables you to make configuration changes without causing operational changes to the current operating configuration, called the active configuration. The device does not implement the changes you added to the candidate configuration file until you commit them, which activates the configuration on the device. Candidate configurations enable you to alter your configuration without causing potential damage to your current network operations. Running configuration refers to the configuration file currently in effect on the device. The running configuration file is labeled Version 0. Candidate configuration signifies the new, not yet committed, configuration file that becomes the running configuration.
A rollback configuration refers to the previously committed configuration. The configuration set that is being propagated to devices to be rolled back if a failure occurs during the deployment operation. You can return to the most recently configured successful configuration on the device.