amarinov's Posts

Hi @harsha219, Are you using the SessionManager.cloneSession() API or the SessionManager.acquireCloneTicket() API of the vSphere Management SDK after obtaining the session clone ticket? Thanks, Aleksandar

Hi @radoslaw_em, I've inlined the answers to your questions in the quote below: @radoslaw_em wrote: Hi @amarinov , I see that our local plugin we currently have, makes use of the libs/packages mentioned by @Sinica87. Just to mention a few usages: PropertyProviderAdapter (implemented by our subclasses), DataProviderAdapter (implemented by our subclasses) Provider Adapters are then registered in DataServiceExtensionRegistry classes other classes like userSessionService, VimObjectRefereneService are also injected in our domain classes: ... <bean name="ourPropertyProviderImpl" class="com.our.package.OurPropertyProviderImpl"> <constructor-arg ref="userSessionService"/> <constructor-arg ref="vimObjectReferenceService"/> <constructor-arg ref="dataServiceExtensionRegistry"/> <constructor-arg ref="ssoServiceImpl"/> </bean> .. I understand that in local plugin these classes are available on vCenter tomcat on which the entire plugin is deployed. It also means, that - for example - a DataService injected in our code comes directly from vCenter's tomcat beans which are already there? It that correct? Correct. In case of the remote plugin we should replace all occurences of com.vmware.vise.* classes with vim25, right? Correct. Correct me if I'm worng but I guess, there is no one-to-one correlation between com.vmware.vise.* and vim25 classes. So is there any migration guide similar to the one for created for frontend api changes but dedicated to backend? Yes, there is no one-to-one correlation. There is no such migration guide 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. Thanks, Aleksandar

  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/aa3773f9-62bf-476a-8703-4ce7f1e990be/Migration-To-JS-APIs.html) 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  

Hi @kaustubh_aphale, You will need to use the the vim25 API or the vAPI to retrieve the necessary data. Eventual data caching should happen on the plugin server, invalidating the cache is a different matter which you should handle on your side. The SDK cannot provide any cached tree hierarchy. Thanks, Aleksandar

Hi @kaustubh_aphale,   The vSphere Client retrieves the hierarchy nodes on demand i.e. the children of a node are retrieved on-demand only when that node gets expanded for the first time. The reason for this is that retrieving the full hierarchy would require multiple calls (the number of calls is equal to number of non-leaf nodes in the desired sub-tree) as first the top-level node has to be retrieved, then all of its child nodes, then all of its grandchild nodes and so on.   Do you have a local or a remote plugin? What do you need this hierarchy for?   Thanks, Aleksandar

Hi @Jomass, This is not the correct sub-forum for your query. Please try posting your question to the vSphere-Management-SDK sub-forum https://communities.vmware.com/t5/vSphere-Management-SDK/bd-p/4524. Thanks, Aleksandar

Hi @kumartade  Your findings are correct i.e. the only view currently supported is the global "administration.ceip" view. Can you elaborate your use case to navigate to specific view(s)? Can you list the views you need to be able to navigate to? Thanks, Aleksandar

Hi @DarkEthanol, The sub-forum related to the SDK you are using is vSphere Management SDK Discussions (https://communities.vmware.com/t5/vSphere-Management-SDK/bd-p/4524), please post your question there. Thank you, Aleksandar

Hi @kumartade, As evident by the error "Refused to apply style from 'https://10.60.6.6/plugins/com.acme.plugin.remote~1.0.0.0~-1202886956/styles.css' because its MIME type ('text/plain') is not a supported stylesheet MIME type, and strict MIME checking is enabled." it seems that the http-party/http-server you are using does not return the correct MIME type for the CSS file and the browser refuses to render the CSS. There is an open issue in the GitHub page of http-party/http-server about additional mime types support: https://github.com/http-party/http-server/issues/35. Please try using another server that has the necessary mime types support. Thanks, Aleksandar  

Hi Shravan, 1. Is it possible to achieve the singleton plugin instance working using the given sdk sample and tools? If so what is the command options we should use to support multiple vCenters? The provided sample does not support working with multiple vCenters. 2. What are the file/function changes we need to make in service/ui code to support this routing? - Your plugin should accept multi-VC configuration at startup. Instead of passing multiple command line parameters in the form: "--vcenter.guid=5xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx --vcenter.thumbprint=1xxxxxxxxxxxxxxxxxxxxxxxxxx --vcenter.fqdn=vc1.com --vcenter.port=443" you should pass a JSON file that contains an array of VC configurations and parse that file to a Java object using Jackson or a similar library. - When your plugin front-end is making a call for a specific object you should pass the target object ID and target VC GUID as part of the REST call. Then your plugin backend should make an API call to that VC, whose IP it should derive from the target VC GUID and plugin configuration. E.g. a view of your plugin is rendered in Cluster -> Monitor and you want it to show some properties of the cluster, then your REST call should contain the cluster object ID and the VC GUID. - When your plugin front-end is making a call that queries all VCs with which your plugin is registered, then the respective plugin backend API should query all VCs present in the plugin configuration. E.g. your plugin has a global view that has to display some properties of all VCs with which your plugin is registered. Thanks, Aleksandar

Hi Kumar, It's recommended to use the newest version of Google Chrome, as we expect that vSphere UI users will be using the latest (or close to latest) version available as Chrome is usually auto-updated. Also the version of Chrome you are using is very old (it has been released at the end of 2018) and does not contain security patches, bug fixes, etc. Thanks, Aleksandar

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.

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/2b52b8aa-7006-45a6-a517-c6b069f01e8e/extension_ref.html).

Hi, To clear things up: if you add scope="global" to your plugin-package.xml your plugin starts working and when you remove the scope="global" it stops working? Did you try deploying and testing your plugin on other vCenter Server versions, what was the result? Can you provide the full logs of vSphere UI server? If you are running a local vSphere UI server as part of the SDK artifact then the logs are located in "html-client-sdk\vsphere-ui\server\logs" on your local machine. If you are deploying your plugin directly on the vCenter Server then the logs are located in "/var/log/vmware/vsphere-ui" on your vCenter Server. Thank you!

/var/log/vmware/vsphere-uiHi, Can you please try to register your plugin in the vCenter Server so that your plugin is deployed as it would be in a user environment? The idea behind this is not to use the "pickup" folder of the vSphere UI server. In either case can you provide the full logs of vSphere UI server? If you are running a local vSphere UI server as part of the SDK artifact then the logs are located in "html-client-sdk\vsphere-ui\server\logs" on your local machine. If you are deploying your plugin directly on the vCenter Server then the logs are located in "/var/log/vmware/vsphere-ui" on your vCenter Server. Thank you!