Type to Scripting object mapping in VCO

[Sumit_Tyagi]

Hi All,

I am trying to build my own plugin. I have exposed my java objects into javascript api of VCO. (http://communities.vmware.com/message/2217337#2217337)

But I suppose the way I have defined finders, the types are not associated with scripting objects.

Below are the steps I followed, please let me know if I missed anything:-

1. Defined finders in vso.xml for every exposed object in the format:-

  <finder datasource="test-datasource" type="aObject" script-name="TESTaObject" java-class="com.test.aObject">
   <relations/>

  </finder>

2. Defined scripting objects in vso.xml for every exposed  object in the format:-

  <object java-class="com.test.aObject" script-name="TESTaObject">

   <description>this is a test object</description>

   <attributes/>

   <methods/>

  </object>

3. Defined Factory (and Adaptor classes) with find (and findAll functions) function, with returns a new instance of the java-class object.

When I find the types in VCO in Search Api, then the types do not show the associated script objects in it. It shows FinderResult as the associated script object.

Please let me know if I am missing anything due to which I am not able to associate types with script objects.

Best Regards,

Sumit Tyagi.

[tschoergez]

moved to the vCO Plugin SDK forums.

Hi!

You only need to specify the finder parts in vso.xml for the object you plan to expose in the Inventory of vCO.

Then you also have to implement the all the find.....() methods in the Factory.

If you only want to expose Java object as scripting objects to Javascript, just the <object> part in vso.xml is enough.

To get a feeling for that stuff, you can download the source code of the Powershell Plugin here: http://communities.vmware.com/docs/DOC-20354  and examine it further...

edit: Corrected the link

Cheers,

Joerg

[Sumit_Tyagi]

Hi Joerg,

Thank you for your quick response!

Is it possible to define a separate find function for every type in factory?

I defined single find function which takes type and id. I return new instance of the "type" object by checking its type.

My find method implementation is like this:-

public Object find(String type, String id) {
        if(type.equals("UcsHandle"))
            return new UcsHandle();
        else
        {
            Object retVal = null;
            retVal = PluginRepository.getMethodById(type);
            if(retVal!=null)
                return retVal;
            retVal = PluginRepository.getMethodHelperById(type);
            if(retVal!=null)
                return retVal;
            retVal = PluginRepository.getFilterById(type);
            if(retVal!=null)
                return retVal;
            return PluginRepository.getManagedObjectById(type);
        }
    }

I will take a look at the powershell code you provided.

Thanks a lot for your assistance.

Best Regards,

Sumit Tyagi

[tschoergez]

Hi,

vCO just calls the one find() method.

However in that find method you can/havve to split the search based on the given type.

So you really end up with a lot of

if(type.equals("TypeA"))

... return PluginRepository.findTypeAById(id)

else if if(type.equals("TypeB"))

return PluginRepository.findTypeBById(id)

else if if(type.equals("TypeC"))

return anyClassDeeperInTheInventory.getById(id)

...

Cheers,

Joerg

[Sumit_Tyagi]

Hi Joerg,

ok, so at that point my implementation is ok.

Now second point is, is it important to define id for the element?

I haven't defined any id in any finder element in vso.xml.

In the find method, what I do is:- I return a new instance of the class required instead of returning any existing object (I am not maintaining any instance of objects). Is this an issue?

If I need to maintain an inventory of objects, then where can I maintain it? And how do I retrieve objects from it?

I mean to say, the instances of objects needs to be maintained somewhere in some class by me. Or VCO do it for me? And if VCO do it, then how do I store and retrive objects from/to it?

PluginRepository class which I defined in my previous example, is simply a class which returns new instance of the type of object, it ignores id totally.

Thanks you for your assistance!

Best Regards,

Sumit Tyagi.

[tschoergez]

The idea of the inventory is to store stateFULL "business objects" there. Usually this stateful information is gathered by the external system you want to integrate. For instance, in the vCenter Plugin you have a list of VM objects, gathered by calls to the actual vCenter.

In the easiest desing you jsut have to keep the "root level" objects of the inventory in vCO, and the for each child object a call to the external system gets the proper child object. Again: vCenter plugin example: Just the connection to the vCenter is persisted in vCO, if you dig down in the inventory tree (or find a VM via finder wizard in workflow input presentation) the plugin will call that vCenter to find the actual VM object.

(Side note: That is just for example, in real world the vCenter plugin has a powerful caching mechanism implemented for better performance. But you get the idea...)

So, how to persist inventory objects in vCO (root level, or even deeper levels):

1. use vCO configuration. For that you have to implement the configuration api, and create your own tab in vCO configuration. (again: vCenter Plugin configuration is done in vCO configuration). In the solar system plugin example you can find an implementation for that, too.
However, this is "old style, and I do NOT recommend to use this anymore.

2. (the modern way) Persist the objects in vCO Resource Elements: Then they are stored in Resource Elements. This allows

  - dynamic reconfiguration at runtime via workflows

  - the plugin configuration is automatically backed up when backing up the vCO database, or exporting packages.

All the newer Plugins use this design (REST, SOAP, Database, Powershell)...

You describe that you always return new objects, that means your inventory is stateless, so you don't really need an inventory at all. Just expose the Java classes to javascript via vso.xml and instanciate them in Javascript.

Cheers,

Joerg

[Sumit_Tyagi]

Hi Joerg,

Thank you for such a clear definition. I got the idea now.

Now one more question in the same context:-

I want make actions out of my exposed objects, and want to pass objects between actions in the workflow.

something like this:-

1. Connect to server and store handle object as workflow attribute in workflow.

2. Do some operation using handle object, get array of result objects and store as workflow attribute (to be used by next operation).

3. Process Objects.

4. Disconnect from server using handle object stored in workflow attribute.

Now when I make an action, and define its return type, then it asks for a type of object. But my scripting objects are not mapped to type of objects, so the workflow errors out saying not able to convert the object.

Is there any way I can pass scripting objects created in one action be passed to next action in workflow, without defining inventory?

Best Regards,

Sumit Tyagi.

[tschoergez · Accepted solution]

Well, that's exactly the need for intentory objects, because now you have stateful objects that you want to pass between workflow elements (an store the in workflow attributes).

However, if you don't want to implement a fully blown inventory:

Try to use the generic types "ANY" or  "Properties" (if you want to create your own "struct") as return type for the action and type for the workflow attributes.

Only drawback: There is no presentation available for these types, so if you use them for workflow input parameters a human user cannot start them (another workflow still can!).

(To close the circle for understanding: The finder windows opened in the input presentation of a workflow use the PluginFactory and the find() methods, so if you want to provide them, you have to implement the finders and therefor a fully blown inventory)

Cheers,

Joerg

[Sumit_Tyagi]

Thanks Joerg!

Got the point now...

Best Regards,

Sumit Tyagi