Have a cloud template input with the drop down options based on a vRO Action. The input for that action is projectId as it needs to be Project specific. This is fine in the custom form as it can bind to the Project and pass the value of the projectId.
However, in Cloud Assembly allegedly environment variables can be used (https://docs.vmware.com/en/vRealize-Automation/8.8/Using-and-Managing-Cloud-Assembly/GUID-12F0BC64-6...) using the syntax for example ${env. projectId}. This however does not work.
Has anyone successfully used an environment variable in a cloud template?
Since I can get this to work in the custom form I think I'd be able to just set the input in the cloud template to string as a freetext field. However, wouldn't that mean if someone provisioned a deployment via the API instead of Service Broker they could put whatever they want? How can the input from an API call to provision a deployment be validated before it is actioned?
Hi RebeccaW, two questions in your post:
Hi Rebecca,
i could attach ${env.projectName} as a custom property of a resource on the cloud template, it worked.
However I was not able to use it as an action input either. Have you found a solution to your question yet?
I'd be curious if your VRO action is calculating the value passed along to it. I was working on a VRO action that would validate an IP address to see if already used in vSphere when the cloud template was being used. This Action worked fairly successfully if the entire IP address was pasted in all at once, otherwise, it tried to evaluate the entry as an integer. "192.168" cannot be evaluated as a string because it's type number.
I have added a custom property via the cloud template to tag each new AWS EC2 instance with the env.deploymentId value and that works seamlessly.
@xian_ what I wound up doing was in the cloud template the input is just a string. In Service Broker for the custom form I set the External Source with one of the action inputs being the Project canvas field.
Thanks, this does not solve your original question on validating the input of API calls, where custom forms do not used...
Does a user need to specify their projectId when calling the blueprint from the API? If you could create your own ProjectId input, then maybe that could be used for the external action. On the custom form, you can hide that one from the user and just bind it to the "real" projectId field. But when called from the API, it would have to be specified.
We do not have experience with using external actions in cloud templates directly (other than some simple testing a while back), so I am not sure if that would work in general.
The user need to specify projectId in API when requesting catalog items. But I cannot reference this in the input validations.
If I add an additional projectId input variable to the template, I can reference it, but nothing will prevent the API user to provide here a different projectId than the requestor projectId - he can trick the logic and validations I want to enforce.
@xian_ this seems to be working to ensure the catalog API user cannot submit a mismatch of the projectId and and added input projectGUID:
vRO Action
if (projectId == projectGUID) {
return("")
} else {
return("projectGUID value does not match projectId value!")
}