When you create a cloud template in Automation Assembler, the resource type palette includes resource types for the supported cloud account and integration endpoints. You might have use cases where you want to create cloud templates based on an expanded list of resource types. You can create custom resource types, add them to the design canvas, and create cloud templates that support your design and deployment needs.

Custom resource name and resource type

The custom resource name identifies your custom resource inside the cloud template resource type palette.

The resource type of a custom resource must begin with Custom. and each resource type must be unique. For example, you might set Custom.ADUser as a resource type for a custom resource that adds Active Directory users. Although the inclusion of Custom. is not validated in the text box, the string is automatically added if you remove it.

Extensibility action custom resources

With custom resource types, you can use extensibility actions in cloud templates to build complex applications. For example, you can use the native integration of extensibility actions with Amazon Web Services and Microsoft Azure to easily integrate with their respective services. You can create extensibility action custom resources by clicking on the Based on option in the custom resource editor and selecting ABX user-defined schema.

Lifecycle actions for extensibility action custom resources

When using a extensibility action for your custom resource, you can define the following lifecycle actions:

  • Create: this extensibility action is called when a deployment is started.
  • Read: this extensibility action is used to retrieve the latest state of the deployed resource.
  • Update: this extensibility action is called when a cloud template property is updated. This action is triggered only when a property is not marked with recreateOnUpdate.
  • Destroy: this extensibility action is called when a deployment is deleted.

These lifecycle actions can either be selected manually from your existing extensibility actions or generated automatically by selecting Generate Actions. When you select Generate Actions you must specify the project in which the new extensibility action will be generated in.

Note: You can edit the extensibility actions associated with your lifecycle actions by clicking on the Open option next to the specific action.

Automation Orchestrator custom resources

Each Automation Orchestrator custom resource is based on a SDK inventory type and is created by a Automation Orchestrator workflow that has an output which is an instance of your desired SDK type. Primitive types, such as Properties, Date, string, and number are not supported for the creation of custom resource types.
Note: SDK object types can be differentiated from other Automation Orchestrator property types by the colon (":") used to separate the plug-in name and the type name. For example, AD:UserGroup is an SDK object type used to manage Active Directory user groups.
You can use the built-in workflows in Automation Orchestrator, or you can create your own. Using Automation Orchestrator to create anything-as-a-service/XaaS workflows means that you can create a cloud template that adds an Active Directory user to machines at deployment time, or add a custom F5 load balancer to a deployment. You can create Automation Orchestrator custom resources by clicking on the Based on option in the custom resource editor and selecting vRO inventory.

Automation Orchestrator custom resource external type

The external type property defines the type of your Automation Orchestrator custom resource. When you select a Create workflow in your custom resource type in Automation Assembler, the external type drop-down appears underneath it. The drop-down includes external type properties, that are selected from the output parameters of the Automation Orchestrator workflow. The selected workflow output properties included in the drop-down must be non-array SDK object types such as VC:VirtualMachine or AD:UserGroup.

Note: When creating custom workflows that use the dynamic type plug-in, verify that their variables are defined by using the DynamicTypesManager.getObject() method.

When you define your custom resource types, you also define the scope of the availability of the select external type. The selected external type can be:

  • Shared across projects.
  • Available only for the selected project.

You can only have one custom resource type with a specific external type value per defined scope. For example, if you create a custom resource in your project that uses VC:VirtualMachine as an external type, you cannot create another custom resource for the same project that uses the same external type. You also cannot create two shared custom resources that use the same external type.

Automation Orchestrator lifecycle action validation

When you add Create, Delete, and Update workflows as lifecycle actions to your custom resource, Automation Assembler validates that the selected workflows have correct input and output property definitions.

  • The Create workflow must have an output parameter that is an SDK object type, such as SSH:Host or SQL:Database. If the selected workflow does not pass the validation, you cannot add Update or Delete workflows, or save your changes to the custom resource.
  • The Delete workflow must have an input parameter that is an SDK object type that matches the external type of the custom resource.
  • The Update workflow must have both an input and output parameter that is an SDK object type that matches the external type of the custom resource.

Custom resource property schema

You can edit and view the custom resource properties schema by selecting the Properties tab. The schema includes the name, data type, property type, and, if it is available, the description of a given property. The schema also defines if a specific property is required or optional in the cloud template.
Note: For the property schema of extensibility action custom resources, all properties are required in the cloud template.
When you add Automation Orchestrator workflows to your custom resource, their input and output parameters are added as properties. For extensibility action custom resources, you must create the property schema of extensibility action custom resources manually in the Properties tab.
Note: The properties defined in the schema of extensibility action custom resources must also be returned values in the Read action of your custom resource and have the same names. For example, if your schema includes the properties domain and location, the Read action must also return the same properties with the same names.
From this tab, you can also modify and format the properties of your Automation Orchestrator or extensibility action based custom resources. For example, you can change the display name of a given property or add constraints.
Note: When adding constraints to either the item section of array fields or properties section of objects fields in the properties schema, verify that you have validated these constraints as incorrectly applied constraints can cause issues with the custom resource. For example, when adding a maximum constraint to a numbers array, you must verify that this constraint does not break the property's default value.

You can edit the property schema for custom resources by navigating to the Properties tab and using either the Code or Form tab.

  • Code: Edit the property schema by using YAML content. When selecting this option, the property schema is defined by using the JSON Schema.
  • Form: For extensibility action custom resources, by clicking New Property, you create a new property by configuring its name, display name, description, property type, and default value. For Automation Orchestrator custom resources, you can also hide non-required and non-computed properties from the schema by clicking Remove Property.

Day 2 Operation Custom Request Forms

You can streamline the request form of the day 2 operations included in your custom resource by adding and modifying different types of resource properties.

For example, you can bind the value of an input parameter in your request form to an external source, such as a Automation Orchestrator action that retrieves a deployment name or project name. You can also bind the value of a specific input parameter to the computed value of two other text boxes included in the same request form.

Note: This functionality is available for both custom resources and resource actions. You can customize the value of the input properties of your request form from the Values tab of the Request Parameters page of the custom resource or resource action editor.

Day 2 Operation Request Form Validation

You can validate the request form of your day 2 operations by adding an external validation. By using an external validation, you prevent the user from submitting the request form until the validation parameters are satisfied. You can add external validation from the Validations tab of the Request Parameters page of the custom resource or resource action editor. After selecting the tab, you can drag a Orchestrator validation element to the canvas and add a Automation Orchestrator action that you want to use for validation.

For example, you can create a custom resource that includes a day 2 operation for changing a user password. For such a use case, you can add a Automation Orchestrator action with newPassword and confirmPassword input parameters that use the SecureString type.

Note: This is a sample script for validating a user password. For your own use case, you can decide to use a different script. 
if (newPassword != confirmPassword) {
    return 'passwords are different';
}
if (newPassword.lenght < 7) {
    return 'password must be at least 10 symbols';
}
return null;