About Packs and Plug-ins

Packs contain Actions or Plug-ins that allow you to enhance the functionality of your system and to integrate third-party products. You can create your own Actions or download Packs and Action Packs from our marketplace. You can do so either from the Automic Web Interface or using a Command Line Interface (CLI).

This page includes the following:

Prerequisites

To install, upgrade or remove Packs using the Automic Web Interface you have to install and configure the Plugin Manager. Otherwise, the Packs page is not displayed in the Administration perspective. For more information, see Configuring the Plugin Manager.

To install, upgrade or remove Packs using the Command Line Interface (CLI) you have to install and configure the Package Manager. For more information, see Installing and Configuring the Package Manager.

To create Actions you have to install and configure the Action Builder. For more information, see Configuring the Action Builder.

More information:

Marketplace

We build, test and continuously release new Action Packs that you can access with a valid CA/Broadcom account through our marketplace.

Our marketplace is also a platform for our user and business-partner community to share Action Packs that they have created for specific needs. You can take advantage of their experiences and efforts, as well as contribute with your own Action Pack solutions.

Check our marketplace regularly, also between releases, to see what new Action Packs we or our community have uploaded. See https://marketplace.automic.com/.

Packs and Action Packs

The currently supported plug-ins are known as Packs. These plug-ins consist of Automation Engine objects and may include CDA-specific objects.

Action Packs are outbound integrations with third-party products such as Amazon S3, Docker, and Tomcat for automation purposes. They group actions that are related to each other (for example, Windows File System Actions) and are always imported and exported as a single unit to an existing CDA client.

Folder Structure - Packs

A Pack consists of the following folders:

  • <PACKAGE_NAME>

    Top-level folder containing all Action Pack content

  • ACTIONS

    Actions contained in the Pack.

  • CONFIG

    Static VARA objects, PromptSet objects and any other objects that are used to store the configuration

  • DOCUMENTATION

    Documentation objects containing license and pack documentation

  • RESOURCES

    Pack resources that are used across multiple Actions.

  • INTERPRETERS

    Storage object containing binaries of external interpreters

  • LIBS

    Storage object containing binaries such as Java JAR files or compiled libraries

  • SCRIPTS

    Script objects where external, interpreted scripts are stored

  • SOURCE

    Internals for each Action such as sub-workflows, Jobs, Script objects, VARA objects, and so on.

  • TEMPLATES

    Template Workflows, which are registered in the UC_OBJECT_TEMPLATE. Actions from other Packs on which the current Pack depends can also be incorporated into this Folder.

Packs can be imported and exported in two different formats:

  • .xml (old, compatible with former versions of CDA) and
  • .json (new, compatible with v12.3 and higher).

You can define which format to use either in the PACKS_COMPATIBILITY_MODE parameter of the UC_CLIENT_SETTINGS or by adding the corresponding option in the apm download command (Package Manager).

More information:

Types of Packs

Packs, Action Packs, Shared Component Packs and Application Packs are classified in categories to help you identify their purpose. You use the Category field to filter for Packs in the marketplace. You see the category of a Pack in the Packs view of the Administration perspective.

Application Packs always have the Application category. Packs and Action Packs may have, among others, the following categories: Network, Download, SCM, Versioning and so on.

When you create your own Pack (custom Packs), you can assign it a category in its METADATA VARA object.

CDA Application Packs

You can create an Application Pack out of an existing Application and export/import the Pack via Plugin Manager/Package Manager or, alternatively, via a code editor integrated with GIT and the REST client.

When you create an Application Pack, the serialized content of the CDA Applications and its related components is stored in the ARA.APPLICATIONS folder of the Process Assembly perspective. The Application Packs are stored under PACKAGES in the same view. The CDA content (Application, Components...) is saved in a storage object of the Application Pack.

For more information, see Creating Application Packs.

See also: