Recently, a large public financial company I worked for needed a report providing real-time sales data for the current quarter. Its technical team updated BW InfoCubes daily, but this wasn’t often enough. The company manages its sales by quarter. At the end of the quarter, the online information is critical for the sales management. The required report should contain historical sales data for the last three months, including the most recent R/3 transactions for the past day, hour, and minute. Users need this information to make accurate and informed decisions based on data from the hectic end-of-quarter period.

This sounds like a complicated requirement, but the BW server already contained almost all relevant data. Therefore, I only needed to bring the latest (next) delta information into the report. This approach solves a range of reporting requirements. Here are a couple of additional business scenarios that you could address with this technique:

• A part of the production line in a manufacturing company includes complicated quality assurance (QA) equipment. The equipment updates the SAP R/3 system with online data regarding product testing. The company has a requirement from its QA manager to present last month’s testing results with current-day results to find relevant exceptions.
  
  
• A company must produce material requirements planning (MRP)-style reports to compare current stock with opened sales orders and production orders.
  
  
• A company just finished a marketing effort including TV and radio and the company needs to assess the impact on sales volume. It wants to use online information to get quick support from its back office.

To create an online report with real-time delta data, create a new generic DataSource to provide BW with the next delta information using the standard function module for delta extraction simulation. Then, based on the created DataSource, define an SAP RemoteCube, which enables a BW report to present these delta data through an online read-only call to the next delta (e.g., without updating BW). Finally, use a MultiProvider to combine data residing in BW with real-time data. You can do this in eight steps:

Step 1. Create a new InfoSource

Step 2. Create an ABAP report based on the standard function module for the delta extraction simulation

Step 3. Create an InfoSet based on the ABAP report

Step 4. Create a new DataSource based on the InfoSet

Step 5. Connect the new DataSource to the InfoSource

Step 6. Generate a RemoteCube based on the InfoSource and assign a source system

Step 7. Create a MultiProvider using the original InfoCube and RemoteCube

Step 8. Copy the report from the original InfoCube to the MultiProvider

This method uses R/3 resources, so limit the users who can access the report to avoid performance problems. In my case, 30 users routinely accessed the report during the end-of-quarter period without adversely affecting R/3’s performance. Performance strongly depends on your hardware and data volume per delta extraction. In my example, I had up to 5,000 delta records.

Note that you shouldn’t use this method when working with complicated upload processes because you may face problems with your delta queue updating timing. For example, say your final InfoProvider is an InfoCube that BW updates in two steps: BW uploads raw data into the DataStore object (formerly called operational data store [ODS] object) and then into the InfoCube. In this case, your delta queue is updated before the next delta is updated in an InfoCube. This means that you cannot use online delta reports during the upload process. These disadvantages are acceptable in most cases.

Step-by-Step Guide

Step 1. Create a new InfoSource. Use an original InfoCube with historical data as a template to define the communication structure. Copy all relevant InfoObjects from the original InfoCube to the communication structure. In my example, I called the InfoSource YSD_ONLINE. Keep in mind that you may use only the InfoObjects selected here in the final report. I use this InfoSource as the basis for the SAP RemoteCube I create in step 6.

Pay attention to the update and transfer rules of the original InfoCube. Reconstruct the logic for the new InfoSource. For example, your original InfoCube contains InfoObject 0CALMONTH (presenting calendar month and year) calculated in the update rules of the original InfoCube by a standard transformation from InfoObject 0CALDAY (presenting the document date of transaction). You should use a formula in your transfer rules for the new InfoSource to calculate the month from the document date. Take into account that complicated calculations (selections) in the transfer rules of the new InfoSource negatively affect how the final report performs.

Step 2. Create an ABAP report based on the standard function module for the delta extraction simulation. The ABAP code in this example is based on the standard function module RSFH_GET_ DATA_SIMPLE. My example uses DataSource 2LIS_11_VAITM with the function module RSFH_GET_DATA_ SIMPLE to bring the next delta records. Figure 1 shows an example of using the function module.

Figure 1

Example of using function module RSFH_GET_DATA_SIMPLE

Create a new report in ABAP Editor (transaction SE38) and add the code in Figure 2. I use the report in my example to define an InfoSet. For this reason, I added special remarks to the ABAP code (*<QUERY_HEAD> and *<QUERY_BODY>) so the report can retrieve data for an InfoSet. For detailed information about this procedure, refer to https://help.sap.com/ saphelp_erp2005vp/helpdata/en/d2/cb45b2455611d189710000e8322d00/frameset.htm.

Figure 2

Code YBW_ONLINE_TEST based on the standard function module RSFH_GET_DATA_SIMPLE

Within the code, fill in the function module parameters:

• i_osource: Add your original DataSource technical name (2LIS_11_VAITM in my example)
  
  
• i_maxsize: Fill in the maximum size of delta record (depends on your delta frequency, 10,000 in my example)
  
  
• i_updmode: Put D for delta mode
  
  
• i_rlogsys: Type your BW system logical name (bw_logsys in my example)
  
  
• i_read_only: Set this flag to X
  
  
• I_T_SELECT: Define selection criteria. Normally, you would not use this parameter because BW recognized your delta criteria (stored in the source system) and used it in its delta collection process. However, the extension of my original DataSource contains time-consuming SELECT sentences to fulfill non-standard fields. I do not want to bring this field to my online report, so I need to notify the user exit here by adding a new field to the original DataSource. This new field tells the user exit that the online report will call it. This differs from the regular delta process and is optional, so I explain it in the sidebar, “Create a User-Defined Field in Selection Table I_T_SELECT.”
  
  
• e_t_data: Define the final data set. The data set records have the same structure as the original DataSource (MC11VA0ITM in my example).

Step 3. Create an InfoSet based on the ABAP report. Use the global area in transaction SQ02 (menu path Environment>Query areas). You only can use an InfoSet from the global area to define a generic DataSource. This setting uses a change request to transfer the InfoSet (menu path SQ02>Environment>Transport). Define the InfoSet name (YBW_ONLINE in my example) and click on the Create button to see the screen shown in Figure 3.

Figure 3

Populate these fields for the InfoSet

Select the Data retrieval by program button and fill in the required fields according to Figure 3. This InfoSet has the same extract structure of the original DataSource (in my example, it’s MC11VA0ITM).

Step 4. Create a new DataSource based on the InfoSet. Use transaction RSO2 to create a new generic DataSource YBW_ ONLINE_IS based on the InfoSet. Create the DataSource by clicking on the Transaction data button on the first screen of transaction RSO2 (Figure 4). 

Figure 4

Create generic DataSource YBW_ONLINE_IS

Then, click on the Extraction from Query button (Figure 5). The InfoSet creates description fields for all relevant fields automatically. This negatively affects final report performance, so hide all descriptions by checking the Hide field check box from the created DataSource on the next screen (Figure 6).

Figure 5

Click on the Extraction from Query button

Figure 6

Check the Hide field check box for all description fields

Step 5. Connect the new DataSource to the InfoSource. To perform this standard procedure, replicate the relevant source systems by selecting them via menu path RSA1>Modeling>Source system, and then right-click and select Replicate. Next, assign the new DataSource YBW_ONLINE_IS to your InfoSource using menu path Modeling>InfoSources and right-click and select Assign DataSource…. Choose YSD_ ONLINE (created in step 1). BW maps most of the InfoObjects automatically according to original DataSource mapping, but it’s possible that you’ll need to map a few InfoObjects using formulas or ABAP routines (Figure 7), as I mentioned in step 1.

Figure 7

Transfer rule mapping between InfoSource YSD_ONLINE and DataSource YBW_ONLINE_IS

Step 6. Generate a RemoteCube based on the InfoSource and assign a source system. The RemoteCube enables a BW report to present these delta data through an online read-only call to the next delta without updating BW. Use menu path RSA1>Modeling>InfoSources, right-click, and choose the Create SAP Remote InfoCube… option. For additional information, see https://help.sap.com/saphelp_ bw33/helpdata/en/da/5909392a430 303e10000000a114084/ frameset.htm.

Use your original InfoCube as the template to define dimensions in the RemoteCube. The new RemoteCube (SDONLNIS in my example) contains all of the InfoObjects from the InfoSource YSD_ONLINE. To assign the RemoteCube to a source system, go to RSA1>Modeling>InfoProviders, right-click, and choose Assign Source Systems….

Step 7. Create a MultiProvider using the original InfoCube and RemoteCube. Use all available fields of both the original InfoCube and RemoteCube (SDONLNIS) in the MultiProvider. Use the original InfoCube as a template for the dimensions.

Use the Create recommendation button in the Identification screen of the MultiProvider to create both characteristics and key figures for identification mapping. For more detail, refer to https://help.sap.com/saphelp_bw33/ helpdata/en/52/1ddc37a3f57a07e1000 0009b38f889/ frameset.htm.

Step 8. Copy the report from the original InfoCube to the MultiProvider. Use transaction RSZC to copy reports from the original InfoCube to the MultiProvider. The MultiProvider combines data residing in BW with real-time data. Now you can run your report to bring together historical and next delta information to your user. Your final report does not differ from the report you copied it from, so the end users won’t notice the difference.

You can use standard InfoObject 0INFOPROV for troubleshooting. It is available in any MultiProvider automatically.

 

Create a User-Defined Field in Selection Table I_T_SELECT

This step is optional. You can use it to transfer any parameters that are not already part of the database information to R/3 DataSources. In my example, I want to change the program flow of user exit RSAP0001, BW Data Extraction: Customer Function Calls. Regular data transfer for any R/3 DataSource triggers this user exit. I need to inform the user exit that my report YBW_ONLINE_TEST differs from the regular delta upload process; it executes a report online. For this purpose, I add the new field ZZEQ_IND to the standard DataSource (2LIS_11_VAITM in my example).

To define extract structures for standard DataSources, use available communication structures via the standard customization process for LO DataSources in LO Customizing Cockpit (transaction LBWE). For example, DataSource 2LIS_11_VAITM is based on the communication structures MCVBAK, MCVBUK, MCVBAP, MCVBUP, and MCVBKD. All communication structures contain special parts for users with the suffix USR (e.g., MCVBAKUSR, MCVBUKUSR).

You can add customer-defined fields to these includes by clicking on the Append Structure button in transaction SE11 for a specific structure. SAP supports this type of extension (append structure) during the upgrade process. All new fields from structures with the suffix USR are available in transaction LBWE. For example, if you add the new field ZZEQ_IND in MCVBAKUSR, you could use the field for any DataSource based on communication structure MCVBAK. A user exit must populate all user-defined fields (in my example, RSAP0001).

To add your user-defined field, open transaction LBWE and select application 11. Go to extract structure MC11VA0ITM. In the first column Structure, add the new field ZZEQ_IND to the original DataSource (2LIS_11_VAITM in my example). In the second column of transaction LBWE called DataSource, define specific field behavior (Figure 1).

Figure 1

Check two flags for field ZZEQ_IND: Selection and Field only Known

In Figure 1, check two flags for field ZZEQ_IND: Selection and Field only Known. The first setting makes this field available for selection. The second setting means that only user exits use this field. The field doesn’t exist in the database.

 

Now I can use field ZZEQ_IND in selection table I_T_SELECT of the function module RSFH_GET_DATA_SIMPLE. You can find an example of filling the selection table in my YBW_ONLINE_TEST report (Figure 2 of the main article). The relevant code is below the remark Online report indicator. You should check new field ZZEQ_IND in the original DataSource (2LIS_11_VAITM in my example) to change the original user exit program flow.

 

For example, Figure 2 shows part of user exit RSAP0001, function module EXIT_SAPLRSAP_001.

Figure 2

Code YBW_ONLINE_TEST based on the standard function module RSFH_GET_DATA_SIMPLE

Variable ol_report contains value X in my example to inform the user exit about online report execution. In the regular delta procedure, this variable contains a blank value.

 

Leon Berman

Leon Berman has been with SAP BW from the very beginning (Release 1.2). He has more than eight years of hands-on experience in retail, software, energy, and manufacturing companies. He focused on SAP BW after seven years of ERP system implementations (SAP and others). Leon is a founder of SAPSoft Consulting Ltd., which provides SAP professional services.

You may contact the author at berman_leon@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.