_vladi_'s Posts

Please use the legacy vSphere Web Client SDK 6.5: vSphere Web Client SDK - VMware {code} Download the 6.5U1 one. You can both check the code or try reproducing this against the WSSDK sample. Cheers, Vladi

Hi, I don't see an issue with the code above. My suggestion is to test without the PropertyConstraint first to make sure there is no error in the rest of the code. Also please try and compare to the WSSDK and other samples from the 6.5U1 SDK which demonstrate such filtering. Cheers, Vladi

Hi, It depends on the use case: If you want to undeploy the plugin from all vSphere Client instances connected to the (possibly multi-vCenter) environment, use the UnregisterExtension API of the vCenter ExtensionManager. If you want to block deployment of the plugin on a particular vSphere Client instance, mark it as incompatible in the compatibility-matrix.xml on the vCenter Server. This could probably be automated but please keep in mind the folder location of the matrix is not a public API and might change in future versions. If you want to keep the plugin deployed but hide its extensions on a particular vSphere Client instance, disable it from the Client Plugins view. There is no public API to achieve this. Normally, the management of plugins is not supposed to be done by the plugin itself but handled externally via the vCenter Server APIs (point 1 above). If you have a specific use case that does not fit this picture please provide more details so we analyze further. Thanks! Cheers, Vladi

Isolation of plugin views require them to be in iframes so the content will always load from scratch. Out of the box is what you can't do at the moment. Nevertheless: within the plugin.xml you can use URL params when navigating from one plugin view to another you can call the app.navigateTo JS API with custom data In both cases the vSphere Client platform can only navigate you to the iframe and any further customizations of routing to sub-pages are entirely on the plugin side. Cheers, Vladi

Hi, The plugin manifest does not provide extensibility for this kind of routing (or deep linking) out of the box. That said, you can specify parameters in the <url> that you could later handle and switch to a sub-view. Cheers, Vladi

Hm, to me it sound like throwing it in each view is exactly where it is supposed to show up as it is applicable to the plugin operations inside the iframe, not to the HTML Client as a whole. If I misunderstood you please elaborate on what you mean by connection to appropriate version (it is not clear what connection you are talking about and version of what you are referring to, the plugin version?)

Hi, This is not available to plugins. You can show alerts on a view level (within the plugin iframe). Globally, the best practice is to create vCenter tasks for operations which are long-running or might fail. In this case the Task panels would provide notification to the user for the success/failure of the operation. As this is not the first time I hear this question: could you please share what kind of use case you would use the global alerts for? Thanks, Vladi

Hi Kumar, This is a nice overview of the Dev process and I will share this with PMs. There are different considerations at play here so we have to strike the right balance: Partners migrate to Remote plugins because they are better in linked environments and in the Hybrid Cloud world, not because they are forced to migrate away from a dying Flex Client. Remote plugins were designed to use mostly the same set of frontend APIs which means you can reuse the UI you already developed (just move the UI to be served from your backend). In a way you can keep using the Plugin Seed in standalone mode to develop the UI. For Remote plugins you just need to change how you package/deploy the UI on your appliance, not how you do web development. Based on this, the approach you have specified works well if you are building a plugin UI from scratch (which you had to do for Flex -> H5 migration). For partners building Remote plugins from scratch we might consider providing Plugin Seed-like tooling. Nevertheless, most partners (like yourself) would rather need Local-to-Remote plugin migration tools to achieve exactly time-to-market requirements your management wants. Hence, in latest 6.7 releases we shipped the SDK with Local-to-Remote plugin conversion tools: Migration To The New JavaScript API manual guide and automatic tool (migrates Bridge API calls to new JS API calls) Plugin Manifest Converter tool (migrates plugin-package.xml / plugin.xml to plugin.json manifest) It would be great if you have any feedback on these (though you probably don't need the first one). There is also the possibility to do Standalone UI to Remote plugin integration which some partners prefer. In summary (for your management ): Migration to a Remote plugin is a lot cheaper from UI migration perspective. It might take more effort only if the Java middle-tier has been heavy (which was not recommended for local plugins anyway). Always happy to jump on a call and discuss details and feedback if needed. Cheers, Vladi

Thanks, Kumar! This is good feedback. The SDK does not impose restrictions on technologies to use for web development. That said, we do understand the need for improved tooling and updated sample tech stack. We are actively working on it but will probably not be exactly as Plugin Seed. Please do let us know if you found particular features of the Plugin Seed very useful and in what way (so we could possibly incorporate this going forward). For example: have you actively used both Dev and plugin mode? What was your dev process with the Seed? Cheers, Vladi

Hi Kobi, From all this info it seems strange that you are getting the catalogs only in the vmware-vpx folder but not in the cmCatalog. This makes me think that the registered localization bundles have not been attached to the actual extension. Still need to try this out locally but in the meantime could you please let me know or provide a code snippet of how the vCenter extension registration is done (especially interested in how the resourceList is set and how the bundles get registered) ? Thanks. Cheers, Vladi

Hi Kobi, I see the following logs: [2020-01-08T13:48:25.724Z] [INFO ] cm-catalog-manager-pool-124  70000179 100018 200002 com.vmware.vise.vim.lookup.LsCatalogManager                       detectServiceProviders took (ms):514 [2020-01-08T13:48:25.744Z] [INFO ] cm-catalog-manager-pool-124  70000179 100018 200002 com.vmware.vise.vim.lookup.LsCatalogManager                       No new locales or service infos to download. This is surprising given the registration should be there. I will try to reproduce this in house. Thanks! Cheers, Vladi

Hi Kobi, I had a deeper look at the details provided. The H5 Client logs are from 2019-12-23. Unfortunately based on the screenshots the extension and the localization files have been registered on 2020-01-01 which is later. Generally the Client downloads the resource bundles on startup and updates with any new bundles on user login so I would like to check what the H5 Client did after the registration. Could you please provide the latest vsphere_client_virgo.log after the time of registration? Thanks, Vladi

Hi Kobi, There are multiple MOBs: /mob is for the current vCenter Server MOB /cm/mob is for the legacy MOB of the ComponentManager which spans across all linked vCenter Servers /lookupservice/mob is for the MOB of the LookupService (successor of ComponentManager) which also spans across all linked vCenter Servers Tasks are uniquely created per-vCenter Server so you have used the right one: /mob The setup with your tasks seems correct. Next thing to check is if you can find the catalog with this ID and localization strings in /etc/vmware/vsphere-ui/cmCatalog If yes, it might be some weird formatting requirement (try removing underscores?). Please let us know how it goes. We will also try to reproduce it with the data provided. Thanks! Cheers, Vladi