VRA 8.2 - Value Picker with External Source

[emacintosh]

Has anyone had any luck with populating a Value Picker form item with an externa vRO action?  The docs say that the action has to return a Properties array, but my action that returns a Properties array does not show up as an option as an external source for a value picker (no actions seem to show up actually) 

We have some fairly large dropdowns and I think the value picker could be a better experience for our users, but I'm not having any luck so far.  I'm also not entirely sure if it is meant to be used with just a list of custom options or if we always have to choose sort of reference type?  The wording is a bit confusing in the docs, but the example seems to indicate the former.

[xian_]

I got stuck earlier: I added a value picker with reference type AD:User to search for a domain user. How can I use the selected username as a request input? Is there some sort of mapping to regular string inputs?

[j_dubs]

I banged my head on the wall for a while on something like this.

In our case, we want to allow the user to pick (one more more) AD Users via lookup on the form and add them to a list that is passed into the deployment.

We would then take these users and add them to an AD Group that we dynamically create with the blueprint (custom resource of type AD:UserGroup) and assign them as members to the group upon deployment.

Using a combination of custom resources on the blueprint (Custom.ADAdminGroup) and we pass the list of users from the input array to the vRO workflow that does the creation of the custom resource.

Blueprint inputs would be an array of objects, with external type AD:User.  This will allow you to have a dataGrid on the custom form, and when you add a row, you get a lookup field that will find your AD User:

inputs:
  adminGroupMembersUsers:
    type: array
    items:
      type: object
      title: AD Users for Admin Group
      $data: 'vro/data/inventory/AD:User'
      properties:
        id:
          type: string
        type:
          type: string

 In the resources, we add an instance of our Custom.ADAdminGroup to the canvas.  It takes multiple inputs, like the OU (we dynamically set this based on inputs as well, but I won't go into that here..) The key here, is we stringify the array of objects (AD:User) to json.  This is then a string input on the vRO workflow:

  AD_Admin_Group:
     type: Custom.ADAdminGroup
    dependsOn:
      - Cloud_machine
     properties:
      ou: '${input.admingroupOU}'
      name: '${resource.Cloud_machine.vmHostname+''_LocalAdmin''}'
      adminUsers: '${to_json(input.adminGroupMembersUsers)}'

The vRO workflow that we wrote for the create of custom object "Custom.ADAdminGroup" will take in that json string of users (which has everything we need..) we parse the string, do a lookup by the user ID, and add the AD:User object to an array.

adUserListJSON = JSON.parse(adminUsers);

try {
  var adUser = Server.findForType("AD:User",adminUserID);
  System.log("Found AD user ["+adUser.name+"] ... Adding to list for membership add.");
  adUserList.push(adUser);
  } catch (e) {
    System.error(e);
  }
}

Once we have our list of AD:Users, then it's basically standard vRO workflows for creating AD group, add members, etc.

Working really well for us so far.  The nice thing about this, is that when we destroy the deployment, we also clean up 

[BrettK1]

Were you able to solve the original issue of getting the vRO action to populate a Value Picker?

I've generated a list of OUs from a base DN, and can return these unsorted to a drop down list, and the template will then create the computer object in the correct user chosen OU.  Unfortunately, the list is both unsorted and long (60 different OUs) so being able to search via a Value Picker would be much easier.  Unfortunately, I'm having the same issue of the script not even showing as an option (and as you said, NO actions show up as options).

[j_dubs]

Honestly, I haven't revisited this.  In our environment we have to punt everything through ServiceNow (ITSM plugin) and not Service Broker.  So now I'm limited to very basic types (string, etc.) so I'm doing everything as json.

I could go back and look at this perhaps - what is it exactly you want to do?

[BrettK1]

I've been slowly getting our migration from 7.6 to 8.x done over the past... year.  At this point there's still some functionality missing in 8, so I don't know exactly when we'll be ready to cut over, but in the meantime I'm using new 8.x functionality to make things better where I can (like reduction of the number of blueprints necessary to provide the same number of options, etc).

For this part in particular, I've made a vRO Action that generates an array of properties (though that generated errors as seen on this page I found, https://kuklis.github.io/cma/post/vra8-external-inputs-and-input-property-groups/ , so I had to change it to.... 'a property'?  I'm not even really sure...) that is a list of all OUs from a parent OU, filtering out 'non-terminal OUs' (any OU with child OUs) or ones with "gorup" in their name to get it down from ~128 to 60 OUs.  Currently this is being sent to populate a Drop Down list for the user to select their desired location for the newly requested machine.  Data is returned as "value: DN (with base DN removed so as to use the activeDirectory relativeDN property), and the OU name and full DN for the drop down display (key).  I don't know javascript, so getting this working took an afternoon, but hey, it works!

Unfortunately an unsorted list of 60 OUs is difficult to scroll through and find what you want, so I would like to use this action to instead populate a Value Picker, so users could enter a search term that would quickly drop the list from 60 to a much easier handful.

Currently I'm stuck at the same point the OP was.  Reviewing the vmWare docs on this hasn't shed any light on it for me yet.

[emacintosh]

I have not revisited this either.  It was a "hey this would be cool" type moment a year ago, but too many other things going on to even remember to swing back to it. Maybe if I get some free time soon, I'll give it another go.  And if it still doesn't work as documented, then I'll open an SR or feature enhancement.

In the meantime, I do think an array of properties should work for the dropdown in vRA.  Specifically, each property should contain a key named "label" and its value would be the thing the user sees in the dropdown.  And a key named "value" and its value would be the value that is assigned to the field in the form.  For example, if you wanted to show your users a "friendlier" OU path, but still grab the DN for yourself:

[
  {
     "label":"Servers\TeamA\Test",
     "value": "OU=Test,OU=TeamA,OU=Servers,DC=Acme,DC=Com"
  },
  {
     "label":"Servers\TeamA\Stage",
     "value": "OU=Test,OU=TeamA,OU=Servers,DC=Acme,DC=Com"
  },
  {
     "label":"Servers\TeamC\Prod",
     "value": "OU=Test,OU=TeamA,OU=Servers,DC=Acme,DC=Com"
  }
]

And if you can get that to work, then you can also sort that array before pushing returning it to vRA.  Something like

// assuming your array of props is in ouList
// may have the return values reversed below, just going by memory
return ouList.sort(function(a,b) {
  if(a.label < b.label) {
    return -1;
  }

  if(a.label > b.label) {
    return 1;
  }

  return 0;
});

[BrettK1]

For the dropdown, an 'array of properties' LOOKED like it would work - the dropdown was populated as intended, but upon selecting a value, it would fail.  The link above outlines the issue I had (here's the section itself - https://kuklis.github.io/cma/post/vra8-external-inputs-and-input-property-groups/#vro-action-returni... ).  The error was like theirs (just substitute my DN value for their name 'Delphine').  Their example is specifically attempting to populate and sort as in your example, but failed the same way mine did.

Value 'Delphine' is not in list of valid values ["label", "value", "label", "value", "label", "value", "label", "value", "label", "value", "label", "value", "label", "value", "label", "value", "label", "value", "label", "value"]

So I had to use their workaround of changing my return from an array to a type "Properties" (and uncheck 'array' on the action), at which point the drop-down worked as intended, just unsorted (where before they were in the order they were traversed in AD).  But, even ordered I think 60 is quite a bit for a user to look through (and unsorted it's impossible), thus the need to try to populate this as a Value Picker instead.

[j_dubs]

Going to give this a try here.. been a while, but there should be ways of getting to where you want - just a value picker of a subset of OUs, where the user just sees the label (name of OU) but you are providing a DN as a string value?  Can you show your ideal payload so I understand?

I know for sorting Properties in lists this is not possible - so in the past I have used hidden fields for the real value selected and a dummy input of an array of strings sorted (as an example.)  The user would pick the string which goes to an action to pull the right properties out.  Ugly, but worked.

Returning an array of Properties is allowed - but the control is DataGrid that I used (as an example, prepopulate a table of disks based on the server type.  That would look like this:

var diskGrid = new Array;
switch(serverPod){
    case "Pod:MS-SQL": diskGrid = [{"size":"60","label":"SQL Binaries","filesystem":"NTFS","mountpoint":"D"},
                                   {"size":"100","label":"SQL Data","filesystem":"NTFS","mountpoint":"E"},
                                   {"size":"50","label":"SQL Logs","filesystem":"NTFS","mountpoint":"F"},
                                  ];
                        break;
    default: diskGrid = new Array;
}
return diskGrid;

[BrettK1]

I wrote a whole lot and deleted it.  Overall I think, both for me and OP, this is more of a lack of understanding of vRO itself.  I have not set up a 'vRealize Orchestrator resource' that is appropriate as the 'Reference Type', and frankly don't even know what any of those mean, nor does the vRO documentation for 'Resource Elements in the vRealize Orchestrator Client' shed any light on it, but I think this is the path that I need to be looking down to enable a searchable list, IF in fact the value picker can accomplish this at all?

But yes, I'm looking to pass along a subset of OUs, with the value being the RELATIVE DN as a string (i.e. the DN with the base DN from the AD Integration removed, for use with the 'relativeDN' property on the VM), and displaying the name AND DN (as names are not necessarily unique on their own).

[j_dubs]

So I think you are looking for something like below.  It's doable with a value picker, you just need to assemble the subset array of properties that you want to pick from.  the "value" field from the selected property will need to be pulled out and assigned to your custom property for relativeDn for the AD integration (you could do this on an ABX)

And when submitted you will get this (stringified) JSON object, which you can chomp up with an ABX to set the value for your relative DN property:

If this is the case - and you already have the vRO action code to prune your list of OUs and get the relative DNs, then you just need some action code to assemble this array of properties are shown in the other example above.

Something like:

//Return Type: Array/Properties

//example sub OUs.  To get the OU DN into the label you will need to do string concat as you process your list.  something like:
// label = ouName + " (" + ouDN + ")"

var OUList = [{ "label":"Production Web (OU=Web,OU=Prod)","value":"OU=Web,OU=Prod"},
               {"label":"Dev App 1 (OU=App1,OU=Applications,OU=Dev)","value":"OU=App1,OU=Applications,OU=Dev"}, 
               {"label":"Dev App 2 (OU=App2,OU=Applications,OU=Dev)","value":"OU=App2,OU=Applications,OU=Dev"}, 
               {"label":"QA SQL (OU=SQL,OU=QA)","value":"OU=SQL,OU=QA"} ];

return OUList;

[BrettK1]

That is basically what I'm going for, and reading your explanation it seems infinitely more complex than I assumed it would be (plus there's the whole 'our value picker doesn't want our data anyway, because we don't know anything about vRO Resources, which is apparently a requirement to get there).

Luckily we are currently also reorganizing our OUs, and the number looks to be down from 60 to 10.  Given this and the complexity of implementing the value picker, it's looking like I should drop the value picker idea entirely.  Thanks for the attempt to explain!

[j_dubs]

hah - infinitely complex.  Sums it up eh.

We just bypass vRA AD integration altogether and use vRO to create computer objects, and our ansible playbooks join the domain.

Our OUs are much simpler - and we don't even let users pick.  Based on their "business" inputs, we decide the OU in an action that they don't get to see.  

Good luck!

[BrettK1]

Our users are systems administrators, we're just doing this to save them the steps of creating the object themselves.

To bring this full circle though - what Reference type would one use for the value picker when trying to pass it just an array of label/value pairs, and is there a way (if necessary) to create custom resources in embedded vRO (it didn't appear there was?)

[j_dubs]

For this example, reference type is "Properties"

If you want to do a custom vRO resource type (dynamic types) - I haven't tried this with vRA8+ .. it may work, but not sure.

[BrettK1]

Other than the (what I found) odd behavior that nothing in the Value Picker shows until you type in a search, this was the magic bullet for getting the values into the Value Picker!  Of course, now I'm not sure if there's a way to map its selected value into the Input to use with the AD Integration (which you're skipping altogether, and maybe this is one of those reasons!)  But hey, that answers the original question at least!

[emacintosh]

thanks for working through this!  Sounds like maybe they fixed whatever bug initially existed, since an array of properties now seems to work?  Although that return value to parse is pretty meh.  I'll give this a go to repro and set to this to answered if I can get it working like this.