Passing deployment data using tokens

When creating service blueprints, you can use deployment data such as hostnames and IP addresses in your software packages and post deployment actions using tokens. This capability lets you easily deploy complex, high value services with parameters that are dynamically evaluated at runtime.

This topic includes the following sections:

• • Overview
  • Before you begin
  • Including a pre-defined parameter token in a service blueprint
  • Creating a custom token
  • Token examples
  • Where to go next

Overview

You can define parameters as part of a service blueprint and at the option level for a particular resource set.

You can also use parameter tokens, such as HostName and IP address, that are defined or assigned in another resource set in the same blueprint. These tokens are applicable for software deployment, BMC Atrium Orchestrator workflows, SQL scripts or other scripts supported that BMC Database Automation supports as Actions, or any deployment scripts (such as BMC Server Automation NSH scripts).

The Custom Resource token patch type is not supported.

For example, consider the following scenario:

• A service blueprint has a definition with a resource set that installs BMC AR System Mid-tier. This resource set requires the hostname of the BMC AR System server that was installed previously as a part of the initial resource set deployment in the same blueprint.
• Create a hostname variable in BMC Server Automation. The hostName variable is defined as a local property in the BMC Server Automation package that deploys the BMC AR System Mid-tier resource set.
• When defining the resource set for the mid-tier deployment, create a token that obtains the hostname from the previous resource set which installed the BMC AR System Server.
• The BMC AR System Server deployment passes the AR hostName as a value to the hostname variable in BMC Server Automation.

Before you begin

• For information about setting up parameters in BMC Server Automation, see Parameterizing-BLPackages-by-adding-local-properties and Parameterizing-NSH-scripts.
• For information about setting up parameters in BMC Database Automation, see Using parameters in PaaS provisioning .
• For information about sequencing the application deployments as part of a service blueprint definition, see Creating-copying-or-editing-a-service-blueprint.

Including a pre-defined parameter token in a service blueprint

1. In the Service Designer workspace, open a service blueprint for editing.

2. Do one of the following:

   If you want to configure parameters...	Then...
   At the service blueprint level	Select Service Properties > Parameters.
   At the definition level	Select Definition > Parameters.
   At the server level	Select a server within a server group and then click Parameters in the edit pane.
   At the application level	Select an application and then click Parameters in the edit pane.
   At the database instance level	Select a database instance and then click Parameters in the edit pane.

3. In the Parameters table, click New .
4. Enter a unique parameter name. This name must be the same name as the one used in a BMC Server Automation package or script or in a BMC Database Automation template or Action. For example, if the parameter in the BMC Server Automation component template has a name of domainControllerName, then you must use the same name as the parameter in BMC Cloud Lifecycle Management.
5. Optionally, in the Label field, enter the name that is displayed to the end user for this parameter.
6. Optionally, enter a short description for your reference.

7. Select a data type of Token.

   Note

   You cannot modify data types later.

   The Token type option is displayed.

8. Select the Token Type. Depending on which token type you select, only specific options are displayed. The options are combined to build the path of the attributes included in the resource set that uses the token. The following token types are available, each with applicable sub-options:

9. Optionally, click Required Value.

   Note

   If you choose to make the parameter required, then there must be a value for the token, otherwise the related action will fail. Also, if this option is not marked as a Required Value but is required in BMC Server Automation or BMC Database Automation, the related action would fail if the evaluation of token does not result in any value.

10. Click OK to save the new parameter.

11. You can continue editing other aspects of the service blueprint. If you are done making changes, you can check it in to the Blueprint Library. See Creating-copying-or-editing-a-service-blueprint for detailed information.

    Note

    You can also use tokenized parameters when setting up option choices for the end-user in a service blueprint. See Configuring-end-user-Option-Choices-in-service-blueprints for information about defining option choices.

Creating a custom token

1. Follow steps 1 through 7 in Including a pre-defined parameter token in a service blueprint.
2. Select a Token Type of Advanced Editor.
3. Select a Token Path Type of Compute or PaaS, depending on the type of resource you are deploying.

4. Click the Token Path field to open the field for editing.
   The field contains a default token for PaaS or compute provisioning.

   Compute token path: 

   /ResourceSet[name=<value>]/ComputeContainer[0]/Server/ServerNetworkInterface[nicNumber=<value>]/IPAddress[isPublic=false]/ipAddress

   PaaS token path: 

   /ResourceSet[name=<value>]/SoftwareContainer[0]/<attr-name>
5. To select another predefined token path, click . A list of token paths appears. Scroll through the list and select another token path.
6. Edit the token string as needed.
    You can edit text that is enclosed in angle brackets ( < > ). Optionally, you can also create your own token string. For examples of how you would construct a token, see Token examples.

7. Optionally, click Required Value.

   Note

   If you choose to make the parameter required, then there must be a value for the token, otherwise the related action will fail. Also, if this option is not marked as a Required Value but is required in BMC Server Automation, the related action would fail if the evaluation of token does not result in any value.

8. Click OK to save the new parameter.

   Note

   If you edit the name of a resource set or delete a resource set, the tokens you have created that reference that resource set must be updated manually to reflect the change.

9. You can continue editing other aspects of the service blueprint. If you are done making changes, you can check it in to the Blueprint Library. See Creating-copying-or-editing-a-service-blueprint for detailed information.

Token examples

A token is formed based on following rules.

• The path elements must be BMC Cloud Lifecycle Management object model class names.
• The conditions inside the path elements must contain the actual relation and attribute names.
  • EQUALS (=), NOT EQUALS (!=), LESS THAN (<), GREATER THAN (>), LESS THAN OR EQUAL (<=) and GREATER THAN OR EQUAL (>=) are allowed
  • AND (&), OR (|) Logical Operators are allowed
  • Conditions for a path element cannot contain both logical operators (that is, both AND and OR).

    • Valid example:

      /ResourceSet[name=RS1&tags.name=T1]/
      ComputeContainer/Server/ServerNetworkInterface/IPAddress[isPublic=true|
      isPublic=false]/ipAddress

    • Invalid example:

      /ResourceSet[name=RS1&tags.name=T1|tags.tagGroup.name=TG1]/
      ComputeContainer/Server/ServerNetworkInterface/IPAddress[isPublic=true|
      isPublic=false]/ipAddress

The following table provides some examples for how you would format token values.

Here is an example of a token used in a multi-tier service blueprint that is deploying both a server and a database. The server deployment includes an application that provisions BMC Server Automation. Configuring BMC Server Automation requires a connection to a database. The application that deploys BMC Server Automation can include a token like the following, which provides the name of the provisioned database:

Where to go next

Creating-copying-or-editing-a-service-blueprint