Custom datasource api: avoid members call on some fields

Hello Vera,

Thank you for your response.

I send you some requests and response. We use Flexmonster version 2.9.9. We choose to implement custom datasource api version 2.8.22 and we disable advanced filters and hierarchical data.
The pivot have no issues with fields like account number. I can list the members and the pivot is what i expect. 

The issue comes from fields like desciption, documentDate,..
The screenshot is the result for the request in the Amount by Description output. I can't list all possible values for the description field but we want to be able to use it in a select request.

Hello Vera,

We don't understand why the /members request is mandatory.
As the /select request return all pivots cells, we thought that we didn't need to list the members.
The list of members of our fields doesn't change. For some fields, we can't provide an exhaustive list of members values.

 
Kinds regards,

Corentin.

Hi Vera,
 
Some fields of our flows are pure user input, as for example the "description" of an accounting movement. We take the assumption that, for a flow of 1 million movements, we will have 1 million distinct descriptions. We've therefore always considered that filtering this field using values doesn't make sense neither from a functional point of view, nor from an UX point of view (listing 1 million values is not usable).
 
So, even if we could list the values of this kind of field, we don't want to.  Those fields are therefore marked as "not filterable" in our system. They can just be retrieved and shown in our visuals, but not actively used to build a query.
 
We found the necessary options to do the same in the flexmonster custom datasource api, as part of the /fields response. As a consequence, we expected the component to *not* query the /members for those fields we mark as non-filterable on members (or at least the fields where all filtering options are disabled).
Our logic is this one:

• The custom datasource API offers a great flexibility on listing fields, members of those fields, and filtering options, which is what we are looking for in the beginning.
• On the other hand, we are then required to entirely build the result of the aggregation on server side (the /select request), and serve the front-end component with all cells values ready to be displayed "as is". We did not especially want to do that aggregation on server side at first, but we simply comply to the API.  We already discussed with you the possibility to keep the aggregation on front-end side in the custom datasource mode, but we understood it is not possible)
• It was therefore quite a surprise to see that the values returned in the /select result were not displayed when the /members could not be listed entirely...  On one hand we have to serve the complete result of the aggregation, but on the other hand the front-end component still filters the result depending on the listed members.

You might have good reasons to explain this behavior. However, from the integrator point of view, we expect this behavior instead:

• Do not query members of fields marked as non-filterable on its members. This is a loss of time and resources.
• Trust the result given by the /select request and display it as it is, which is actually what is described in the API documentation
• As a consequence, do not filter again the /select result based on the members of the fields present in this result

In order to have more details on the context of our integration, you can have a look at this former ticket, where we discussed about implementing the custom datasource api: https://www.flexmonster.com/question/is-there-a-way-to-specify-all-the-possible-values-of-a-hierarchy-beyond-what-cant-be-found-in-the-data/
 
As a workaround for now, we will always return "empty" values for those fields marked as "non-filterable". The user will therefore not be able to see the values of that field in the pivot configurator (bad), won't be able to filter it (good), and will only see the values when flexmonster is displayed using the "usual" mode (i.e. the server serves a JSON with all the data and the aggregation is done by the front-end component).  So only our "pivot configurator" is impacted by this limitation, but we would like to see with you if we can find a solution.
 
Thanks again for your time and expertise.
 
Olivier
 

Hello Vera,

Thank you for your investigation.

This solution seems a good improvement to us.
But what happens for the values of filterable fields that are in the /select but are not listed as members?
Does Flexmonster show the value contained in the select response? or the report line is missing as before?

Thank again for your investigation and your solution to our problem.

Kinds regards,
Corentin

Hello Vera,
 
Thank you for your work ! Unfortunately, we have had no time to test your solution.
 
I will be happy to you let know when it's done.
 
Kind regards,
Kevin