Report-Report Interface (RRI) makes it possible to jump from one report to another. It comes predefined with a number of report types as jump targets (receivers). Standard jump targets include BEx Queries, Web applications, Crystal Reports, InfoSet Queries, transactions, ABAP reports, and Web addresses (URLs). In certain situations it may be necessary to jump to report types not defined in the standard RRI. You may also require field mappings between the sender and receiver that are not supported by the generic interface. If the standard interface does not satisfy your requirements, you can implement your own custom report types as receivers.

It is fairly easy to define two queries — for example, a summary level and a detail level — and add the ability to jump from the summary level to the detail level. Consider the sample data presented in Tables 1 and 2. The summary level query in Table 1 lists order quantities per material. The detail level query in Table 2 breaks up the order quantities by material and order date. Users can select a material listed in the summary level and have it displayed in the detail level query, with its total order quantity broken up by the order dates.

To define the jump from the summary level to the detail level, follow these steps:

Step 1. Enter the technical name of the query. Go to transaction RSBBS (maintain sender/receiver assignment). In the One Query tab enter the technical name of the summary level query prefixed with the name of the source InfoProvider (Figure 1). Click on the Create button. If you don't know the technical name of the query, click on the drop-down box of the Sender field. Look for the InfoProvider that supplies data to your query. Locate the query beneath it and double-click on the query to bring the technical name to the Sender field.

Figure 1

Enter the technical name

Step 2. Define the detail level query as the receiver. Click on the Transfer button (Figure 2).

Figure 2

Designate the detail level query as the receiver

Step 3. Save the jump definition. The system returns you to the Maintain Sender/Receiver Assignment screen. The receiver line now contains your detail level query. Click on the save icon. To test the jump, execute the summary level query, right-click on any material number, and choose Goto>Detail Level from the context menu (Figure 3).

Figure 3

Example of jump from summary level to detail level query

The filter values (in this case Material = 1247) are passed from the sender query to the receiver automatically. You do not need to define restrictions on the material characteristic in the detail level query. As long as the material characteristic is present in the lower receiver query (in rows, columns or free characteristics), the jump produces the desired results.

What do you do if the standard RRI interface does not list your report type as an available target or if it does not support the mapping necessary to pass the filter data from the sender to the recipient? You must enhance the SAP standard with custom report types.

I will now show you how to implement an enhancement that takes an external service order number and converts it to an internal GUID. You can use the internal number to call a service order display transaction in SAP CRM (within SAP NetWeaver Portal). Standard RRI facilitates the passing of values of characteristics present in the sender query. In this particular case, the source InfoProvider contains the external service order numbers. It does not store the internal GUID. For the sake of illustration, assume that the receiver transaction requires the GUID. To accomplish the task, you need to perform three activities:

• Activity 1: Create an ABAP class with interface IF_RS_BBS_BADI_HANDLER
• Activity 2: Create the BAdI RS_BBS_BADI
• Activity 3: Create the jump target using the newly defined report type

All activities are performed in your SAP NetWeaver BI system. After you complete the activities, a new report type is visible in the drop-down box in the Maintain Sender/Receiver Assignment dialog box.

Activity 1

Go to transaction SE24. Create a new Object type (class). Here I created a new class called ZCL_IM_RS_BBS_BADI_HANDLER_DET (Figure 4). When prompted, enter the description and leave all settings as they are (Figure 5).

Figure 4

Create the new Object type (class)

Figure 5

Enter the description and click on the Save button

Within the class, in the Interfaces tab, create interface IF_RS_BBS_BADI_HANDLER (Figure 6). In the Methods tab, create a class constructor. Make sure you click on the Class constructor button, not Constructor (Figure 7).

Figure 6

Create the interface IF_RS_BBS_BADI_HANDLER

Figure 7

Create the Class constructor

Double-click on the CLASS_CONSTRUCTOR method in Figure 7 and insert the code shown in Figure 8. This code allows the URL targets, but not a SAPGUI-type target. The text you define here appears in the drop-down box as a new jump target in transaction RSBBS.

Figure 8

The code determines the category of jump targets that are valid using the custom report type

Next, double-click on the IF_RS_BBS_BADI_HANDLER~GET_TARGETS method in Figure 7 and insert the code shown in Figure 9.

Figure 9

This code populates the help list that displays when you request help (F4) for the custom report type while in transaction RSBBS

Figures 10 and 11 illustrate the dependencies between the texts coded in the methods and the choices proposed in the enhanced RSBBS transaction.

Figure 10

Menu option as the result of the 'Jumps to transactions within Portal' code in Figure 8

Figure 11

Descriptions added as a result of the ls_f4_list-txtlg code in Figure 9

Double-click on the IF_RS_BBS_BADI_HANDLER~CALL_URL method in Figure 7 and enter the code shown in Figure 12. In the code, note the logic used to read the value of the service order number that the user selects. This is highlighted in Figure 12. This code reads the number of the service order selected by the user and converts it to the internal GUID format. Then it builds the URL that is the concatenation of the portal target transaction and the internal GUID required by the transaction.

Figure 12

The circled code reads the value of the service order number that the user selects

Note the name of the characteristic in bold green, ZSRV_ORD. The field name must correspond to the name of the characteristic, the value of which you want to read from the line selected (right-clicked) by the user. The selected row is always in line one of the internal table L_SX_MAPPING. By copying this logic and repeating it with names of other characteristics, you can read in values of other characteristics present in the same row of the sender query. For example, you could read in two values, concatenate them, and then use the combined value to access a receiver that requires the compounded key.

Activity 2

Go to transaction SE19 and create a classic BAdI called RS_BBS_BADI. Then create the implementation of the classic BAdI Z_RS_BBS_BADI_DET. After you create the BAdI implementation, click on the Change button. Go to the Interface tab and double-click on the GET_TYPES method (Figure 13).

Figure 13

Double-click on GET_TYPES method

Insert the code shown in Figure 14 into the GET_TYPES method.

Figure 14

This code instantiates the new report type

Activity 3

All you have to do now is to go to transaction RSBBS and use the newly defined receiver report type. Figure 15 depicts the top-level query that lists service orders and the Display Service Order transaction (within SAP NetWeaver Portal). When the user right-clicks on the service order number in the query and chooses Goto>Details of Service Order from the context menu, the application jumps to the Service Orders display transaction and presents the order the user selects.

Figure 15

Service order query (sender) and display service order transaction (receiver)

To facilitate the jump, I had to define new report type capable of converting the external service order number (available in the InfoProvider) to the internal GUID (required by the display transaction within SAP NetWeaver Portal). To define the jump from the service order query to the display service order transaction, follow these steps:

Step 1. Go to transaction RSBBS. In the One Query tab enter the technical name of the service order query prefixed with the name of the source InfoProvider. If you don't know the technical name of the query, click on the drop-down box of the Sender field. Look for the InfoProvider that supplies data to your query. Locate the query beneath it and double-click on the query to bring the technical name to the Sender field. Click on the Create button (Figure 16). My query is called ZSERVICE_ORDER. It reads data from InfoCube ZSRV_C17, thus the sender's complete name is ZSRV_C17/ZSERVICE_ORDER.

Figure 16

Enter the technical name of the query

Step 2. Define the new report type as the receiver. You can recognize it in the drop-down box because it has the name you assigned to it in the CLASS_CONSTRUCTOR method. Then click on the drop-down menu to see the list of receivers available for the new report type (Figure 17).

Figure 17

Click on the drop-down menu for a list of receivers

You are presented with the list of available receivers (Figure 18). Double-click on the Details of Service Order line. The choices you see here correspond to the F4 help items you coded in the IF_RS_BBS_BADI_HANDLER~GET_TARGETS method. Click on the Transfer button.

Figure 18

Choose a new report type and click on the drop-down menu

Step 3. Save your work and test the jump. You are returned to the RSBBS screen. Note that the receiver line now contains your detail level query. Click on the save icon (Figure 19).

Figure 19

Save the sender/receiver assignment

Test the jump by executing the service order query. Right-click on a service order number and choose Details of Service Order from the context menu. You can use the code presented in this article to define other custom report types and complex mappings between the sender and receiver. For additional details, refer to https://help.sap.com/saphelp_nw70/helpdata/EN/45/e5c16e810473b1e10000000a11466f/frameset.htm. This link provides an example of how you can schedule Google searches directly from your queries.