tschoergez's Posts

oh, I indeed did talk about the New project wizard. I will try to reproduce the issue in my lab. It might be a "bug" in the SDK, occuring now because of another version of JUnit used... java - JUnit: how to avoid "no runnable methods" in test utils classes - Stack Overflow Cheers, Joerg

Hi, can you try to use the new plugin wizard that's part of the SDK to create a plugin skeleton? The SolarSystem example is quite out of date and uses old mechanism, and it obviously is not really updated completely. Cheers, Joerg

Never heard about a siteminder plugin. So you have to figure out if Siteminder has an API, then you can decide if you can use the existing plugins, like SOAP and REST, or if you really have to develop a plugin. Cheers, Joerg

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

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

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

Hi, there are no methods available out of the box for storing the configuration in xml. You have to create/parse the xml content manually in the PluginAdaptor.loadConfiguration() and ...saveConfigurationMethods(). Be aware that newer plugins use ResourceElements in the vCO database to store the configuration data. That allows to change the config during runtime without the need for restarting the vCO service. To find an example how this can be done, download and inspect the open-source Powershell Plugin http://communities.vmware.com/docs/DOC-20354 Cheers, Joerg

You try it in the wrong dialog... The dialog of your screenshot is to do the actual binding to existing workflow attributes / input parameters. You have to create a workflow attribute/input parameter first. Click on the "Create parameter/attribute in Workflow" link in the dialog shown in your screenshot. Cheers, Joerg

Hi! Does it work if you set the type of the workflow attribute to "Any"?? If you want your Scripting objects to be "transferable" between different elements in the workflow (aka. having them as typed workflow attributes), you have to implement a "finder": This is done in the PluginFactory class in you Plugin. Consider it happens that the vCO service restarts while the workflow is "waiting" at the use interaction in your example. Then the PersonInfo object is gone from the memory, and vCO must be able to find that object again. For the basic dataytpes like a string that is not necessary, because they can be reproduced just by having the value. You can find examples for these finder methods in the SolarSystem example as well. Some other tips: Don't miss the documentation of the Plugin SDK, right now that is only available as part of the Eclipse help. (I admit, that is not the first place where I looked for it, too ) Read the Best Practices Guide:  http://communities.vmware.com/docs/DOC-20393 Increase the loglevel of your vCO Server to "debug" (don't do this in production, it slows down the vCO server quite much!). Then you see much more information about the different calls to the Plugin that happen when a workflow runs. Cheers, Joerg

Hi! I don't think thats possible, to directly "manipulate" the JavaScript-Engine of vCO. Short try if you want to use a standard java libary class: Use a shutter-file. Search the forums (=google vco shutter file :smileylaugh:) and http://mighty-virtualization.blogspot.de/2011/01/vco-access-to-java-classes.html to get an idea. If that's not working, you have to create your own Plugin for vCO. Get the vCO-Plugin SDK, watch the videos and read the docs, it's not toooo complicated to get started... http://communities.vmware.com/groups/vco-plug-in-sdk Regards, Joerg

Hi! you can specify an Input Presentation property and call an action which return the array of VMs the users then can select from. See this discussion here, http://communities.vmware.com/message/1875816#1875816 it also describes how to do this. Regards, Joerg

Hi! Besides the annotations in the Java-Code: Is there a way to generate the vso.xml based on existing Javadoc html-files? Consider a situation where you want to present a 3rd-party library available as .jar-file into vCO, and you don't have access to the sourcecode... Regards, joerg