Working with Packs and Plug-ins

As an Administrator, you can install Packs and Plug-ins to enhance the CDA functionality and allow integrations with third-party products. Packs and Plug-ins integrated into AWI can be managed from the user interface (by using the Plugin Manager plug-in) or via the Package Manager CLI. To know how to manage CDA plug-ins for third-party products see: Working with CDA Plug-ins for third-party products

Graphic depicting dependencies of Action Builder, Package Manager, Plugin Manager, content artifacts and Marketplace

This page includes the following:

About Packs and Plug-ins

What are Packs?

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

What are Action Packs?

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/ASO client.

Pack Folder Structure

ARA Application Pack

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. See: Working with CDA Entities as Code.

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

Viewing Packs

Packs can be accessed:

Installing, Upgrading and Importing Packs

The predefined Action Packs that let you incorporate different actions into release workflows are available at https://marketplace.automic.com/.

Important! An imported Application Pack is only compatible with the exact same version of the Action Packs used in the origin system.

To Install a Pack (GUI)

On the Administration perspective, go to Packs and select Install Pack. Press the Upload button, navigate to the location where you have downloaded the Pack and follow the instructions of the wizard.

After the installation is complete, the new Action Pack can be found in the PACKAGES folder of the Process Assembly perspective.

Notes:

Some Packs may contain AWI plug-ins, which are installed together with the Pack. To check if the Plug-in has been registered correctly do one of the following:

Application Pack Installation

After installing an Application Pack, the new Application and its related entities will be available in the Release Automation perspective.

Note:

To Install a Pack (CLI)

Use the following command to install a Pack:

apm install <pack name> -pw <password>

Alternatively, you can install a Pack from a file:

apm install --from-file <path to the pack archive or directory> -pw <password> -u user/department

Notes:

Examples

Single Pack installation:

apm install --from-file C:\Pack.Bond_PCK.AUTOMIC_BOND_1_0_0+build.164.zip -pw aepwd -u ADM/ADMINISTRATORS

Multiple Pack installation:

apm install PCK.AUTOMIC_HTTP PCK.AUTOMIC_FTP -H automicdev -S AUTOMIC -p 1234 -c 123 -u AUTOMIC/AUTOMIC -pw aepwd

Important! The installation of a Pack may be restricted to a limited number of clients. You can use the option -c <number> to change the target client of the installation or enter the following command to bypass the client check: --ignore-client-restriction.

To Upgrade a Pack (CLI)

Use the following commands to upgrade Packs:

Command for updating the Pack index (to be run only once):

Important! Upgrading a Pack may be restricted to a reduced number of clients. You can use the option -c <number> to change the target client of the upgrade or enter the following command to bypass the client check: --ignore-client-restriction.

When updating a Pack , be aware of the following:

Creating Packs

Before creating an Action Pack, the following should be defined:

The following graphic depicts the typical workflow when creating an Action Pack:

Graphic depicting typical workflow when creating action packs

To Create an Action Pack

  1. Under the Process Assembly perspective, click the Action Packs accordion tab in the sidebar.
  2. Select Create Action Pack. The New Action Pack dialog is displayed.
  3. Enter a title for the Action Pack. The name for the Action Pack is suggested automatically. The name consists of the following parts:
    • PCK.CUSTOM (prefix). The prefix can be configured via the actionbuilder.properties file. For more information, see Installing the Action Builder.
    • Title of the Action Pack.

  4. Select Create Action Pack.

Note: It is good practice to provide information to others in the documentation object of the Action Pack to help identify your content. It can be found in the Documentation folder of the Pack in the Explorer.

Creating Application Packs

Important!

  1. Go to the Release Automation perspective.
  2. Do one of the following:
    • Right-click an Application and select one of the following options:

      • Add to Application Pack

        Click it to create a new Application Pack.

      • Application Pack > Save

        If a Pack for this Application already exists, this option is shown instead. Click it to update the information that is contained in the Pack.

    • Double-click an Application to open it and click the Properties tab.

      Click the Application Pack drop-down in the toolbar and select Save.

  3. Enter a new title (name) for the Application Pack or edit the existing one:

    • The recommended naming convention is PCK.APP.[Application Pack Name]
    • Name/Title fields can contain up to 255 characters
    • The name must be unique and may only contain alphanumeric characters, ".", "-", "_", "@", "$", "#"
    • Special characters and space characters are not supported. They are replaced by underscores.
  4. Click Add/Save.
    • Saving your changes creates a new minor version of the Pack. For example: 1.0.0 > 1.1.0
    • If the Application uses objects that are stored outside the Application folder or that are not related to any Action Pack, you are prompted to confirm the creation of the Application Pack without the objects. Alternatively, you can cancel the creation process, add the objects to the Application folder, and start again.
    • The new Application Pack is created in the PACKAGES folder of the Process Assembly perspective

Notes:

Creating Template Action Packs for Component Workflows

Templates for component workflows can be easily distributed and installed on different CDA systems by using CA Automic Package Manager.

Note: The Action Builder must be installed and configured.

To Create a Template Action Pack for Component Workflows

  1. Create the Action Pack structure:
    1. Go to the Process Assemblyperspective and click the Action Packs accordion tab in the sidebar.
    2. Click Create Action Pack. The New Action Pack window is displayed.

    3. Enter a title for the Action Pack (for example: Component Workflow Template). The name for the Action Pack is suggested automatically.

      Image displaying New Action Pack dialog

    4. Click Create Action Pack.
  2. Clean up and define the Action Pack metadata:
    1. Switch to the Explorer.
    2. Navigate to the Action Pack, located in the PACKAGES sub-folder.
    3. Delete the following folders:
      • ACTIONS
      • RESOURCES and its subfolders.
      • SOURCE (this folder should only be deleted if not needed. Please note that the sub-workflows (SOURCE/SHARED/JOBP) and PrompSets (SOURCE/SHARED/PROMPTSETS) are stored here).
    4. Delete the VARA object located in the CONFIG folder (for example: PCK_CUSTOM_COMPONENT_WORKFLOW_TEMPLATE.PUB.PROMPT_EXTERNAL.MAP).
    5. Add a new XML VARA object:
      1. Click Add Object.
      2. Name it PCK.<pack-name>.PUB.INTERFACE (for example: PCK.CUSTOM_COMPONENT_WORKFLOW_TEMPLATE.PUB.INTERFACE)
      3. Optionally, enter a title.
      4. Click Rename.

      5. Click Add Key to create a new key and name it Interface.

      6. Click the new key and add the following XML-structure to list the Workflow Templates with the corresponding settings for the component custom type:

        <interface>

        <templates>

        <add-templatekey="ARA.INSTALL.<CustomType>(.DEFAULT)">PCK.<pack-name>.PUB.TEMPLATE.INSTALL.<WF-name>(.DEFAULT)</add-template>

        <add-templatekey="ARA.UNINSTALL.<CustomType>(.DEFAULT)">PCK.<pack-name>.PUB.TEMPLATE.UNINSTALL.<WF-name>(.DEFAULT)</add-template>

        </templates>

        For example:

        Install key=<add-templatekey ="ARA.INSTALL.TOMCAT.DEFAULT">PCK.CUSTOM_COMPONENT_WORKFLOW_TEMPLATE.PUB.TEMPLATE.INSTALL</add-template>

    6. Go to the Action Pack main folder (for example: PCK.CUSTOM_COMPONENT_WORKFLOW_TEMPLATE).
    7. Open the metadata VARA object (for example: PCK.CUSTOM_COMPONENT_WORKFLOW_TEMPLATE.PUB.VAR.METADATA) and redefine the files if needed.

      1.  In the Dependencies row enter any dependent Action Pack. (An Action Pack depends on another if Actions of this Action Pack are used inside the Template workflow).

      2. Optionally, enter a description for the Action Pack.

    8. Open the DOCUMENTATION folder and double-click the PUB.DOC DOCU object.

    9. Click the Documentation accordion tab and enter any general information that may be helpful to use the Action Pack.

    10. Back to the DOCUMENTATION folder, open the PUB.LICENSES DOCU object an enter any relevant information related to licensing (for example: this Action Pack may not be modified).
  3. Create template workflows:
    1. Open the TEMPLATES folder.
    2. Click Add Object.
    3. Unfold the Workflow (_FLOWS) object and select COMPONENT_FLOW Workflow.
    4. Click Add Object. The Rename Object dialog is displayed.
    5. Enter the same names as those specified in the XML VARA object and set the title accordingly.

    6. Use the Process Assembly to design the template workflows by dragging and dropping the desired Actions into the workflow and setting the parameters.

      Note: A copy of an existing component workflow can be used as a starting point to design a workflow template.

      Important! The keys specified in the interface-XML must follow the aforementioned structure. Workflow names must follow the naming conventions too.

  4. Export the Action Pack:

    Packs can be exported in the Process Assembly perspective to be reused in another client or system.

    Important! When exporting a Pack, ensure that the metadata contains the correct values. It is good practice to increase the version number with subsequent releases of your Pack to distinguish between different versions. The version number can be set in the Metadata object of the Pack.

    To Export an Action Pack

    1. On the Action Packs page of the Process Assembly perspective, right-click the relevant Action Pack and select Export.

    2. On the Export Action Pack window, select Export to automatically validate and build the Pack.

    3. Select Download to download the Pack and select a destination.

    A semantic check is performed before exporting the Action Pack, thus ensuring that the Actions are defined correctly. The following properties are checked:

    • Generate Job at = Runtime
    • Deactivate on Finish = After error-free execution.
    • Error-free status = ANY_OK
    • Overwrite Agent's value = “&AGENT#“ or leave it empty

    Note: It is not recommended to export Action Packs with a hard-coded Agent/Login set.

    This Action Pack can be used to install the created workflow template into another CDA systems.

    Note: Templates can only be used in the same AE/ARA-System where the Action Pack was created if they are installed via the Package Manager.

Configuring Sync Interval of Application Packs

After installing an Application Pack, the new Application and its related entities will be available in the Release Automation perspective.

The synchronization interval between the Application Pack installed in the Automation Engine and the CDA system can be configured in the Application section of the customer.config file (Automic\Release.Manager\WebUI\customer.config). See: Configuring the Web Application - Customer.Config.

Exporting Packs

Packs can be exported in the Process Assembly perspective to be reused in another client or system.

Important! When exporting a Pack, ensure that the metadata contains the correct values. It is good practice to increase the version number with subsequent releases of your Pack to distinguish between different versions. The version number can be set in the Metadata object of the Pack.

To Export an Action Pack

  1. On the Action Packs page of the Process Assembly perspective, right-click the relevant Action Pack and select Export.

  2. On the Export Action Pack window, select Export to automatically validate and build the Pack.

  3. Select Download to download the Pack and select a destination.

A semantic check is performed before exporting the Action Pack, thus ensuring that the Actions are defined correctly. The following properties are checked:

Note: It is not recommended to export Action Packs with a hard-coded Agent/Login set.

To Export an Application Pack

Applications that have already been added to an Application Pack can be exported.

Cloning Packs

The cloning functionality of the Action Builder allows you to save time when creating Packs which are similar to existing ones.

Important! Action Packs can only be cloned provided the SEARCH_SCRIPT_FOR_USAGE setting in the UC_CLIENT_SETTINGS Vara is set to Y. For more information, see the Prerequisites table in Installing the Action Builder.

Note: Cloning an Action Pack results in all Actions and objects that directly belong to it (Includes, Prompsets, Workflows) to be copied.

To Clone Packs

  1. On the Action Packs page of the Process Assembly perspective, right-click the relevant Action Pack and select Clone.

  2. (Optional) Change the title for the cloned Action Pack.

    Tip: It is recommended to enter a descriptive name because the title helps you and others to better identify the purpose of the Action Pack.

  3. Enter a Name. A prefix is automatically added by the system to adhere to the Action Packs' naming conventions.

    Note: Prefixes can be configured via the action.builder file.

The cloned Action Pack is displayed on the list.

Deleting Packs

To Delete a Pack (GUI)

On the Packs page of the Administration perspective, right-click the Pack you want to delete and select Remove.

To Delete a Pack (CLI)

Use the following commands to remove Packs:

Note: Deleting an Application Pack will not remove the imported Application, its Components or definitions from the system.

Getting Help and Further Commands (CLI)

For more details on sub-commands, options and syntax, refer to the built-in help.

Command Structure

The APM CLI uses a multipart structure. Each command consists of:

All APM commands have the following syntax:

apm <command> [option] [<arguments>]

Passwords

Passwords can be specified with the following commands: -pw or --password.

Important! The values will not be displayed in the command line while typing.

Common Options

The following options are available for all APM commands:

Common Options for Automation Engine Connection Commands

Get Help for a Command

For details on commands, call apm <command> -h or apm <command> --help.

Find more Commands

For a list of available commands, call apm -h or apm --help.

Analyze and Display Current Environment Issues

apm doctor check

Fix Current Environment Issues Detected by the Doctor Check Command

apm doctor fix

Note: Extended Packs: run this command if you want to scan for and update missing hooks and VARA objects of base Packs.

Display Pack Content

apm show [option] <pack_name>

Where [option] can be one of the following:

Download Packs

Download Packs from the Automation Engine client to the working directory.

Important! A package.yml file must exist in the current working directory. If the file does not exist, call the following command to create it: apm init <pack_name>

apm download [option]

Where [option] can be one of the following:

Upload Packs

Upload Packs from the working directory to the Automation Engine client.

Important! A package.yml file must exist in the current working directory. If the file does not exist, call the following command to create it: apm init <pack_name>

apm upload [option]

Where [option] can be one of the following:

Working with CDA Plug-ins for third-party products

You can download the CDA plug-ins from: https://marketplace.automic.com/.

Refer to the CDA Plug-ins for Third-Party Products section for more information about how to install and manage the CDA plug-ins.