A little update, the data sent by the subscription "Catalog item request completed" is the following:
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.
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.
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.
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.