Working with Actions

As an Application Developer, you use the Action Builder plug-in to create Actions (sets of objects) for common operations to be used in Workflows.

Watch this introductory video to get a quick overview of the Action Builder:

Important! The actions that you can perform depend on your folder permissions, see: Folder Permissions.

This page includes the following:

About Actions & Action Packs

What are Actions?

Actions are pre-defined tasks for executing single operations as part of the Workflow. They simplify constructing Workflows by providing reusable, ready-to-use, and tested building blocks for frequently needed operations.

Actions cover different areas of critical data center operations and help you to automate simple and complex tasks. Examples of simple actions are checking file system operations or permission on Windows, UNIX and Linux. Some of the more complex actions include creating websites, web applications, and application pools for various platforms like IIS, JBoss, Tomcat, or Websphere.

Because Actions are parametrized with prompts for input values, they can be applied in various workflows.

Structure of Actions

An Action consists of all of the following:

Furthermore, most Actions specify a rollback task that is executed if the workflow containing the Action fails.

Note: Actions are stored in the Automation Engine. Although they could be built in the Automation Engine directly, you would need to create many objects manually. The Action Builder provides means to create a skeleton for new Actions in a comfortable, integrated user interface.

Action Folder Structure

Within the Action Pack SOURCE folder, a folder for the Action is created. Beneath this folder, several sub-folders containing objects that are referenced by the Action are also created:

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

For example, the Tomcat Action Pack (which is available at https://marketplace.automic.com/) lets you automate application deployments to a Tomcat application server. The Tomcat Action Pack contains the following actions:

Creating CLI Actions

Watch the video:

Important! The following components have to be installed on the client before creating CLI Actions:

To Create CLI Actions

  1. Navigate to the Process Assembly perspective and click the Packs tab.
  2. Click the Pack where you want to create the Action or create a new one. For more information, see the Creating Packs section.
  3. Click Add Action. The Add Action window is displayed.
  4. Select the CLI Action type (Command Line).
  5. Enter a Title for the Action. The Name for the Action is suggested automatically.
  6. Enter a new Category for the Action or select an existing one from the drop-down list. Categories are used to group and easily find the Actions and are displayed on the Actions tab.
  7. Click Next to confirm the creation of the Action.
  8. Re-validate your input and click Add to create the Action.

Notes:

Creating REST Actions

REST Actions can be created, for example, to trigger a TeamCity build via CDA REST API. For more information, see CDA REST API - General Info.

Graphic depicting REST action logic

Watch the video:

Important! The following components have to be installed on the client before creating REST Actions:

Note: These components are available from https://marketplace.automic.com/.

To Create REST Actions

  1. Navigate to the Process Assembly perspective and click the Packs tab.
  2. Click the Action Pack where you want to create the Action or create a new one. For more information, see the Creating Packs section.
  3. Click Add Action. The Add Action window is displayed.
  4. Select the REST Action type (REST).
  5. Enter a Title for the Action. The Name for the Action is suggested automatically.
  6. Enter a new Category for the Action or select an existing one from the drop-down list. Categories are used to group and easily find the Actions and are displayed on the Actions tab.
  7. Click Next. The Add Action dialog is displayed.
  8. Select the Authentication type for the endpoint. None is selected by default.

    Note: The following authentication methods are available: None, Basic, Digest, NTLM, OAuth 1.0a, OAuth 2.0, AWS Signed URL.

  9. Click Add to create the Action.

Notes:

Creating Composite Actions

Sometimes you may want to create Actions which make sense not only on their own, but also with other Actions. This is where Composite Actions come into play. They avoid wiring work for every new instance of that combination.

Watch the video:

To Create Composite Actions

  1. Navigate to the Process Assembly perspective and click the Packs tab.
  2. Click the Pack where you want to create the Action or create a new one. For more information, see the Creating Packs section.
  3. Click Add Action. The Add Action window is displayed.
  4. Select the Composite Action type.
  5. Enter a Title for the Action. The Name for the Action is suggested automatically.
  6. Enter a new Category for the Action or select an existing one from the drop-down list. Categories are used to group and easily find the Actions and are displayed on the Actions tab.
  7. Click Next to confirm the creation of the Action.
  8. Re-validate your input and click Add to create the Action.

Notes:

Cloning Actions

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

Note: Cloning an Action results in all objects that directly belong to it (Includes, PromptSets, Workflows) to be copied. Cloned Actions can be used independently.

To Clone Actions

  1. Go to the Process Assembly perspective, click the Packs accordion tab in the sidebar.
  2. Select an Action Pack. The list of available Actions is displayed.
  3. Right-click an Action to select Clone. The Clone Action dialog is displayed.
  4. Select the Pack where you want to save the cloned Action.
  5. Optionally, change the title for the cloned Action.
  6. Click Clone.
  7. The cloned Action is displayed in the list.  

Deleting Actions

  1. Go to the Process Assembly perspective and click an Action Pack.
  2. Select an Action and click Delete.

Using Inline Documentation for Actions

  1. Go to the Process Assembly perspective and click an Action Pack.
  2. Double-click an Action.
  3. Open the Documentation tab.

Troubleshooting

Error:

An error message is displayed when running a Runbook Action with Powershell v >=3.0. For example:

__uc_return : The term '__uc_return' is not recognized as the name of a cmdlet, function, script file, or operab

path is correct and try again.

At C:\temp\test.ps1:75 char:3

+ __uc_return( 9999 )

+ ~~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (__uc_return:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

Solution:

Add the following if script (in bold) to the HEADER.WINDOWS.USER.HEAD object to ensure that your actions can execute with all versions of PowerShell:

if ($PSVersionTable.PSVersion.Major -le 2)

{

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetField"

$objectRef = $host.GetType().GetField("externalHostRef", $bindingFlags).GetValue($host)

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetProperty"

$consoleHost = $objectRef.GetType().GetProperty("Value", $bindingFlags).GetValue($objectRef, @())

[void] $consoleHost.GetType().GetProperty("IsStandardOutputRedirected", $bindingFlags).GetValue($consoleHost, @())

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetField"

$field = $consoleHost.GetType().GetField("standardOutputWriter", $bindingFlags)

$field.SetValue($consoleHost, [Console]::Out)

$field2 = $consoleHost.GetType().GetField("standardErrorWriter", $bindingFlags)

$field2.SetValue($consoleHost, [Console]::Out)

}

See also: