VMware Cloud Community
TGrissom
Contributor
Contributor

Catalog Item with Provisioning Request - Not Saving Properties

I'm using an XaaS request to take user input and replacing properties in a new provisioning request. The rough vRO workflow is as follows:

// catalogItem is a predefined blueprint

var request = vCACCAFERequestsHelper.getProvisioningRequestForCatalogItem(catalogItem);

var requestData = vCACCAFERequestsHelper.getProvisioningRequestData(request);

var jsonData = JSON.parse(requestData);

// ------ Do some processing of data here to the jsonData

// Send off the request

vCACCAFERequestsHelper.setProvisioningRequestData(request, JSON.stringify(jsonData));

result = System.getModule("com.vmware.library.vcaccafe.request").requestCatalogItemWithProvisioningRequest(catalogItem, request);

If I run this request as an admin user, then the request runs as expected and the properties are updated with the new data from this workflow.

If I run this same request as a regular user, the workflow runs successfully and the new VM is built but none of the properties are updated on the new VM.

I can output the jsonData and see that the value are in fact getting updated by vRO and sent over to the requestCatalogItemWithProvisioningRequest method.

System.log(JSON.stringify(jsonData));

Any ideas why I'm getting different behavior between different user types?

Reply
0 Kudos
2 Replies
bradger33
Enthusiast
Enthusiast

Hey, im having similair issues whereby setProvisioningRequestData does not actually set the properites.

DId you ever resolve this?

Thanks

Reply
0 Kudos
TGrissom
Contributor
Contributor

I did not continue with this path much further after this point. Instead I had switched back to using composite blueprints. I found that by leveraging custom properties and the event broker I was able to achieve enough automation through vRO to make my deployments work as needed.

I had another question I had opened up here around permissions for the user to be able to see the XaaS blueprint but not the Composite blueprint it called. The answer to that on was to have the XaaS blueprint call the Composite workflow as a service account rather than the user that launched it. You may want to try that route if you also find it's a permission issue.

Best of luck!

Reply
0 Kudos