Dynamic Extensions Filter Query

The vsphere-ui process parses the plug-in manifest when the plug-in is registered wih the Extension Manager of vCenter Server, and stores the information as long as the plug-in remains registered. When a user navigates to a Summary tab, Monitor tab, or Configure tab, or when a user clicks the Actions menu, the user interface code in the browser sends a filter query to a plug-in server to determine its choices for dynamic extensions. The plug-in server responds with a visibility choice for each dynamic extension that applies in the current context.

An example message sequence for a filter query is illustrated in the following diagram.

Notes about the sequence diagram:

• Reading the manifest file is not part of the filter query sequence. The diagram includes the manifest fragment for context.
• The variable proxy-base in the endpoint URL refers to the proxied plug-in server base URL that the client code prefixes to the dynamicUri in the manifest file. All client queries to the plug-in server pass through the reverse proxy for security reasons. For more information, see Client-Server Communications with Remote Plug-ins.

The client filter query consists of an HTTPS POST request to a dynamicUri endpoint specified in the plug-in manifest file. The client code chooses the URL configured for the vSphere object type and the extension type that are currently active in the user interface.

Tip: A best practice is to maintain a different endpoint for each extension type (Summary, Monitor, Configure, or Menu) and return visibility choices ( true or false) for only the relevant dynamic extensions.

The request header contains:

• The body type specifications ('application/json' for both request and response).
• HTTP cache control settings.
• Identity and authentication headers:
  • Node ID (unused)
  • The vsphere-ui endpoint URL This tells the plug-in server which vCenter Server manages the context objects.
  • The session token for the client's authentication with the vsphere-ui endpoint. This allows the plug-in server to authenticate with vCenter Server to retrieve properties needed to make filtering choices.

For example:

  'content-type': 'application/json',
  'Accept': 'application/json',
  'Cache-Control': 'no-cache, no-store, max-age=0',
  vmware-api-session-id: c621c819-4f65-1b02-2214-c7ac159ad4d4
  vmware-api-ui-endpoint-url: https://93.184.216.34/api/ui
  vmware-api-ui-node-id: 6079314c-d525-43a1-8a54-735f5417f11e

The request body contains:

• The API version of the filter query protocol, used to negotiate message format with the plug-in server.
• The locale code.
• A list of object IDs for the current context objects. For dynamic actions, the list of object IDs may be any length. For dynamic views, the list may contain only the object ID that pertains to the Summary tab or Monitor tab or Configure tab that the client is rendering.

For example:

  apiVersion: "1.0.0"
  objectIds: ["urn:vmomi:VirtualMachine:vm-1005:27a09c68-d1d6-4fe2-a28f-616949f30930"]
  locale: "en-US"

The response from the plug-in server must be a single anonymous JSON object that contains:

• The latest version of the filter query protocol that the server is prepared to handle, used to negotiate message format with the client.
• A list of dynamic items, where each item is an object that contains:
  • The id or navigationId of a dynamic view or the id of a dynamic menu action. A navigationId value is assigned to the id property in the response object.
  • Boolean values visible to control whether the dynamic extension displays in the user interface, and (as of 8.0 U3) relevant to control whether to remove it from the interface.

For example:

  {
    apiVersion: "1.0.0",
    dynamicItems:
    [
      {
        id: "MonitorDynView",
        visible: true,
        relevant: true
      },
      {
        id: "DeleteAction",
        visible: false,
        relevant: false
      }
    ]
  }