I have few BEx queries (OLAP cubes for third-party client) and .prpt reports in Pentaho that uses these BEx via OLAP data source (OLAP4J, MDX). When I execute these BEx in SAP BW or even directly as SOAP service (XML/A execute command via SoapUI) I'm getting result very fast, just 2-3 seconds. But when I try to execute the same BEx queries in Pentaho I'm getting results after 1-2 minutes It doesn't matter if I execute reports that are already published on Pentaho BI server or if I execute these reports in Report Designer. Caching is enabled.
MDX-query is very simple:
As captured with Wireshark, Pentaho does multiple http requests to get metadata about all existing cubes (and their measures too!) in current catalogue.
It's look like this:
1. DISCOVER_PROPERTIES
2. DISCOVER_DATASOURCES
3. DBSCHEMA_CATALOGS
4. Execute required BEx query
5. DISCOVER_PROPERTIES
6. MDSCHEMA_CUBES
7. MDSCHEMA_CUBES by specified catalog
8. MDSCHEMA_MEASURES by specified cube
9. MDSCHEMA_MEMBERS by 1st measure
10. MDSCHEMA_DIMENSIONS by specified cube
11. MDSCHEMA_HIERARCHIES by measures
12. MDSCHEMA_LEVELS by measures
13. MDSCHEMA_PROPERTIES by measures
14. MDSCHEMA_MEMBERS by 2nd measure
...
~350. MDSCHEMA_MEMBERS by last measure of last cube from specified catalog
~354. Execute required BEx query at second time
...
420. MDSCHEMA_PROPERTIES by last hierarchy of specified cube.
Capture of network packets in attachments.
It is OK that Pentaho tries to get metadata information by specified cube, but executing MDX query twice and getting metadata of all other cubes from catalogue is very unefficiently.
Previously I read about similar problem with SSAS:
http://sourceforge.net/p/olap4j/disc...hread/161c048e
http://sourceforge.net/p/olap4j/disc...read/79fad9d7/
https://github.com/olap4j/olap4j/pull/8
But this information doesn't help with SAP XML/A provider. Changes in OLAP4J driver (in org.olap4j.driver.xmla.XmlaOlap4jCellSet and org.olap4j.driver.xmla.XmlaOlap4jCube) cause unstable rendering of reports.
So the main question is: how to improve performance?
report_sap_bex.txt
MDX-query is very simple:
Code:
SELECT
NON EMPTY
{ [00O2TQU30NKBTE188HYVQMXKU].Members }
ON COLUMNS,
NON EMPTY
{ [00O2TQU30NKBTE184UOSJ253R].Members }
ON ROWS
FROM
[CATALOG_NAME/CUBE_NAME]
SAP VARIABLES [PARAM_1] INCLUDING [HIERARCHY_1].[${VALUE_1}]
[PARAM_2] INCLUDING [HIERARCHY_2].[${VALUE_2_1}]:[Z_DATPRB].[${VALUE_2_2}]As captured with Wireshark, Pentaho does multiple http requests to get metadata about all existing cubes (and their measures too!) in current catalogue.
It's look like this:
1. DISCOVER_PROPERTIES
2. DISCOVER_DATASOURCES
3. DBSCHEMA_CATALOGS
4. Execute required BEx query
5. DISCOVER_PROPERTIES
6. MDSCHEMA_CUBES
7. MDSCHEMA_CUBES by specified catalog
8. MDSCHEMA_MEASURES by specified cube
9. MDSCHEMA_MEMBERS by 1st measure
10. MDSCHEMA_DIMENSIONS by specified cube
11. MDSCHEMA_HIERARCHIES by measures
12. MDSCHEMA_LEVELS by measures
13. MDSCHEMA_PROPERTIES by measures
14. MDSCHEMA_MEMBERS by 2nd measure
...
~350. MDSCHEMA_MEMBERS by last measure of last cube from specified catalog
~354. Execute required BEx query at second time
...
420. MDSCHEMA_PROPERTIES by last hierarchy of specified cube.
Capture of network packets in attachments.
It is OK that Pentaho tries to get metadata information by specified cube, but executing MDX query twice and getting metadata of all other cubes from catalogue is very unefficiently.
Previously I read about similar problem with SSAS:
http://sourceforge.net/p/olap4j/disc...hread/161c048e
http://sourceforge.net/p/olap4j/disc...read/79fad9d7/
https://github.com/olap4j/olap4j/pull/8
But this information doesn't help with SAP XML/A provider. Changes in OLAP4J driver (in org.olap4j.driver.xmla.XmlaOlap4jCellSet and org.olap4j.driver.xmla.XmlaOlap4jCube) cause unstable rendering of reports.
So the main question is: how to improve performance?
report_sap_bex.txt