Post on 06-Sep-2020
Table of ContentsLab Overview - HOL-2012-04-SDC - Building a Remote Plugin for the vSphere Client ......2
Lab Guidance .......................................................................................................... 3Module 1 - Quick start with remote plugin development (30 minutes) .............................9
Introduction........................................................................................................... 10Step 0: Create, build and deploy a remote plugin skeleton project within a fewminutes ................................................................................................................. 16Step 1: Enhancing remote plugin prototype with a new extension .......................19Step 2: Create UI content for extensions .............................................................. 20Conclusion............................................................................................................. 25
Module 2 - Enhancing the Remote plugin logic and UI (30 minutes)...............................26Step 3: Using the vSphere Client front-end API .................................................... 27Step 4: Using the navigation API ........................................................................... 29Step 5: Using the localization API.......................................................................... 31Conclusion............................................................................................................. 34
Module 3 - Remote Plugin Lifecycle (15 minutes) ........................................................... 35Introduction........................................................................................................... 36Plugin Upgrade...................................................................................................... 37Conclusion............................................................................................................. 39
HOL-2012-04-SDC
Page 1HOL-2012-04-SDC
Lab Overview -HOL-2012-04-SDC -
Building a Remote Pluginfor the vSphere Client
HOL-2012-04-SDC
Page 2HOL-2012-04-SDC
Lab GuidanceNote: It will take about 60 minutes to complete this lab. While modules aremostly independent it is recommended to complete them in the given order.
The Table of Contents can be accessed in the upper right-hand corner of theLab Manual.
Lab Abstract:
This lab in a quick introduction to developing Remote plugins for the vSphere Client. Itserves as a demonstration of how easy it is to do a proof of concept for integrating withthe vSphere Client.
The Remote plugin architecture serving as the foundation of the mechanisms in this lablays at the core of the vSphere Client for both vSphere and VMware Cloud. It is alsochosen and the only supported architecture for integrating UI plugins with VMwareCloud on AWS.
Lab Module List:
• Module 1 - Quick Start with Remote Plugin Development (25 minutes) (Basic)• Module 2 - Enhancing the Remote Plugin Logic and UI (20 minutes) (Basic)• Module 3 - Remote Plugin Lifecycle (15 minutes) (Basic)
Lab Captains:
• Vladimir Velikov - Senior Member of Technical Staff• Martin Stoev - Member of Technical Staff
This lab manual can be downloaded from the Hands-on Labs Document site found here:
http://docs.hol.vmware.com
This lab may be available in other languages. To set your language preference and havea localized manual deployed with your lab, you may utilize this document to help guideyou through the process:
http://docs.hol.vmware.com/announcements/nee-default-language.pdf
HOL-2012-04-SDC
Page 3HOL-2012-04-SDC
Location of the Main Console
1. The area in the RED box contains the Main Console. The Lab Manual is on the tabto the Right of the Main Console.
2. A particular lab may have additional consoles found on separate tabs in the upperleft. You will be directed to open another specific console if needed.
3. Your lab starts with 90 minutes on the timer. The lab can not be saved. All yourwork must be done during the lab session. But you can click the EXTEND toincrease your time. If you are at a VMware event, you can extend your lab timetwice, for up to 30 minutes. Each click gives you an additional 15 minutes.Outside of VMware events, you can extend your lab time up to 9 hours and 30
minutes. Each click gives you an additional hour.
Alternate Methods of Keyboard Data Entry
During this module, you will input text into the Main Console. Besides directly typing itin, there are two very helpful methods of entering data which make it easier to entercomplex data.
HOL-2012-04-SDC
Page 4HOL-2012-04-SDC
Click and Drag Lab Manual Content Into Console ActiveWindow
You can also click and drag text and Command Line Interface (CLI) commands directlyfrom the Lab Manual into the active window in the Main Console.
Accessing the Online International Keyboard
You can also use the Online International Keyboard found in the Main Console.
1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.
<div class="player-unavailable"><h1 class="message">An error occurred.</h1><div class="submessage"><ahref="http://www.youtube.com/watch?v=xS07n6GzGuo" target="_blank">Try watching this video on www.youtube.com</a>, or enableJavaScript if it is disabled in your browser.</div></div>
HOL-2012-04-SDC
Page 5HOL-2012-04-SDC
Click once in active console window
In this example, you will use the Online Keyboard to enter the "@" sign used in emailaddresses. The "@" sign is Shift-2 on US keyboard layouts.
1. Click once in the active console window.2. Click on the Shift key.
Click on the @ key
1. Click on the "@ key".
Notice the @ sign entered in the active console window.
HOL-2012-04-SDC
Page 6HOL-2012-04-SDC
Activation Prompt or Watermark
When you first start your lab, you may notice a watermark on the desktop indicatingthat Windows is not activated.
One of the major benefits of virtualization is that virtual machines can be moved andrun on any platform. The Hands-on Labs utilizes this benefit and we are able to run thelabs out of multiple datacenters. However, these datacenters may not have identicalprocessors, which triggers a Microsoft activation check through the Internet.
Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoftlicensing requirements. The lab that you are using is a self-contained pod and does nothave full access to the Internet, which is required for Windows to verify the activation.Without full access to the Internet, this automated process fails and you see this
watermark.
This cosmetic issue has no effect on your lab.
Look at the lower right portion of the screen
HOL-2012-04-SDC
Page 7HOL-2012-04-SDC
Please check to see that your lab is finished all the startup routines and is ready for youto start. If you see anything other than "Ready", please wait a few minutes. If after 5minutes your lab has not changed to "Ready", please ask for assistance.
HOL-2012-04-SDC
Page 8HOL-2012-04-SDC
Module 1 - Quick startwith remote plugindevelopment (30
minutes)
HOL-2012-04-SDC
Page 9HOL-2012-04-SDC
IntroductionDuring this lab you will learn how to create a new vSphere Client plugin based on theRemote plugin architecture introduced in vSphere Client 6.7 Update 1 and chosen as thefuture-proof platform for building UI extensions for vSphere and VMware Cloud.
You will be using the vSphere Client SDK and get to know a number of APIs and bestpractices.
The easiest way to kick off remote plugin development is to see a skeleton project inaction. In the vSphere Client SDK this is the remote plugin starter sample.
This Module contains the following lessons:
• Step 0: Create, build and deploy a remote plugin skeleton project within a fewminutes
• Step 1: Enhancing remote plugin prototype with a new extension• Step 2: Create extension UI view
Before going hands-on let's first get an overview of what the vSphere Client SDK andremote plugins are all about...
HOL-2012-04-SDC
Page 10HOL-2012-04-SDC
vSphere Client SDK
vSphere Client SDK is a collection of libraries, tools, code samples and documentationthat help you create vSphere Client HTML extensions to provide customized solutions inthe vSphere UI.
vSphere Client Extension Points
Extension points are the various places where a plugin can insert its own UI elementsinside the vSphere Client in order to provide additional functionality. The nextscreenshots describe the main extension points.
HOL-2012-04-SDC
Page 11HOL-2012-04-SDC
The left navigator and the main menu allow to add links as single entry points to theplugin UI.
The picture below is an example of a plugin global view, i.e. a view taking the wholeworkspace area, not related to any inventory object context on the left.
Global views are used by plugins to display their standalone UI, custom inventories,plugin-wide settings or server administration.
The Monitor and Configure tabs of vCenter Server inventory objects can be extendedto include plugin views.
HOL-2012-04-SDC
Page 12HOL-2012-04-SDC
Plugins can also insert a portlet which is a section view in the Summary page ofvCenter Server inventory objects, i.e. a small area containing key plugin information.
Plugins can extend menus with their own sub-menus. Such menu items bring up amodal dialog or wizard to collect the user input before calling the back-end server toexecute an operation.
HOL-2012-04-SDC
Page 13HOL-2012-04-SDC
Local vs. Remote Plugin Architecture
Since vSphere 6.7 Update 1 the vSphere Client supports the Remote pluginarchitecture next to the aging Local plugin architecture.
The main difference is that local plugins rely on a Java service deployed inside thevCenter Server to communicate with external backend servers while remote plugins talkdirectly to their plugin backend server through the reverse proxy of the vCenter Server.
The remote plugin approach is significantly superior to the local plugin mechanisms in anumber of areas:
1. There are no executable plugin bits inside the vCenter Server improvingstability of the vCenter Server product and ability to troubleshoot issueswith vendor plugins.
HOL-2012-04-SDC
Page 14HOL-2012-04-SDC
2. vCenter Server upgrade can take place independently from external solutions.3. Support for multiple plugin versions and multiple plugin instances within
Linked vCenter Server environments.4. Freedom of technology stack to use by plugin vendors (no Java or OSGi
requirements).5. Improved performance of the vSphere Client and the plugin itself.
Although currently vSphere Client supports both architectures Remote plugins areconsidered the future of UI integration with vSphere and VMware Cloud!
So let's get started...
HOL-2012-04-SDC
Page 15HOL-2012-04-SDC
Step 0: Create, build and deploy aremote plugin skeleton project withina few minutesIn this section we will setup the project and setup the framework to extend the vSphereClient.
Build the remote plugin sample starter
The remote plugin sample starter is a skeleton project of a remote plugin containing noreal UI implementation but establishing the framework to easily integrate extensionswith the vSphere Client.
Open a Command prompt terminal
C:\Users\Administrator>_
Go to step 0
cd C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter
Build the starter project with Maven
mvn clean install
Start the plugin server
The built remote plugin sample starter project is a SpringBoot application.
It needs to be started to be ready to receive requests from the vCenter Server's vSphereClient app and serve the plugin UI content.
java -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Register the plugin to the vCenter Server
To make the remote plugin discoverable by the vSphere Client it needs to be registeredas a vCenter Server extension.
HOL-2012-04-SDC
Page 16HOL-2012-04-SDC
This is usually done by a vendor installer talking to the vCenter Server'sExtensionManager API. The SDK contains a registration script for the same purpose thatcan be extended by the developer or used as-is.
Open a new Command window and execute the script as follows:
"%VSPHERE_SDK_HOME%\html-client-sdk\tools\vCenter plugin registration\prebuilt\extension-registration.bat" -action registerPlugin -url "https://vcsa-01a.corp.local/sdk" -pu "https://192.168.110.10:8443/sample-ui/plugin.json" -c VMware -k sample -u"Administrator@corp.local" -p VMware1! -v 1.0.0 -st"55:5d:b1:0d:e0:33:3e:10:ab:1e:f4:86:62:61:f0:7f:93:fe:f6:9b" -remote --name myplugin--summary "Sample Plug-in"
The above command uses the following data required as input:
• vcsa-01a.corp.local is the vCenter Server address• 192.168.110.10 is the local IP• 55:5d:b1:0d:e0:33:3e:10:ab:1e:f4:86:62:61:f0:7f:93:fe:f6:9b is the thumbprint of the
SpringBoot application serving the Remote plugin. It can normally be discoveredby navigating to https://192.168.110.10:8443/sample-ui/plugin.json in thebrowser and going to Not Secure -> Certificate -> Details -> Thumbprint.The thumbprint needs to be formatted to use a colon separator : after everypair of characters.
HOL-2012-04-SDC
Page 17HOL-2012-04-SDC
See the integrated plugin in the vSphere Client
Open the vSphere Client at https://vcsa-01a.corp.local/ui, login with the standard labcredentials (Administrator@corp.local / VMware1!) and click on the vSphere Client Homeicon. Verify that the name myplugin provided during registration is shown in the Clientplug-ins administration view and the display name vSphere HTML SDK Sample isshown in the left navigator and the main menu.
HOL-2012-04-SDC
Page 18HOL-2012-04-SDC
Step 1: Enhancing remote pluginprototype with a new extensionAdding new extensions required by the plugin use cases is straightforward. In the nextpages we will cover some common scenarios.
Create a new Datacenter summary portlet extension
View the extension in the vSphere Client
Rebuild the sample and restart the server
mvn clean installjava -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Within the vSphere Client in the browser go to Host and Clusters and select one of theexisting datacenters (e.g. RegionA01). Refresh the browser.
The new plugin portlet is displayed on the Summary page and its simple content isdisplayed.
HOL-2012-04-SDC
Page 19HOL-2012-04-SDC
Step 2: Create UI content forextensionsThis section will prepare the plugin server to handle HTTP requests and serve the plugincontent.
Implement the backend controller
Go to C:\labfiles\HOL-2019\store\step 2\ folder and copy the BasicController.java .
Go to C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\java\com\vmware\sample\remote and create a new folder named controller .
Paste the BasicController.java into the controller folder.
The only thing this controller does at this point is listening for GET requests to /rest/base/{objectId}
@RestController@RequestMapping("/rest/base")public class BasicController {
@RequestMapping(value = "/{objectId}", method = RequestMethod.GET)public String backendGreeting(@PathVariable("objectId") final String objectId) {
return "Hello from backend " + objectId;}
}
Register the controller with the SpringBoot app
Copy file C:\labfiles\HOL-2019\store\step 2\spring-context.xml inside C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources .
This makes sure the basicController bean is created on startup.
Copy file C:\labfiles\HOL-2019\store\step 2\SpringBootApplication.java inside C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\java\com\vmware\sample\remotereplacing the old version of the file.
This wires spring-context.xml with the SpringBoot application startup.
Now the BasicController is fully configured.
HOL-2012-04-SDC
Page 20HOL-2012-04-SDC
@ImportResource("classpath:spring-context.xml")@org.springframework.boot.autoconfigure.SpringBootApplicationpublic class SpringBootApplication {
public static void main(String[] args) {HttpsURLConnection.setDefaultHostnameVerifier(NoopHostnameVerifier.INSTANCE);SpringApplication.run(SpringBootApplication.class, args);
}}
Add the HttpClient dependency
To enable HTTP communication to and from the plugin server it needs to be configuredto use the HttpClient library.
Copy file C:\labfiles\HOL-2019\store\step 2\pom.xml inside C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\ replacing the old version of the file.
org.apache.httpcomponentshttpclient
Add a new Host menu action
Let's create one more extension as part of this remote plugin: an action this is displayedwhen the user opens the contextual menu of a Host.
To do this copy a new version of the plugin.json manifest from C:\labfiles\HOL-2019\store\step 2\ to C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static\ replacing the old version of the file.
"HostSystem": {"menu": {
"actions": [{
"labelKey": "RemoteSample:backup.action","icon": {
"name": "main"},"trigger": {
"type": "modal","uri": "index.html","titleKey": "RemoteSample:backup.action","size": {
"height": 250,
HOL-2012-04-SDC
Page 21HOL-2012-04-SDC
"width": 500}
}}
]}
}
This extension definition introduces a new Host menu action with the given labelKey andicon . Upon clicking the action menu item a new modal dialog is triggered which has theprovided titleKey and size (in pixels). The content of the modal dialog is againretrieved from the plugin server at the specified uri .
View the extensions in the vSphere Client
Rebuild the sample and restart the server
mvn clean installjava -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Within the vSphere Client in the browser go to Host and Clusters and select one of theexisting datacenters (e.g. RegionA01). Refresh the browser.
The new plugin portlet is displayed on the Summary page and now its content is servedfrom remote plugin server (our example SpringBoot app).
HOL-2012-04-SDC
Page 22HOL-2012-04-SDC
Right-click on a Host (e.g. esx-01a.corp.local), navigate to the vSphere Client SDKSample sub-menu and select the new Backup action.
HOL-2012-04-SDC
Page 23HOL-2012-04-SDC
A modal dialog is opened with UI data also loaded from the plugin server.
HOL-2012-04-SDC
Page 24HOL-2012-04-SDC
ConclusionCongratulations! You now know how to create, build and deploy a remoteplug-in,
how to define additional extensions in the plug-in manifest file and
how to load views which contain data from the plug-in server.
You've finished Module 1
Congratulations on completing Module 1.
If you are looking for additional information on vSphere Remote Plug-in creation, try onethese:
• vSphere Client SDK homepage• Developing Remote Plug-ins with the vSphere Client SDK• vSphere Client Remote Plug-in Extensions Reference
Alternatively, have a look at the Remote plugin sample part of the vSphere ClientSDK deliverable which demonstrates the remote plugin extensibility best practices andis based on Clarity design system, Angular and Typescript.
HOL-2012-04-SDC
Page 25HOL-2012-04-SDC
Module 2 - Enhancing theRemote plugin logic and
UI (30 minutes)
HOL-2012-04-SDC
Page 26HOL-2012-04-SDC
Step 3: Using the vSphere Client front-end APIEssential part of the plugin integration is its usage of the front-end APIs to retrievecontext from the vSphere Client and perform operations.
Let's go through the most common use cases...
Create a new Datacenter monitor view extension
Copy the C:\labfiles\HOL-2019\store\step 3\plugin.json file and replace the one inC:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static .
In the current example a new monitor view is added to all Datacenter objects in theinventory.
"monitor": {"views": [
{"labelKey": "RemoteSample:datacenter.monitor","uri": "datacenter_monitor.html"
}]
}
Implement monitor view UI
Go to C:\labfiles\HOL-2019\store\step 3\ folder and copy the datacenter_monitor.html toC:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static .
This html file first bootstraps the vSphere Client front-end API. The API is delivered bythe vSphere Client inside the plugin iframe as htmlClientSdk JavaScript object but it stillneeds to be initialized by the plugin view with a call to htmlClientSdk.initialize() .
The monitor view UI content defines a simple button that demonstrates the usage of theapp.getContextObjects() front-end API and displays its result. In this case it is the id of thecurrently selected datacenter.
View the data center monitor view in the vSphere Client
Rebuild the sample and restart the server
HOL-2012-04-SDC
Page 27HOL-2012-04-SDC
mvn clean installjava -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Within the vSphere Client in the browser go to Host and Clusters and select one of theexisting datacenters (e.g. RegionA01). Refresh the browser.
The new plugin monitor view is displayed in the table of contents of the Monitor page.It resides in its own category carrying the plugin name which is automatically created bythe vSphere Client.
The datacenter monitor view shows a button to retrieve the current context object.Upon click the full datacenter reference id is displayed.
HOL-2012-04-SDC
Page 28HOL-2012-04-SDC
Step 4: Using the navigation APITo provide plugin workflows consistent with the vSphere Client the plugin APIs supportnavigation from one remote plugin view to another.
This is possible via the app.navigateTo front-end API.
Enabling navigation to a plugin extension
Extensions must explicitly allow being navigated to. This is achieved by providing adedicated navigationId of the extension within the plugin.json manifest.
The navigationId must be unique within the scope of the plugin manifest. Uniquenessacross plugins is ensured by the vSphere Client so the navigationId can but does nothave to include namespaces.
Let's provide a navigationId to the monitor view extension of the remote plugin.
To do this copy the C:\labfiles\HOL-2019\store\step 4\plugin.json file and replace the one inC:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static .
"monitor": {"views": {
"navigationId": "datacenterMonitor","labelKey": "RemoteSample:plugin.name","uri": "datacenter_monitor.html"
}}
Navigating from another plugin extension
Now we are going to change the implementation of the datacenter summary portletcreated earlier to navigate to the datacenter monitor view.
Copy the C:\labfiles\HOL-2019\store\step 4\datacenter_summary.html file and replace the one inC:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static
It contains a call to app.navigateTo API passing the navigation id of the target extensionand the id of the object to navigate to.
htmlClientSdk.app.navigateTo({targetViewId: "datacenterMonitor",
HOL-2012-04-SDC
Page 29HOL-2012-04-SDC
objectId: htmlClientSdk.app.getContextObjects()[0].id});
Test the plugin view navigation
Rebuild the sample and restart the server
mvn clean installjava -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Within the vSphere Client in the browser go to Host and Clusters and select one of theexisting datacenters (e.g. RegionA01). Refresh the browser.
Click the link inside the plugin summary portlet. The vSphere Client navigates to theMonitor page, the plugin monitor view is selected in the table of contents and itscontent is populated.
HOL-2012-04-SDC
Page 30HOL-2012-04-SDC
Step 5: Using the localization APIAn important and sometimes overlooked aspect of plugin UI is its localization support.This is one thing which sets high quality plugins apart.
Let's make sure our plugin checks this box...
Add localization support to plugin extension
Go to C:\labfiles\HOL-2019\store\step 5\ folder and copy the datacenter_monitor.html toC:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\staticreplacing the existing file.
It uses app.getClientLocale() API to retrieve the vSphere Client locale currently selectedby the user. Then it contains a simple logic to demonstrate localization mapping(normally this will be a full-blown mapping of all plugin strings to all locales).
Go to C:\labfiles\HOL-2019\store\step 5\ folder and copy the jquery.min.js to C:\labfiles\HOL-2019\store\step 0\remote-plugin-sample-starter\src\main\resources\static . This library isused by the datacenter_monitor.html .
Important: localization within the view is completely owned by the plugin as this codelives in the plugin iframe. In contrast, the localization support part of the plugin.jsonmanifest is dedicated to the plugin strings vSphere Client needs to display outside theiframe - categories, menu entries, etc.
View the data center monitor view in the vSphere Client
Rebuild the sample and restart the server
mvn clean installjava -jar target\remote-plugin-sample-starter-6.7.0-SNAPSHOT.jar
Within the vSphere Client in the browser go to Host and Clusters and select one of theexisting datacenters (e.g. RegionA01). Refresh the browser if you are already on thispage.
The plugin monitor view is displayed in the table of contents of the Monitor page.
Change the vSphere Client locale
Navigate to the right settings menu > My Preferences > Language > SelectDeutsch from the drop-down and click Save.
HOL-2012-04-SDC
Page 31HOL-2012-04-SDC
This will change the localization of the vSphere Client to German language.
HOL-2012-04-SDC
Page 32HOL-2012-04-SDC
Observe the plugin view is localized
When the datacenter monitor view is refreshed it is shown in German - the currentlyselected locale of the vSphere Client. Note this is a vSphere Client owned setting anddoes not necessarily match the browser locale.
HOL-2012-04-SDC
Page 33HOL-2012-04-SDC
ConclusionCongratulations! You now know how to make a complete integration betweenthe remote plug-in views and the vSphere Client.
You have finished Module 2
Congratulations on completing Module 2.
If you are looking for additional information on vSphere Client SDK APIs, try these:
• vSphere Client SDK homepage• vSphere Client SDK User Interface Modules
Alternatively, have a look at the Remote plugin sample part of the vSphere ClientSDK deliverable which demonstrates the API best practices and is based on Claritydesign system, Angular and Typescript.
HOL-2012-04-SDC
Page 34HOL-2012-04-SDC
Module 3 - Remote PluginLifecycle (15 minutes)
HOL-2012-04-SDC
Page 35HOL-2012-04-SDC
IntroductionIn the previous modules you built and deployed a plugin in a Development environmentusing the same means a plugin is delivered to end-users in a Productionenvironment - via the vCenter extension registration mechanism.
Let's have a look at a high-level summary of this process...
Plugin Deployment Overview
When the user logs into the vSphere Client the plugin is requested from the vCenter, itsmanifest is downloaded from the registered URL, parsed and all extensions are createdin the vSphere Client. Here are the detailed steps:
1. The plugin.json manifest file is hosted on the plugin server.2. The vCenter Server administrator has registered the plugin using that hosted
location URL.3. During a user login the vSphere Client asks vCenter Server for the list of its
registered plugins.4. If vSphere Client finds a plugin that hasn't been deployed yet (or is a new
version) it downloads its manifest using the registered URL.5. vSphere Client performs compatibility checks6. Then the plugin's extensions and forwarding rules are registered within the
vCenter Server.7. The plugin UI becomes visible in the Client for all future users.
HOL-2012-04-SDC
Page 36HOL-2012-04-SDC
Plugin UpgradeIn this section we will go through the plugin upgrade cycle by just changing the pluginversion and vendor.
We don't need to change the plugin content itself to demonstrate the upgrademechanism. The only thing that matters for vSphere Client to replace an existing pluginis to find a plugin registered with the vCenter Server's ExtensionManager with the sameid and a higher version number.
Updating plugin registration with vCenter Server
Bring back the terminal window where you ran the extension-registration script earlierand enter the following command:
"%VSPHERE_SDK_HOME%\html-client-sdk\tools\vCenter plugin registration\prebuilt\extension-registration.bat" -action updatePlugin -url "https://vcsa-01a.corp.local/sdk" -cMyCompany -k sample -u "Administrator@corp.local" -p VMware1! -v 1.0.1
The only differences with the registration command are -action updatePlugin , -v 1.0.1 ,and -c MyCompany . We're updating the existing plugin registration, changing its version toa higher number and adding a vendor name "MyCompany".
Deploying updated plugin
In order to see the new plugin version you must refresh the vSphere Client in thebrowser. The refresh process will trigger the download of the new plugin version.
HOL-2012-04-SDC
Page 37HOL-2012-04-SDC
The plugin discovery can also be triggered by a user login into the vSphere Client.
Navigate again to the Administration > Client Plug-Ins view to observe that theupdated plugin version is now active.
HOL-2012-04-SDC
Page 38HOL-2012-04-SDC
ConclusionCongratulations! You now know how to handle a remote plugin lifecycle inProduction.
You have finished Module 3
If you are looking for additional information on plugin upgrade and vCenter Serverextensions, try these:
• vSphere Client SDK homepage• Deploying Remote Plug-ins for the vSphere Client• ExtensionManager API part of the vSphere Web Services SDK
You have reached the end of this Hands-on-lab!
Thank you!
HOL-2012-04-SDC
Page 39HOL-2012-04-SDC
ConclusionThank you for participating in the VMware Hands-on Labs. Be sure to visithttp://hol.vmware.com/ to continue your lab experience online.
Lab SKU: HOL-2012-04-SDC
Version: 20200324-141103
HOL-2012-04-SDC
Page 40HOL-2012-04-SDC