Get payload or properties from Xaas blueprint to Orchestrator ? (in vRA7 / vRO 7)

[jgnzlz8]

It's possible get the payload of a VM in vro when i use XaaS Blueprint ?

I have an scripteable taks whith: "var machine = payload.get("machine") ;" but the log show machine=null .

When i use the scriptable task on a subscription the payload.get work perfectly .

Thanks!  

[SeanKohler]

If you can take in machine name, you can look up anything.  A lot can be done with a string.

[jgnzlz8]

I need get the Ip of the vm.

[CSvec]

Long answer short: No.

"properties" is a value passed by the event broker specifically. XaaS blueprints don't use them or have them as all of their inputs are directly mapped. You have form inputs from vRO, and a few _asd references like who requested the action that show up for the ride if you want them.

XaaS blueprints can take anything from a form. Though from what you're describing it sounds kind of like a resource action instead? You want to take action on a dynamic VM object? Because the form component will let you specify a VM (just have the form inputs in vRO be a vc:virtualmachine or something similar) Either way, properties the String of Doom isn't a thing in XaaS. And the prior poster is correct that passing strings into XaaS blueprints and doing the lookup there is usually your best bet for portable and reusable code.

[kumarsenthild]

Thank you very much for explaining. Is there anyway to get request ID from XaaS form. I need to send email to user with request ID

[pedjono]

Hi kumarsenthild​,

Not sure if you worked this out or found your answer somewhere else...

I am assuming you want to get the USERID of who requested the XAAS catalog item.. If this is correct then this is how I have done it..

On your Orchestrator workflow you need to add an Input parameter to capture this. (same for any other inputs you want - in my case an email, crq number and an 'are you sure' checker)

I have an Attribute I have called 'requester', In the Schema I have a "scriptable task" dealing with all the Inputs, but the part of interest to you is this simple line: var requester = requestedby just make sure you set the "IN" local parameter to 'requestedby' and then in the "OUT" tab a local parameter for the attribute 'requester'.

Next have your workflow do what its doing...

On the End of my workflow I have used the built in worflow called "Send Notification" this sends an email.

I have added the Attribute 'requester' as an "IN" parameter to the Send Notification workflow, In the scriptable task of the workflow you can write the content of the email... SO along with other things my content has a line saying{ " This was requested by: "+requester }

Now for the xaas blueprint...

When you pick your workflow when creating a new xaas blueprint, you should have a "requestedby" field, select this and update it like this:

 

Remember to click Apply

Now your field should look like this:

But we dont want that showing up when users are working with the catalog item... so go back in and make it constantly not visible:

Remember to click Apply

Now when you choose your catalog item you wont see this field but it will be auto populating.

So long as all configured correctly your vRO workflow will run and send the email including the requester,

something like this:: (sorry about the blue.. but have too..)

Hope this helps you, or someone else in the future.

Cheers

Jono.

[msaxbury]

vRA has to pass the form data to vRO somehow. If the workflow errors the stack trace prints out inputs and attributes and such, how does one enumerate the content being sent from vRA to vRO for XaaS blueprint requests like they do with 'payload' and machine.properties for regular blueprints?

[msaxbury]

Ilian Iliev gave a partial answer in this discussion - https://communities.vmware.com/thread/605658

"XaaS/vRA communicates with vRO via vRO REST API."

[pedjono]

Hi msaxbury​

What I have found is when you create a XaaS blueprint, you select the Orchestrator workflow you want.

It will have the INPUTS from the workflow and you can set those on the blueprint to be filled in by the user etc.

If you want to have more INPUTS on the XaaS blueprint, these will need to added as INPUTS to the workflow and then the scripts in the workflow updated accordingly to use these for variables etc.

Hope that helps and makes sense.

Cheers

Jono.