How to display a scripting-object in workflow presentation?

[yatigammanabnd]

In my workflow I would like to present to the user a list made up of a scipting-object from my plugin, lets call it "MyObject", by the object name.

At the moment, for the Presentation property of my Workflow:

• I have created an Input variable of type "String",
• set it to "Predefined list of answers"
  • bind it to an action that iterates through my list of MyObjects and puts the names of them into an Array. This Array of Strings is then presented to the user.

This works fine.

What I'd rather do is just pass the list of objects straight to Presentation. But when I set this up:

• make an input variable of type "MyObject",
• set it to "Predefined list of elements"
  • bind it to an action which returns an Array of "MyObject"

No list is presented to the user, only a clickable "Not Set" text that does nothing.

Although strangely when I run this Workflow in vSphere, a list is presented, but the list is presented as many "[object Object]"s.

How do I make my scriptable-object appear nicely (or at all) in the presentation dropdown without having to iterate through it to extract the names of them? (in both vRO and vSphere)

[iiliev]

Does your scripting type MyObject have a property name (of type String)? If I recall correctly, the value of this property is used as display name in object choosers.

[yatigammanabnd]

So I added a name property of type String, but nothing changed.

Initially I also added it as an "idAccessor" of the @VsoFinder annotation, but have just come to the realisation that the object I want in the dropdown is not stored in a database -> so I kept getting exceptions in the log.

So my new question (still related), is two-fold:

• Is the only way the produce an Array of Type [MyObject] that can be passed from an Action to a Workflow presentation is to make it a "Finder" Object?
  • I ask as the "MyObject" is not stored but generated from an external API. If there is a different type of Object that would allow this? And so show the "name" property of the object in a dropdown box?
• If if does need to be a "Finder" object, How do I make it not crash (spit out exceptions in the log) when it tries to display it in a dropdown box?
  • If the only way is to make it stored in the database with some of my other objects, then so be it.

[iiliev]

I created a sample plug-in from one of the provided vRO Maven archetypes, and was able to see it in the UI chooser in presentation field bound as predefined list of elements to an action returning array of my objects.

If possible, could you send me your plug-in project? I guess it will be easier to troubleshoot the issue if I can run it through debugger to see what is going wrong.

[yatigammanabnd]

Hello,

I too have made a sample plugin from the archetype (as to use my plugin would require access to our API, which you won't have). Anyway, this sample plugin that I'll attach results in the same issue (Try the workflow "getObjects" - run it too as it contains a script that does the same as the Action but output the names). Also attached is a zipped form of the project files as that is easier than accessing them from the jar in the plugin.

[yatigammanabnd]

I'm guessing there has been no luck figuring out what is going wrong?

[iiliev · Accepted solution]

Sorry, got some urgent tasks to do and completely forgot about this thread

I see at least two issues with the implementation of MyObject:

1. its VsoFinder annotation is incomplete, for example, it lacks idAccessor property.
2. your plug-in's factory does not support MyObject in finder methods, for example, trying to find some MyObject instance by its ID will return null. That's why nothing happens when you click the chooser field in the presentation; it tries to convert the objects returned by the bound action call but this causes an exception as the factory couldn't find them (you can see the exception in vRO client log file).

[yatigammanabnd]

ok. so if I understand correctly, are the following statements correct?

• To have MyObject in a dropdown (and display its name property), it has to be a fully fledged "finder" object -> where it is stored in the factory('s database) and has a idAccessor property set.
• And it cannot be a "half fledged finder object", where it only has the VsoFinder annotation purely to pass it around in vRO (from action to workflow presentation) and is never stored in the factory.

If that is so, fair enough. I'll keep that in mind.

p.s.

In case you are wondering why make it a half fledged "Finder" object: this "MyObject" is actually stored in an external application, so rather than make a second database in vRO of the same objects and keep it synchronised. I query the external application and pass it through to vRO -> hence does not enter the factory (which holds information about how to connect to the external application).

But it seems now, that if the above statements are true, I'll have to stick with extracting a list of names from the objects rather than pass the objects straight to the workflow presentation (or store make the object a proper Finder object) -> unless there is another way you can think of?

[iiliev]

The idea is not to mirror the data model of the external application into vRO database and keep it synchronized.

Internally, vRO server does not have access to the runtime state of the external application, so it has to be able to 'query' the external application for necessary information. Let's take a look at some use cases:

1. You create a workflow with an input parameter of some plug-in type, let's say VC:VirtualMachine. When you launch the workflow presentation, you'd expect to be able to click on the input parameter and choose some particular virtual machine from the list of all available machine. How vRO knows the list of available machines? It doesn't know the current list of machines, so it calls the corresponding plug-in factory to get the list of runtime objects of the given type (VC:VirtualMachine), the factory calls the corresponding vCenter server and gets the list from it.
2. You create a workflow with an output parameter of some plug-in type. We execute the workflow successfully, and then at some point you select the execution in vRO client and want to check what is the value of this output parameter. When the workflow completes and the execution information is persisted into vRO database, it stores not the whole runtime object of the output parameter, but only its type and its ID. However, what you'll see in the vRO client variables tab for this execution output paramete, it not the object ID but some human-readable info, perhaps object name. How vRO client knows the output parameter name? It doesn't know it, so it calls the corresponding plug-in factory to locate plug-in object instance by its type and its ID, and if found, it'll be able to get access to the other properties like the name.

So, in these cases vRO server has access to limited info about plug-in object instances, either just object type or object type plus object ID, and to get access to full plug-in objects, it need to 'locate' them by querying the external application. That's the role of the plug-in factory, which knows how to connect to the external application and how to use its API to locate objects.

Hope the above makes sense. You can check vRO documentation/dev guides for further information about the roles of various vRO plugin components.

[yatigammanabnd]

I've been doing lots of learning around the "PluginFactory" (IPluginFactory interface), and now completely understand what you mean!

I've marked I think the key point you made as the correct answer, but to be honest, that and your final response with examples was a great help in understanding how the java plugin works within vRO.

Thank you

[ivgivanov]

Absolutely great info in this thread! iiliev can you please share your example of vRO plugin with proper implementation of a custom object? I think it will be very useful if we can see the correct definition in vso.xml and method in plugin factory

Thanks!