I am hoping to have an Orchestrator validation that checks how many times a username has deployed the same catalogue item and limit any further requests based on that number.
I do not see any policies and even the Max. instances per request in service broker only denies instances per request and not per user total.
I am new to scripting in general so i don't know if it is even possible to pull a list of deployments where I could use the usernames to check against.
Any help is appreciated, vRA 8.4
I won't claim this is the best way or even a good way, but first thought that comes to mind is to keep track of it in a config element in vRO - maybe a config element per catalog item with a number attribute for each user?
Then when the deployment kicks off, increment the number for that user's attribute for the given catalog's config element - I believe all of that info would be available either in inputProperties or one of the metadata fields.
To "validate", I see two options - either fail the deployment after submitted based on that number. Or add that number as a hidden input on the form (requiring a vro action to go get it from the config element). And then do some form validation on whether the user has hit their limit for this catalog item already.
Admittedly, if you're new to vRO and scripting then the learning curve for this may be a bit too steep and would be difficult to work through on a thread like this. So you may still be better off looking for a newer or more proper way to handle, as this approach may be a bit "old school". Or if you can open a case for vmware to see if they can help?
Yes I was considering something like that as well and while I am full of ideas on how it could work its the scripting implementation that is the wall for me.
I've opened a ticket as well as this used to be a feature in older VRAs so hopefully i can find a solution that way. Do you happen to know of any resource that could help with understanding how to call on specific VMware properties and integrating them into a script?
I currently use a re-namer for machine names on deployment and while i understand the underlying framework of binding actions and where variables come from in forms and to the scripts find it really difficult to find new variable locations such as a list of deployment names (which must exist ahah)
Anyway, thank you for your help!
Context may help a bit.
If you want to look across all of the existing deployments to get properties from them, then you may need to use the API, which may be a bit beyond your capabilities at the moment. But using Postman (or a similar tool) would be a good starting point and pretty good skill to have in general. The vRA Programming Guide might be a place to start with just reading about it. And the swagger documentation that exists with all vRA instances would help see how the API is layed out.
If instead you want to know things about "this" deployment, then those are typically included in the payload sent from vRA to vRO. They look a little different between XaaS requests vs Cloud Templates.
For the former, the workflow inputs are obviously available as separate inputs. And the metadata variables (like requestor) are available via the System.getContext() function (iirc).
For cloud templates, I believe the metadata fields are accessed the same way. For custom properties in the cloud template, they'd be available via inputProperties.customProperties. However, those change based on which event topic you have subscribed to - but the list of fields for each Event Topic is outlined in those Event Topics in Cloud Assembly extensibility.
As an example, the Deployment topics won't have your custom properties. Instead they'll have the inputs from the form themselves.
I'm sure that is all clear as mud. None of it is terribly complicated, but tough to summarize. There is a lot of material out there about using extensiblity in vRA 8 and the API in general, but I don't recall which ones helped me the most. I'd suggest googling around and playing.
I really appreciate your help, I have a coworker who actually knows how to code and with the use of an existing action we are solving a seperate issue which is being unable to deploy multiple nics attached to the same network thorugh a cloud blueprint. So this action is now able to be run on a vm and replace the DVP of nics 1,2,3 with the DVP from nic 0.
That;s all fine and dandy but these deployments also have two there vms where i need to do this to them. And where we are struggling is to get a list of deployed VMs attached to specific deployment. Knowing this would allow this action to be run on the deployment and not 3 times one per machine. And if we got that figured out we would also be able to somehow make it run after the cloud deployment is finished so the user never has to even run the action.
As such if we coulf just figure out how to get deployment content and deployments per user it would also solve the original issue of limiting the amount of deployments.. Really sucks to have the motivation but now the knowledge ahah.