vRealize Orchestrator additionalPropertyFilters Explanation

Summary

The Orchestrator VcPlugin getAll…() methods (such as VcPlugin.getAllDatastores(), VcPlugin.getAllVirtualMachines(), etc.) accept two parameters, additionalPropertyFilters and xpath.  Use of xpath has been well documented, but I had trouble finding information on additionalPropertyFilters.  Then, I found this explanation in the vRO Coding Design Guide, page 26:

For performance reasons, the returned objects are not fully populated with all of the properties but a pre-defined set of properties. The initial set can be determined by looking at the plugin inventory – all properties displayed in the inventory are in the initial properties set. If additional properties are needed, specify them during the getAll…(…) call so that the request from the vCenters can get a combined set of properties upfront. If this is not done and extra properties are referenced by the workflow or action then a remote call is made each time to vCenter to create a vCenter filter for the tuple <vm, property=”” name=””>, which wastes resources both for remote execution and for filter management on vCenter side.

Ah hah!

 

How To Use additionalPropertyFilters

A quick look at vroapi.com tells me the syntax is getAll…(string[], string).  As a test, I created a string array containing the name of all properties for the VcVirtualMachine class and ran this code successfully:

Simple!

 

Performance Gains?

After performance testing, I found an average gain of 190ms per VM when reading all the VcVirtualMachine’s base level attributes.  However, I’m using Date.now() for performance testing and it is less granular than I would like, also this wasn’t exactly the most controlled test – other environmental factors may have impacted performance, so your results may not be the same.

For the performance test, I ran 30 iterations of VcPlugin.getAllVirtualMachines() and averaged execution time with and without the additionalPropertyFilters parameter, 195ms and 165ms respectively.

Then I read all base-level properties from the first 200 virtual machines, using the object returned by each of the two types of calls, and averaged that time per VM.  I felt that this should trigger the “remote call… to vCenter” referenced above.


…Results!

  • Per-VM property read time without additionalPropertyFilters: About 240ms
  • Per-VM property read time with additionalPropertyFilters: About 50ms

 

Hope this helps.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recent Posts

Categories

Archives

GiottoPress by Enrique Chavez