Package Management

The fundamental set of information used to group a set of instructions and their possible dependencies is called a package. The Software Management application facilitates the creation of specialized packages that download and upload files and perform operations such as setting the value of a data item. For purposes of a Platform administrator, think of a package as containing the following sections:

For details about each of these application sections, click the section name. Not all agents support all features of packages. For complete information about the features of packages supported by agents, refer to Package Features Supported by Axeda Agents.

How Axeda® Agents manage packages

When the Agents receive packages, they queue packages that are scheduled to start later and run those that have no time setting. Agents can queue multiple packages, but they can process only one package at a time. If the Axeda Platform tries to run another package at the same time, the Agent returns an error status. From the Software Management application, you can cancel a package that is queued but not a package that is running. From the perspective of the Agents, a package contains only a header and a list of SOAP commands. Each command is processed sequentially and synchronously. The pre-process and in-process dependencies are packaged as SOAP commands as well. The Agents evaluate the Registry and Data Item dependencies. The Platform evaluates Package dependencies. The Agents communicate the status of the package to the Axeda Platform.

The possible statuses of packages follow:

§         Queued -- The Agent has received the package but has not started processing it.

§         Started -- The Agent has started processing the package.

§         Error -- The Agent has failed at some point during the processing. An error code and an identifier for the instruction that failed are included in the error message sent to the Platform.

§         Canceled -- The Agent received an asynchronous SOAP command that canceled the package.

§         Timed Out -- A package dependency timed-out, terminating the package.

§         Success -- The Agent successfully ran the package.

The Axeda® Platform has one additional status, which is Not Yet Queued, indicating that the Agent has not yet contacted the Platform.

Note: If retrying packages is enabled for the Platform, users creating or editing packages can select whether the package should be retried if its deployment fails. In addition, file upload actions initiated either by the Agent or by a user of the Axeda® Connected Product Management Applications are automatically retried.

For Axeda Gateway, Connector, and Agent Embedded Agents, if the package has a Restart instruction, and the Agent re-registers without going missing (in other words, restarts quickly), then pending package deployments are not retried.

If a restart is initiated when retries are exhausted, the asset deployment is marked by the Platform as Failed with the Platform error code "Retry Limit Exhausted".

See also  Retrying Package Deployments for more information.

What happens if an Agent shuts down?

If the Agent receives a shutdown message, the execution of the package is stopped. Any package upload or download in process is stopped. During shutdown, the Agent's ability to complete each package's commands successfully is unpredictable. An Agent shutdown can happen asynchronously from three sources: an action from the Axeda Platform, the EShutdown utility, or the Axeda Builder application.

If a file upload in progress when an agent shuts down was initiated by that agent using File Watcher, then the upload starts again when the agent restarts. Any upload/ or download operation that was initiated from the Axeda Platform and in progress when an agent shut down, either using a package or tasks or actions works exactly the same way.