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