Unsupported content


This version of the product has reached end of support. The documentation is available for your convenience. However, you must be logged in to access it. You will not be able to leave comments.

Configuring service blueprint parameters

Service blueprint parameters are used to pass data to the software, scripts and BMC Atrium Orchestrator workflows included in the service blueprints.

This topic includes the following sections:

The following video (5:56) discusses the types of parameters you can include in service requests and where those parameters appear to end users in BMC Cloud Lifecycle Management.


Parameter levels

A cloud administrator can set parameters in the blueprint so that end-users are prompted  at the time of a request. In the following example, the end-user can modify the HTTP Port or the Webmaster Email with their own parameters.

Any field in bold with an asterisk ( * ) requires a value; otherwise, the system returns an error.

To provision an Apache server VM, the administrator configured two fields (HTTP Port and Webmaster Email) in the service blueprint that the end-user can enter or modify. The Parameters tab of the Service Properties dialog box is shown in the following figure.

As a cloud administrator, you can add parameters at the service blueprint level for one or more service blueprint definitions and  for applications that are associated with resource sets. You can also add parameters through Service Catalog options and option choices.

  • Parameters at the service blueprint level apply to all definitions of that service blueprint. The various BLPackages you can specify in a service definition (for example, OS and Software Packages under Components) might take parameters that can specify configurable options or settings, user names, or passwords. For more information about option choices that an end-user might choose, see Configuring end-user Option Choices in service blueprints.
  • Parameters at the definition level apply to a specific definition (for example, a Large definition that utilizes three tiers) but not to another (such as a Small definition with only one tier). The definition allows you to specify values for parameters expected by any of the packages (for example, with the NSH scripts or AO Workflows). You must know what parameters the packages expect and the names of the parameters when defining parameters in a definition.
  • Parameters at the application, server, and database instance levels allow end users to provide input for the software that is deployed as part of an application, server, or database. For example, if you are deploying an application that populates a database and sets up users for the database, the end user might be asked to provide names of users. To set up parameters, you must know what parameters the software expects and the names of the parameters. For more information about parameters for PaaS provisioning, see Using parameters in PaaS provisioning.
  • You can also add service blueprint parameters through Service Catalog options and option choices. For example, instead of having an Apache Service Offering and Blueprint, you can offer the end-users a RedHat service offering and give them the choice to add Apache as an option. As part of the option fulfillment, the cloud administrator can specify parameters that the user enters or that are automatically set when someone selects that option.

Within a level, parameters must have a unique name, unless all parameters in the blueprint with that name have an identical value. For example, if you have a parameter called AmazonOption specified for a definition, you can have another AmazonOption parameter specified elsewhere in that definition only if the values are identical. If the names are the same, but the values are different, the Service Designer presents a validation error for you to correct. Be aware that blueprints in the Blueprint Library might contain their own parameters. If you reuse a blueprint, its parameters might conflict with the parameters defined elsewhere in the reusing service blueprint.

Order of precedence

Service blueprint parameters have an order of precedence:

  1. If you create parameters at the service blueprint level with the same name as a parameter for a definition, the parameters in the definition take precedence.
  2. If you create parameters with the same name in the service blueprint and Service Option attached as a Day 1 option to a given service offering, the parameters in the Service Option take precedence.

Before you begin

To support service blueprint parameters when provisioning servers, you must:

To support service blueprint parameters for platform-as-a-service (PaaS) provisioning, you must:

To configure parameters

In the Service Designer workspace, open a service blueprint for editing and do one of the following:

If you want to configure parameters...Then...
At the service blueprint level

Select Service Properties > Parameters.

At the definition levelSelect Definition > Parameters.
At the application levelSelect an application and then click Parameters in the edit pane.
At the server levelSelect a server and click Parameters in the edit pane.
At the database instance levelSelect the instance and click Parameters in the edit pane.

Take the following steps to define the parameter:

  1. In the Parameters table, click .

  2. Enter a parameter name.
    This field is required.
  3. Enter a user friendly display label.
    This field is required. The end user sees this label when the package is provisioned instead of the parameter name.
  4. Enter a short description.
    This information appears as a tooltip.


    If you are building a parameter for a password with regular expression validation, make sure that you provide a description that informs the user about the requirements of the password. For example, you might require the password to contain at least one numeral. When the Regular Expression field contains a string, and the Password field is checked, the description is displayed to the user if validation fails for an entered password.

  5. Select the appropriate data type (for example, StringNumericBoolean or Token) that controls the input menu type.
    Depending on which data type you select, only specific options are available. For example, if you select Boolean, only the Default ValueUser Entry Enabled, and Required options are available. You cannot modify data types later. If you are creating a Token parameter, see detailed instructions in the Passing deployment data using tokens page.
  6. In the Default Value field, enter the the appropriate value (for example, the default value if you storing user input).
    For example, enter the default value that the end user will see during the request, or the value used with parameters (when User Entry Enabled is not selected). Make sure that you enter appropriate values per data type. There is no validation checking in the UI other than the Regular Expression pattern. However, the Numeric data type will not let you enter non-numeric values. If you select Boolean, you can only choose {true} or {false} as the default value.
  7. In the Regular Expression field, enter the pattern text that the parameter value must match for validation.
    For example, if you want the parameter value to consist only of alphabetical characters, enter \[a-zA-Z\]\ as the String values. You can use Regular Expression with String or Numeric data types, but not Boolean.
  8. Select Ignore Case to only compare character sequence.
    For example, you would select Ignore Case if ABC and abc are both considered valid matching patterns.
  9. Click User Entry Enabled to prompt the user to enter the value during provisioning.
    This action allows the end-user to specify an input and, if needed, override the default value.
    1. Click Required if input is mandatory.
    2. Click Password Field for password-style input (where the values are not displayed).
      The password values are initially displayed as you enter them. But after you save the parameters, they are then masked as asterisks.
      The Password Field is independent of the User Entry Enabled field. You can mask the default value even if User Entry Enabled is not selected.

Related topics

Onboarding and offboarding compute resources 
Creating, copying, or editing a service blueprint     
Predefined IBM LPAR parameters
Passing deployment data using tokens

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.