Developing remote plugin and found different JavaScript interfaces and manifest file type. Trying to understand the things.

[kumargandhi16]

Hi,

We have developed a vCenter Html plugin two years back with technologies in UI like, Angular, Clarity design system .... There was also lot new developments on the backend.

Now we are in the process of developing remote plugin.

First off i am trying to research / understand what is the difference between the previous one and the new remote plugin?. Any pointers in this regard... (I am reading the vsphere-client-sdk-673-remote-programming-guide.pdf for now)

Also while going over the documentation of vsphere-client-sdk-673-remote-programming-guide.pdf found few new things, like below.

• In the documentation it says to use the new plugin user JavaScript interfaces with htmlClientSdk.js, called, model, app, event... But in our existing plugin-ui we were using WEB_PLATFORM referencing from window.parent.
• Found the plugin manifest file type is changed to plugin.json. Previously it was plugin.xml file with its own definitions of plugin, resources, extension.. Now I am not sure how much of this is supported with new format of manifest file type plugin.json.

Now should we update our plugin code as per new guide. I am seeing in the guide that accessing window.parent is not recommanded... PFA screenshot.

Please share few inputs, thanks.

[amarinov]

Hi,

In general:
The main difference between local and remote plugins is that remote plugins run on a separate appliance i.e. it they do not run in the vSphere UI server (Virgo). It is up to the remote plugins to provide their backend appliance.
Remote plugins running in a separate appliance solve the issue of shared dependies between the core vSphere UI and plugins and it also allows remote plugins' backend to be written a language different than Java.

Now on the other two questions:
> In the documentation it says to use the new plugin user JavaScript interfaces with htmlClientSdk.js, called, model, app, event... But in our existing plugin-ui we were using WEB_PLATFORM referencing from window.parent.
Generally the SDK does not support and does not recommend accessing properties of window.parent except in the case of the legacy API WEB_PLATFORM API. Your plugin should not need to access window.parent properties when using the newer JavaScript APIs for both local and remote plugins. The reason for not supporting and not recommending accessing properties of window.parent is that these properties might get removed or changed. Also for remote plugins it is possible that the plugins isolation level is increased in the future and then accessing such properties might throw a security error. After a remote plugin loads the "htmlClientSdk.js" artifact and initializes the SDK then all remote plugin APIs will be available in window.htmlClientSdk under their respective sub-categories.

> Found the plugin manifest file type is changed to plugin.json. Previously it was plugin.xml file with its own definitions of plugin, resources, extension.. Now I am not sure how much of this is supported with new format of manifest file type plugin.json.
The new plugin manifest format is much simpler than the old one. You don't need to use complex extensions and extension points any more as in the new format the set of extension points and the way extension are described is simplified. As a result of this the new format does not support all of the old format's extension points. The new format allows the SDK to validate a remote plugin's manifest during deployment and fail the deployment if the manifest does not have the correct format e.g. missing required properties, misstyped properties, non-existing properties, invalid property values or types etc. The full description of the new format schema can be found here: https://code.vmware.com/web/sdk/67/client -> vSphere Client Remote Plug-in Extensions Reference (https://vdc-download.vmware.com/vmwb-repository/dcr-public/158d4b12-3175-4913-8da3-a0a7b2b58a5b/2b52...).

[kumargandhi16]

Hi,

Thanks for the quick reply.

Thanks for explaining difference between the local and remote plugin.

Our plugin developed back in early 2018 (previously it was a Flex UI plugin so we have moved to Html UI plugin) is using the WEB_PLATFORM APIs as per the vSphere standards back then. While researching about the remote-plugin development found that there is new changes like new APIs and plugin.json file...

Now the question is should we migrate to the new JavaScript APIs using the htmlClientSdk.js. If we have to migrate how long is the task?.

We are also thinking to keep the plugin-ui code as is (not migrate to new JavaScript APIs right now) if this is taking time or if we think the support for WEB_PLATFORM APIs is still available via vSphere Client UI for at-least a year maybe and plan the migration after doing the necessary research.

Can you please let me know what you think.

Also our plugin is in a separate repository before and now we are planning to move to new repository with new structure and everything, Is this necessary change?. PFB screenshot where we will have the plugin ui code.

Thanks.

[amarinov]

Hi,

I would suggest that you start migrating your plugin to a remote plugin. If you hit any issues while migrating please feel free to ask questions or contact us so we can resolve the issues or implement the necessary changes if needed. We're still supporting the WEB_PLATFORM APIs in the vSphere 7.0 release.

It's hard to estimate how long the migration will take without knowing how and which JS APIs your plugin is using. Some of the old JS APIs do not have an equivalent in the new JS APIs and would require bigger changes in the plugin code. Also remote plugin architecture is different than local plugin architecture in several ways. Additionally you have to take into consideration what extension points your plugin is utilizing now and whether they have a remote plugin equivalent, if they don't you will have to make changes to the plugin UX.

Additionally we've provided a migration tool for remote plugins, you can find it on the SDK home page.

Thanks.

[kumargandhi16]

Hi,

Thanks for the reply.

It's good to know that WEB_PLATFORM APIs are still supported in vSphere 7.0. This will certainly give us needed time to migrate.

Our plugin is really vast we are using so many APIs and extensions. I am not sure if i can share more information in this regard (I will get approval from my manager), but we have extensions with extendedPoint like "vsphere.core.datastore.summarySectionViews, vsphere.core.datastore.monitorCategories, vsphere.core.datastore.monitorViews ....", so if few of these extensions are not supported then we will have to look at new UX as you mentioned and this we can only plan after doing the necessary research.

Maybe for now we will move our code base of the plugin-ui to the new folder structure (remote-vcp/src/main/ui) and just change the wiring of the endpoints and plan the migration with a future release.... Question: Why do we have a ui folder here, i understand this is the location of the plugin-ui, so when vCenter is registered will this be plugin-ui that is deployed in the vSphere Client UI of the vCenter.

I will check out the migration tool you mentioned in the SDK, I also found one post on this - Migration Tool for new JavaScript API

Also i am still trying to understand the remote plugin architecture, different from local plugin architecture!!, I am doing some reading... can you please share some docs or videos in this regard.

Thanks.