7.0 U1 release of vSphere brings significant improvements to UI plugins and core vSphere Client. The enhancements are focused around UX, flexibility of API consumption and plugin compatibility across vSphere Client releases.

Dynamic Extensions

The vSphere Client provides a Service Provider Interface (SPI) which can be implemented by remote plugins to enable dynamic filtering of their UI extensions. Plugins may now indicate which extensions are to be shown based on a specific vendor-defined condition. Normally, this is either an object property or the user having a certain privilege.

Local plugins have always had a way to filter their UI extensions by using <propertyConditions>, <privilege>, <conditionalProperty> or <requiredPrivilege> tags specified in their plugin.xml manifest file. However, the design of this solution means that the vSphere Client would evaluate each extension condition separately. This may involve making multiple remote calls to the vendor backend which can have impact on the overall performance and responsiveness of the UI.

By providing an SPI, the vSphere Client SDK enables remote plugins to specify which extensions are dynamic in their plugin.json manifest file. The new approach for remote plugins has a number of significant advantages:

• Conditions are completely defined and owned by the vendor which expands on the limited set of scenarios supported by local plugins.
• The dynamic extension filtering is executed by the plugin’s backend server preventing any performance impact of the plugin vSphere Client integration.
• Each condition can be reused for multiple plugin extensions but evaluated only once.

As of 7.0 U1 the vSphere Client supports dynamic extensions on Monitor views, Configure views and Menu actions for all vSphere managed objects.

Actions on multiple target objects

Remote plugins can define an action applicable to multiple objects of the same type (e.g. on VMs in the same state). It can be executed on all of them in bulk.

An action needs to be explicitly marked with the acceptsMultipleTargets property to support multiple execution objects.

Plugin multi-version support

It is common that a plugin needs to work on multiple major vSphere versions (e.g. 6.7 and 7.0) to ensure the expected continuity for a vendor solution. Of course, this means that the plugin should use only APIs available in the smallest supported version (6.7 in the example). This puts a natural limit to the adoption of new plugin features and APIs released in later versions of vSphere.

With the introduction of the remote plugin multi-manifest vSphere Client SDK 7.0 U1 makes it possible to consume new APIs within the same plugin. It allows a remote plugin to bundle multiple manifests responsible for different feature sets into a single zip archive – for example one manifest for 7.0.1, one for 7.0 and another for 6.7:

The plugin would deliver the manifests zip as a single vCenter Server extension. Each respective version of the vSphere Client would parse the multi-manifest and recognize the plugin manifest version it is compatible with.

Accessibility & Icons

VMware is continuously improving the vSphere Client’s accessibility to people with disabilities. It is following the main Web Content Accessibility Guidelines (WCAG) and has introduced a new set of accessible icons.

Plugins are recommended to conform to these guidelines as well.

As part of the SDK support for plugins a new accessibilityTitle API for dialogs has been added. The remote plugin sample part of the SDK demonstrates means to make a plugin accessible.

SDK samples & recommendations

• leverage new library versions (Clarity Design System 3.0 and Angular 9).
• declare custom privileges and tasks.
• detect plugin data changes and refresh plugin views via WebSocket.

Full details about the 7.0 U1 release of the vSphere Client SDK and related documentation are available on the vSphere Client SDK home page.

Please direct any questions to the vSphere Client SDK forum or the comments section below.