Apart from the occasional bugfix Update 3 releases of vSphere are normally uneventful for the vSphere Client SDK and plugins. That said, the 6.7 Update 3 contains a few notable improvements both on the UI plugin management side and on the SDK. You can get the bits from the vSphere Client SDK home page on VMware {code}.

Access control to plugin management actions

The Client plug-ins administration view of the vSphere Client (HTML) features the option to enable or disable plugins. This option was available to any logged-in user regardless of their privileges in the vSphere environment.

This security limitation has been resolved in vSphere Client 6.7 U3 by allowing the plugin management actions only to the users of the Administrators group. Further development on RBAC for plugin management is considered going forward.

Plugin Management UI enhancements

vSphere 6.7 U2 introduced the Plugin Management UI feature – this has been extensively covered in the previous blog post Digging through logs is over and my dedicated post on the VMware vSphere blog.

Thanks to the help of the vCommunity and the high visibility of the feature within the vSphere Client the SDK team received lots of feedback – most of it immediately addressed in the 6.7 Update 3 release.

Better visibility of plugin error messages

In 6.7U2 all failed tasks were reported with the default vCenter task error status as defined by the Task API: “Cannot complete the operation. See the event log for details.”. Users could see more info about the failure and the context of it only by checking the Error stack in the task details.

This has been enhanced by a dedicated task error status which indicates the failure reason directly in the Recent tasks and Task console:

It is important to note that this again leverages a public method to extend vSphere: defining faults and localization through the ExtensionManager API of the vCenter Server. The approach is highly recommended to all partner solutions (not only UI plugins) which integrate with vSphere and want to track long-running operations. It will be a topic of a separate post.

Reporting of incompatible Flash plugins

The vSphere Client (HTML) creates vCenter tasks for all registered plugins without exception. This includes the Flash plugins which are treated as incompatible and result in Failed tasks. As all tasks are also displayed in the deprecated vSphere Web Client (Flash) these failure reports looked like Flash plugins are incompatible with the Flash client which brought some confusion (see this community thread).

This is now resolved by reporting the status of Flash plugin deployment tasks as Completed and providing result info about the incompatibility in the task details.

Note we cannot just stop creating these tasks for the Flash plugins as by design the vSphere Client is able to detect the incompatibility only after downloading the plugin and parsing its plugin-package.xml manifest which has already created a “Download plug-in” task. Skipping the “Deploy plug-in” task would leave the plugin reporting in inconsistent state for the user.

There can be better task statuses with clearer semantics than “Completed” but such are not supported by the vCenter Task API and we are committed to using public APIs available to all partners.

Extended coverage of plugin error scenarios

Some edge cases of plugin failures were not covered by the first version of the Plugin Management UI and those were being reported as a general error. 6.7 U3 release brings added detailed support for the following additional scenarios:

• Plugin deployment timeout: the deployment has started but is taking too long. A failure is reported but the task is not cancelled and may still succeed (e.g. on slower environments).
• Remote plugin configuration error: covers issues with registration of plugin forwarding rules with the Reverse proxy of the vCenter Server done by the vSphere Client.
• Remote plugin manifest format error: the JSON manifest does not match the schema of the remote plugin extensibility format (e.g. there is an unknown property, a value is not in range, etc.).

UX best practices added to the SDK samples

Based on the UX design guidelines for the vSphere Client the SDK has been extended with some examples of classic UX patterns for plugins.

Navigation through custom data

The app.navigateTo() in conjunction with app.getNavigationData() frontend API provides means for a plugin to navigate and pass on data from one of its views to another. The API reference contains information about how it can be used but there have been some questions from plugin writers around this capability. The bottom line is: app.navigateTo() needs to be called in the source plugin view andapp.getNavigationData() in the destination plugin view to acquire the context data the plugin wants to pass on.

With 6.7 U3 this has now been demonstrated in the HTML Sample.

Summary portlet links to Monitor/Configure view

Plugin developers often strive to make the plugin content as prominent on the UI as possible. A common and recommended pattern is to define the most important information in a portlet on the Summary view (which is the home page of an object) and provide links to the Monitor and Configure views of the plugin for more details like grids, charts, etc.

Some bugs and edge cases have also been fixed in the 6.7 U3 release. Please check the release notes for details on these.

As always, your feedback is extremely important for the future development of the plugin story and the SDK!