Professional Documents
Culture Documents
August 2004
TABLE OF CONTENTS
1 Business Scenario
You want to download BW query results. Those file download results should arrive either in flat files, or in transparent tables. The downloaded files should be based on existing BEX query definitions. And most of all, the downloads should be executed repeatedly and fully automated in the background.
2 Introduction
The following step-by-step guide describes how you can achieve the desired results of query result download. It is based on transaction code RSCRM_BAPI, a function available in BW 2.1c since SP 8.
Before you proceed, please view the following important notice: As of release 3.0B (as well as 3.0ASP7), a new functionality called SAP BW Open Hub is available, that enhances BWs openness in an Enterprise Data Warehouse environment. Therefore SAP BW is even more capable of taking over the role of an Open Hub Platform, and to function as well as an information hub and distributor. The Open Hub functionality largely enhances the openness of BW, its capabilities surpass the RSCRM_BAPI capabilities by large. In any case, independent of which extraction method you choose (RSCRM_BAPI, OpenHub, or other tools like LISTCUBE), it is important to note that SAP BW Enterprise Data Warehouse de facto will function as an Open Hub Platform. Since extracting data from SAP BW by any means requires additional licensing, please make sure to contact your SAP representative.
3 Background
The transaction RSCRM_BAPI in the SAP BW system was created for the purpose of testing a programming interface for extracting query results from SAP BW. This programming interface takes the query definitions as the basis for generating MDX statements that are transferred to the ODBO interface in SAP BW. The result generated is either returned to the callup program as an internal table or updated in tables and files.
Although the functions and performance with the transaction RSCRM_BAPI is comparable to the functionality offered by the Business Explorer Analyzer, certain aspects and in particular some restrictions ought to be considered before deciding whether to opt for these transactions in a project.
4 Restriction of RSCRM
Certain queries that can be defined in the Business Explorer Analyzer cannot be supported by RSCRM_BAPI due to the limitations of the ODBO interface. This applies to the following queries: Queries that use the operators CT, RT, and GT as well as %CT, %RT, and %GT in calculated key figures Queries that use replacement path variables while the reference query uses variables that are open for input. User exit variables, on the other hand, are supported.
Furthermore, the ODBO interface expects there to be filters and variable values in the InfoCube it is based on. To achieve this, these values are checked upon input, which can lead to longer response times in such cases.
The ODBO interface does not support filter and variable values that contain special characters, accents, or characters in the lower case. This restriction applies regardless of which additional characters are permitted for key values in the SAP BW settings. Accents such as the German "Umlaut", however, are supported for displaying the results.
In the case of Top N conditions, the resulting set might vary between the Business Explorer Analyzer and the ODBO interface if multiple identical values occur due to different sort processes.
If a default value is defined for a variable, the ODBO interface always applies this value, even if it had been explicitly deleted manually in the variable dialog box. It is recommended that you do not use default values.
Variables with the dynamically changeable flag enabled are not supported by ODBO.
Output values for missing or invalid key figure values can be defined in the settings for SAP BW using transaction RSCUSTV4. If nonnumeric output values are defined for this case, the key figure value will be set to zero.
When the query results are written to tables, the structure of the query is converted so that characteristics appear in the rows and key figures in the columns, thereby supporting a flat table model.
When the query results are written to tables, the characteristics of a query are used in the generated table as key fields. Due to the restrictions imposed by the Data Dictionary, the combined width of all key fields must not exceed 255 bytes. The number of active characteristics is limited to 16 as well.
Queries for the InfoProviders "InfoObject" and "InfoSet" are not yet supported by RSCRM_BAPI. We are currently in the process of releasing this functionality for BW 3.x. .
Its advised to have a deeper look at note 605208, which describes even more critical restrictions!!!
5 Performance
The ODBO interface in SAP BW is intended to be used in OLAP applications for performing complex requests with multidimensional data. It has been optimized for this purpose, not for reading mass data. The ODBO interface has not been released for extracting mass data from SAP BW.
For some queries, execution with the ODBO interface can in some instances take considerably longer than with the Business Explorer Analyzer. Moreover, server memory consumption during complex queries can also be fairly high. This is the case if, for example, a large number of characteristics are used in the drilldown (unlike in typical OLAP applications). Characteristics that are not essential should always be removed. The same applies to any superfluous attributes and key figures. Characteristics serving simply as filter characteristics should not appear in the drilldown; they should be defined as free characteristics instead.
Note that conditions can only be active within a query while the characteristics used are still in the drilldown. If this is not the case, the condition is automatically deactivated.
Packaging
To avoid memory bottlenecks RSCRM_BAPI allows you to use the packaging option (semi-automatic division of a query into several individual requests). To do this, you select a characteristic during scheduling. All values belonging to this characteristic that are found in the InfoCube are automatically divided into intervals of appropriate size ("packages") and these packages are then transferred as interval filters to individual batch jobs.
The size of the packages is set automatically on the basis of the number of characteristics in the drilldown. With BW 2.1C SP8, however, you have the option of specifying the package size explicitly (by choosing Extras Package Size: Extract in the menu). With BW3.x and an up-to-date SP its now even possible to set an individual package size per extract.
The set of characteristics that can be used depends on the query design. Only active characteristics are possible. Furthermore it depends on the created conditions. If a condition is set to be evaluated independently or if a Top or Bottom condition exist on the 1st characteristics its not possible to package the query at all. Because of the nature of those conditions they can only be evaluated on the whole query at once.
The possible set of characteristics depends further on their use in conditions. E.g. characteristics that are used in conditions with the type "Top-Count", "Bottom-Count", "Top-Sum", "Bottom-Sum", "TopProduct", and "Bottom -Product" are not allowed to be selected for packaging since the total resulting set would otherwise fail to fulfill the defined condition. Please use the F4 help as it will only offer possible characteristics.
The InfoProvider interface can be used internally if the query does not contain the following elements: Conditions Hierarchies Exit variables Characteristics in columns Key figures in rows Restricted and calculated key figures Date key figures Currency translation Concurrently a variable and a filter on a characteristic
HOW TO SCHEDULE QUERY EXTRACTS USING RSCRM _BAPI Variables on compounded characteristics Stock key figures Exception aggregation
If the above conditions are fulfilled, the data can be transferred directly from the InfoProvider. Doing so can have considerable performance benefits. With an up-to-date SP theres an OLAP Check button in the toolbar that gives an explanation on which prerequisites of the current query are not fulfilled.
2. Under query properties, make sure to mark the checkbox Release for OLE DB for OLAP. Then generate and safe the query.
2. Now you are on the main screen of transaction RSCRM_BAPI. Although there is a variety of features available on this screen, for the purpose of this How-To Paper lets focus on the query result download functionality. From the menu icons, click on Extract.
3. Now you are on the definition screen for a query extract. You will need to provide the following information: Technical Name of Extract: You have to choose a unique technical name, which identifies the extract that you want to create. This name is used for the table creation in DDIC (or for the structures generation in DDIC, in case that you choose file output). The generated technical name will be constructed as follow s: /BIC/0C + technical name (Up to BW2.1c/SP7: ZCRM + technical name). The files can be found in the directory DIR_HOME (to be defined via transaction code AL11). User: This is the user id, which will be used for extract creation. This user id needs to have authorization to execute the query; starting from
BW2.1c/SP8, also the authorization object RSCRMEXTR is checked. Language: Language chosen for textual information in the extract. Packaging on Characteristic: This is basically a partition criteria, which allows you to break down the query execution / extract into several smaller packets. It is required in case of large data volumes, in order to avoid an ODBO memory overflow. (Note: This option cannot be chosen in case of conditions, like TOPN etc.). Package Size: This is the size of each package. Extract Type: There are three options for results output. CSV- or fixedlength flat file, or transparent table. Extract Contents (table only): In case that you had chosen the transparent table for file output, select whether you want to reinitialize the table for every extract, or if you simply want to append to an existing table. File Parameters (file only): In case of flat file output, define the file name for output. Should the file already exist, it will be overwritten. Note, that only files on the application server are allowed here; you cannot choose files on the client machine.
Start Condition: Use the usual BW scheduling features to plan the data extract.
4. In case that you had defined user input variables in the query, now you will be prompted for the variable values. Enter the variable values (either manually or via variant), and then press the Continue icon. Now your job is scheduled or executed (depending on the start conditions selected above). 5. Back on the main screen, you can branch now to the monitor, via the icon Batch Monitor.
6. A traffic light will indicate the status of the process. If the traffic light is yellow, you know that the process is still running. It has finished without errors, when you see a green icon. A red icon would indicate a problem situation, which would require individual further research.
7. You can double-click on the traffic signal for further details. The new Package Information tab shows details of each package.
8. From the menu, you can also display the table / file contents (transaction AL11 is called in case of files).
10
11
Appendix
12