Plugin Objects being available as Types in the Orchestrator UI

[BlueDevilDan]

I'm trying to understand the interaction of plugin scripting objects and the types (like for workflow parameters and attributes)

When I try to change the type of a workflow attribute for example, I get a list of typs that includes primitive script types and types that appear to be from Plugins (such as SSH:File, SSH:Folder, SSH:RootFolder, SSH:Connection and a number of others with VC: prefixing). How are these types created from the plugin such that they appear here. I have some types that my plugin provides that I would like to use here because they would hand off from one workflow task to another, but I can't see how that is done. I have dug through the vmware-vmosdk-ssh.dar file trying to see how these SSH types were defined, but I can't see anything that was done that seems obvious to me.

Thanks

[admin]

In first hand, you have scripting objects (you already know how it works, I think). On the other hand, you have "Finder objects"; this objects are findable using a "unique" ID (you have to define it by your own way (it's just a String). This ID is basically linked to what the plugin intend to work with. For example, a file system object will have an ID that looks like the file path: A unique way to get the file.

The plugin must be able to get the item from the ID at any time. (In previous versions, the item is retrieved from the plug-in for each separate boxes in the workflow; now this is done only when the workflow resume from a "waiting-signal" / after anwer user interaction). vCO Server request the object from the ID via the IPlugin* interface, (methods find(...) ). You should also implement the relation models.

Now, in JAVA code, we always implement the finder and the scripting objects (when the two types are implemented) with the same Java class.

(It's late here, and I hope my message is clear enough)

[BlueDevilDan]

OK. I think I get it.

From the documentation however, I never would have understood that finders had this role to play in being able to pass my custom object in and out of workflow tasks. So essentially you are saying that you never really hold objects at the workflow level, more like just string memento representations. And when passed in to a task you 'find' the object to pass it into the task and on output to merely track the identity of the object back in the workflow attribute.

[stuartclements]

Hi Dan,

Thanks for identifying this gap in the docs. I'll add a description of Finders and FinderResults in an uncoming release of the docs.

Thanks again,

Stuart

vCenter Orchestrator Tech Pubs