vRA 8.8 Cloud Assembly dynamicEnum with projectId as input

[RebeccaW]

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-6391-4E5F-AA48-C5959024F3EB.html) 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? 

[bdamian]

Hi RebeccaW, two questions in your post:

1. The custom forms works only in Service Broker. I didn't find a way to test it from Cloud Assembly.
2. There are different APIs for Cloud Assembly y Service Broker. A typical user doesn't have access to Cloud Assembly API so there will be no problem.

[xian]

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?

[RebeccaW]

  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.

[xian]

Thanks, this does not solve your original question on validating the input of API calls, where custom forms do not used...

[emacintosh]

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.

[xian]

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.

 

[RebeccaW]

 this seems to be working to ensure the catalog API user cannot submit a mismatch of the projectId and and added input projectGUID:

• Cloud Template: added input named projectGUID; used this as the input for my dynamicEnum on the input field I need to use the action for since the environment variable isn't working.
• Service Broker: on the custom form set visibility for projectGUID to NO and Value Source to Bind Field bound to the Project canvas field; at this point the Service Broker user sees nothing different but the Catalog API user could put in a different value for projectGUID and get the wrong set of valid values for the dynamicEnum field
• Service Broker: On the Validations tab added an Orchestrator validation and an Action that tests if projectId matches projectGUID. Of the Catalog API user has to now set projectGUID to the same as the projectId they are using. They get a 400 Bad Request error if they do not with the reason set in the vRO action used for validation

vRO Action

if (projectId == projectGUID) {
    return("")
} else {
    return("projectGUID value does not match projectId value!")
}

[eswoodford]

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.