class UpgradePackage

+-SystemFunctions

+-SwM

+-UpgradePackage

+-RoleUpgrade [0..1]

Controls the change process of the software configuration of a ME.
An instance of UpgradePackage (UP) represents a specific change
of software configuration from the existing one to the new one identified by the attribute administrativeData. The execution of the change process described by UP class is the normal way to change the content of the SW inventory. An UP can be seen as a modification agent. It can add new, remove, or modify functionality. The sequence in which a Software upgrade executes is as follows:
1. Prepare
2. Verify, which is optional
3. Activate
4. Confirm
When the upgrade package MO is created the upgrade control file is downloaded to specify the administrative data and the activation steps for this upgrade.

This MO is created by the system.

References from:: SwM;

Actions
`boolean`	`activate ( );` Current upgrade package is taken into operation fully or partially. Partial activation occurs if the UCF defines activation steps and attribute ignoreBreakPoints is false. The ME upgrade engine notifies the operator that the activation step is completed. The next activation step starts when the operator invokes an activate action. Each UP must have at least 1 activation step. When attribute ignoreBreakPoints=true, all activation steps are executed in sequence. When an activation step is complete, the ME executes the next activation step. That means there is no operator invocation when an activation step is complete. The time for observation of correct operation of the ME, after each completed step, is always monitored by a supervision timer. The invocation of activate() can be monitored by a supervision timer. If the supervision timer expires before invocation of activate() or confirm(), the activation fails and the ME falls back to state PREPARE_COMPLETED. The action returns immediately after invocation. The progress of the action can be tracked by attribute progressReport. The action returns false if the action could not start for any reason, for example, another parallel action is in progress. In all other cases, it returns true. This action can be invoked when the state is PREPARE_COMPLETED or ACTIVATION_STEP_COMPLETED. If the action is invoked in a state where the action has no meaning, ME is expected to return an error message.
`boolean`	`cancel ( );` Cancel can be invoked during any long-lasting operation. Stops the operation and restores the consistent state that existed before the long-lasting operation started. Furthermore, cancel() can also be invoked when the UP is in state WAITING_FOR_COMMIT or ACTIVATION_STEP_COMPLETED without having a long-lasting operation in progress. Calling cancel() in this state orders the ME to restore the state that existed before the activation procedure started. The action returns immediately after invocation. The consequences of the action can be tracked by attribute progressReport. The action returns false if the action is refused by the ME. If the action is invoked in a state where the action has no meaning, the ME is expected to return false. In all other cases, it returns true. This action can be invoked when the UP state is PREPARE_IN_PROGRESS, ACTIVATION_IN_PROGRESS, ACTIVATION_STEP_COMPLETED, or WAITING_FOR_COMMIT.
`boolean`	`commit ( );` Action commit is deprecated, it is recommended to use action confirm. Stops the activation supervision timer (fallback timer) and confirms the upgrade. The action returns immediately after invocation. The progress of the action can be tracked by attribute progressReport. The action returns false if the action could not start for any reason, for example, another parallel action is in progress. In all other cases, it returns true. This action can be invoked when the state is WAITING_FOR_COMMIT. The CoreMW implementation of the commit action has always been ansynchronous. This is an deviation from the ECIM SwM commit which was an synchronous action. Deprecated: Action has been removed from ECIM SWM 4.2, deprecated in CmwSwM 5.1
`boolean`	`confirm ( );` Stops the activation fallback timer and confirms the upgrade. The action returns when the synchronous action is completed. This action can be invoked when the state is WAITING_FOR_COMMIT. The action returns true on success, false on failure.
`boolean`	`prepare ( );` Prepares the Managed Element for activation of the current upgrade package. Executing prepare() does not have any negative impact on the in-service performance of the Managed Element. The action returns immediately after invocation. The progress of the action can be tracked by attribute progressReport. The action returns false if the action could not start for any reason, for example, another parallel action is in progress. In all other cases, it returns true.
`boolean`	`verify ( );` Verifies the ability to activate the current upgrade package. The action returns immediately after invocation. The progress of the action can be tracked by attribute progressReport. The action returns false if the action could not start for any reason, for example, another parallel action is in progress. In all other cases, it returns true. This action can be invoked when the state is PREPARE_COMPLETED. If the action is invoked in a state where the action has no meaning, the ME is expected to return an error message.This action can be called as an option in the whole upgrade procedure. The action can be called more than once if required.

Attributes
`int32 noNotification readOnly`	`activationFallbackTimer = -1` The activationFallbackTimer is the maximum execution time of an activation operation. The activationFallbackTimer is fetched from the packageInfo.xml. The default -1 value denotes that the activation timer is disabled.
`ActivationStep[1..] readOnly`	`activationStep` List of activation steps in the activation procedure. It is possible to stop after each step, perform supervision, and continue with the procedure.The upgrade procedure consists of at least one activation step.
`ProductData[1..] readOnly`	`administrativeData` The product identification of the software versions that are activated when an upgrade is completed. If the resulting software version after activation is unknown or uncertain, the administrativeData can be empty.
`DateTime readOnly`	`created` Date and time this Upgrade Package instance is created.
`uint16[0..1] noNotification readOnly`	`creatorActionId = 0` The Id of the action that created this UpgradePackage MO. Default value 0 shows that the ME does not record this information.
`ExecMethod[0..1] noNotification`	`execMethod` The execution method of a specific UpgradePackage.
`boolean`	`ignoreBreakPoints = true` Influences the behavior of the activate() action. False means there is a breakpoint between each activation step. Activation process stops at each breakpoint. True means execution ignores breakpoints between activation steps and instead executes the end-to-end activation process. This invokes all activation steps in sequence, assuming no errors occur.
`EcimPassword[0..1]`	`password` Password to the server that provides the UpgradePackage.
`AsyncActionProgressWithSteps[0..1] readOnly`	`reportProgress` Represents the progress report, including the result, of the ongoing action. This MO supports only one action execution at a time.
`UpgradePackageState readOnly`	`state` Current state of Upgrade Package.
`string key mandatory noNotification restricted`	`upgradePackageId` Holds the name used when identifying the MO.
`string[0..1]`	`uri` A URI that points to the directory where the UP can be found. The URI can be local, for example, file://data/dir/subdir. It can also be remote, for example, ftp://hostname/dir/subdir.
`string[0..1]`	`userLabel` Free-text description of the Upgrade Package.

class UpgradePackage