VM Requester/Owner Email, First/Last Name, etc. vCAC / VCO

[tperrySov]

I am trying to find a way from VCO to figure out the VM or Requester email, first name, last name.  I can currently get the owner from the code below, but I have not been able to figure out a simple method of getting email, first name, last name.   I was thinking of going an hitting AD but that really becomes complicated based on multiple AD servers with multiple tenants.  I know VCAC has this information, it can send emails, it shows your First Name Last Name in the top right corner.   Currently I am using vCAC 6.1 and vCO 5.5.2.

Any idea on how I can get email, first name, and last name of the owner?    Any help or pointers is appreciated. 

var ownerEntity = virtualMachineEntity.getLink(vCACHost, "Owner")[0];

vmProperties.ownerName = ownerEntity.getProperty("UserName").toString();

System.log("OWNER: " + ownerEntity.toSource());

---- Output----

[2014-10-22 15:14:56.281] [I] OWNER: ({, entityKey:{UserID:"2"}, entitySetName:"Users", hostId:"a6574542-3b3a-4362-b8f0-b466cc011a56", internalId:"%282%29%40a6574542-3b3a-4362-b8f0-b466cc011a56%40ManagementModelEntities.svc%40Users", keyString:"(2)", modelName:"ManagementModelEntities.svc", pluginFactory:class com.vmware.o11n.plugin.dynamicops.VcacPluginFactory @364aeeff-31a6-4efd-8fd2-b2a69008eeb8; Wed Oct 22 19:14:55 UTC 2014, properties:{UserName:"xxxx@xxx.local", UserID:2}, type:"VCAC:Entity", wrappedEntity:OEntity[OProperty[UserID,EdmSimpleType[Edm.Int32],2],OProperty[UserName,EdmSimpleType[Edm.String],xxxx@xxx.local],OProperty[UserNameDescription,EdmSimpleType[Edm.String],null]]})

Thanks,

Tim

It always seems that the simple things take longer than the complex things....

[stvkpln]

vCAC is pulling that information from Active Directory. It doesn't cache that information (as far as I'm aware). Your best bet would be to leverage either the vCO AD Plugin, or if you need to support multiple domains, leverage the vCO PowerShell plugin.

[tperrySov]

That is what I am afraid of.  Since I have multiple Tenants, multiple AD, I would have to query the tenant, get the AD configuration (if that is even possible... haven't looked at that yet), ensure I have credentials to query, etc.  This gets pretty ugly.   All for something that should be pretty easy, email and names would be pretty essential for formulating error messages, sending email status's, etc.   

[stvkpln]

Unfortunately, I think it's a bit more complicated than that. For actions initiated directly within vCAC, I agree, that information may be readily (ish) available because vCAC can go and query the authoritative source (read: Active Directory) for the information it needs, but vCAC out of the box doesn't give a lot of extensibility for customizing emails, etc... That's what vCO is there for. The main issue is that vCAC would have to maintain that metadata about the user (and theoretically, other) objects.. and that can be pretty ugly. Frankly, I wouldn't want vCAC storing that information as yet another repository of information that needs to be synchronized from the authority (it would have to.. that info can change). Do you really think it's reasonable to effectively cache all of your user information in vCAC? I don't, and I wouldn't want that information stored there.

The direction VMware is going with all of this is to leverage Orchestrator as your point of extensibility. The upside is that if you get this to work once, it's reusable code and can be extended out for other purposes. I was able to do some (simple) AD integration for checking OU structure integrity during provisioning with a PowerShell call, and it took me less than a day to build and test the functionality.

[tperrySov]

While expecting vCAC to cache the information may be unreasonable, a simple passthrough api so you don’t have to reinvent the wheel is not.    Basically you have to reinvent SSO to get a users first name and email, which is already being used in other places in the application.  A simple api that retrieves user details that goes through sso makes more sense than going around it and out to the AD source.  For instance, what if in the future it changes to LDAP, SAML, etc.  I now have to figure out each of those integrations.  I am not saying that it can’t be done, but it is extremely inefficient and complicates the simple.  Everything the GUI can do I should be able to do via API, that includes getting user details.

[david615]

I don't mean to beat the dead horse but I do believe vRealize automation should cache session user's property information - at least an email address.

Trying to jump through hoops (extra steps with AD integration) to just to get email address of the vRA user is inefficient.

Having said this, API to get Ldap object property is available but not as a workflow.  You will have to create your own.

David