In the age of automation, services or workflows are the building blocks of any automated pipeline. Services or workflows allow us to design our automation as per our needs. With the advancements in the cloud architectural patterns and strategies, services/workflows need to be more adaptable to cater the dynamic hybrid cloud solutions.
Input parameters are fairly common, but if I had to give a short definition of them, I would say they are mechanisms that allow an entity to supply data to any procedure during its execution. Or, in simple technical terms, they allow a user to pass on values to any process, whether a service or a workflow. By adding dynamic data fetching capabilities to your workflow input parameters, you can make your service/workflow more flexible and robust, providing a better user experience.
The Terraform & Service Automation Module in IBM Cloud Pak for Multicloud Management supports dynamic input parameters to help users compose a hybrid service or workflow.
To get the most from this article, you should have a basic understanding of virtual machine (VM) creation.
Optionally, if you want to replicate the VM creation service example, you will need a license for IBM Cloud Pak for Multicloud Management with the Terraform & Service Automation Module (formerly IBM Cloud Automation Manager) installed.
It takes about 15 minutes to read this article.
Types of input parameters
In most scenarios, input parameters can be broadly classified as either open-ended or close-ended. Open-ended parameters require a user to add values manually (typically via a text box). Close-ended parameters allow a user to select a value from an allowed list of values (mostly via drop-down lists). Close-ended parameters can be further classified as pre-defined or real-time:
- In pre-defined scenarios, an allowed list of values is defined in advance by the service/workflow designer.
- In real-time scenarios, an allowed list of values is fetched or received from a source or provider (mostly via a rest call) during the time of the service/workflow execution.
There is often a need to generate the allowed list of values dynamically depending on selected values of the input parameters. For example, let’s say you are designing a service for users to create an Amazon Web Services (AWS) virtual machine (VM). First, you need some input data from the user, such as the AWS Account, AWS Region, Virtual Private Cloud (VPC), and Subnet. (For simplicity, let’s assume that the Security Group, VM Type, and other necessary attributes are hardcoded.) You must create input parameters for the each of these attributes and there are several options:
- If you create an open-ended input parameter to collect the data, your user must manually find and type in all of the values, such as Account ID, Region ID, VPC ID, and Subnet ID.
- If you create a close-ended, pre-defined parameter, the allowed values are fixed and your user experience is very restrictive since they cannot create VMs in newly created Region/VPC/Subnets.
- If you create a close-ended, real-time parameter, the allowed values would be fetched in real time for each input parameter independently. But, again, it might not be the best experience for your user since the drop-down values (allowed values) for Subnet would be all the Subnets for a given AWS account, irrespective of what Region and VPC your user selects.
The best user experience is created by adding dynamic data fetching capabilities to a close-ended, real-time parameter. Once the user selects an AWS Account and Region, the allowed values for the VPC input parameter are only the VPCs of the selected AWS Account and selected Region. Then, once the user selects a VPC from these allowed values, the allowed values for the Subnet input parameter should only be Subnets of the selected AWS account and selected VPC.
Dynamic parameter design and implementation
To add dynamic behavior to an input parameter, you should first understand how to define the dynamic input parameter and how to resolve (get allowed values) for it. Returning to the example of a VM creation service, the diagram below illustrates how the dynamic input parameters must be associated with assets and dependents.
- Asset Type is an implementation of dynamic behavior which can be linked to any input parameter to make it dynamic in nature.
- Depends On indicates the required dependent inputs to the asset implementation.
- Source is a collection of dynamic input parameter implementations (assets). Each source is associated with a cloud provider type.
- Connection is the cloud provider user account.
Once all the values of the dependent input parameters are available (as the user selects them), you just need to call the implementation of the associated asset to resolve that input parameter.
Dynamic parameter example
To visually demonstrate a dynamic input parameter, below are screen captures from IBM Cloud Pak for Multicloud Management with the Terraform & Service Automation Module installed. With this module, you can automate provisioning of infrastructure and VM applications across multiple cloud environments with optional workflow orchestration.
Terraform & Service Automation provides a library of services created by users, which may include components such as user interaction, template, custom actions, and orchestration logic. It also comes with immediate implementations for a few assets, which gives a service designer the ability to add dynamic behaviors to service input parameters.
Service creation flow
For the purpose of this demonstration, let’s assume you have an existing service in the Terraform & Service Automation Module to create an AWS VM. Within the Parameters tab, you can see that
cloud_connection (AWS Cloud Connection) is already an input parameter that allows your end user to select the AWS account:
You must create a corresponding activity parameter, such as
aws-region, and its dependent parameters to be able to link it to the
cloud_connection input parameter:
Once you select regions from the Asset Type list, its dependent parameters (
Cloud Connection) are displayed in the DependsOn section. Now you need to link to an already created input parameter, which in this case is
cloud_connection (AWS Cloud Connection).
Your newly created input parameter (
aws_region) is now displayed under the Input Parameters list:
As you create additional parameters for VPC and Subnet, you’ll see more options for linking them as dependent parameters:
After creating several parameters, the Input Parameters list looks like this:
You are now ready to deploy (execute) the service to test the user experience.
Service deployment flow
On the Deploy a Service page, your user must fill some necessary info, such as Namespace and Service Instance Name. Look at the first input parameter,
AWS Cloud Connection, under the Service Input Parameters section. The list shows all the available AWS accounts that the user can use to deploy this VM service.
When your user selects an AWS account, a list of AWS regions appear that are associated only with that account:
After making a selection from the AWS Region list, the VPC Name list displays the names created by the selected AWS region only:
If the region selection is changed, the VPC Name list also changes. The values shown in the list are real-time values and are dependent on the previously selected input parameters. Just the way you want your dynamic input parameters to behave.
You can create better user experiences by adding dynamic data fetching capabilities to your input parameters. They make your service/workflow more flexible and robust and allow end users to have much more refined experiences.