Is there a REST API for quickviews?
This was bugging me so I played around some more. I think you can get a SQL like extract which can be filtered as needed. Its certainly not the full functionality of an MDX query, but might be sufficient for your needs? Basic setup:
Dashboard DataSet BR > Data Adapter > GetAdoDataSetForAdapter.
The key is/are the BRApi.Import.Data.FdxExecute... functions which are DataTable objects by default. I was able to use FdxExecuteDataUnit to pull a major data unit and then filter the results down to relevant items with the filter string component (filters using SQL syntax). Note, this is base level data, not aggregated. Reference threads:
Hope this is enough to get you started.
-DB
db_pdx Thanks again for your pointers. I may have taken a lot longer to find this stuff if you hadn't pointed me to it. I can tell you are quite a bit more familiar with the platform than I.
I forgot to circle back and update the forums. Just to recap, there was no generic "quickview" mechanism for retrieving arbitrarily shaped data from the REST api.
However with the help of the new "FDX" api's, a developer can retrieve a large superset of the data they may need, and then do post-processing on the client side. This is possible because of optimizations in the FDX api's.
There are some steps.... You first have to create a cubeview that defines the superset of data you are interested in having. Make it sufficiently large so that it can answer a lot of questions. Mine is defined to a scope that almost matches the "data unit" (ie. retrieves all interesting data for an entity and year).
Once you have a cubeview defined, you can access it via REST using the "GetAdoDataSetForAdapter" endpoint. There are a few unintuitive hoops you need to jump thru to get to your cubeview.- REST calls Dataset Adapter
- Dataset Adapter calls Dataset BR
- Dataset BR calls FDX Execute (BRApi.Import.Data.FdxExecute...)
- FDX Execute runs your cubeview
Unfortunately this approach isn't ideal (as you can probably see for yourself). It is quite unintuitive and I'd go so far to say that experienced software developers might look at many, many alternatives before they finally land on this one. By that time they've rebuilt their client software a number of times. It is a pity that some of these layers couldn't be removed or simplified. I think the complexity is related to the fact that OS product team may assume a normal cubeview REST call will perform well under most instances (and you won't need FDX). This is not the case. Also the complexity is probably temporary - and may be related to the fact that FDX is a recent addition to the product and isn't exposed directly via the REST API.
Hope this helps others who need faster, or more flexible data out of onestream.
PS. Here is some additional explanation of FDX
