Unexpected list of propertySpecs in QuerySpec from HTML client

[jvitorino]

Hi,

We've extended the HTML client via the vise.relateditems.specs extension point and the data that is rendered in the view/columns displays correctly as long as we don't apply a filter using the filter box in the UI.  If we attempt to apply the filter, then we start to see some unexpected results and the result are a little different in 6.5 vs. 6.7.

Looking at the HTTP request that's sent to /ui/list/ex, I see the following JSON payload:

{ 

   "constraintObjectId":"urn:vmomi:ClusterComputeResource:domain-c978:91164109-1fa2-4368-80cb-fe0cf4e1926f",

   "queryFilterId":"relatedItemsListFilterId",

   "filterParams":[ 

      "com.simplivity.cluster.related.hosts"

   ],

   "requestedProperties":[ 

      "id",

      "primaryIconId",

      "name",

      "labelIds",

      "simplivity:virtualControllerName",

      "simplivity:state",

      "simplivity:clusterName",

      "simplivity:datacenterName",

      "simplivity:currentVersion",

      "simplivity:managementIp",

      "simplivity:storageIp",

      "simplivity:federationIp",

      "simplivity:virtualControllerShutdownStatusString",

      "simplivity:upgradeStatus"

   ],

   "dataModels":[ 

      "simplivity:HostSystem"

   ],

   "searchTerm":"jesse",

   "searchableProperties":[ 

      "name",

      "simplivity:virtualControllerName",

      "simplivity:state",

      "simplivity:clusterName",

      "simplivity:datacenterName",

      "simplivity:currentVersion",

      "simplivity:managementIp",

      "simplivity:storageIp",

      "simplivity:federationIp"

   ],

   "take":100,

   "skip":0,

   "page":1,

   "pageSize":100,

   "sort":[ 

      { 

         "field":"simplivity:datacenterName",

         "dir":"asc"

      }

   ],

   "group":[ 

   ],

   "listViewId":"com.simplivity.host.list",

   "isLiveRefreshRequest":false

}

which looks as I would expected since it includes the necessary data, including the requestedProperties.  However, if I set a breakpoint in my DataProviderAdapter, it looks like the QuerySpec.ResourceSpec.PropertySpec list isn't populated from the requestedProperties that are in the payload.  In 6.5, the list is empty.  In 6.7, it seems like the list of propertySpecs is always a single entry and the entry seems to be the property that we're sorting on.  Again, this only happens when we attempt to apply a filter. 

Is this behavior expected or is there something wrong with the way in which the QuerySpec is being generated from the HTTP request?

Thank you,

Jesse

[Denis_Chorbadzh]

Hi Jesse,

Is it possible that you send us screenshots of the UIs (both 6.5 and 6.7) before and after applying the filter?

Thank you,

Denis

[jvitorino]

here are the requested screenshots, you'll notice that after the filter is applied that the only column this is returned/displayed is the name column.  This happens to be the column that is being sorted.  you'll notice the odd behavior if the data is sorted by another column,  in the screenshot, I show that when sorted on "Datacenter" and when filtered then the two columns that are returned are Name and Datacenter.

[Denis_Chorbadzh]

Hi Jesse,

Thank you for providing the screenshots and data.

I tried to reproduce the issue using the ChassisB sample plugin from vSphere 6.5U1 HTML Client SDK. In my case, when I tried to filter the table, I was not getting any results at all.

After some investigation, I found an error in the ChassisB's ChassisRackVSphereDataAdapter which implements DataProviderAdapter. I simply replaced "Comparator.TEXTUALLY_MATCHES" with "Comparator.CONTAINS" on line 673 and then everything was working as expected. I was able to filter the chassis objects and all columns were populated with data. The catch here is that, when you apply a filter, it is run only against the searchableProperties which are the columns marked with <sortProperty> in the plugin.xml. This means that, if you want to be able to filter using all columns, the columns shoud have <sortProperty> tag.

After applying the fix the sample started working as expected and I am not able to reproduce exactly your scenario. This probably means that there could be a problem in your DataProviderAdapter.

So could you please inspect ChassisB's ChassisRackVSphereDataAdapter and compare it with yours. You can also experiment with the sample and reproduce your issue.

Best Regards,

Denis 

[jvitorino]

I tried to reproduce using the sample adapter and can't seem to reproduce the issue, however stepping through that code gave me some additional knowledge on how things seems to be working for the filtering operation.  In the sample code, I see that 3 calls are made to the adapter.

1) Request with the PropertyConstraints which results in items that match

2) Request with the RelationConstraint which result in items that are related

3) Request with the ObjectIdentityConstraint with the PropertySpecs for the object that I assume were resolved from the union of the first two responses.

In our adapter, we only see the first two calls even though our responses for the first two include the same ResultItem.  One difference that I see is that the sample returns ResultItems where the resourceObject is a URI.  Our adapter returns ResultItems where the resourceObject is a ManagedObjectReference.  I'm not sure if the is the root cause or if there is anything else that may be causing the issue.  Without being able to step through the code, it's very difficult to understand why the third call isn't made into our adapter.  Is there some additional logging that I can enable to help troubleshoot the issue? 

[Denis_Chorbadzh]

I think it is possible that having the ResultItems as ManagedObjectReference instead of URI may cause the problem.

Please look at "createResultItemsForModelObject" method and try to do the same.

--Denis

[jvitorino]

OK, I will attempt to make the necessary changes.  I tried yesterday, however it resulted in further regressions.  I worry on how much our code may need to change to accommodate this.  Do you know why a URI is required here? 

[_vladi_]

Hi,

This should be a fairly straightforward change as the sample is getting the URI from the managed object which you already have.

Otherwise, this is a DataService API which, admittedly, is insufficiently documented. Provider's code generally needs to comply with it to get expected behavior.

Please keep us in the loop of how this change goes.

Cheers,

Vladi