According to our APF POC1 spec
The logic in the table is:
Regarding table VBRK and VBRP we already two BASIC CDS views:
All the fields we needed are already in the CDS views. Besides there’s already a CUBE view:
I_BillingDocumentItemCube
So I think there may be 2 options:
Directly use the Cube view, build query views upon it.
Advantage: convenient, fast;
Disadvantage: the complexity of Cube view is high, may affect the performance, we may not need all the information in the Cube.
Build our own Cube view and Query views.
Advantage: less complexity, performance should be better;
Disadvantage: we need time to create the Cube view, to think what fields and annotations we need.
This is my draft idea, need further discussion.
Another thing is, regarding all the KPI in POC1, do we need several query views(Odata service) for different KPI? such as:
Sales Volume by Year;
Sales Volume by Year Quarter;
Sales Volume by Year Month;
Should we use 3 query views and use different field in Group By? Or can we use parameters or will the APF framework automatically aggregate the measure by the unselect fields? For this, I need to have a try.
For testing, I create query view Zmx_SalesVolume_Apf_Qry:
with some parameters, and in APF Configuration Modeler, I create an application ZMX_SalesVolume_Test:
I don’t find a place to set the parameter value like Smart Business. When I execute the app, add the configured step. An error occurred:
Seems the error is related to parameters. I’ll remove the parameters in query view and try it again.After discussion, we decide to choose option 1, directly re-use our CUBE view, and build specific query view on it. As for the performance issue, we’ll not consider it for now.
And I’ve tested that we only need one query view, we put all the fields we need in this query view. In APF framework, the measure(Sales Volume) will automatic aggregate the value grouped by unselected fields.
As for giving value to query view parameters, the individual configured filters could do it. But after a meeting with APF colleague, we realize that this kind of filter will significantly affect the performance, because when APF app is initializing, it will retrieve the data of the Entity Set to fill the drop down list, if the data is very large, for example 10000 entries, it will be very slow for the app to initialize.
Smart filter is different, it only retrieve data when it’s used, so we prefer to use smart filter, but currently smart filter doesn’t support assign parameter values. But there’s a work around to do it, by creating another CDS view and include a field with the same name as the parameter in our query view (For example, P_Currency). Then set this field’s Entity Set to Smart Filter. I will try it in this takt.