Supported interpolation expressions
Managed services service components have the capability to take an input parameter from another service component, hence links to all composer supported interpolation expressions are also included here.
The composer enables you to connect input parameters to service parameters or output parameters of other activities. These parameters are determined by composer supported expressions.
- Input and output parameter formats of all activities
- Inbuilt input and output formats of all activities
- Detailed information with examples for all activities
- Troubleshooting
Input and output parameter formats of all activities
Input and output parameter formats of the different activities are tabulated as follows:
| Format | Example | Refers to |
|---|---|---|
${templates.<ID>.output.<PARAM_NAME>} |
${templates.tomcat019453ac.output.TomcatNode01_ip} |
Output Parameter of a template. It is applicable only for terraform template as Helm does not support output parameters. |
${templates.<ID>.<PARAM_NAME>} or ${templates.<ID>.input.<PARAM_NAME>} |
${templates.tomcat019453ac.TomcatNode01-mgmt-network-public} |
Input Parameter of a template |
${input_parameters.<PARAM NAME>} |
${input_parameters.Conn} | Dynamic parameters for template activity. Here, <PARAM NAME> can be a variable of type connection or sharedparameter that you need to configure as input parameter during service definition.
For more information about shared parameter, see Shared parameters in Templates topic. For more information about connection, see the Different ways of adding values for the cloud connection in Templates topic.
For the behavior of these dynamic parameters at runtime, see Creating a service instance. |
${resthooks.<ID>.output.<PARAM_NAME>} |
${resthooks.resthookf342a67e.output.body} |
Output parameter of a Rest Hook. |
${resthooks.<ID>.input} |
Payload of the Rest Hook. | |
${resthooks.<ID>.output} |
Response or output or body parameter of Rest Hook. | |
${notifications.<ID>.output.<PARAM_NAME>} |
Output parameter of notification. |
Inbuilt input and output formats of all activities
The inbuilt input parameters for activities are tabulated as follows:
| Format | Refers to |
|---|---|
${templates.<id>.instance_name} |
Name of the template instance |
${templates.<id>.template_name} |
Name of the template |
${templates.<id>.template_version} |
Version of the template |
${templates.<id>.title} |
Title of the template |
${templates.<id>.stack_id} |
Get the stack id of an activity |
${resthooks.<id>.url} |
URL of the Rest Hook. |
${resthooks.<id>.method} |
Method |
${resthooks.<id>.headers.<name>} |
Name of the header |
${resthooks.<id>.payload} |
Payload |
${resthooks.<id>.authentication.type} |
Authentication type |
${resthooks.<id>.authentication.username} |
User name |
${resthooks.<id>.headers.Content-Type} |
Content type headers |
${resthoooks.<id>.title} |
Title of Rest Hook |
${notifications.<id>.to} |
Receiver email address. |
${notifications.<id>.cc} |
Copy to email addresses. |
${notifications.<id>.bcc} |
Bcc to email addresses. |
${notifications.<id>.sender_name} |
Email id of the sender. |
${notifications.<id>.subject} |
Subject of the notification. |
${notifications.<id>.message} |
Notification message. |
${notifications.<id>.title} |
Title of the notification. |
${decisions.id.selection} |
Retrieve data about the decision that got selected at the time of deployment. |
The inbuilt output parameters for the different activities are tabulated as follows:
| Format | Refers to |
|---|---|
${templates.<id>.action}: CREATE / DELETE |
Create or delete action |
${templates.<id>.status} : SUCCESS / IN_PROGRESS / FAILED |
The status of a template. It can be success, in progress, and failed |
${templates.<id>.status_message} |
Additional message for the status |
${templates.<id>.stack_message} |
Template execution stack logs (from IAAS) |
${templates.<id>.stack_error_message} |
Template error message (from IAAS) |
${templates.<id>.created_at} |
Time of creation of the template. (from IAAS) |
${notifications.<id>.status} : SUCCESS / FAILED |
Status of the email notification. |
${notifications.<id>.status_message} |
Additional message for the status. |
Detailed information with examples for all activities
The following table has links to input and output parameter mapping details of all activities along with their examples:
| Service component / General | Input and output parameter mapping |
|---|---|
| Templates and helm charts | Input output mapping for templates and helm charts |
| Integration > Resthooks | Input and output parameter mapping for resthooks |
| Flow components > Decision | Parameter mapping for decision |
| Notifications > Email notification | Input and output parameter mapping for email notification |
| Service instance level parameters | Service instance level parameters |
| Interpolation parameters of Error flow | Service instance level parameters in Error flow |
| Shared parameters in service interpolations | Using shared parameters in service interpolations |
Troubleshooting
If a service references a string literal, such as ${<text>} in the parameter value of an activity, then use $${<text>} as a string to escape it in the service definition. For example, you have a helm chart
that contains ${path.config/prospectors.d*.yml} in Filebeat.config.modules.path. When you create a service to deploy this helm chart, the following error occurs:
Error: Invalid resource : ${path.config} (hint: 'path' not found)
{"error":{"statusCode":500,"message":"Internal Server Error"}}
To resolve this error, change ${path.config} to $${path.config}.
For more troubleshooting information, see Troubleshooting Service Composer or Portal issues.