kumargandhi16's Posts

Hi @stoevm  Thanks for checking this issue and replying I will go through shared docs and come back. **We are giving support for remote-vcp from vCenter version 8.
Hi @Denis_Chorbadzh  I checked the Java code for getUserSession()...In general what it does is read the values defined in the Configuration class, like, there are few constants defined in the class,... See more...
Hi @Denis_Chorbadzh  I checked the Java code for getUserSession()...In general what it does is read the values defined in the Configuration class, like, there are few constants defined in the class, and Java backend just sets and gets these values?, looks like they are hardcoded or reading from env fields? (Not entirely sure, I am not a Java dev) But, the getUserSession() API from the Html bridge JavaScript actually gives the serversInfo and linkedServersInfo dynamically. PFB screenshot. It's sad that htmlClientSdk (JavaScript APIs) doesn't have such API!!. We have a linked vCenters setup and we are having trouble fetching the right api-endpoint that we need to set in the headers for our API calls. PFB screenshot of out current setup. We have two plugin instances, each with its own vCenter. Now the problem is getting the right api-endpoint for the selected plugin instance. PFB code for the three headers we set in the remote-vcp UI code.   // Below are the headers we set for UI API calls. getHttpClientHeaders(): any { return { "vcenter-guid": this.getGUID(), "vmware-api-ui-endpoint-url": this.getUIApiEndpointUrl(), "vmware-api-session-id": this.getVMwareAPISessionId() }; } // Below fetching the API end point, but what about for linked setup!! getUIApiEndpointUrl() { return this.gs.getClientSdk().app.getApiEndpoints().uiApiEndpoint.fullUrl; }   Can you please provide some feedback? Thanks.
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 ar... See more...
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.
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 h... See more...
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.
Hi, I made a post with questions regarding the same. Can you please check the post and reply?. Developing remote plugin and found different JavaScript interfaces and manifest file type. Tryin... See more...
Hi, I made a post with questions regarding the same. Can you please check the post and reply?. Developing remote plugin and found different JavaScript interfaces and manifest file type. Trying to understand the thin… Also i would like to know how long before the Html bridge APIs is completely removed so i can plan to migrate to new JS APIs?. Please let me know, thanks.
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 i... See more...
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.