Expand +



Cascading Prompts: The Next Generation of F4 Value Help Filtering

by Matt Vasey, SAP BI Lead Consultant, Enterprise Wide

September 20, 2017

Achieving consistent and relevant user prompt selections across multiple BI front-end tools has been a key area for many BI implementations. Value help and the cascading filtering of a list of values have often been a limitation and complex area in SAP BW, particularly when large volumes of master data are present. A combination of native SAP HANA and SAP BW modelling can optimize and improve the SAP BW F4 value help across the SAP BW environment.

A key area for many SAP BW and BI implementations centers on the user’s ability to drill down through various hierarchies — for example, time, product, or location — to output specific reporting information in a timely, usable, consistent manner. Traditionally, this process can be done via a prompt selection screen before the report run time to filter the report result set, or after the report run time, via numerous in-report filtering mechanisms such as drilling down through hierarchies. 

Complex, flexible data structures, coupled with ever-growing data volumes, produce master data structures in the hundreds of million records, hindering users’ ability to achieve efficient filtering of prompts. 

Traditionally, F4 variable input help returns a long list of unwanted values to the user. For example, if a specific vendor is entered via a variable and the next variable, such as product, is selected, you would retrieve a long list of unwanted products that is not specific to the vendor selected in the previous input. 

In SAP BW, the introduction of RSR_VARIABLE_F4_RESTIRCT_BAdI helped to restrict the input help values from BW 7.01, but when filtering across large master data objects, this mechanism’s performance becomes suboptimal. Using the performance of SAP HANA calculation views, this now provides a user-friendly way to cascade filter SAP BW variables.

Using key features of SAP HANA, SAP BW, and ABAP, I show how to create an alternative mechanism—cascading prompts—to quickly and easily drill and filter through many hierarchies consistently across various front-end tools, significantly enhancing the end-user experience. 

Cascading prompts provide a consistent, usable, performance-based approach to drill-down functionality across most SAP BI front-end tools. With the advantage of using external SAP HANA views, an extensible, fast, stable master data view can be used for simple to very complex filtering scenarios. 

One of the major advantages of cascading prompts is that the implementation can be phased into existing environments over time by creating new variables and changing relevant BEx queries over time. Users have given me some very positive feedback regarding having a consistent filtering mechanisms to obtain information quickly and correctly. 

An Overview of Cascading Prompts

To understand what a cascading prompt is, you can take the following definition into context.  

A cascading prompt is a prompt to filter values in another prompt. For example, a report contains the columns Product and Product Status. You create prompts for these columns, and you specify that the Product prompt is a cascading prompt that uses Product Status as the source. In an SAP BW context, this step can be done via the variable selection screen.  

The main concept of cascading prompts is to deliver a filter mechanism to business users that is consistent across all front-end tools. It needs to be intuitive, specific in nature, and easy for end users to understand what needs to be selected—and how—to get to their analysis quickly and accurately. 

You often hear reporting users say, “Well, I have filtered by a specific vendor, but I see products that this vendor doesn’t actually sell to us showing up in the list of values to select from.” In your SAP BW/BI landscape you may also hear users mention that they filter the report output in different ways in each tool—for example, in Web Intelligence via input controls, or via relational hierarchies in SAP BusinessObjects Analysis for Microsoft Office. 

By using BEx Queries (shown in the following examples), users can now select a specific set of variable values in the prompt screen that interact and filter each other’s selections. With the specific filtered list of values, the cascading prompts can also be applied to very large data sets, such as products, in a quick and responsive manner with similar functionality and look and feel across all SAP BI reporting toolsets.   

This is also a consistent, easy-to-use filter mechanism across various BI front-end tools, all via the Prompts screen.

Web Intelligence

The functionality works in a similar way across multiple BI tools, via a Prompts screen and variable selection. Figure 1 shows a filtered list of values of categories, by site and department for Web Intelligence. 

Figure 1
Cascading prompts via a Web Intelligence Prompts screen

In the Prompts screen, I selected a site (N010) and a department (062) and then selected Category for further filtering. The category list of values presented has been filtered specific to my prior selection. Without the cascading prompt limit, I would have been shown a full list of all categories across the entire system. Prior to the implementation of cascading prompts the F4 value help would display an error message that the system had reached the maximum value to display a list. This keeps the prompts selection precise and relevant to the end user.

SAP BusinessObjects Analysis for Microsoft Office

The cascading prompt functionality is also the same in SAP BusinessObjects Analysis for Microsoft Office (Figure 2), all via a Prompts screen. In this example I have entered a site (N010), a Department (062), and a Category, Apple iPad accessories. I now select a product class for further filtering, and I am presented with a list of relevant classes rather than a full list, which would be in the 10,000s. This is all returned in a sub-second, across a product hierarchy of more than 100,000,000 records.

Figure 2
SAP Business Objects Analysis for Office variable selection

SAP Lumira Designer

Cascading prompts also work in SAP Lumira Designer in a similar way via the Prompts screen. In Figure 3 you can see a shorter list of all the departments of a particular site, not the unfiltered list of departments across the whole company.

Figure 3
SAP Lumira Designer prompt selection

How is this achieved outside standard SAP BW BEx Query and how can you implement it?  

Before going into the details for doing this step, I first need to add a disclaimer. It’s important to note that data sources for reports are used via BEx Queries and Business Intelligence Consumer Services (BICS) connections, offering all the features of the online analytical processing (OLAP) engine, including security, authorizations, and BEx calculation logic. This feature offers a comprehensive and consistent method for users to drill down and filter the reports’ result sets across various SAP BI front-end tools.  

Cascading prompts are, for all intents and purposes, an extension of the standard BAdI enhancement RSR_VARIABLE_F4_RESTRICT_BAdI. Extending this BAdI to apply the filtering logic would often be enough for basic filtering, although the BAdI logic would all be computed in the OLAP engine.  

With specific use cases, such as filtering products, vendors, or master data with huge data volumes, SAP HANA can be used to do the heavy lifting, filtering, and passing of the result sets back to be displayed to the end user in very quick response times. Figure 4 shows a diagram of all the major components and how the cascading filtering logic is computed from user input, through the various components of BI, SAP BW, and SAP HANA. 

Figure 4
Design architecture and step-by-step implementation numbering

Figure 4 includes the prompt screens displayed via the different reporting tools, as well as the BEx variables and queries. It highlights the BAdI RSR_VARIABLE_F4_RESTRICT_BAdI for each InfoObject required to be filtered and the InfoObjects that are available in SAP BW to be exported as SAP HANA views. The SAP HANA calculation view logic to join specific InfoObjects can be used to create an extensible master data view that can be used across multiple BAdI calls. Finally, the calculation view is transposed as an ABAP view in SAP BW to return a filtered list back to the BAdI call.  

SAP BW OLAP faces challenges with master data volumes—for example, plant material, which can easily hit 100 million records. However, SAP HANA calculation views can filter through those volumes of records, giving the user sub-second responses. 

Benefits of Cascading Prompts

Here is a list of some major benefits of using cascading prompts as a filter mechanism in your BI architecture: 

  • The ability to filter large volumes of F4 value help list values in sub-second timings
  • The ability to provide a consistent filtering mechanism across multiple BI tools
  • A reduction in the amount of data that is sent to the front end for in-report filtering, often slowing down the initial refresh of reports
  • Flexible, extensible methods to add complex business logic in filtering rather than computing in the front end
  • Consistency of reporting output, offering data that is capable of online analysis and scheduling functionality
  • A filtering mechanism that is held in one place for easier maintenance and support
  • Reduced amounts of BEx variables created by super users
  • A centralized view that can be used in other areas of reporting 

So, the next question is, how can you implement a similar approach in your current SAP BW or SAP BW/4HANA system? In the next section, I provide you with step-by-step implementation details that answer this question.  

Step-by-Step Implementation

This step-by step guide focuses on one main scenario of filtering product-level information. It is designed to be used as a rough guide to start leveraging cascading prompts. The master data setup in data warehouses is very specific to each organization; hence, the following steps can be used for guidance and amended to your specific environment. In the following guide, I have tried to use as much of the more commonly used SAP BW content areas across various systems as possible. 

Because the BAdI logic can be filtered based on specific variable technical names, you can implement the logic shown in this section in line with your current BEx queries.

The following guideline is broken up into four main steps to enable cascading prompts:

  1. Create an extensible master data SAP HANA calculation view, joining Material Sales and Plant Material.
  2. Import a master data SAP HANA calculation view as a consumable ABAP view in SAP BW.
  3. Create a BEx Query and customer exit variables for users to provide their input.
  4. Create an RSR_VARIABLE_F4_RESTRICT_BAdI to define the logic for cascading filtering and outputting a filtered list of values to the user.  

Each of the following steps is highlighted in the diagram in Figure 4

Step 1. Create an SAP HANA Master Data Calculation View

This implementation is specific to the SAP BW on SAP HANA and SAP BW/4HANA environments as a prerequisite, ensuring that the most recent SAP BW and ABAP perspectives have been installed.  

As mentioned previously, you need to create a calculation view that is extensible and can be used to filter by numerous dimensions focusing on product information. The calculation view does the heavy lifting and filtering on large master data tables. In addition, you need to create a view joining 0MAT_PLANT and 0MAT_SALES, both of which are widely used objects across numerous BI systems.  

The join conditions are specific to this use case, but can be amended to match your system, assuming you have BI content installed. 

Create Z_PRODUCT_BAdI: Launch SAP HANA studio and select the SAP HANA modeler. In the screen that opens (Figure 5), create a new standard graphical calculation view. In this example, I call it Z_PRODUCT_BADI. Select the Data Category as DIMENSION (highlighted in red). Click the Finish button, which takes you to Figure 6

Figure 5
Create a Z_PRODUCT_BADI SAP HANA calculation view

Create a Join: In the next few steps I create a join between two master data tables in SAP BW and select a number of attributes of the master data objects that are used as filters in the user prompts. For example, this master data object could be the site, vendor, or brand of a particular product. 

In Figure 6, I create a new join. In the example I have used Plant Material and Material Sales, two widely used standard objects in the SAP system that are shown in further steps. Select the join and drag and drop it onto the canvas. 

Figure 6
Drag and drop a new join to the canvas

Add 0MAT-PLANT and 0MAT_SALES to the Join: Select Join_1 to go to Figure 7. Click Join_1 and select the highlighted add objects icon.

Figure 7
Add an object to the join

I am creating a join between two SAP BW master data objects—0MAT_PLANT and 0MAT_SALES. 0MAT_PLANT holds attributes that are specific to the material plant and 0MAT_SALES holds attributes of products that have been sold. Joining the two tables gives a complete central and local master data view of the product. In the calculation view in SAP HANA you use the technical P master data tables of the required InfoObjects.

After you select the add objects icon, you have to search for and add the two P tables of the relevant InfoObjects as shown in Figure 8.  Press Enter after you select the first table and search again for the next table. You have to search one at a time and then press Enter, which takes you to Figure 9. Only the sales table is displayed in Figure 8.

Figure 8

Click the OK button in Figure 9

Figure 9
Click the OK button

Define the Join Condition: This outcome differs from system to system depending on how each master data object has been set up, although the following join conditions can be used as a template. After you click the OK button to add the two tables shown in Figure 10, you need to create a new join condition. This condition should be an inner join type.

Figure 10
Inner join of PMAT_SALES and PMAT_PLANT

After you select the PMAT_SALES join, the properties of the join are displayed on the screen shown in Figure 11. Ensure the join type is inner join. 

Figure 11
Join type

To reduce the number of joins and improve the performance of the calculation view improvements, I have enhanced the SAP standard PMAT_PLANT InfoObject to include the sales organization and distribution channel as attributes. This is a consistent way to join PMAT_SALES and PMAT_PLANT.

Use the following join conditions between PMAT_SALES and PMAT_PLANT (Figure 12). 

Figure 12
Complete the join conditions

0MAT_PLANT object in BW has been enhanced to include SALESORG and DISTR_CHNL as attributes, as follows:





To create the joins above, drag and drop the required dimensions from MAT_SALES to MAT_PLANT in the join Details screen, as shown in Figure 13

Figure 13
Join dimensions by dragging and dropping

Create a Join: After you’ve selected the join conditions in Figure 12 and joined the dimensions, the join should look like the one shown in Figure 13. If you require further join conditions specific to your use case, this is where you can extend them.

Output Columns to Be Used for User Filtering: After you create the join you can select any objects by which you want to filter the master data view—for example, the number of products sold in a specific site or by a specific vendor. To do this step right-click the column and select Propagate to Semantics as shown in Figure 14. Your screen will then include the final output of dimensions and measures of the calculation view.  

Figure 14
14 Select the Propagate to Semantics option

Add the MAT_SALES Join to Semantics: Adding the dimensions from the previous step adds the required dimensions to use for filtering in the following steps. Your calculation view should now look similar to Figure 15. As mentioned above, all the included dimensions can now be used to filter your master data view in the following steps. You can add further dimensions as you require them. 

Figure 15
Final calculation view model giving a view of dimensions that can be filtered in further steps

Save and Activate the View: To complete this step, select the Semantics button and save and activate your view by selecting the save and activate icon in Figure 16.  

Figure 16
Save and activate the view

Test Run View: Right-click the Semantics button and select the data preview icon highlighted in yellow in Figure 16. In Figure 17, you can see all the departments that have products assigned to company brand 01. You can use this data to simulate how the prompt filters work in subsequent steps. 

Figure 17
Preview the data

You now need a way to consume the calculation view in SAP BW when a BEx Query is accessed and filters are passed down to SAP HANA. For this step, you need to create an ABAP view based on the SAP HANA calculation view. After you create this view, you can then incorporate it into various elements in SAP BW, specifically via a BAdI call.   

Step 2. Import a Master Data SAP HANA Calculation View as a Consumable ABAP View in SAP BW

Now that the SAP HANA calculation view is created to join both Plant Material and Material Sales, you need to have a method for integrating it within any logic you create in SAP BW and BEx. This step is done by consuming the calculation view as an ABAP view, which will be completed in the next steps. The ABAP view can then be used in any BAdI or customer exit code you write. In the case of cascading prompts you make calls to send filter criteria to the calculation view and pass the result set back to the SAP BW ABAP engine, using the extremely fast filtering of the SAP HANA level.

Open an ABAP Perspective and Log on to a Connected SAP BW System: First, make sure that the ABAP perspective is installed. In SAP HANA studio, you need to open the ABAP perspective. To open the ABAP perspective, follow menu path Window > Open Perspective > Other… (Figure 18). This path takes you to Figure 19.  

Figure 18
Open the perspective and select Other..

Click the ABAP option and click the OK button (not shown). 

Figure 19
Select the ABAP perspective

An ABAP button now appears in your ribbon. Click this button (Figure 20) and you see the screen shown in Figure 21.

Figure 20
ABAP perspective in the ribbon

Log in to your SAP BW system and select your default package, in this case, ZBW. Then select Dictionary > Views > New Dictionary View.

Figure 21
Select the New Dictionary View option to consume the SAP HANA calculation view built in the previous steps

Create a New ABAP View: After you select the New Dictionary View option in Figure 21, the system opens the screen in Figure 22 in which you can create a new view. In this case, the view is named Z_PRODUCT_F4. 

Figure 22
Z_PRODUCT_F4 ABAP view to connect to an external SAP HANA calculation view

Select the External View radio button and click the Browse button next to the SAP HANA View field to find the calculation view that was created in the earlier steps (Figure 23), in this case Z_PRODUCT_BADI - ZH.

Figure 23

Confirm the Attributes: After you click the Next button in Figure 23 (not shown), the system displays the details for the dimensions that are available in the semantics of the calculation view (Figure 24).

Figure 24
ABAP view attributes

Click the check icon and then the activate icon (Figure 25). 

Figure 25
Check and activate the view

Confirm the View in the SAP BW GUI: Now, when you log on to the SAP BW instance, the view is available to be consumed in SAP BW via the SAP GUI. In Figure 26 you can see all the ABAP Dictionary views that can be consumed in your connected SAP BW instance. The view created in the previous steps is highlighted in red.

Figure 26
ABAP Dictionary views available to be consumed in SAP BW

The next step is to log in to your SAP BW system via the SAP GUI and execute transaction code SE16. In the screen that opens (Figure 27), select the view you created earlier, in this case Z_PRODUCT_F4. Click the green checkmark icon highlighted in red, which takes you to Figure 28.

Figure 27
Z_PRODUCT_F4 Data Browser

Click the execute icon in Figure 28.

Figure 28
Filter the input and select the view

Filter the Master Data View: After you click the execute icon in Figure 28, the system opens a screen like the one in Figure 29 in which you can now run some filters on the view to emulate the list of values that will be returned as a result of your prompts created in the next steps.  

The example in Figure 28 could be a use case for a user to select a specific brand and site. After the user selects a brand and site, the system returns a filtered list of products specific to the selection. 

For this example, I want to view all the DELONGHI brand products sold by one store. This view provides a filtered list of products that can then be consumed in the cascading product prompt for a user to filter further. In Figure 28 type in your specific filters and click the execute icon. This action displays a list of filtered values shown in Figure 29.

Figure 29
Filtered output based on input criteria

As you can see in Figure 29, the calculation view is up and running—and it can now be used to filter and return specific data sets. 

The next step is to link the variables that the user enters in the Prompts screen (any columns selected in the calculation view in Figure 24 can be used). This step is done using BEx Query variables.  

To complete this step, you need to make prompts available to the user to enter so that the system can capture the selection and cascading filter logic. All reporting is done via BEx Queries using BICS. The next section outlines a typical scenario for creating a BEx Query and new variables.  

Step 3. Create a BEx Query and Customer Exit Variables for Users to Provide Their Input

As the main semantic layer between the front-end reporting tools and the BAdI logic held in SAP BW, the BEx Query is an essential part of the model. Variables and InfoObjects are used as the main call to the BAdI to capture a user’s response and send the specific filter criteria to the SAP HANA view to send back the filtered the list of values.  

You need to create a simple BEx Query to be used as an output for other reporting tools, but also predominately to show the construct of how the BEx Query communicates with the cascading prompt functionality. 

The example used here is specific to the implementation and is used to highlight how the functionality works to filter product master data. You can incorporate the functionality into your environment by following these steps and making amendments to specific InfoObjects used in your environment:

  • In this example, you create two new variables and include a number of existing SAP system content variables  
  • Select the time variant (for example, Mtd/Ytd)
  • Select the company brand
  • Select the site
  • Select the preferred vendor (e.g., the vendor held on the master data of the product)
  • Select the product
  • Create a new BEx Query on a base InfoProvider that contains the objects on which you need to filter

Create a BEx Query: In the example shown in Figure 30, I called the Vendor Product Selection Query (Y_ZVHCORP01_Q00003_VENDOR). This query is based on the specific composite provider of the environment. You can create the BEx Query on any relevant InfoProvider in your environment, ensuring all InfoObjects you would like to filter by are available. 

Figure 30
Create a new BEx Query

Create New Variables: It’s up to you to choose which InfoObjects should be included in the cascading prompt. In this example, I use the following:

Ensure the settings for creating the two new variables (from the 0MAT_PLANT_0VENDOR and ZPRODUCT InfoObjects) are shown in Figures 31 and 32

In Figure 31 ensure the general settings of the prompt are selected for Processing by Manual Input/Default Value to ensure users can enter values into the prompt. The trigger mechanism to call the ABAP view is handled by the BAdI that is created later. 

Figure 31
Ensure processing via manual input is selected

Next click the Details tab, which takes you to Figure 32.

Figure 32
Ensure the variable is ready for input

When you are creating the variables that you require for cascading, ensure that they are ready for input by checking the Variable Is Ready for Input check box. By default, this is left blank so be sure that you select it when creating your variables. Now save the variable. Then, in the BEx Query filter, ensure that the two new variables are included. In Figure 33 you can see the variables selected in the example scenario.

Figure 33
BEx Query filter results – Characteristic relationship displaying variables

After you save the variables and the query, click the Filter button (boxed in red in Figure 33). The result set (shown in Figure 34) includes several measures that are relevant for the analysis. For example, sales, quantity, comparisons, and some InfoObjects are set as free characteristics, which the user can select after the report has been refreshed to enrich the report analysis display.

Figure 34
BEx Query rows/columns

Save the BEx Query: The final steps for creating the new query are to check and save your query. To do this go to the Query tab and click the Save option (Figure 35). The BEx Query is complete. 

Figure 35
Save the query

As shown in Figure 36, when you run the query, by default, you can see that when a specific product is selected, an unfiltered list of all the products company-wide is selected that shows more than the maximum result set that is allowed. I added prompt selections, then selected Product by clicking the icon next to it.

Figure 36
Select the product

I have added prompts for one site and one vendor, which should have a small number of products from which to select in Figure 37. Instead, Figure 37 shows the whole list of products, many of which are not relevant to my analysis.

Figure 37
The unfiltered product list of help values shows all products for the entire data set

In the next section, I create the ABAP logic to capture the user’s input to each variable and return a specific filter list of values.  

Step 4. Create an RSR_VARIABLE_F4_RESTRICT_BAdI to Define the Logic for Cascading Filtering

At this point, the base underlying SAP HANA view is set up and returning results to filter on specific inputs. Also, the BEx Query has been created as the main communication to capture the user’s filter input requirements.  

The last step is to develop a codebase to link the two with the logic to filter each variable in the prompt screen based on the user’s input, and return a filtered list of values back to the prompt screen.  

For example, you want to filter a product’s list of values based only on the products sold at a specific site rather than an unfiltered list of all products. In the example, the focus is on the product list of values being filtered by several inputs.  

This is a significant use case that uses the SAP HANA optimized view to quickly return a filtered list of products based on a very large result set. For smaller master data objects, the calculation view can be computed on the InfoObjects themselves rather than by using the new SAP HANA view.  

Ensure RSR_VARIABLE_F4_RESTRICT_BAdI Is Set Up: To set up the construct of the BAdI RSR_VARIABLE_F4_RESTRICT_BAdI, refer to the documentation here.

In this case, name the enhancement implementation ZVAR_F4_RESTRICT. This holds multiple classes to filter specific InfoObjects. 

For this scenario on high-volume filtering, I created a single class for each InfoObject (e.g., product, brand, and vendor) although for small volumes of InfoObject data, this could be used in one implementation class based on the InfoObject filters, rather than using the SAP HANA view.  

Once the enhancement implementation ZVAR_F4_RESTRICT has been created, create a new class implementation and call it ZVAR_F4_RESTRICT_PRODUCT by clicking the Change button (Figure 38) or pressing Enter.

Figure 38
Create a new BAdI implementation

That takes you to Figure 39. Click the Enh. Implementation Elements tab and then click the create icon. 

Figure 39
Select the new implementation

This action displays the screen in Figure 40 in which you can enter the technical name and text of your implementation class. I have called the class ZCL_F4_RESTRICT_PRODUCT as part of the BAdI implementation created previously (refer back to the instructions before Figure 38).

Figure 40
Create a new BAdI implementation and implementation class

Once created, the implementation has two areas that you need to define: the implementing class and the filter value. The filter value essentially triggers the BAdI to be called. The implementing class is the restriction logic based on the flat, node, or hierarchy values. 

Click the continue icon (the green checkmark) in Figure 40 to create your implementation class. Figure 41 appears.

Figure 41
Filter value based on an InfoObject

Expand the class you just created. In the Flt. Val. (filter value) tab highlighted in Figure 41, select the InfoObject on which the variable is based. In this case, the BAdI is triggered once you select the variable created in the previous steps. In this case, I used the ZPRODUCT InfoObject (Figure 41) highlighted in orange. 

To enter the InfoObject select the Flt. Val. tab highlighted in the red box in Figure 41 and type in the name of the InfoObject. Press Enter.   

This is a custom product InfoObject that is specific to the implementation, but it can be extended to any InfoObject required. In a standard case, for example, this could be InfoObject 0MAT_PLANT or ZPRODUCT in our specific example. Figure 42 shows the InfoObject and variable in the BEx query, created in previous steps.  

ZPRODUCT highlighted in blue is the InfoObject, which is a copy of 0MAT_PLANT.  When a user runs a report based on the BEx query and selects the product prompt, this will now trigger the BAdI.  

Figure 42 displays that ZPRODUCT is part of the BEx query created earlier, which now triggers the code to be created in the following steps below based on Figure 41.  

Figure 42
Trigger InfoObject ZPRODUCT in the BEx Query

Implementation Class: In this example, I use a restriction based on the flat structure, although this could also be extended out to hierarchy and node restrictions. The following logic is based on the specific InfoObjects in your system and can be extended or amended to fit specific requirements.  

When creating the new implementation class, implement the following pseudo logic:  

  1. Obtain the list of selected InfoObject(s) values in the Prompts screen.
  2. Check the criteria and only process the F4 value help filtering logic if certain criteria are matched—for example, only display active sites based on an active/inactive flag
  3. Filter the SAP HANA master data view based on the selection of filled-in prompts
  4. Return the final list of values to the selected prompts 

You should still be on the same screen shown in Figure 41., which is shown in Figure 43 to highlight the class. Double-click the Implementing Class link highlighted in red and then double-click the GET_RESTRICTION_FLAT method as shown in Figure 44.  

Figure 43
Double-click Implementing Class

Figure 44
Double-click the flat restriction method

Double-clicking the flat restriction method displays Figure 45. This displays a blank method that you can now customize. Because I selected the RESTRICTION_FLAT method, the system filters on a flat structure of master data. If node or hierarchy characteristics are required, then you can use the _NODE or _HIER methods provided by SAP. The code in Figures 46 to 50 has been optimized for the specific environment. However, anyone with ABAP experience can amend this code for specific use cases and specific systems. You can use this code as a base template and modify it as needed for the InfoObjects and variables specific to your environment. 

Figure 45
A blank method, to be modified and the below code to be amended and added based on specific environment objects

You place the code in Figure 46 into Figure 45. The code in Figure 46 includes all the data declarations to be used in method. This includes declaring a table of each InfoObject to hold the user’s entered F4 Help values.  

METHOD if_rsr_variable_f4_restrict~get_restriction_flat.
    DATA: lt_comp_sel   TYPE TABLE OF rsrange,
          lt_stor_sel   TYPE TABLE OF rsrange,
          lt_dept_sel   TYPE TABLE OF rsrange,
          lt_vend_sel   TYPE TABLE OF rsrange,
          lt_vpre_sel   TYPE TABLE OF rsrange,
          lt_site_sel   TYPE TABLE OF rsrange,
          ls_selection  TYPE rsrange,
          lt_product    TYPE TABLE OF /bic/oizvenart,
          lv_product    TYPE /bic/oizvenart,
          l_s_range     LIKE LINE OF c_t_range,
          prev_flag     TYPE CHAR1,
          avend_flag    TYPE CHAR1,
          lv_prefix     TYPE string VALUE 'SAPBWMESSAGE',
          lv_suffix     TYPE n LENGTH 3,
          loc_var_range LIKE LINE OF i_t_var_range.

Figure 46 Data declarations

For each variable, you want to read and use the user’s selection to filter the result needed to declare a table of type ranges and to capture the user’s input from the variables. A copy of the product InfoObject is used to populate the filtered list that, in turn, is used to populate the F4 Help screen.

There are some specific flag objects to be used─for example, product active/inactive─that determine what SAP HANA view should be used to filter based on the actual (transactional) or preferred (master data) vendor. Any variable required to be used as a filter input should be declared here.  

Several loops are required to capture all the entries a user has selected for each variable. The code shown in Figure 47 loops through each of those variables and captures the input. In this example, you can see all objects captured from the prompts, including Store, Site, Department, Vendor (held on transaction), and Preferred Vendor (held on master data). The code directs the system to read the user’s input from the prompt screen for each InfoObject. The selection is appended and stored to be used later as filter selections for the view.  

    LOOP AT i_t_var_range INTO loc_var_range
      WHERE iobjnm CP '*ZPHSTORE'.
      ls_selection-sign   = loc_var_range-sign.
      ls_selection-option = loc_var_range-opt.
      ls_selection-low    = loc_var_range-low.
      ls_selection-high   = loc_var_range-high.
      APPEND ls_selection TO lt_stor_sel.
    LOOP AT i_t_var_range INTO loc_var_range
      WHERE iobjnm = '0PLANT'.
      ls_selection-sign   = loc_var_range-sign.
      ls_selection-option = loc_var_range-opt.
      ls_selection-low    = loc_var_range-low.
      ls_selection-high   = loc_var_range-high.
      APPEND ls_selection TO lt_site_sel.
    LOOP AT i_t_var_range INTO loc_var_range
      WHERE iobjnm = '0VENDOR'
         OR iobjnm = 'ZBATCH__0VENDOR'.
      ls_selection-sign   = loc_var_range-sign.
      ls_selection-option = loc_var_range-opt.
      ls_selection-low    = loc_var_range-low.
      ls_selection-high   = loc_var_range-high.
      prev_flag           = ' '.
      avend_flag          = 'X'.
      APPEND ls_selection TO lt_vend_sel.
    LOOP AT i_t_var_range INTO loc_var_range
      WHERE iobjnm = '0MAT_PLANT__0VENDOR'.
      ls_selection-sign   = loc_var_range-sign.
      ls_selection-option = loc_var_range-opt.
      ls_selection-low    = loc_var_range-low.
      ls_selection-high   = loc_var_range-high.
      prev_flag           = 'X'.
      avend_flag          = ' '.
      APPEND ls_selection TO lt_vpre_sel.
    LOOP AT i_t_var_range INTO loc_var_range
      WHERE iobjnm CP '*ZCOMPBRND' OR iobjnm EQ 'ZCURCOBRD'.
      ls_selection-sign   = loc_var_range-sign.
      ls_selection-option = loc_var_range-opt.
      ls_selection-low    = loc_var_range-low.
      ls_selection-high   = loc_var_range-high.
      APPEND ls_selection TO lt_comp_sel.
      LOOP AT i_t_var_range INTO loc_var_range
        WHERE ( iobjnm CP '*ZDEPT' OR iobjnm EQ 'ZCURDEPT' OR iobjnm CP '*ZDERDEPT' )
          AND vnam <> 'ZCUOM_DEPT2'.
        ls_selection-sign   = loc_var_range-sign.
        ls_selection-option = loc_var_range-opt.
        ls_selection-low    = loc_var_range-low.
        ls_selection-high   = loc_var_range-high.
        APPEND ls_selection TO lt_dept_sel.

Figure 47  Read users’ input, append it, and store it  

You can further add more code to the logic to include or exclude specific variables names, if needed. As you can see, in this example I excluded specific variables for specific use cases, for example, 'ZCUOM_DEPT2'. This makes the code implementation flexible to start developing in existing environments where existing variables are already in use. All the user’s inputs in the variables screen have now been captured. 

For a product list, even filtering, for example, by department can result in hundreds of thousands of products. Figure 48 shows the logic for filtering by product site, vendor department, or a combination of all the variables that are needed to be populated to return the list of values. 

* Only process when the selection is relatively small.
    IF lt_vend_sel IS NOT INITIAL OR
       lt_vpre_sel IS NOT INITIAL OR

       ( lt_dept_sel   IS NOT INITIAL AND
       lt_comp_sel IS NOT INITIAL AND
       lt_site_sel IS NOT INITIAL ).

Figure 48 Filter only filter if certain criteria are met 

Specific to the use case in this article, the code in Figure 49 is for when an actual vendor flag is used to determine which SAP HANA view to use to filter and populate the list of values between the vendor held on the transaction (actual) and a vendor held on the master data. That comes from the view you created earlier. An avend flag is a true/false flag to indicate if a vendor is the actual vendor on the transaction or a preferred vendor held on the master data. 

IF avend_flag = 'X'.

        FROM ZADIM02_HV4B
        INTO TABLE lt_product
       WHERE ZCOMPBRND    IN lt_comp_sel
         AND ZPHSTORE     IN lt_stor_sel
         AND PLANT        IN lt_site_sel
         AND ZDEPT        IN lt_dept_sel
         AND ZCATEGORY    IN lt_cate_sel
         AND ZGROUP       IN lt_grou_sel
         AND ZCLASS       IN lt_clas_sel
         AND ZBRAND       IN lt_brnd_sel
         AND VENDOR       IN lt_vend_sel
         AND ZPREF_VENDOR IN lt_vpre_sel.

Figure 49 Use the avend flag to decide which view to use to filter

Call to the SAP HANA Calculation View to Filter the F4 Help List of Values

When the actual vendor selected is blank, then you can use the SAP HANA view you created in the first steps. Filter the view based on the inputs captured by the user variables at the start of the class (Figure 50). This method sends filters to the SAP HANA calculation view—Z_PRODUCT_F4 created in steps 1 and 2. The filters are based on the user input captured in Figure 49. The result is then processed to populate the F4 Help values of the product variable. The list of filtered products is then captured in lt_product for further processing to output the F4 list of products.

ELSEIF avend_flag = ' '.

        INTO TABLE lt_product
       WHERE ZCOMPBRND  IN lt_comp_sel
         AND ZPHSTORE   IN lt_stor_sel
         AND PLANT          IN lt_site_sel
         AND ZDEPT          IN lt_dept_sel
         AND ZCATEGORY      IN lt_cate_sel
         AND ZGROUP         IN lt_grou_sel
         AND ZCLASS         IN lt_clas_sel
         AND ZBRAND         IN lt_brnd_sel
         AND VENDOR         IN lt_vpre_sel.

      IF lt_product IS NOT INITIAL.
*Start inserting F4 list.
        l_s_range-iobjnm = i_iobjnm.
        l_s_range-sign   = 'I'.
        l_s_range-option = 'EQ'.
        CLEAR l_s_range-high.
        LOOP AT lt_product INTO lv_product.
          l_s_range-low = lv_product.
          APPEND l_s_range TO c_t_range.

        l_s_range-iobjnm = i_iobjnm.
        l_s_range-sign   = 'I'.
        l_s_range-option = 'EQ'.
        lv_suffix  = 7.
        CONCATENATE lv_prefix lv_suffix INTO l_s_range-low.
        APPEND l_s_range TO c_t_range.

* Insert dummy product for message display.
      l_s_range-iobjnm = i_iobjnm.
      l_s_range-sign   = 'I'.
      l_s_range-option = 'EQ'.
      lv_suffix  = 1.
      WHILE lv_suffix < 7.
        CONCATENATE lv_prefix lv_suffix INTO l_s_range-low.
        APPEND l_s_range TO c_t_range.
        lv_suffix = lv_suffix + 1.

Figure 50 Method to send filters to the SAP HANA calculation view 

Now when I run Query Y_ZVHCORP01_Q00003_VENDOR, instead of prompting me with all products provided as F4 help values, the system instantly provides me with a specific list of products sold by vendor 604531 (Apple) to the site A022 (Figure 51). This makes the prompt selection much more relevant and user friendly. 

The view is filtered by Company Brand 01, Store 01020, Site A022, and Vendor 604531. When you select the product variable, you can now see a filtered list of specific products that have been sold from the selection made in the prompt screen. Previously, in Figure 37, this would display every product and exceed the maximum number allowed for F4 Help values. 

Figure 51
Final Prompts selection screen


The example provided is just for one specific variable, but this can easily be extended to any variable across your environment. The example provides the key foundation on which you can build. More complexity, business scenarios, and usability enhancements can be added into the logic. For example, you can include or exclude values based on the active or inactive status of master data and the most recently changed dates, or if stock is available for a product. The master data calculation view is also extensible. You can report on it, for example, by showing local pricing at the site level versus centrally held prices.

An email has been sent to:


Matt Vasey

Matt Vasey ( is an SAP BI Lead Consultant for Enterprise Wide ( with experience across multiple industry areas. He is a BI architect and implementation specialist, involved in all parts of the project life cycle. Matt has an in-depth understanding of SAP BW, SAP HANA, and SAP BI, particularly in Design Studio and Web Intelligence.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!