Question about migrating vSphere Local to Remote plugin

[radoslaw_em]

UPDATED POST:

Hi,

we're going to migrate our local plugin to a remote one. After a while of investigating we have a few questions regarding the migration key-points:

#1 Using the web-platform.js (so called Bridge API) in javascript/UI code

• We understand, that this lib is deprecated now and despite the fact that is works on vcenter 7.0 now, there is not guarantee that it will work in future version (possibly it will not). Correct?
• We should get rid of the web-platform.js usage and use only the new htmlClientSdk approach by importing and initializing this javascript library in each javascript code we use. Correct?
• Do you have any migration guide with example showing how to cope with methods which cannot be migrated using VMWare migration tool (https://vdc-download.vmware.com/vmwb-repository/dcr-public/2e8015c4-5848-44ee-8473-a77feadb9c3a/aa37...)

#2 Using com.vmware.vise.* packages in backend code:

• In our local plugin the com.vmware.vise.data.query.DataService class is injected into our code via context config file. We understand, that in order to build a project we need such dependency in local dependecies, but in runtime (when local plugin is deployed on VCenter) these classes are available and injected from VCenter context, right?
• Remote plugin backend will run on our appliance, so we cannot use com.vmware.vise.* anymore and replace all it's usages with vim25.jar. It is correct?
• Do you have any migration guide / tips regarding com.vmware.vise to vim25 migration?

#3 Our undestanding the the entire migration process:

We understand that in order to migrate the local plugin to the remote architecture, we need to cover the following things:

• We can use our current local plugin UI, but have to remove usage of web-platform.js from our UI code (#1)
• We need to introduce vim25 lib to access vcenter data and replace com.vmware.vise.* usage with vim25 (#2)
• We need to rebuild the plugin.xml to the plugin.json format
• We need to adjust our currect plugin registration process so plugin is registered as remote one (
• We need to deploy our remote plugin on our-own appliance (unlike the local plugin)

Are there any things we miss in the entire process?

Thanks,

Radek

[amarinov]

Hi @radoslaw_em,

The answers to your questions are inlined in the quote below:

---

@radoslaw_em wrote:

UPDATED POST:

Hi,

we're going to migrate our local plugin to a remote one. After a while of investigating we have a few questions regarding the migration key-points:

#1 Using the web-platform.js (so called Bridge API) in javascript/UI code

• We understand, that this lib is deprecated now and despite the fact that is works on vcenter 7.0 now, there is not guarantee that it will work in future version (possibly it will not). Correct?
  Correct, the web-platform.js approach and APIs are not supported for remote plugins at all.
• We should get rid of the web-platform.js usage and use only the new htmlClientSdk approach by importing and initializing this javascript library in each javascript code we use. Correct?
  Correct, you should load, initialize and use the htmlClientSdk.js script located at /api/ui/htmlClientSdk.js in each HTML page provided by your plugin. You should NOT copy and bundle the htmlClientSdk.js script with your plugin.
• Do you have any migration guide with example showing how to cope with methods which cannot be migrated using VMWare migration tool (https://vdc-download.vmware.com/vmwb-repository/dcr-public/2e8015c4-5848-44ee-8473-a77feadb9c3a/aa37...)
  Not at the moment, you should follow the suggestions provided in "3. Unsupported Methods" of the guide. If these suggestions don't work for you or something is not clear you then please post further questions related to specific method migration.

#2 Using com.vmware.vise.* packages in backend code:

• In our local plugin the com.vmware.vise.data.query.DataService class is injected into our code via context config file. We understand, that in order to build a project we need such dependency in local dependecies, but in runtime (when local plugin is deployed on VCenter) these classes are available and injected from VCenter context, right?
  Correct, but this class is available only for local plugins.
• Remote plugin backend will run on our appliance, so we cannot use com.vmware.vise.* anymore and replace all it's usages with vim25.jar. It is correct?
  Correct.
• Do you have any migration guide / tips regarding com.vmware.vise to vim25 migration?
  Not at the moment, you should use the PropertyCollector and other classes provided by vim25, there is an example usage of the PropertyCollector in the remote plugin sample. Please refer to the vSphere Management SDK documentation for further details.

#3 Our undestanding the the entire migration process:

We understand that in order to migrate the local plugin to the remote architecture, we need to cover the following things:

• We can use our current local plugin UI, but have to remove usage of web-platform.js from our UI code (#1)
  Somewhat correct, you should replace the usages of the web-platform.js API with the new JS APIs, additionally the authentication flow is somewhat different, please refer to the vSphere Client SDK documentation.
• We need to introduce vim25 lib to access vcenter data and replace com.vmware.vise.* usage with vim25 (#2)
  Correct.
• We need to rebuild the plugin.xml to the plugin.json format
  Correct.
• We need to adjust our currect plugin registration process so plugin is registered as remote one (
  Correct.
• We need to deploy our remote plugin on our-own appliance (unlike the local plugin)
  Correct.

Are there any things we miss in the entire process?
Does not seem so, but please refer to the vSphere Client SDK documentation where the process should be described in details.

---

Thanks,
Aleksandar