So this is a bit of an expansion of this discussion: https://communities.vmware.com/thread/500669?start=0&tstart=0
You will see that pizzle85 managed to solve his challenge of BG object ownership by using an ASD Service Catalog Request located in each Business Group's Entitlements so a member of the business group can just run the Provision required to bring the BG item under management in the business group. This is quite an effective method to solve the need. He then has a Resource Action that allows for re-"Provision" which changes owner within the business group: a necessary task because managers tend to move around a lot so they can look busy. (just kidding, I love managers--who have a sense of humor) So to change owner... just perform a "provision" again.
Apparently this is one of the best kept secrets in vRA because it has been hard to figure out, and nobody is writing about it. (I can only assume that there is some SE out there who has worked with the developers to get this capability going and it hasn't been shared widely.)
Note: I think Business Groups as a Service is something I need to plan for (vs centrally managed Business Groups) even though their future implementation might vary, so my examples here are related to that effort because I am too lazy to demonstrate a generic example. BUT... the idea is... ownership of ASD Inventory Objects (representing ANY Custom Resource) can be modified using this method. Ownership includes both the owner represented by "ME" in the Items list... and the Business Group (subtenant Reference & Label) where the item resides in inventory.
In 6.2.x, I have not found any method in the vRO plugin for vRA to be able to change ownership and business group of an ASD Custom Resource Inventory Item, but it can be accomplished via a combination of (1) ASD Service Catalog or Resource Action "Provision" capabilities and (2) REST calls through the vRA plugin service channels. (the latter uses the plugin service account authorizations/entitlements)
Consider this image...
This could represent a central management point for many business groups: where I can assign a set of resource actions allowing for automation of various business group needs, an anchor point for actions. Those entitled in the sktest business group would be able to see all the business groups for the tool.
This also could represent a starting point where business groups are created as real objects, returned as custom resources, and "provisioned" as inventory object items. But once there...maybe you want to move it?
seantesting doesn't belong in sktest as we decided to change from the "we manage it for you" model to the "manage it yourself" model.
And it moves now owned by the vRA plugin service account... (which an entitled user could run Take Ownership and own it in that business group)
The service account obviously needs to be part of the destination business group and as it ends up, has to have an entitlement to any "provision" action in the business group even though the object doesn't exist there.
This is a tricky hack and this is how it works...
1. vRO workflow calls the Take Ownership Action in vRA via REST (front door process). As noted before, this has a provision attribute to the action which we know changes the owner. So we would expect that the owner would change to the user that is making the request: which is the service account. The service account becomes the owner, but this wouldn't change the Business Group.
2. So we change subtentantRef and subtenantLabel in the REST call to the business group we want to target, even though the object isn't in inventory in that business group. And Voila! The business group item representation re-provisions as a new owner in a new business group. Effectively changing the owner and moving the object from one BG to another BG using the management-method vs the self-service-method (the latter as pizzle85 did).
Again... maybe you care less about Business Groups. Maybe you would prefer self-service. It is the capability of moving a custom resource inventory representation that matters.
Here is an example of the REST call to run the "Take Ownership" action. I have a script before this that pulls in all the variables for the "Resource" I am targeting (from the BusinessGroup object ID), the action I am running (Take Ownership ID), the business group Ref and Label) and some of the properties I need for the Take Ownership action like bgName... but those are actually not necessary. (all of the "entries" are what is required per the Take Ownership request... if that request didn't require any inputs, there would be no entries... it is the top change of subtenant that allows for the BG move)
--------------------
System.log("resourceRef: " + resourceRef);
System.log("resourceActionRef: " + resourceActionRef);
System.log("targetRef: " + targetRef);
System.log("targetLabel: " + targetLabel);
System.log("bgName: " + bgName);
var payload ={
"@type":"ResourceActionRequest",
"resourceRef":{"id":resourceRef},
"resourceActionRef":{"id":resourceActionRef},
"organization":{"tenantRef":"vsphere.local","tenantLabel":"vsphere.local","subtenantRef":targetRef,"subtenantLabel":targetLabel},
"state":"SUBMITTED",
"requestNumber":0,
"requestData":
{"entries":[
{"key": "provider-rYouSure","value":{"type":"boolean","value":"true"}},
{"key": "provider-bgName","value": {"type": "string","value":bgName}}]}
}
payload = System.getModule("org.dojotoolkit.dojo.json").serialize(payload);
System.log(payload);
Server.log(payload);
var catalogRest = cafeHost.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE);
var response = catalogRest.post("consumer/requests",payload);
Best of luck in your Automation Efforts!
Sean