Configure general settings, create properties, and write custom action scripts to install, configure, update, or uninstall your Software component on provisioned machines.

As a software architect, click Design > Software components and click the Add icon to create a new Software component.

New Software General Settings

Apply general settings to your Software component.

Table 1. New Software General Settings




Enter a name for your Software component.


Using the name you specified for your Software component, vRealize Automation creates an ID for the Software component that is unique within your tenant. You can edit this field now, but after you save the blueprint you can never change it. Because IDs are permanent and unique within your tenant, you can use them to programmatically interact with blueprints and to create property bindings.


Summarize your Software component for the benefit of other architects.


On the design canvas, blueprint architects can only place your Software component inside the container type you select.

  • Select Machines to require architects to place your Software component directly on a machine component in the design canvas.

  • Select Software components if you are designing a Software component that should never be placed directly on a machine component, but can be nested inside one of several different Software components.

  • Select a specific published Software component if you are designing a Software component specifically to nest inside another Software component that you created.

  • Select Azure Virtual Machine if you are designing a Software component specifically for an Azure blueprint.

New Software Properties

Software component properties are used to parameterize scripts to pass defined properties as environment variables to scripts running in a machine. Before running your scripts, the Software agent in the provisioned machine communicates with vRealize Automation to resolve the properties. The agent then creates script-specific variables from these properties and passes them to the scripts.

Table 2. New Software Properties




Enter a name for your Software property. Property names are case-sensitive and can contain only alphabetic, numeric, hyphen (-), or underscore (_) characters.


For the benefit of other users, summarize your property and any requirements for the value.


Software supports string, array, content, boolean, and integer types. For a detailed explanation of supported property types, see Property Types and Setting Options. For information about property bindings, see When Your Software Component Needs Information from Another Component and Creating Property Bindings Between Blueprint Components.


  • To use the value you supply:

    • Enter a Value.

    • Select Required.

    • Deselect Overridable.

  • To require architects to supply a value:

    • (Optional) Enter a Value to provide a default.

    • Select Overridable.

    • Select Required.

  • Allow architects to supply a value or leave the value blank:

    • (Optional) Enter a Value to provide a default.

    • Select Overridable.

    • Deselect Required.


Mark properties as encrypted to mask the value and display as asterisks in vRealize Automation. If you change a property from encrypted to unencrypted, vRealize Automation resets the property value. For security, you must set a new value for the property.


If secured properties are printed in the script using the echo command or other similar commands, these values appear in plain text in the log files. The values in the log files are not masked.


Allow architects to edit the value of this property when they are assembling an application blueprint. If you enter a value, it displays as a default.


Require architects to provide a value for this property, or to accept the default value you supply.


Values for computed properties are assigned by the INSTALL, CONFIGURE, START, or UPDATE life cycle scripts. The assigned value is propagated to the subsequent available life cycle stages and to components that bind to these properties in a blueprint. If you select Computed for a property that is not a string property, the property type is changed to string.

New Software Actions

You create Bash, Windows CMD, or PowerShell action scripts to specify exactly how components are installed, configured, uninstalled, or updated during deployment scale operations.

Table 3. Life Cycle Actions

Life Cycle Actions



Install your software. For example, you might download Tomcat server installation bits and install a Tomcat service. Scripts you write for the Install life cycle action run when software is first provisioned, either during an initial deployment request or as part of a scale out.


Configure your software. For the Tomcat example, you might set the JAVA_OPTS and CATALINA_OPTS. Configuration scripts run after the install action completes.


Start your software. For example, you might start the Tomcat service using the start command in the Tomcat server. Start scripts run after the configure action completes.


If you are designing your software component to support scalable blueprints, handle any updates that are required after a scale in or scale out operation. For example, you might change the cluster size for a scaled deployment and manage the clustered nodes using a load balancer. Design your update scripts to run multiple times (idempotent) and to handle both the scale in and the scale out cases. When a scale operation is performed, update scripts run on all dependent software components.


Uninstall your software. For example, you might perform specific actions in the application before a deployment is destroyed. Uninstall scripts run whenever software components are destroyed.

Select the Reboot checkbox for any script that requires you to reboot the machine. After the script runs, the machine reboots before starting the next life cycle script. Verify that no processes are prompting for user interaction when the action script is running. Interruptions pause the script, causing it to remain in an idle state indefinitely, eventually failing. Additionally, your scripts must include proper exit codes that are applicable to the application deployment. If the script lacks exit and return codes, the last command that ran in the script becomes the exit status. Exit and return codes vary between the supported script types, Bash, Windows CMD, PowerShell.

Script Type

Success Status

Error Status

Unsupported Commands


  • return 0

  • exit 0

  • return non-zero

  • exit non-zero


Windows CMD

exit /b 0

exit /b non-zero

Do not use exit 0 or exit non-zero codes.


exit 0

exit non-zero;

Do not use warning, verbose, debug, or host calls.