VMware Communities: Plugin Objects being available as Types ...

VMware

Up to Discussions in Orchestrator APIs

Sample Code
Tech Exchange

Orchestrator APIs:

This Question is Possibly Answered

1 "correct" answer available (10 pts) 1 "helpful" answer available (6 pts)

3 Replies Last post: Oct 23, 2009 3:26 AM by stuartclements

Plugin Objects being available as Types in the Orchestrator UI posted: Oct 20, 2009 7:10 AM

BlueDevilDan

18 posts since
Jun 17, 2009

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

Tags: plugin, type

Re: Plugin Objects being available as Types in the Orchestrator UI

1. Oct 21, 2009 2:34 PM

in response to: BlueDevilDan

Cédric

75 posts since
Jun 27, 2008

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)

Re: Plugin Objects being available as Types in the Orchestrator UI

2. Oct 22, 2009 10:02 AM

in response to: Cédric

BlueDevilDan

18 posts since
Jun 17, 2009

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.