This sample shows how to add action extensions on existing vSphere objects (see the chassis-ui sample for actions on new objects). Actions added by a plugin are grouped in a sub-menu of that object's context menu. Most of the time actions will be used to trigger a server-side operation. In this sample of the actions calls a java service implemented in vmaction-service.
The vmaction-ui defines a set of 3 actions and uses a filter on VirtualMachine objects to make them appear only in VM menus.
Plugin vmaction-ui requires vmaction-service to run. Import both projects in Eclipse, build and deploy the bundles to the server, putting vmaction-service first. Start a client session and select any VM from our vCenter inventory. Right-click on the VM, you should see a new sub-menu at the bottom of the VM menu, called "Actions Sample". It contains the 3 action items defined in this sample within it's own menu structure.
Here is the message displayed by the java service callback.
In plugin.xml: this sample implements extension vise.actions.sets to define 3 actions and extension vsphere.core.menus.solutionMenus to create a custom menu using those actions. They share the same command class com.vmware.samples.actions.VmActionCommand.
The <metadata> filter restrict these actions to VirtualMachine objects, i.e. the Actions Framework will only add a plugin sub-menu to the VM's context menu. The attribute <conditionalProperty>config.template in the 3rd action restricts that action to template VMs, the action is disabled for all other VMs. Note that the property is not restricted to what is in the vSphere APIs, you could use a custom property and implement a PropertyProviderAdapter on the server side.
If you omit to define a solutionMenus extension containing those actions the framework generates a default "flat" menu with all the actions and the title All package-name Actions" (where package-name is the name defined in plugin-package.xml) or All bundle-name Actions when running in dev mode, because no package name is available yet.
In VmActionCommand.as: each action's code is implemented as [RequestHandler] using the action's unique extension id. See how the method getIResourceReference() extracts the selected object from the ActionInvocationEvent: IResourceReference is a generic type for all vSphere object resources that must be used for passing those objects to the server. The 2nd action uses ActionCommandProxy to call the vmaction-service on the server side.
If you get compile-time errors like the one below (invalid RequestHandler id) it is because the metadata checker tool is enabled by default and requires you to add these RequestHandler ids to the white list of authorized ids. Follow the link to learn more about this tool.
For more on this plugin configuration that is required to call vmaction-service, see Calling a Java service from the client in the SDK Tutorial.
For more on the localization implementation, see helloworld-i18n-ui.
This is the dummy java service used by vmaction-ui. Although it doesn't do much it must still be deployed on the server for vmaction-ui to load and run successfully since there is a dependency.
In VmActionServiceImpl.java: notice the injection of vimObjectReferenceService in the constructor. This service is required to extract the vSphere object's type and value from its resource reference. See how the constructor argument is added in WEB-INF/spring/bundle-context.xml.
The configuration files required to publish this java service correctly are:
When you start implementing your own plugin make sure to keep your java services as light-weight processes, they should only be a "pass-through" between the client and vCenter Server or other data sources.
See also: Other samples - SDK Tutorial - FAQs - Flex API docs - Java API docs