1 2 Previous Next 18 Replies Latest reply on May 11, 2018 8:25 AM by mbomb67 Go to original post
      • 15. Re: vRA 7.x - VirtualMachine.Admin.Owner
        bdamian Hot Shot

        A little update, the data sent by the subscription "Catalog item request completed" is the following:

        taskType: PROVISION

        subtenant: fcb8a0f5-a6cf-46b8-9d2f-585a57dff9f3


        requestId: 3873e726-74e9-4052-96d1-bf079f7e2c8d

        success: true

        deploymentId: d1ca808b-0ada-4c8c-b278-cb3c15eba125

        blueprintId: BlueprintName


        requestStatus: SUCCEEDED


        The best shot is to read the original Request, but the "requestId" sent by the subscription is not here:


        I guess it is from here:


        but this service do not allow GET calls


        So, dead end again.

        Is there any way to get the data from the original request based on the "requestId" sent by the subscription "Catalog item request completed"?

        Thanks a lot.

        • 16. Re: vRA 7.x - VirtualMachine.Admin.Owner
          qc4vmware Master

          What we've had to do in the past is loop until the catalogResource is returned.  Its not instant or at least my experience is it can take a while varying on how busy things are and overall performance of your deployment.  I'm still very new to the subscriptions but I'm fairly certain if you are subscribed to a point in the lifecycle where the deployment has completed you should not have an issue changing the owner.  You just might have to loop and retry a few times.  Also, make sure your event subscription doesn't timeout too quickly.


          Other ways you can achieve what you want to do are through a XaaS if you are licensed for it and use a workflow that does the deployment and a last step in that workflow is changing the owner. 


          You could also do an asynchronous workflow call from within your subscription that loops until all the assets needed seem to be available in the api.  I've done this sort of thing many times in the past to deal with timing issues.


          Nearly all of our deployments are done by a service account so they all need to have their owners flipped.  We happen to use an XaaS blueprint as the launching point but are rapidly moving functions into the event subscriptions.


          If I get a few minutes I'll try to put together a workflow package along with the subscription attributes necessary for it to work.

          • 17. Re: vRA 7.x - VirtualMachine.Admin.Owner
            bdamian Hot Shot

            I can't really do the async call because this is an automated process and I need to know if something goes wrong. If I make the subscription "non blocking", I cannot raise an error if there is one. So, the only option is to do this with two different calls to the API (for now).


            What I need right now is to get the original request, but the API doesn't allow GET calls to that service.


            Thanks anyway, I'll keep looking.

            • 18. Re: vRA 7.x - VirtualMachine.Admin.Owner
              mbomb67 Novice

              We had these same requirements, and were able to meet them by using the Default error handler element in the workflow schema to send us an email if there is an issue with the asynch workflow called after the request has exited. We have deployed hundreds of VMs in this fashion, and have had less than five that we have had to step in and manually change the owner.


              1 2 Previous Next