BEx

5 Easy Tips to Manipulate BEx Queries Using Variables  

by July Hartono, Alpha Net Consulting LLC

The author provides her favorite methods for getting good results with BEx queries, including specifying a variable offset and using a customer exit as a variable.

Categories: BEx, Reporting

Variables are very useful for manipulating a BEx query to get a specific result. Not only do variables allow you to enter your selection criteria for a query, they also allow you to re-use that input for another query (via the report/report interface). What follows are five of my favorite tips for using variables in BEx queries. They apply to both BW 2.x and 3.x unless otherwise noted.

Tip 1. Specify a Variable Offset While in many cases the variables that SAP provides as standard Business Content serve the purpose as is, you often need to enhance them just a little bit to meet your requirement. A simple example is the variable for current fiscal period. You might wish you also had a variable for a previous fiscal period, which SAP does not provide. You can actually convert the current fiscal period variable to a previous fiscal period by setting a variable offset of -1.

Here is how to set a variable offset. Go to the BEx Analyzer or Query Designer and open your query. In Query Definition, restrict the Characteristic InfoObject with a variable as needed. Right-click on the variable, and then

choose Specify Variable Offsets. (See Figure 1).

Figure 1 Setting a variable offset

Tip 2. Add a Customer Exit as a Variable Sometimes, the variable you need is not part of standard Business Content, so you must create your own. This is usually as easy as typing in a default value, but you occasionally need a more complex variable that requires ABAP code in a customer exit. To do so, start by executing transaction code RSZV, Processing by: Customer Exit, for BW 2.x, or go to the Variables Wizard in BW 3.x.

Note: You can access the Variables Wizard in BW 3.x when you are restricting an InfoObject(Figure 2).

Figure 2 Set up a customer exit as a variable using the Variables Wizard in BW 3.x

Then, go to transaction CMOD (Project) and create a project. Click on Enhancement assignment (Figure 3). At the next screen (Figure 4), enter RSR00001 under Enhancement and BW: Enhancements for global variables in

reporting under Text.

Figure 3 Create a project and then click on Enhancement assignment

Figure 4 Enter the enhancement name and description

Next, click on Components and double-click on EXIT_SAPLRRS0_001. This brings you to Function Builder (Figure

5). Now, double-click on the code INCLUDE ZXRSRU01 and enter your routine.

Figure 5 The Function Builder screen

When you finish, save your code and activate the project.

Tip 3. Find a List of SAP Exit Variables Typically, you look for SAP exit variables when you are in the Query Definition trying to restrict an InfoObject with variables. In BW 2.0B, you look in transaction code RSZV. Both are very restrictive. In the

Query Definition, you can see only a list of variables that is relevant to that InfoObject and no information about the properties of that variable. In RSZV, you have all the variables listed, but you must examine each variable one by one to find which InfoObject is relevant and what it does. It is a very tedious process. However, there is a way for you to see a list of SAP exit variables and to search through them based on the variable properties.

Figure 6 Use transaction code SE16 to locate table RSZGLOBV

First, go to table RSZGLOBV via SE16 (Figure 6). Then enter the value 4 (SAP exit) in the Processing Type field.

A list of SAP customer exits like the one shown in Figure 7 should appear.

Figure 7 A list of SAP customer exits

Tip 4. Find ABAP Code Behind SAP Exit Variables Now that you know how to create your own variables using a customer exit, you might wish to simply copy the code behind an SAP exit variable and modify it for your own purposes. This will save a lot of time during development. Here is how to find the ABAP code for an SAP exit variable.

All SAP exit variables are just function modules. Therefore, go to Function Builder (SE37) and enter

RREX_VARIABLE_EXIT in the Function Module field (Figure 8). Search the ABAP code for the name of the variable you need.

Figure 8 Use the Function Builder screen to locate ABAP code for exit variables

If not found, go back to the first screen of the Function Builder and enter RSVAREXIT_ * in the Function Module field and press the F4 key to find a list of all the other SAP exit variables.

Tip 5. Steps in Processing Variable Exits To help you customize your variables to fit your business requirement, you need to know exactly when these ABAP code segments in your customer exit are executed during query execution. The variable value is checked in a customer exit. Every variable type (not only customer exit variable) can be checked. The customer exit for variables can be called up to three times:

1. The first step (I_STEP = 1) is before the processing of the variable pop-up and is called for every variable of the processing type Customer exit. You can use this step to fill your variable with default values.

2. The second step (I_STEP = 2) is called after the processing of the variable pop-up. This step is called only for those variables that are not marked as Ready for input and are set to Mandatory variable entry.

3. The third step (I_STEP = 3) is called after all variable processing and is called only once and not per variable. Here you can validate the user entries.

Perhaps these five tips will inspire the BW reporting analysts among you to get more creative with your use of variables.

Note! I_STEP is the field name in the customer exit to specify where in the process you would like to check your variable.

A Simpler, Cleaner Approach to Trend Reporting in BW Using Variables  

by Rob Oliver, Manager, Integrated Enterprise Systems, Deloitte Consulting

When building reports that show past and projected results, query designers might start by creating a large column structure. This approach might prove cumbersome. The author shows a more flexible method using structures and a little user input via simple variables.

Categories: BEx, Reporting

Your company wants a report that shows all sales (value or volume) over a range of years, maybe for a product, a brand, or a market. This report shows actual sales trends for comparison against forecast and plan, enabling the business to spot growth areas or where products are stagnating. The report might look something like this:

First column starts from early history (10 years ago to last year) Second column shows the current year (year to date, plus plan or forecast for remainder of year)

Third column shows the short-term plan for next year

The last few columns show strategic planning information for two to five years into the future

A query designer might start building this report by thinking about a large column structure. This would work, but it could result in changes every year as another year of history means adding columns. Alternatively, you could use a structure requiring complex user entry of variables to add flexibility, but thereby reducing user friendliness.

There is another way. I will demonstrate an approach that uses a combination of structures and characteristics in a column, providing a flexible report that is easy to develop. It also requires minimal user input via simple variables. This approach eliminates the need for annual changes to the structure. As one year rolls into the next, the structure design automatically takes this into account. For the scenario described above, this approach requires a structure with six entries. You also need to create a couple of simple exit variables, although depending on individual

requirements, the content variable may be adequate. The end result will look something like Figure 1.

Figure 1 A complete trend report

Here's how the approach works: A formula pulls together all the data requested by the query. However, the inclusion of a calendar year object then disaggregates the data based on the calendar year of all the facts gathered. I will show you how to build such a structure. If you follow along and build it, you can review the structure and see that each element contains discrete data. The first two columns are combined to provide the total year data, which is a combination of actual and forecast data, for the year that the user enters.

At first, you might think that this approach hasn't saved much time. Depending on the volume of data (spread of years in the past and into the future), the amount of effort saved will vary. If the report was for one year of history, the current year, and one year of plan or forecast data, the effort required to produce the report is the same as using a column structure. As soon as additional years are added on either end, the time savings start to materialize. However, the approach also works for monthly, weekly, or even daily trend reports, depending on the time characteristics available, using the same size structure as for years.

Compare the approach outlined above with building a column structure for a five-year range, capturing each month to separate history (two years), actual and forecast (one year), and plan data (two years). This would be: 5 x 12 = 60 columns just for monthly trend reports. Big column structures like this not only have more maintenance overhead, but also have slower performance at run-time due to the need for the system to calculate the values in individual cells.

Let's look at the steps required for this structure-and-characteristics approach to trend reporting. The steps below apply to both BW 2.x and 3.x.

Step 1. Create a New QueryGo the BEx Analyzer (or Query Designer in BW 3.x) to create your new query. Keep the row/free characteristics

definition simple to allow drill-down and display to whatever level of detail you require. In my example, I have included only Sales Office and Material Type in the rows. Drag and drop whatever you require from the Dimensions on the left.

Step 2. Create a Column Structure

Right-click on Columns in the BEx Analyzer or Query Designer and select New Structure as shown in Figure 2.

Figure 2 Begin to create a column structure with the New Structure option

Step 3. Make Column Structure SelectionsThe design of the query will vary by business and the volume of data available in the InfoCubes. In this example, it is necessary to create five selections for the column structure and one formula. Right-click on the Columns option

(Figure 3) and create these one at a time using the New Selection and New Formula drop-down menu items.

Figure 3 Select column structures and formulas to use for the report

Each of these selections contains the relevant restrictions to ensure that the data in each selection contains unique data, avoiding overlapping records. This again will vary with InfoCube design, but in general the useful objects will be version, value type, and those that are time-based. I used these objects in my example:

0VERSION0CALMONTH0CALYEAR

When the New Selection window pops up, enter a suitable title. In Figure 4, I used Actual Sales Volume. Then drag in the appropriate key figure and the objects necessary to restrict. For this selection, only the Calendar year object is needed (Figure 4). Right-click on the year to restrict the selected data (Current Year derived from input variable ‘month' in my example), select a value range by changing Selection at the top of the window to Value Range from

the default Single Values. Click on the Variables tab.

Figure 4 Once you've named a new selection, restrict the selection by year and provide a value range

Step 4. Specify the Variable OffsetsIn the example, the selected variable is a customer exit to derive the year from the 0CALMONTH object that the user selects at run time. (This customer exit is a relatively simple process covered in the SAP online documentation. The sidebar, “Creating Variables with BW 3.x,” on page 12 shows how the process has changed from BW 2.x.) However, you could adapt standard variables to provide a suitable workaround. This variable will be set as both the “from” and

“to” values described next. To achieve the range of the years the report requires, use the Specify Variable Offsets function. This feature allows you to define different data selections for different columns based on just one input from the user—e.g., the user enters “2003” as the current year, and the variable value -1 (the offset) captures 2002 data.

Figure 5 Set the "from" value in the first Enter Variable Offset pop-up window, and set the "to" value in the second Enter Variable Offset pop-up window

The two windows shown in Figure 5 should appear in succession. The first sets the “from” value—in this case, a value of -5 from the year derived from the calendar year and month that the user enters at run-time. Click on OK, and the second window where you set the “to” value appears; I used -1. So, if the user enters 06.2002 for the calendar year and month, the “from” value becomes 2002 - 5 = 1997 and the “to” value becomes 2002 - 1 = 2001.

Step 5. Complete the Other Column Structure Selections

Continue to define all the other selections in the Columns structure option (Figure 6). The details for achieving the required restrictions for my example follow. Again, restrictions will vary with InfoCube designs. All structure selections use the same key figure, so this is not repeated below. An alternative would be to include the key figure as a filter. However, other InfoCube designs may use separate key figures for plan and actual data.

Figure 6 Define the remaining column selections

Actual Sales — from start of input year to month -1: Use the calendar month/year input variable as the “to” value. An additional customer exit variable calculates the “from” value as “month 1” for the year of the input variable. Use variable offset -1 for the “to” value.

Forecast — from input month until year-end: Use calendar year month input variable as the “from” value. An additional customer exit variable calculates the “to” value as “month 12” for the year of the input variable. Use the Version option (on the left in Figure 6) to restrict to plan data rather than the actual sales data. This ensures no overlapping records.

Annual Plan Forecast Year +1: Use the Actual Sales calendar year variable to default the year to what the user enters, but with a variable offset of +1 to capture the next year's data. Use Version to restrict to plan data and to segregate the annual plan from a rolling forecast or any different versions.

Strategic Forecast Year + 2 to Year +5: Use the Actual Sales calendar year variable to default the year to what the user enters, but set the range with a variable offset (+2 to +5) to capture the future years' data. Use Version to restrict to plan data and to segregate the strategic forecast from a rolling forecast or any other versions.

Step 6. Put All the Selections TogetherNow you must create the formula to add all the above structure elements together. Right-click on the column structure name and select New Formula. Describe the formula appropriately and add all the selections together. A

click on the check icon will confirm it is correct (Figure 7).

Figure 7 Click on the check icon to confirm that the formulas syntax is correct

Step 7. Hide the Column SelectionsThe final trick is then to hide all the selections, leaving the formula as the only part of the structure to be displayed. To do so, right-click on each selection, choose Properties, and then flag the selection as Hide. Then drag the Calendar

year InfoObject (in the Columns area) to be either above or below the structure. Do not add any restriction to this object. Doing this provides the needed drill-across capability.

Creating Variables with BW 3.x

With BW 3.x, you must create variables through the BEx Query Designer using the Variables Wizard. This is a useful feature as the query developer no longer has to go from the BEx Query Designer to BW's initial logon screen to create new variables. (Don't worry; you can still look up your variables using transaction code SE16.) I'll introduce you to BW 3.0's Variable Wizard using the trend reporting query as an example. The query developer needs to define a variable that is automatically populated with the value of the year from another variable. For example, if a user enters 03.2003 for 0CALMONTH, the new variable takes the value 2003. The steps to do so

follow:

Step 1. Create an Input Variable Go to the BEx Query Designer. To restrict the 0CALMONTH object, right-click on Calendar year/month and then choose New Variable (Figure 1). This executes the Variables Wizard. Step through the Variables Wizard, completing the fields with the required values as shown in Figures 2 through 5. Once you've completed the entries and saved the new variable, you can use it in the query. Remember the technical name you gave the

variable for use later. In my example, the name is ZP_YRMTH.

Figure 1 Select New Variable from the BEx Query Designer to access the Variables Wizard

Figure 2 Enter a name and description for the variable, and then identify its processing type

Figure 3 Indicate what the variable represents, whether entering a variable is mandatory, and whether it has to be ready for input

Figure 4 Set a default value for the variable (blank=null)

Figure 5 Click on Finish to save the variable

Step 2. Create a Customer Exit VariableThis customer exit variable derives the calendar year for the value entered in the Calendar year/month variable. Right-click on Calendar year/month in the BEx Query Designer, select the Variables tab, and right-click on New Variable. Work through the screens as in step 1 to create another variable with the following attributes:

Variable Name: ZX_CYEAR

Variable Description:

Calendar Year from Input Cal Month Year

Processing by: Customer Exit

Characteristic:Calendar year should appear by default

Variable represents:

Single Value

Variable is: Mandatory

Ready for input: Do not flag

Default value: Null (leave blank)

Click on Finish to save the variable.

Step 3. Create ABAP Code to Populate the Year Value in the Customer Exit Variable The Basis team may complete this task. This includes creating the project and assigning the component as follows:

Enhancement

RSR00001 BW: Enhancements for global variables in reporting

Function Exit EXIT_SAPLRRS0_001

Use transaction code CMOD. Display the BW project by selecting from the drop-down menu and clicking the Display button. Click on the Components button, and then double-click on EXIT_SAPLRRS0_001. A screen appears at the bottom with the line INCLUDE ZXRSRU01. Double-click on ZXRSRU01 to get to the details of the

include code. You or your Basis team can add the code shown in Figure 6 to perform the task of taking the year from the calendar month/year that the user enters. Save and activate each level of the enhancement while backing out of the screens until you reach the initial screen where you perform the final activation. Again, this is an area where you should work with an experienced ABAPer.

Figure 6 Code to capture the current year from what the user enters

Step 4. Execute the QueryWhen you execute the query, the only date-related variable that should appear is the one for Calendar year/month. The customer exit subsequently gathers the appropriate data for columns based on the variable offsets that you used.

A Strategy for Collecting and Transporting BW Requests  

by Sushrut Shrotri, Manager Specialist, BI Practice, Deloitte Consulting

The author presents an alternative method for collecting and transporting requests using SAP's BW Transport Connection. The complex models often used for BW implementations require a collection/transport strategy, like the one in this article, for BW requests.

Categories: BEx, Data Extraction, SAP ERP, Transports

SAP created the Correction and Transport Organizer (CTO) to move configuration settings, programs, and data across different systems. BW, however, uses a modified version of the CTO called the BW Transport Connection. With standard CTO, collecting and transporting requests is a relatively simple process. This is not necessarily the case with the BW Transport Connection, particularly for complex data models. You need a transport strategy with BW, so I'm presenting a process using the BW Transport Connection that has worked well at many of my clients. This process applies to all versions of BW.

A typical SAP environment consists of development, quality assurance, and production R/3 systems, and corresponding BW systems. Transports run from the development to the quality control and production systems, as

Figure 1 shows.

Figure 1 Connections and data flow between corresponding BW and R/3 systems

After the connections have been established and the appropriate security access has been delegated, you need to perform a series of checks. For example, make sure that the relevant release-dependent extractors have been installed. You also want to confirm that the remote ID and Transport Management System (TMS)/CTO authorizations to relevant users have been set. The remaining checks are specific to the BW Transport Connection, so I've outlined the remaining steps you must perform to use this tool.

Step 1. Checking the Connection Between BW and the Source Systems The first check is to ensure that BW is properly connected to the source systems. This is required for replication of the DataSources before transporting. Go to the Administrator Workbench (transaction code RSA1) and click on the

Modeling tab (Figure 2), and then click on the Source Systems menu item.

Figure 2 Check connectivity to source systems

To the right you will see a list of source systems. Right-click on the one you want and then select Check in the pop-up window that appears. Repeat the process for each of your source systems.

Step 2. Map Source System Names The next step is to map your source systems to BW. Since some objects in BW are source-system specific (such as transfer rules and transfer structures), these objects must establish the connection to the target source system after successful transport. In the Administrator Workbench of the target system, click on Tools>Mapping of Source

system names, as shown in Figure 3.

Figure 3 Select the Mapping of the source system names option

This will bring you to the screen shown in Figure 4. Here, you enter the appropriate object names in the source system (R/3) column (OrSrceSyst) and the corresponding object name in the target system (BW) column

(TargSrceSyst).

Figure 4 Enter the corresponding R/3 and BW object names in the appropriate columns

Step 3. Configure the TMS

This check ensures that the TMS has been configured properly and is active. This is a Basis function. Figure 5 shows the configuration screen for the TMS check (transaction code STMS).

Figure 5 The TMS configuration screen

Step 4. Create Development ClassesThis important step ensures that the objects are collected and stored correctly. In general, you need to create the following development classes:

One for all the administrator objects—InfoObjects, InfoCubes, ODS, InfoSources, InfoPackages, etc. For all queries and query elements—one development class for each InfoCube/ODS on which you write a

query, and one development class for all variables (recommended for complex implementations with large query-development teams).

For all the technical business content—BW Statistics, for instance

Also, use the BEx Development Classes button under Transport Connection of the Administrator Workbench to assign BEx development classes.

Step 5. Collect ObjectsBy default, all new BW objects are stored in the local development class ($TMP). These objects must be collected and assigned to a transportable development class and a transport request to carry out transports.

You can separate the objects into two main collections: initial collection and changes. The steps for setting up each of the three classes of initial collections follow. For individual objects, select the object from the object list, set the

grouping to Only necessary objects, and set collection to Manual collect. (See Figure 6.)

Figure 6 Settings for collecting objects by Repository Cache, Grouping, and Cellection mode, respectively

For Administrator Workbench objects (InfoObjects, InfoCubes, ODS, InfoSources, InfoPackages, etc.). In the

Transport Connection section of the Administrator Workbench, make the following settings before carrying out the transports:

Setting Value

Repository Cache Do not use

Grouping In data flow before

Collection mode Collect automatically

Identify the data target at the top of the data model. To illustrate, I've created the sample PCA MultiCube shown in

Figure 7. Drag and drop the data model into the collection area. The system will automatically collect all the objects for that data target. Click on the transport icon to create a new request to store the collected objects.

Figure 7 An example PCA MultiCube

For Business Explorer objects. Set the following values for each item below:

Setting Value

Repository Cache Do not use

Grouping Only necessary objects

Collection mode Collect automatically

Select all the queries that need to be transported for a data target (InfoCube or ODS). Drag and drop the queries into the collection area. The system collects the required objects. For each query collected:

Right-click and deselect all objects under InfoCube/ODS

Expand and select the workbooks to transport

Right-click and deselect roles selected

When you are finished with all the queries, click on the transport icon and select the development class for that InfoCube/ODS. Save it in a new transport request.

For variables. Set the following values for each item below:

Setting Value

Repository Cache Do not use

Grouping Only necessary objects

Collection Collect automatically

Select object types from the Transport connection menu and select Query Elements. Select Variables from the Variable submenu and drop them into the collection area.

For transporting changes. If objects have never been transported before, changes can be made directly since the objects still reside in the local development class. You can then wait for the prompt for a transport request if they have been transported to a target system.

Administrator Workbench objects prompt for a transport request during the change. Variables prompt for a transport request during the change.

Business Explorer objects are saved automatically under the BEx request assigned to the BEx development class.

Step 6. Release the TransportsFor simple data models, you just release each request after it is collected. For complex data models, do not release any requests until all data targets have been collected. Then release requests in the same sequence in which they were collected, and likewise transport them in the same sequence in which they were collected.

The five-step transport sequence is as follows:

1. Transport the extraction structures, extraction programs, and DataSources from R/3 development to R/3 quality to R/3 production systems.

2. Replicate the DataSources in BW.

3. Transport administrator objects from BW development to BW quality to BW production systems. Transports that export DataSources from one R/3 system to the next require a replication from R/3 to BW and a re-transport of the corresponding infosources in BW.

4. The variables transport.

5. Related BEx objects transport in the sequence in which they were collected.

I have not run into any issues when transporting Administrator Workbench objects (InfoCubes, InfoSources, InfoPackages, ODS, etc.) if the transport requests are collected, released, and transported in the appropriate sequence. However, transports with exported DataSources might require a replication and a re-transport for BW releases up to 2.1. Using the automatic collection function for BEx objects requires a custom development strategy depending on each client outside the technology. This might reduce the flexibility of the system.

My company has successfully used the above process for different implementation scenarios across different industries with different functionalities.

Accurately View Price Reports with Multiple Vendors and Multiple Materials  

by Andrey Bondarev, BW/SEM Consultant, Bluefin Solutions Ltd.

The sum of prices per product often is not an accurate measure of performance when comparing multiple vendors, materials, and prices. The weighted average method, however, adjusts the sums proportionately so that you can make an accurate judgment of vendor performance. While BW has no standard weighted average method of aggregation, you can model it in BEx Query Designer using calculated key figures.

Categories: Aggregates, BEx, Reporting

Key Concept

The weighted average aggregation method makes quantities consistent at any drill-down level, without major changes to the back end, by using sums adjusted to reflect the proportionate prices of materials sold by different vendors.

In my work with clients, I have encountered several functional and technical issues involving product pricing. Aggregating the prices for comparison purposes is not as straightforward as simply adding the prices or taking the average of the prices because these figures are not consistent across drill-down levels. However, by weighting the averages, I can create a report that reflects the proportionate prices of each vendor across drill-down levels. This allows you to compare the purchasing price variance (PPV) to determine which vendor gives you the best value. I will show you how to use BEx Query Designer to model a weighted average aggregation method using calculated key figures.

Say you purchase three materials from two different vendors and you want to compare the performance of each vendor in July 2005 by using the purchasing performance report. Multiple vendors, materials, and prices are involved, so neither summation methods nor average methods present a consistent, accurate view of price reporting. Using the weighted average aggregation method lets you view price reporting in this situation and reflects all prices proportionately depending on the quantity sold in a given time frame.

Even if your reporting requirements on prices are not as complex as described in this article, you may find some of my tips and tricks useful. Purchasing is just one of the examples of the application of the weighted average aggregation method. You could apply the same methods described in this article to a Sales and Distribution (SD) report. For example, instead of vendors, you could use this method for customers. This functionality has proven to work with BW 3.x.

I’ll explain the theory behind the weighted average aggregation method and show you how it provides consistent reporting at all drill-down levels. Using my example of a purchase performance report, I’ll walk you through the thought process of setting up the necessary formulas, show you how to implement them in BW, and demonstrate how the weighted average aggregation method works for both drill-down by material and drill-down by vendor.

Build the Purchase Performance Report

To compare vendor performance, include the following key figures in your purchase performance report:

PPV

Material standard price

Invoice actual price

Actual quantity purchased

In addition, to make the comparison, you need to be able to drill down using the following characteristics:

Material

Vendor

Table 1 shows the transactional data of three materials (M) sold by two different vendors (V). Only the first four columns constitute the transactional data from the source system. Invoice actual price may also come directly from the source system, but it is better to calculate invoice actual price in the report using a calculated key figure that divides invoice value by invoice quantity. Not keeping the invoice actual price in the InfoCube allows better aggregation and unit of measure display, as I will show in my example.

Material code

Vendor code

Quantity

purchased

Invoice value

Invoice actual price

Material standard

price/metric ton (TO)

PPV

M1 V1 10 TO 1400 EUR 1400 EUR/TO 1600 EUR/TO 2000 EUR

  V2 2 TO 4000 EUR 2000 EUR/TO 1600 EUR/TO -800 EUR

M2 V1 5 TO 1500 EUR 300 EUR/TO 250 EUR/TO -250 EUR

  V2 20 TO 5000 EUR 250 EUR/TO 250 EUR/TO 0 EUR

M3 V1 5 TO 3000 EUR 600 EUR/TO 650 EUR/TO 250 EUR

  V2 25 TO 15000 EUR 600 EUR/TO 650 EUR/TO 1250 EUR

Table 1 Transactional data of three materials sold by two different vendors

To aid my comparison in Table 1, I also added the material standard price and calculated the PPV, although these figures are not made available in the InfoCube.

Note

Normally, an InfoCube contains a time dimension, but the data in your InfoCube refers only to July 2005, so your sample report does not need a drill-down time characteristic.

Calculate the PPV

When comparing pricing, the typical performance measure is the PPV, which is calculated as: PPV = (material standard price – invoice actual price) x actual quantity purchased.

In this formula, the material standard price is an attribute of the material (or compounding InfoObjects, such as 0MAT_PLANT or 0MAT_SALES). The price is dependent not only on material, but also on organizational levels.

Positive PPV means that you save money by buying materials at prices lower than expected. Negative PPV means the opposite; you lose money by buying materials at prices higher than expected. The higher the PPV, the better the vendor performance.

Regardless of the drill-down level, the PPV is calculated based on prices according to the formula above. The total PPV remains the same, even if you change the drill-down level without changing variables or filters.

Note

You can also extract the PPV from the GLPCA table in the Financial Accounting (FI) system. However, you need to use the PPV formula defined in this article if you want to forecast PPV. For more details, go to help.sap.com and look for “purchase price variance.”

Aggregate Key Figures to Calculate the PPV

To figure out the aggregated PPV to compare the overall performance of each vendor, you need to aggregate the key figure amounts for each vendor. The aggregation method used for invoice actual price and material standard price is the same. However, the realization of this method is different. I have the invoice value in my transactional data for computing the invoice actual price, but I do not have anything for standard value for computing the material standard price.

I’ll show you a numeric example to illustrate the challenges of an apparently simple purchasing performance report.

When it comes to building similar reports, you may wish to create similar tables and use them for testing. Table 2 contains the detail from the material master data shown in Table 1.

Material code

Material description

Material standardprice/metric ton

(TO)

M1 Lamb 1600 EUR/TO

M2 Potato 250 EUR/TO

M3 Strawberry 650 EUR/TO

Table 2 Materials sold by the vendors

Your company buys the materials in Table 2 from the two vendors shown in Table 3. From the example shown in Table 1, you can see that if you choose to drill down by material, you come across a problem. The invoice actual price for materials M1, M2, and M3 differs for each vendor and is not defined at the material level.

Vendor code

Vendor description

V1 Five Star Farming Ltd.

V2 Diamond Farms Ltd.

Table 3 Vendors selling the materials listed in Table 1

Aggregate the Invoice Actual Price

To define an invoice actual price at the material level, drill down to material M1 (lamb) and aggregate the key figures

for both vendors. From Table 1, you can figure out the key figures, except for the invoice actual price (Table 4).

Material code

Material descripti

on

Quantity purchased

Invoice value Invoice actual price

Material standard

price

PPV

M1 Lamb 12 TO 18000 EUR ? 1600 EUR/TO 1200 EUR

Table 4 Invoice actual price missing

Both invoice value and quantity purchased are additive key figures; they may be aggregated by summation. Additive key figures are accurate at any drill-down level because the summation result does not depend on the order and grouping of additives. (Examples of non-additive key figures are a price or a date.)

So, what should be displayed for invoice actual price? Neither summation methods nor average methods give you a useable figure because the sum figure of 3400 EUR/TO is incorrect, as is the average figure of 1700 EUR/TO. Invoice actual price is defined as invoice value divided by invoice quantity (Figure 1). Its use as a calculated key figure is equivalent to the aggregation of actual prices using the weighted average method, where purchased

quantities serve as weights. The formula in Figure 2 illustrates this. Take the total invoice value (14000 for V1 + 4000 for V2) and divide it by the total quantity purchased (10 for V1+ 2 for V2). The result is 1500 EUR/TO.

Figure 1 Formula for invoice actual price

Figure 2 Example of aggregated invoice actual price

The total aggregated price of 1500 EUR/TO is more accurate than the price calculated by a simple average method, 1700 EUR/TO. Most of the quantity was bought at 1400 EUR/TO and a relatively small part was bought at a higher price. Therefore, the aggregated price should not be too far from 1400 EUR/TO. The invoice actual price is also accurate at any drill-down level because it is defined as a calculated key figure based on two additive key figures.

Aggregate the Material Standard Price

If you aggregate the material standard price the same way as the invoice actual price, you can include both prices in the PPV formula, enabling you to compare vendor efficiency, depending on the actual quantities of materials purchased. The aggregation of material standard price, however, is more difficult. Whereas the aggregation of material standard price is trivial at the material level, in the drill-down by vendor, the material standard price needs to

be consistently displayed. Use the formula shown in Figure 3 to aggregate the material standard price.

Figure 3 Formula for material standard price

Because I do not have the total standard value for the formula in Figure 3, I need to calculate it to obtain the material standard price. Total standard value is defined as the sum of all quantities valuated at standard price. To calculate

the total standard value, use the formula in Figure 4.

Figure 4 Formula for total standard value

If you do not need to keep the material standard price as master data, you could use the same easy formula for material standard price as for invoice actual price. You could incorporate the master data read in the update rules and calculate the total standard value for the transaction data.

Nevertheless, you may want to keep the material standard price as master data. For example, it might be changed quite often. The InfoCube only contains historical valuation, while the users might be interested in the current standard value. In this case, follow the aggregation method I outlined in this section.

The weighted average method is not one of the standard aggregation methods, but you can model it on the BEx level. Now I will show you how to apply this aggregation method to the purchasing performance report.

Weighted Average Aggregation Method in BW

The following steps assume that you already have the InfoCube with vendor and material characteristics, as well as invoice actual price, invoice value, and quantity purchased key figures.

Step 1. Create a new query in BEx Query Designer to display the invoice actual price and quantity. In the BEx toolbar, click on the Open button and choose Query from the drop-down menu. In the pop-up window that follows, click on the New button. Select the InfoCube and double-click on it. In the next screen, drag and drop the Vendor

and Material characteristics to the Free Characteristics and Rows sections (Figure 5).

Figure 5 Create the query

Although Invoice Actual Price could be available in the InfoCube, it is not used directly in this query. Instead, use the NOERR function (invoice value/quantity purchased), because it ensures that you do not get any errors if no quantity has been purchased. You thereby avoid division by zero overflow.

Right-click on the Calculated Key Figure subtree and select New Calculated Key Figure. Double-click on the

NOERR function from the Data Functions subtree (Figure 6) to create the calculated key figure from the relevant key figures. Drag and drop Invoice Value and Quantity Purchased into the formula and insert the division sign (/) between them.

Figure 6 Invoice Actual Price (Calculated) as a Calculated Key Figure

Drag and drop the Invoice Actual Price (Calculated) and Quantity Purchased key figures to the Columns section. You should end with a screen similar to Figure 5.

Step 2. Run the query. Click on the check mark icon in the upper left corner of the BEx Query Designer screen to

run the query and view the results in Microsoft Excel. Figure 7 shows the Purchasing Performance Report drilled down by material and vendor using the query navigation functions.

Figure 7 Purchasing Performance Report drilled down by Material and Vendor

Double-click on the cell to the right of the characteristic name (for Vendor, the cell selected in Figure 7) to add drill-down by this characteristic. You could reach the equivalent result by right-clicking on the same cell and choosing Add drilldown from the context menu. My report has a default drill-down by material; therefore, all I need to do is double-click on the cell to the right of Vendor after the initial query execution.

By using division in the formula for the Invoice Actual Price (Calculated), the weighted average aggregation method works for the Result rows (and at the material level) and the unit of measure is also present.

Step 3. Add the material standard price to the report. First, I’ll show you what happens if you simply add the standard price as an attribute of material in a formula variable. In BEx Query Designer, create a new calculated key figure by right-clicking on the Calculated Key Figure subtree and choosing New Calculated Key Figure. In the next

screen, shown in Figure 8, right-click on the Formula Variable subtree and choose New Variable.

Figure 8 Select New Variable from the Formula Variable subtree

You now need to make entries on several screens, as shown in Figures 9, 10, and 11.

Figure 9 Select Replacement Path to indicate you are using an attribute

Figure 10 Select the characteristic that has material standard price as an attribute

Figure 11 Select Attribute Value and then select the exact attribute (Standard Price in this case)

Step 4. Build the calculated key figure material standard price. As in step 3, right-click on the Calculated Key Figure subtree and choose New Calculated Key Figure. Expand the Formula Variable subtree and double-click on the variable you created in step 3. Add this calculated key figure to your report.

Execute the report and drill down by vendor using the query navigation functions. The report shown in Figure 12 displays the results.

Figure 12 Drill down by Vendor

Recall that the invoice actual price is the invoice value divided by quantity purchased. The material standard price is simply the sum of the prices of the underlying materials, which is clearer if you add drill-down by material, as shown

in Figure 13.

Figure 13 Drill down by Vendor and Material

Note that the material standard price is displayed as EUR, giving you no information about the unit of measure. You must build a formula that gives you appropriate overall results and enables you to list the unit of measure for the material standard price.

Step 5. Create the standard value formula that represents the value of purchased materials at material standard price. Because it is a value, you want only the currency attached to it, which is why the quantity is put in this formula as a value without dimension. The formula should look like this: Standard value = material standard price x NODIM (quantity purchased).

The trick about this key figure is the setting Time of Calculation to Before Aggregation. This setting ensures that you get the sum of products of prices by quantities. In BEx Query Designer, right- click on the Standard Value calculated key figure you just created and choose Properties. In the Aggregation section, for Time of Calculation, select Before Aggregation from the drop-down list.

Step 6. Define the material standard price. All you need to do is to divide the standard value by quantity, as shown by this formula: Material standard price = NOERR (standard value/quantity purchased).

Follow the instructions outlined in step 1 to create the material standard price calculated key figure shown in Figure

14.

Figure 14 Define the material standard price

You might be surprised by the last two calculated key figures I created. First, the material standard price is multiplied by quantity, and then it is divided by quantity again. Setting the Time of Calculation to Before Aggregation effectively puts the weighted average formulas in place.

Step 7. Build the PPV formula. As a last step to calculate the PPV, build another formula. Again, follow the steps

outlined in step 3 to define the PPV: PPV = standard value – invoice value (Figure 15).

Figure 15 Define the PPV

This calculated key figure puts in place the definition of PPV. Now drag and drop the above key figures, material standard price, and PPV into your report and see what it looks like at the different levels of drill-down. Double- click on the gray cell to the right of the characteristic name to execute the different levels of drill-down shown in Figures 16

through 19.

Figure 16 Drill down by Material

Figure 17 Drill down by Vendor

Figure 18 Drill down by Material and Vendor

Figure 19 Drill down by Vendor and Material

The PPV figures in the purchasing performance reports show that you save money on your purchases of strawberries and you do not gain or lose money on your purchases of lamb. However, you lose money on your purchases of potatoes. In addition, although both vendors have positive PPV, Five Star Farming Ltd. is more attractive than Diamond Farms Ltd. because Five Star Farming Ltd. has a total PPV of 1000 EUR, while Diamond Farms Ltd. has a PPV of 250 EUR.

Note that the PPV displayed in the screenshots above is consistent with the original PPV formula: PPV = (material standard price – invoice actual price) x actual quantity purchased.

This is true at all levels of drill-down and with any combination or sequence of drill-down characteristics. I achieved this result because I used the weighted average aggregation method for both material standard price and invoice actual price. You can view additional examples of analysis using this method in the Downloads section of the BW Expert Web site at www.BWExpertOnline.com.

Important Points to Consider

Here are some important points to consider when choosing to use the weighted average aggregation approach.

The Before Aggregation calculation time can produce a warning when analyzing query performance in RSRV because this setting affects the performance of the report. However, it is a standard feature and it should be used where appropriate. Avoid using it when many records are involved in the aggregation (e.g., non-cumulative key figures) and make sure it is properly tested on production volumes of data.

If no quantities have been purchased, both actual and standard prices are displayed as zeros.

If the material standard price attribute already exists for a material, its default aggregation could be already set to Average. Such attributes cannot be included in the formulas in this article, because mixed aggregation is not allowed in formulas and there is no way to change the aggregation method once the InfoObject has been created. In this case, you must create a copy with summation aggregation.

If the currencies or units of measure used in aggregated prices are different, the system cannot produce a consistent result. In this case, the system displays the default asterisk symbol for Mixed Values. You can change this symbol in transaction RSCUSTV4. If you still need to display the resulting price, select the Mixed Values option in the same transaction.

Add Workbooks to Users' Favorites for Improved Communication

by David Eady, Reporting Team Lead, SI Corporation

Normally, BW reporting users open a workbook from a BW role and then save the workbook to their favorites. In certain situations, it is helpful if the development team could automatically add a workbook to a user's favorites. Learn a shortcut using a function module that adds a workbook to a user's favorites without the user's intervention. You can also add a power user's workbook to your own favorites.

Categories: BEx, Reporting

Key Concept

In BW BEx reporting, users have the ability to add Excel workbooks to their list of favorites. The list of favorites is handy for users because it gives them quick access to the workbooks that they use most frequently.

Many BW reporting users pull published Microsoft Excel workbooks from the roles menu, set up the filters and navigation state that they require, and save the resulting workbooks to their BEx favorites. Once their favorites are set up, users rarely return to the roles menu to open BW workbooks.

The original workbook is still attached to the BW role and anyone with authorization to that role can still access it. However, by saving the modified workbook to their favorites, the user creates a new, separate workbook that only exists in the user's favorites. This method of saving workbooks to favorites presents some downfalls for developers.

The first problem is that developers can't access workbooks stored in a user's favorites because those workbooks aren't attached to a role. Workbooks attached to BW roles are generally easier to discuss because the developer and the user both have access to the same workbook. Secondly, developers often need to distribute a workbook to a single user for testing purposes. Short of emailing the workbook (which companies often discourage for security and data auditing purposes), there is no easy way to make a workbook visible to a single user other than my workaround.

You can avoid these problems by using my technique to automatically add a workbook to a user's favorites in BEx, as

shown in Figure 1, and to add to a user's favorites list. To learn more about workbooks, see the sidebar, "BW Workbook Fundamentals." With a little knowledge of how BW stores favorites and of a system-supplied function module, you can have greater control of your users' favorites. This shortcut saves time because you don't have to publish the workbook to a role and it also makes the workbook accessible to super users and to the developer. See the section, "Add a User's Favorites to Your Favorites," to learn how to apply this method to your own favorites.

Figure 1 Workbooks in a user's Favorites

Note

Remember when using this tip that you and your users are both referencing the same physical workbook stored in BW. You have not created a separate copy of the workbook but have just added a reference of that workbook to the user's favorites. If users open the workbook from their favorites, change the workbook, and save it back to their favorites, then you see that change when you open the workbook from your favorites.

Note

As you evolve from workbook-based reporting to Web-based reporting, you can take advantage of personalization of Web templates to replace the favorites functionality. Until then, this method helps you manage favorites in BW.

Tip!

Using the technique explained here, the developer could place a workbook that's in the development stage into a power user's favorites for quality checking. This method is also helpful if a power user is developing a workbook and has a question. You can also use this technique to add the power user's workbook to your favorites for analysis.

Add a Workbook to a User's Favorites

Step 1. Find the workbook's technical ID. Workbooks are stored in BW using a technical ID. This 25-character string is a system-generated, unique identifier of the BW workbook. The simplest way to locate this workbook ID is to open the workbook in BEx. Log in to the BW GUI and double-click on a workbook in your favorites (or launch BEx Analyzer from the Windows menu or with RRMX), choose Open>Workbooks, click on the Favorites button, and select the workbook to open. Right-click on the workbook, choose Properties, and click on the Information tab

(Figure 2). The Workbook ID (server) field contains the workbook's technical ID.

Figure 2 Identify the workbook's technical ID

Step 2. Execute the FAVOS_EVENT_ADD_TO_USER_SHELF function module in transaction SE37. You can use the FAVOS_EVENT_ADD_TO_USER_SHELF function module to add a workbook to a user's favorites. You can open this function module with transaction SE37 and execute in test mode by pressing F8 or clicking on the execute

icon, shown in Figure 3.

Figure 3 Execute function module FAVOS_EVENT_ADD_TO_USER_SHELF in test mode

Step 3. Enter parameters and execute. While in test mode, enter the following parameters in the FAVOS_EVENT_ADD_TO_USER_SHELF function module:

Uppercase/Lowercase: Select this check box to allow the text description to contain lowercase letters. Otherwise, the text description of the workbook will be in all uppercase letters when added to the user's favorites.

USER_NAME: Enter the user who wants the workbook added to his or her favorites

REPORTTYPE: TR (for transaction)

REPORT_NAME: RRMX (the transaction used to execute BEx queries and workbooks)

SAP_GUID: The 25-character workbook ID from step 1

TEXT: The text description to display in the user's favorites

Leave the other entry fields with their default values. Execute the function module by clicking on the execute icon or

pressing F8 (Figure 4). The workbook is now listed in the user's favorites (Figure 1). The user can then open the workbook, refresh it, and validate that the workbook meets format and data requirements. Once the user has signed off on the workbook, you can publish it to the rest of the company by saving it to a BW role.

Figure 4 Execute the function module to list the workbook in the user's favorites

Add a User's Favorites to Your Favorites

The process for adding someone else's favorite to your favorites is very similar to the steps above. First, identify the 25-character workbook ID. You could ask the user whose favorites you want to add to open the workbook in BEx and perform step 1, or you could look up the workbook ID yourself. If you look in the SMEN_BUFFC table using Data

Browser (transaction SE16), you can see all the workbooks that are associated with a user (Figure 5).

Figure 5 Open table SMEN_BUFFC using transaction SE16

Note

By specifying TR for the REPORTTYPE field and RRMX for the REPORT field, you limit the selection to only workbooks (Figure 6 ). If you don't add these restrictions, you see all the users' favorites, including those that are not workbooks.

Figure 6Filter the SMEN_BUFFC table to only show the workbook favorites for a specific user

The SAP_GUID column holds the 25-character ID of the workbook (Figure 6 ). You can now use the

FAVOS_EVENT_ADD_TO_USER_SHELF function module discussed in step 2 to add the workbook to your own favorites.

Figure 7Locate the 25-character workbook ID in the SAP_GUID column of Data Browser and specify which user's favorites to list in your favorites

BW Workbook Fundamentals

BW workbooks make up the foundation of BEx reporting. They store query results together with fixed navigational states and filters. They can group together various queries from different InfoProviders to give a broad view of a company's activities.

Many tables are important in the storage and handling of workbooks in BW. For instance, RSRWBINDEX holds basic system information about the workbooks including:

FILESIZE: The size of the file

STATCHANGE: The number of times the workbook has been changed

STATREADST: The number of times the workbook has been read

TIMECREATE: When the workbook was created

WBSTORE: Where the workbook is stored in BW

Some other relevant tables include:

RSRWBINDEXT: Holds the text description of the workbook

RSRWORKBOOK: Holds a cross-reference between the workbook and the queries that are contained in the workbook. This is very handy for locating all work books that hold a certain query. If you know the query ID (which you can get from the RSRREPDIR table), then you can find all workbooks in BW that contain that query.

You could also use the query where-used feature from BEx Query Designer. To open a query in BEx Query Designer, launch BEx Analyzer (either from a Windows Start menu or from BW with transaction RRMX) and choose Open>Queries. Select the query and click on the change icon. You could also open a workbook containing a query

and click on the Change query (global definition) icon in the BEx toolbar (Figure 1).

Figure 1 Open a query in BEx Query Designer

If you open a query's definition and click on the where-used icon , you see a list of workbooks that contain the query. The list includes the workbook's text description but provides no additional information, such as the technical name or the roles that contain the workbook. If you need more specific information (other than the workbook's name), you should use the RSRWORKBOOK table.

Workbooks are stored in BW in either the RSRWBSTORE table or Business Document Store.

The RSRWBSTORE table stores customer-created workbooks. If the workbook entry in RSRWBINDEX has T in the WBSTORE field, this means that it is stored in RSRWBSTORE.

Business Document Store contains standard content queries. Use transaction BDN1 to start Business Document Navigator and enter the following information to see the workbook information in Business

Document Store (Figure 2):

Figure 2 View workbook information via transaction BDN1

– Class Name: BW_CATALOG

– Class Type: OT

– Object Key: A_ and BW workbook ID (e.g., A_3Q4SHG9O3H83YY1A4QKOKKQ3E).

– Document Type: BW_XLWB_XL

Click on the execute icon or press F8 to see the details shown in Figure 3.

Figure 3 Details of workbook stored in Business Document Store

An Insider’s Guide to SAP BusinessObjects and SAP NetWeaver BW: What Tools Should You Use Going Forward?  

by Ned Falk, Senior Education Consultant, SAP, and Antonio Soto, Platinum Education Consultant, SAP (May 2009)

Delve into the reporting and analysis tools available with SAP BusinessObjects and SAP NetWeaver BW. Find out when to use which tool, where to find it, and who should be the one using it. Learn which BEx tools SAP will continue to develop and which SAP BusinessObjects tools you should consider for your long-term reporting and analytics needs.

Categories: BEx, Reporting, SAP BusinessObjects, SAP NetWeaver Portal, SAP NetWeaver Visual Composer

Key Concept

To help distinguish different product offerings, BI now refers to the premium SAP BusinessObjects portfolio of products, including Xcelsius and SAP BusinessObjects Web Intelligence. SAP NetWeaver BW, formerly SAP NetWeaver BI, refers to the data warehouse.

The acquisition of Business Objects has brought changes to SAP in the areas of business intelligence (BI), Financial Performance Management (FPM, formerly Corporate Performance Management [CPM]), and governance, risk, and compliance (GRC) tools. This article focuses on the BI changes. With change comes some unavoidable confusion. The purpose of this article is to expose you to the future of BI at SAP and to provide you with an action plan.

Some of the BEx tools will no longer be developed and, in their place, SAP is focusing efforts on many of the tools originating from the Business Objects acquisition. Rest assured that SAP will continue to support older products for many years. Organizations that are currently implementing the BEx applications should not worry. That said, what products are in support mode and which ones will continue to be developed?

First, we’ll let you know about the long-term planned product offerings. Then we will go over the kinds of skills needed for each tool, as well as the target group for each role. With this knowledge, you can informatively decide which products are the ones your company needs as part of a long-term plan.

Note

It’s important to know the updated BI terms and how SAP uses these terms. Refer to Davin Wilfrid’s article “SAP BusinessObjects Update: One Year Later: What You Need To Know About SAP and the SAP BusinessObjects Portfolio,” which was posted to the ERP Expert knowledgebase in February 2009.

Figure 1 shows what makes up the BI platform, which consists of the SAP BusinessObjects products linked to SAP NetWeaver BW, as well as information from other sources, both unstructured and structured.

Figure 1 Components of the BI platform

To summarize, here are the three main ideas concerning the current direction for SAP NetWeaver BW and SAP BusinessObjects tools:

The SAP data warehouse is now called SAP NetWeaver BW. The name change shows the continued emphasis on the enterprise data warehouse (EDW) as the core SAP data warehouse option. The SAP BusinessObjects BI tools become the premium front-end reporting applications. You use the Information Management (IM) tools in the back end.

SAP BusinessObjects presentation and data analysis tools become the main front-end tools. Exceptions to this statement include:

A new OLAP tool currently named Project Pioneer, which takes the best of SAP BusinessObjects Voyager and SAP BEx Analyzer to make a best-of-breed tool for OLAP data analysis. This option is due by the end of 2010.

SAP NetWeaver Visual Composer becomes a core product for complex application development (that does not require code), incorporating Web services, BAPIs, and BI data for the Web

BEx Query Designer remains a critical tool to expose the SAP NetWeaver BW warehouse data to the SAP BusinessObjects BI tools

A partnership with SPSS, Inc., is available for predictive analytics

Most companies still need the performance and flexibility that the SAP NetWeaver BW data warehouse provides. For companies with source data outside of SAP systems, SAP BusinessObjects IM tools are often also needed. They focus on extraction, transformation, and loading (ETL) as well as data cleansing in external systems. For companies that only obtain data from SAP OLTP systems (e.g., SAP ERP and SAP CRM), SAP NetWeaver BW can be your only back-end tool because it is the best tool for ETL from these SAP systems.

Figure 1 shows the BI platform, but not specific tools. A roadmap is the best way to identify the current and long-term

product offerings. Figure 2 shows all the products that are available now or planned to be available in 2010. We did not include existing SAP BEx or SAP BusinessObjects tools that are not part of the premium path. We will then provide you the basics of each product offering to help you make an informed decision of what’s right for your organization.

Figure 2 Current and planned BI tools

Note

SAP BusinessObjects Polestar is now referred to as the data exploration software in the SAP BusinessObjects BI package. It takes the Google-style search of the SAP BusinessObjects Polestar and combines that GUI with the technical behind-the-scenes performance and scalability of SAP NetWeaver Business Warehouse Accelerator. The new software is a major step forward in easy-to-access information delivery for all levels of a company, including executives.

Notice that BEx Query Designer is the only existing BEx tool that becomes a strategic product. Crystal Reports will replace BEx Report Designer. Although BEx Web Application Designer (BEx Web AD) is not strategic, its critical functionality will not be lost going forward. Critical BEx Web AD features will be covered by current or future improvements to SAP NetWeaver Visual Composer and Xcelsius. SAP plans to take BEx Analyzer and an existing BusinessObjects product called Voyager and create the new advanced OLAP tool currently called Project Pioneer. BEx Web AD functionality, such as BEx Web Template, will come with a software development kit (SDK) on Project Pioneer.

Skill Sets

In the sections that follow, we provide a short definition and description of each of the tools shown in Figure 2. For each tool, we list the skill sets needed to use it. We separate the skill sets into four categories:

Technical analyst (TA): Works with data warehouse tools to prepare, model, and store the data. Works with functional analyst to define technical specs. This person can read and may write code (not necessarily ABAP).

Business analyst (BA): Defines the functional requirements. This person may perform some data modeling work or at least approve the resulting data model that the TA generates.

Power user (PU): This is preferably a business person. In some situations, this person can report to IT or could even be the same person as the BA. In a perfect world, these people should create queries. They should also be able to train end users in some ad hoc reporting tools. In the case of SAP NetWeaver MDM, the PU is also the lead user for master data entry and audit.

Project management (PM): This is the team that leads the overall BI project. They need to be exposed to all the available tools so they can position them in the overall project and assign personnel appropriately.

Note

The job of dashboard and SAP BusinessObjects universe (semantic layer) design can fall into any of the four categories, depending on the individual’s skills.

Information Management

IM is sometimes called the back end. It has tools that support data storage in the warehouse and the ETL or cleansing process. In general, tools in this section target people on the technical side more than those with business knowledge.

SAP BusinessObjects Data Integrator

SAP BusinessObjects Data Integrator is an ETL tool that is part of SAP BusinessObjects Data Services (Figure 3). As with all ETL applications, it extracts data from varied sources, transforms it, and loads it into data marts, data warehouses, or other targets. SAP BusinessObjects Data Integrator moves the data in both real time and in batch. Most manipulations are done graphically without custom coding.

Figure 3 SAP BusinessObjects Data Integrator

Although the ETL component in SAP NetWeaver BW can link directly to most data sources, it is best at linking to SAP OLTP systems and a list of common databases where it uses database client-specific drivers. SAP BusinessObjects Data Integrator works best if your company has data in many varied sources (other than SAP OLTP) and needs controlled staged extraction with good metadata management and traceability. Typically, SAP NetWeaver BW is a target of the ETL flow from SAP BusinessObjects Data Integrator.

In special cases, you could use SAP BusinessObjects Data Integrator to manipulate data for direct access in the BI layer or to provide data to another warehouse or system. For example, if you want to create or update an SAP BusinessObjects universe from disparate raw data sources, you can use SAP BusinessObjects Data Integrator to consolidate all raw data sources to a specific staging environment. Metadata parameters from this staging environment are captured into an XML file using SAP BusinessObjects Data Integrator. Using a universe designer built-in utility named Metadata Exchange, the system can build a universe or update it automatically based on metadata contents in the SAP BusinessObjects Data Integrator-derived XML file.

Target groups: (TA and PM) This tool manipulates data, so the target group is more technical than functional. SAP BusinessObjects Data Integrator creates most of the code in an SQL background. Prior ETL experience is helpful.

SAP BusinessObjects Data Quality Management

SAP BusinessObjects Data Quality Management was originally a separate tool, but it is now bundled with SAP BusinessObjects Data Integrator, forming the SAP BusinessObjects Data Services offering. SAP BusinessObjects Data Quality Management verifies data and processes it for duplicate records, helping to ensure that only accurate

information enters your systems (Figure 4).

Figure 4 SAP BusinessObjects Data Quality Management cleanses, matches, and consolidates master data

This tool complements many of the SAP NetWeaver MDM features for ensuring the quality of master data such as products and customers. Although SAP NetWeaver MDM has extensive features in this area, the target of the data for SAP NetWeaver MDM is always the SAP NetWeaver MDM system. SAP BusinessObjects Data Quality Management can target any table in any system with scrubbed data, because of its integration with SAP BusinessObjects Data Integrator. For companies with master data in many separate systems that requires extensive cleansing logic that crosses systems, preprocessing with SAP BusinessObjects Data Quality Management makes sense, even if the end result is SAP NetWeaver MDM.

Target groups: (TA, PM, and BA) This tool also manipulates and cleanses data, but the logic might require as much business knowledge as technical knowledge. It is for this reason that BAs should know the tool’s features even if the TA is the one using it.

SAP NetWeaver BW Data Warehouse

SAP NetWeaver BW is a data warehousing toolset designed to efficiently extract data from various sources, but with

a strong focus on SAP Business Suite products (Figure 5). It provides complete templates of database schemas, with extraction modules and queries to support standard data warehousing practices. SAP recommends that you use SAP NetWeaver BW queries on top of SAP NetWeaver BW database structures to expose warehouse data to the SAP BusinessObjects BI tools.

Note

SAP BusinessObjects Data Integrator and Data Quality Management tools integrate with SAP NetWeaver BW in the “Third-party BI data” section in Figure 5. BEx Query Designer and SAP NetWeaver BW Accelerator are covered separately later in the article.

Figure 5 SAP NetWeaver BW warehousing components

Target groups: (TA, PM, and BA) This is a total warehouse solution, so it has modeling (database design) and ETL. We feel that BAs should know the tool’s features to help create better specifications, even if the TA is mostly responsible for using this tool.

SAP NetWeaver MDM

If your organization has grown from acquisition or had poor controls in place originally, you have master data quality issues. Master data refers to the core data for your company and comprises the databases for products, customers, employees, and suppliers. This information is extremely critical, which is why master data management is so important. SAP NetWeaver MDM provides tools in three main areas: flexible database design for master data central storage import (cleansing, matching, and elimination of duplicate data), publishing of Web-enabled product catalogs,

and the controlled distribution of master data to SAP and non-SAP systems. Figure 6 shows how high-quality master data can improve insight across organizations.

Figure 6 Cross-organization master data management with SAP NetWeaver MDM

Target groups: (TA, PM, BA, and PU) SAP NetWeaver MDM is a complete tool for master data design maintenance and distribution and, as such, all types of skills apply to it.

SAP NetWeaver BW Accelerator

SAP NetWeaver BW Accelerator is a separately installed IT appliance. This means it is both hardware and software delivered as one unified, low maintenance black box that drastically improves query performance. Co-developed by SAP and Intel using special hardware and indexing techniques, SAP NetWeaver BW Accelerator takes queries that used to run in hours (or even days) and accelerates them to seconds.

Note

For more information about SAP NetWeaver BW Accelerator, refer to these two BI Expert articles: “Tips and Techniques for Optimal Query Performance with SAP NetWeaver BI Accelerator,” posted in January 2009, and “Best Practices for Creating a Sound Strategy for Your SAP NetWeaver BW Accelerator Implementation,” posted in March 2009.

Target group: (TA) Except for BAs and PMs justifying the SAP NetWeaver BW Accelerator purchase, this appliance requires only limited technical support.

Business Intelligence Solutions

BI solutions are sometimes referred to as the front end. They include all the tools required for enterprise reporting, ad hoc querying, and information analysis. In general, tools in this section target business analysts and report developers.

BEx Query Designer

BEx Query Designer employs a drag-and-drop GUI to generate SQL code for queries against the SAP NetWeaver

BW data warehouse — no code required (Figure 7). The data warehouse schemas are very sophisticated. The ability to model and display multiple time-dependant hierarchies and model different historical perspectives of the data — not to mention more common features such as calculations

and restrictions — makes BEx Query Designer a strategic tool. SAP recommends exposing the SAP NetWeaver BW data to the SAP BusinessObjects reporting tools via a query. Direct access via SAP BusinessObjects tools to the OLTP data presents performance and flexibility issues.

Figure 7 BEx Query Designer

Target groups: (PM, BA, and PU) Although the technical team should be aware of this tool’s capability, it is a functional tool for the business people.

SAP NetWeaver Visual Composer

SAP NetWeaver Visual Composer is a BEx Web AD tool that builds interactive Web applications across system

boundaries (Figure 8). It can seamlessly combine generic Web services, BAPIs (for access to SAP ERP and SAP CRM transactional data), and BI data (both SAP NetWeaver BW and non-SAP-based BI data). This allows the construction of interactive operational and analytical dashboards. The look and feel of these dashboards is further enhanced by the incorporation of Adobe Flash technology. It does all this without the designer writing any code.

Figure 8 SAP NetWeaver Visual Composer

Target groups: (TA, BA, and PM) You can use SAP NetWeaver Visual Composer to create complex dashboards. You can also use it as a prototype tool or for productive applications. No code is needed, but prior application development is a plus.

SAP NetWeaver Portal

SAP NetWeaver Portal offers a central point of access to both SAP and non-SAP information sources. All applications that provide information to perform a job or role at your company (or a partner company) can be presented via a standard Web browser using SAP NetWeaver Portal. It can present SAP BusinessObjects Infoviews that contain SAP BusinessObjects reporting output or it can contain Microsoft Excel or Web output originating in SAP NetWeaver BW. In addition, Web pages and enterprise software applications can be presented in one unified place.

You can either use the portal internally in your company or you can allow your partners to access them. The advantage is that the underlying systems are presented as one integrated screen with one password. The portal provides a role-based, personalized place for end users while being secure and scalable for IT. It allows all users to

focus on their own jobs, without knowing what system is actually doing the processing for them (Figure 9).

Figure 9 SAP NetWeaver Portal: Bringing all the pieces together to the end user. Source: SAP

Target groups: (TA, PM, and BA) SAP NetWeaver Portal has technical, layout, organization, and security components, requiring both business and technical skills.

Project Pioneer

Project Pioneer is slated for release in 2010 (Figure 10). It is an advanced OLAP tool targeting BAs and PUs. Whereas SAP BusinessObjects Web Intelligence targets the casual (business) user, Pioneer will have the functions and features for the sophisticated analyst of OLAP structures, such as SAP NetWeaver BW. It will include a native Microsoft Excel mode and integration into Microsoft Live Office XI to easily link BI data to Microsoft PowerPoint and Microsoft Word. Pioneer will also have a Web mode. More than just slice and dice, it will have advanced charting and predictive analysis features.

Note

Pioneer is the name of the internal development project, but it may not be the name of the final release.

Figure 10 Project Pioneer: The future of complex OLAP

Target groups: (BA, PU, and PM) PUs are the primary Pioneer users. BAs will participate in the requirements specification and, depending on the organizational model, also use Project Pioneer. PMs need to be exposed to all the available tools so they can position them in the overall project and assign personnel appropriately.

SAP BusinessObjects Web Intelligence

SAP BusinessObjects Web Intelligence is an ad hoc query and analysis application that enables business users to design queries and create reports (Figure 11). SAP BusinessObjects Web Intelligence empowers non-technical users by providing a UI that allows users to drag and drop simplified database definitions called business objects contained within a semantic layer called a universe to create queries. A universe interacts with SAP BusinessObjects Web Intelligence by dynamically preparing SQL as the user prepares a query using drag and drop. For more

information about universes, see the “Universe Design” sidebar.

Figure 11

SAP BusinessObjects Web Intelligence: Ad hoc analysis for business users

SAP BusinessObjects Web Intelligence XI 3.0 introduces the ability to not only query via a universe, but also via Microsoft Excel spreadsheets and delimited text files. In addition, SAP BusinessObjects Web Intelligence provides intuitive formatting capabilities. It is also available in Java 2 Runtime Environment (J2RE), which allows IT departments to easily deploy SAP BusinessObjects Web Intelligence to multiple users without having to install the Windows-based SAP BusinessObjects Web Intelligence rich client version on a workstation.

SAP BusinessObjects Web Intelligence is intended for the slicing and dicing of data. The drilling capabilities provide an easy way to manage data analysis in a multi-dimensional InfoCube.

Target groups: (PM, BA, and PU) This tool targets end users and PUs who train end users on how to best use the SAP BusinessObjects Web Intelligence.

Crystal Reports

Unlike SAP BusinessObjects Web Intelligence, the design side of Crystal Reports is intended for a more technical

audience (Figure 12). Although you can create most reports without code, Crystal Reports uses a proprietary language (Crystal Syntax) that is derived from Microsoft Visual Basic programming language. This programming language provides flexibility around report formatting as well as granular management of report processing strategies.

Figure 12 Crystal Reports design and preview mode

Crystal Reports allows you to connect to virtually any data source (structured or non-structured), create joins between tables, and define appropriate relationships to build sophisticated reports that fulfill complex formatting requirements. The newest version, Crystal Reports 2008, puts more emphasis on Web 2.0 technologies. In contrast to other tools, the Crystal Reports output focuses on beautifully formatted output with much less focus on slice and dice functionality.

Crystal Reports is also intended for mission-critical report printing requirements. With Active X and Java viewing options, report consumers can take advantage of the pixel- perfect print engines available via the Infoview portal, part of SAP BusinessObjects Enterprise.

Target groups: (PM, BA, and PU) Although a technical person may be needed when code is necessary (only very complex reports), we recommend focusing the tool on the BAs and PUs. PMs need to know about this tool so they can position it in the overall project and assign personnel appropriately.

Xcelsius

You use Xcelsius to create dashboards and visually appealing data analysis applications for performance

management analysis, statistical process control, and general dashboard management (Figure 13). In design mode, it uses Microsoft Excel, but it deploys as a Flash file on the Web.

Figure 13 Xcelsius deployed on the Web

SAP Business Objects Xcelsius Enterprise is the corporate version that uses SAP BusinessObjects Enterprise XI to leverage information managed by universes via SAP BusinessObjects Query as a Web Service (QaaWS). The XI platform provides security, connectivity, and interactivity whether the SAP BusinessObjects Xcelsius Enterprise is deployed to Infoview (a Web application that can view various types of reports) or embedded inside Microsoft Office and Adobe PDF.

Target groups: (PM, BA, PU) Complex applications can be built code free, so technical analysts are typically not needed.

Now that you know the very basics of the information access tools, you should also be aware that many of these tools are integrated with the SAP BusinessObjects Enterprise XI platform. To complete your BI knowledge, the technical team must ramp up on performance issues, security, system connectivity, and other advanced features of SAP BusinessObjects Enterprise XI.

For information on related SAP Education courses, refer to the "Introductory SAP Courses for SAP NetWeaver BW and SAP BusinessObjects" guide available in the Downloads section.

Universe Design

The power behind SAP Business Objects reporting, query, and analysis has traditionally been the empowerment of non-technical users to take ownership of query design, formatting, and formula and variable management. The source for this empowerment lies within a semantic layer between SAP BusinessObjects Web Intelligence end users’ data sources and the universe.

A universe is a proprietary SAP BusinessObjects file that contains information about underlying operational data sources in the form of logically defined business objects. The data sources can be OLTP-based, a data warehouse, or data marts. To have an efficiently managed ad hoc querying environment, an SAP BusinessObjects Data Quality Management team works closely with the operational database team and business analysts to design a universe that satisfies business users’ reporting and ad hoc analysis requirements.

Information is logically organized into universe classes (left pane) as business definitions (Figure A). The universe schema (right pane) manages the database (metadata) relationships that govern SQL generation when devising an SAP BusinessObjects Web Intelligence query.

Figure A Business/semantic layer supporting SAP BusinessObjects BI tools

[back]

Avoid Split Records in MultiProviders  

by Martin Ringvold, Independent SAP NetWeaver BI Consultant

When you report on MultiProviders, you can run into split records. In this situation, the report contains redundant and incorrectly categorized data. Find out how you can use restricted key figures to avoid this problem.

Categories: BEx, Reporting

Key Concept

A restricted key figure is a BEx Query Designer object that represents a subset of aggregated values. It is available in Business Content or a query developer creates it in BEx. In addition to other uses, restricted key figures allow the developer to aggregate numerical values in an InfoProvider based on characteristic values. Restricted key

figures can help a query developer to develop more intuitive and organized reports originating from MultiProviders.

In the design phases for SAP NetWeaver BI projects, you often generate analytical reports across functional areas. For example, you may need to create a report that spans opportunities and sales in a CRM pipeline report. This often requires the design team to merge opportunity and sales transactional data physically into one InfoCube. Or you may need to use a logical database, such as an InfoSet or MultiProvider, to cover the opportunity and sales InfoCubes.

A common pitfall occurs when using characteristics in reports that are not common between the InfoProviders covered under the MultiProvider umbrella. For instance, InfoProviders from different functional areas do not share the same characteristics. I’ll illustrate a technique to overcome a common problem encountered with MultiProviders that I refer to as split records. I will show you how to simplify reporting across functional areas and avoid expensive design implementations involving physical merging of data in your data warehouse environment. Finally, I will mention some points to consider when using this workaround. I have implemented this technique successfully with SAP BW 3.5 and SAP NetWeaver BI 7.0.

Using MultiProviders in Reports

A MultiProvider is a logical layer that sits on top of one or more InfoProviders, so it does not contain any data. Its main functionality is to allow the SAP NetWeaver BI developer/configurator to point to different InfoCubes (or other InfoProviders) and determine which characteristics are equal between them. Then, the query developer can create a report from the MultiProvider that connects these common characteristics. However, if the characteristics are not common between InfoCubes, then you can use the technique I describe.

MultiProviders allow you to report on key figures from characteristics in different InfoCubes in which the characteristics are mapped logically together in a union.

For the sake of the analytical case in this article, consider the records for the data entries from Business Content Info– Providers 0CRM_C04 (opportunities) and 0CSAL_C04 (sales orders). Figure 1 and Figure 2 show the query definition and query result from the opportunity InfoCube. They include records from two prospects with In Progress

and Lost transactions.

Note

In SAP CRM, a business partner is called a “prospect” in Opportunity Management and a “sold-to party” in Sales Management. Both InfoObjects are reference characteristics of 0BPARTNER.

Figure 1 0CRM_C04 opportunity query definition. This simple query definition returns the expected sales figures for all prospects in the opportunity InfoCube.

Figure 2 0CRM_C04 opportunity query result with the expected sales figures for the prospects

Figures 3 and 4 show the query definition and query result from the sales InfoCube with the sold-to parties identical to the prospects from the opportunity InfoCube.

Figure 3 0CRM_C04 sales order query definition. This simple query definition returns all open sales orders for customers in the sales InfoCube.

Figure 4 0CRM_C04 sales order query result with the open sales order figures for all customers

You can use a MultiProvider to map the prospect (0CRM_PROSPE) and sold-to party (0CRM_SOLDTO) InfoObjects because they are both business partner (0BPARTNER) reference characteristics. You could create a report across sales and opportunities if you insert Sold-To Party (or Prospect) in the Rows area and Expected Revenue and Sales Revenue in the Columns area of BEx Query Designer.

Figure 5 shows the BEx query definition and Figure 6 shows the result. In this example, the sold-to party in the query definition represents both prospects and sold-to party business partners. You can share the key figures Open order

value and Expected Net Value across the characteristics mapped in the MultiProvider.

Figure 5 Query definition from a MultiProvider that has mapped the sold-to party from the sales InfoCube to the prospect from the opportunity InfoCube

Figure 6 The query result from the query definition shown in Figure 5

The Problem — Split Records

A problem arises when your user requests a report based on the example in Figure 6, but with the format in Table 1.

The analyst wants to view a report showing Lost and In Progress opportunities along with the open orders for the same business partner. However, the MultiProvider cannot create a characteristic union for the opportunity user status between the opportunity and sales InfoCubes. The opportunity user status characteristic does not exist in the sales InfoCube.

Characteristic 1

Characteristic 2 Key figure 1 Key figure 2

Customer Opportunity status Expected net value Open order value

Table 1 Sales pipeline report request

Receiving the requirements in Table 1 the query developer may first believe the MultiProvider would allow him to simply create a query with Sold-To Party and Opp User Status in the Rows section along with the key figures

Expected Net Value and Open order value in the Columns section (Figure 7).

Figure 7 A query definition from a MultiProvider that attempts to combine opportunity status with sales and opportunity key figures

As a result, the analyst expects to see each characteristic, in this case the customer or sold-to party, in relation to Open order value and Expected Net Value on one line in the report. Although the report returns the information the user requested, the results include split records and redundant rows for each customer (Figure 8). Also, a MultiProvider cannot accept mixing characteristics that are not common in all the InfoCubes in the query without

displaying Not Assigned for one or more characteristics in the report.

Figure 8 The resulting report does not intuitively show customers’ records with both Expected Net Value (opportunities) and Open order value (sales)

The Workaround

In Figures 5 and 6 the key figures are shared between characteristics that are mapped in the MultiProvider. The sold-to Partner has both Expected Net Revenue and Open order value on the same report line. This is possible because the system mapped the Sold-To Party to Prospect in the opportunity InfoProvider. In the MultiProvider you can align the sales InfoCube’s sold-to party characteristic with the opportunity InfoCube’s prospect characteristic because they both are reference characteristics for 0BPARTNER.

From my examples to this point, you can see that it is possible for a MultiProvider across a common characteristic to report on a common key figure as shown in Figure 6. Again, the characteristics Prospect and Sold-To Party are mapped in the MultiProvider. No other characteristics are involved in the report.

For this process, assume that only the Sold-To Party characteristic is common between the two InfoCubes. Based on this fact, I create three restricted key figures to summarize opportunity volumes in the In Progress, Lost, and Open order stages.

By creating a restricted key figure with selections from chosen characteristics, you can replace the incompatible characteristics with restricted key figures. These become the building blocks of the method to avoid split records. Here are the steps to create the BEx objects that support the reporting platform. I use two restricted key figures for opportunities and one restricted key figure for the open sales volume.

Step 1. Create the restricted key figure Opportunity Status In Progress. In BEx Query Designer, right-click on the Key Figures folder under the InfoProvider section on the left pane. Select New Calculated Key Figure.

In the next screen you can drag and drop multiple characteristics and one key figure. The restricted key figure requires two separate elements: the key figure to report on and the characteristics selections. In the example in Figure 9, the query developer created a restricted key figure that shows all the expected net values in which

Opportunity Status is equal to In Progress in the opportunity InfoCube.

Figure 9 Restricted key figure Opportunity Status In Progress

The restricted key figure limits the number of records aggregated by characteristic selection. I restrict the key figure by Opportunity Status equal to In Progress and set the InfoProvider equal to Opportunities. Including a restriction on the InfoProvider for the restricted key figures on a MultiProvider is a good practice for improved performance.

Step 2. Create the restricted key figure Opportunity Status Lost. Repeat the procedure for step 1 using the Lost value.

Step 3. Create the restricted key figure Sales Revenue. Figure 10 shows the third restricted key figure for Sales

Revenue. This restricted key figure returns all open sales in the sales order InfoProviders.

Figure 10 Restricted key figure Sales Revenue

Step 4. Create the BEx query. Use the Sold-To Party characteristic, which is mapped with the Prospect InfoObject in the MultiProvider. Note that from a technical point of view, the system treats restricted key figures as regular key

figures. Figure 11 shows the query definition and Figure 12 shows the result of the workaround, bringing the opportunity and sales records together for customers. This report now shows the customers’ combined sales and combined opportunity expected sales. By using restricted key figures instead of opportunity status as a characteristic in the BEx query, you avoid the split record problem.

Figure 11

Query definition with the restricted key figures

Figure 12 Query result without the split records

Points to Consider

As always, workarounds require give and take. Although you are able to avoid the split records, your report is not as flexible in terms of slicing and dicing and drill downs. Specifically, end users only avoid the split record scenario if they use characteristics that are common between the InfoProviders and mapped under the MultiProvider. Additionally, a report using this technique with separate characteristic values requires many restricted key figures, which can add to the workload in development and maintenance of BEx queries.

BEx Information Broadcasting in SAP BW 3.5 Puts Users Front and Center  

by Glen Leslie, BI Product Manager, SAP Labs

SAP has expanded the feature set in the latest iteration of SAP BW. Included in the new functionality is BEx Information Broadcasting, which provides a variety of ways for users to disseminate information. This introduction to BEx Information Broadcasting and its front-end tool, the BEx Broadcaster, will give you a head start on putting it to use.

Categories: BEx, Reporting

Key Concept

BEx Information Broadcasting encompasses the functionality within SAP BW 3.5 for distributing reports and other information by email or SAP Enterprise Portal. The BEx Broadcaster is a tool for precalculating and distributing queries, Web templates, and workbooks for distribution through BEx Information Broadcasting.

As part of SAP NetWeaver ‘04, SAP BW 3.5 brings to bear a number of features. One of the more interesting of them is BEx Information Broadcasting. With it, users can share information in a more relevant form that is timely, easily accessed, and efficiently distributed in the context of their analysis.

Meeting the broad spectrum of needs of so-called “information consumers” is one of the primary purposes of the new BEx Information Broadcasting in SAP BW 3.5. I will give you a detailed look at how this new technology for BEx-based information dissemination provides individuals with new insights and allows them to solve problems more quickly. With BEx Information Broadcasting, users can also immediately inform others of problems or potential problems that require the collaborative attention of their colleagues.

View from the Top

BEx Information Broadcasting in SAP BW 3.5 supports a variety of access points and configuration options to provide

end users with the ability to define what, when, and to whom information is broadcast. Figure 1 shows how BEx Information Broadcasting applies to different usage scenarios within SAP BW 3.5. See the “Information Broadcasting System Requirements” sidebar for more details on what it takes to bring this functionality online. BEx Information Broadcasting links specific user types to whatever SAP BW sources the broadcasting user has access to and supports different broadcast modes via two different channels and a variety of formats. The two channels supported by BEx Information Broadcasting are SAP Enterprise Portal and Simple Mail Transport Protocol (SMTP), which is the standard supported by most email/workgroup products. Numerous attributes can then be selected, influencing display and execution of the broadcast for either distribution channel.

Figure 1 The BEx suite in SAP BW 3.5

Table 1 offers a list of the broadcasting options available using BEx Information Broadcasting. The biggest difference in the two channels is that broadcasting to SAP Enterprise Portal either places information into Knowledge Management (KM) folders within the portal itself or into Collaboration Rooms. Broadcasting to SAP Enterprise Portal provides significant advantages, which I’ll detail later.

 

Email

SAP Enterprise Portal

Sources

BI Web applications (dashboards, cockpits)

BEx Analyzer workbooks

SAP BW queries

Formats

HTML/MHTML1

Zipped files

MS Excel workbooks

Modes

Precalculated

Online links

Timing

Ad hoc

Scheduled

Event-based (e.g., change of underlying data in source)

Broadcasting user interface

Wizard

BEx Broadcaster (“Expert mode”)

Recipient

Leverages features of email system  

Leverages SAP Knowledge Management (KM) functionality  

Leverages SAP Collaboration Room functionality  

Table 1 SAP BW 3.5 Information Broadcasting options

The Broadcasting Wizard

Email provides a familiar medium for the ubiquitous transfer of important content to other users inside or outside the company. A wizard is available to ease the task of information sharing via email and SAP Enterprise Portal. One of the key access methods the broadcasting wizard offers comes via new menu options in both the BEx Web Analyzer and the BEx Analyzer. Figure 2 shows how the wizard is launched to initiate a broadcast of analytical information within the BEx Web Analyzer. The broadcast preserves the navigation state of originating SAP BW analysis or report.

Figure 2 Initiate the broadcasts wizard from the new BEx Web Analyzer

The wizard is straightforward and allows users to select from the formats and modes listed in Table 1. The specific target email addresses are chosen and a brief message can be included if desired. This screen is slightly different if SAP Enterprise Portal is chosen as a target.

Users can execute a broadcast immediately or choose to schedule it for later. For immediate execution, selecting the Execute button provides single point-in-time broadcast. If Continue is selected, users have several scheduling options that are controlled by authorizations. Figure 3 shows the available options. The first option broadcasts when

data in an underlying SAP BW source changes. In the center of the dialog box, users can set a Predefined Time provided by the SAP BW administrator. The last option provides for ad hoc scheduling. See the “Setting up Information Broadcasting Timepoints” sidebar for more details.

Figure 3 Options for scheduled broadcasts using the wizards

Once a broadcast is initiated, the results of the source content are sent. Viewing is dependent on the format chosen.

The BEx Broadcaster

The broadcasting wizard is not the only way to initiate a broadcast in SAP BW 3.5. The BEx Broadcaster is a general term that describes all the functionality to administer combinations of settings listed in Table 1. The easiest place to administer these broadcast settings is via a tabbed display in the new BEx Web Analyzer. Clicking on the Information Broadcasting tab in the BEx Web Analyzer allows users to immediately see the broadcasting settings

applied to a template (Figure 4). This view displays the settings and allows for changes.

Figure 4 Broadcast settings

Note

While a new query template is the default in SAP BW 3.5 (0ANALYZER), customers can retain their default Web template by overriding the new setting in the SAP BW IMG and using 0QUERY_TEMPLATE as the system default.

The BEx Broadcaster hosted in the BEx Web Analyzer extends the number of options offered by the broadcasting wizard. Additional options can provide descriptive names of settings for SAP BW Web templates, workbooks, and queries. Beyond this the broadcast originator can also define additional settings for accompanying text, filtering of exception-based content, and general filtering offered in the recipient display. Many of these controls can be limited via authorizations set by administrators.

For email-based broadcasts, you can send email to specific users and roles (e.g., groups) defined via transaction SU01 in the SAP BW system. In addition, limits can be placed on source data so it reaches only specific users or restricts it so users can view part of the source data. You can send broadcasts in other languages if the relevant master data is maintained in the SAP BW system for the target language selected.

BEx Broadcaster features are available via several other access points including the BEx Query Designer menus and Web Application Designer (Web AD) menus. BEx Broadcaster also works as a standalone Web application via Web

AD (Figure 5).

Figure 5 You can deploy BEx Broadcaster as a standalone Web template via a new SAP BW 3.5 Web item

Broadcasting to SAP Enterprise Portal

Another important feature of Information Broadcasting in SAP BW 3.5 is its seamless integration with SAP Enterprise Portal. As noted earlier, broadcasts can target both KM folders and Collaboration Rooms.

The broadcast wizard is available for use with SAP Enterprise Portal. The key difference is that when SAP

Enterprise Portal is selected as the target, the wizard uses a slightly different interface. Figure 6 shows how KM folders and Collaboration Rooms become available as targets for the broadcaster with SAP Enterprise Portal.

Figure 6 The broadcasting wizard looks slightly different when targeting SAP Enterprise Portal

While it’s out of the scope of this article to completely describe KM functionality, essentially it manages documents as well as other objects within a hierarchical folder structure. As Figure 6 shows, the folder list includes a Content Management repository target (CM Repository view). The SAP KM repository supports a number of repository managers to manage unstructured content posted to it.

SAP BW content broadcasted to SAP Enterprise Portal effectively becomes a KM document and a number of KM services are immediately available to work with the SAP BW content. Some of the basic services include subscription

functionality (Figure 7), notations, ratings, and discussion support. Advanced TREX indexing is also a possibility for these documents.

Figure 7 SAP BW content as a documaent in a KM folder

KM folders support a private and public set of folders based on the setup of KM for your particular organization. This is also reflected in the setting shown in Figure 6. Note that either a Personal Portfolio or Other Directory can be specified as a target.

Employing SAP Enterprise Portal also provides a number of more robust services such as security options that allow administrators to establish access control lists for document hierarchy control. In addition, templates are supplied for creating a more flexible layout and design of the entire KM interface and custom templates also can be developed. For a more detailed look at KM, visit http://service.sap.com/nw-km.

Information Broadcasting is not restricted exclusively to KM folders in SAP Enterprise Portal. As I mentioned earlier, Collaboration Rooms can also be targets. These inherit much of the KM service functionality but for a more focused purpose. Collaboration Rooms link people together and zero in on a particular problem, project, or upcoming event.

Collaboration Rooms provide access to structured, unstructured, and task-oriented information (Figure 8). They are based on the same folder and document metaphor used in KM but add various workgroup features such as calendaring, task lists, workflow integration, chat features, and the ability to integrate third-party virtual meeting tools such as Microsoft NetMeeting.

Figure 8 SAP BW content in a Collaboration Room

The Collaboration Room feature set allows Information Broadcasting to shine when immediate, urgent, or project-threatening issues are revealed via SAP BW analysis. Such analysis can be broadcast into a Collaboration Room where team members have instant access to the information. No longer do users have to rely on mass email or manually disseminating information. If potential issues are identified when analyzing SAP BW content, selecting Distribute>SAP Enterprise Portal quickly broadcasts the analysis to Collaboration Rooms where teams can immediately begin addressing issues. The broadcasted content also provides ongoing status information as new data is posted to SAP BW.

Collaboration Rooms functionality offers much more to bring colleagues together to collectively manage problem solving. More information is available in discussion forums hosted at the SAP Developer’s Network (SDN). The site also offers Know How Network Webinars devoted to the topic such as SAP NetWeaver Product Manager Kim Huffman’s overview of the collaboration functionality recorded in June 2004. It can be viewed at http://www.sdn.sap.com via Upcoming Events>Webinar Schedule. Also visit http://service.sap.com/nw-collaboration for additional information.

SAP realizes that all of this new functionality can be a little overwhelming. With SAP NetWeaver 2004, a new role became available as part of the SAP Enterprise Portal delivery to assist and ease deployment of SAP BW Content in the portal including broadcast content. The showcase role (com.sap.ip.bi.business_explorer_showcase) shown in

Figure 9 provides an easy, single point of entry for SAP Enterprise Portal-targeted broadcasts.

Figure 9 BEx showcase role

Alternate personalized views are reflected in the showcase role such as the My Portfolio tab, which provides a view of an individual’s private set of KM folders. The BEx Portfolio tab is a view of a designated section of the KM folder

hierarchy for public SAP BW BEx broadcasts. The Collaborative BI tab offers a list of the Collaboration Rooms a user can access. In addition, the BEx Web Analyzer and the standalone BEx Broadcaster are available in this showcase role on separate tabs for easy access.

Information Broadcasting System Requirements

Enabling the BEx Information Broadcasting functionality within SAP BW requires a few extra steps beyond basic SAP BW configuration. First, component application service packs are consolidated into support stacks in SAP NetWeaver '04, and under the under current plan NetWeaver Support Stack 5 will support the functionality for Mass Shipment. The Mass Shipment release is slated later in the second half of this year. You can visit http://service.sap.com/sp-stack for more details on the support strategy and http://service.sap.com/nw04 for release information.

Basic BEx Information Broadcasting via email requires the SAP BW 3.5 component, the SAP Internet Graphics Server (IGS) 6.40 component, and the SMTP email services of the underlying SAP Web Application Server (Web AS) 6.40. Note that SAP Web AS 6.40 is included as the platform for SAP BW 3.5 and must be installed to run SAP BW 3.5. If broadcasting to the BEx Portfolio, then the SAP Enterprise Portal component must also be activated and configured.

Details on configuring BEx Information Broadcasting are available at http://help.sap.com following menu path Documentation>SAP NetWeaver>English>Information Integration>SAP Business Information Warehouse>New Features and Changes in SAP BW 3.5>Information Broadcasting. The “How To” section of http://service.sap.com/bw features white papers at Services & Implementation>HOW TO...Guides>SAP BW 3.5.

Setting Up Information Broadcasting Timepoints

Administrators are allowed significant influence on broadcasts by establishing specific “timepoints” defined on the SAP BW server. Timepoints are simply specific times the administrator has defined in transaction SM36 for initiating a broadcast. There are three basic requirements for a timepoint to appear in the broadcast scheduling dialog:

The SM36 job name must use the prefix TP_BROADCASTING_ (e.g., TP_BROADCASTING_WEEKLY). Whatever text is used after the second underscore will be displayed as a tool tip in the scheduling dialog box. In this example, WEEKLY is displayed as a timepoint

A job STEP must be defined to execute the SAP-delivered ABAP program (RSRD_BROADCAST_FOR_TIMEPOINT)

The start conditions for the job must be set to Periodic execution within the start condition as well as to a

specific period (e.g., daily, weekly, or monthly)

Timepoints can be monitored, modified, and deleted with the SM37 Job Overview and Administration functions.

Bookmarks and Query Views Demystified  

by Ned Falk, Senior Education Consultant, SAP (July 2009)

Bookmarks can improve performance, reduce query proliferation, and give users more of what they want: easily accessible targeted information. Find out how you can publish them through SAP NetWeaver Portal. Also, take a deeper look at bookmarks and query views to see how you can integrate both into dashboards.

Categories: BEx, Performance, Reporting, SAP NetWeaver Portal

Dear BI Expert,

I would like to know more about how to publish BEx Web bookmarks through SAP NetWeaver Portal 7.0. Could you help?

Thanks,

Jacques Renaux, Lhoist Group

Thank you for your letter. To best answer your question, I’ll use a typical business scenario. A company has a mix of users, including:

Analysts, who carry out numerous slice-and-dice navigations of varied information

Semi-analysts, who perform a few navigations of a contained scope of information

Executives/information consumers just obtaining information from reports with out much or any navigation

The company uses BEx Analyzer (Excel) and allows many users to author queries so they can view the data they need. The company now has a query proliferation issue with too many similar queries, causing system performance issues. It wants to move to the Web and limit query authoring to a few users, enabling these users to save specific data navigations. You can reduce the number of query authors by using bookmarks to enable users to view the data

as needed. Figure 1 illustrates how bookmarks work with data.

Figure 1 Queries, query views, Web templates, and data providers

Queries provide data to workbooks, dashboards, or BEx Web Analyzer. They can do this directly or via views (saved navigations) of the query. Bookmarks are saved navigations of a Web template. If a single query is the only object in the Web template (as is the case with the BEx Web Analyzer template), then the bookmark and query view functionalities are similar. Although a single query view and a template bookmark could have significantly different target groups, they both give users quick and easy access to the required data navigations — without query proliferation.

BEx Bookmarks in SAP NetWeaver Portal

SAP NetWeaver Portal is a good way to organize your business data and operational transactions in one place. The

query is the starting point. Figure 2 shows a simple query in BEx Query Designer, NEDQUERY1.

Figure 2 A simple query is the starting point for your query views and bookmarks

Figure 3 shows the executed query using BEx Web Analyzer. From here you can bookmark your query navigation or create a query view. In my example, the bookmark is a link that becomes available in a folder on a portal page.

Figure 3 BEx Web Analyzer, which is one place to create bookmarks and query views

After you execute the desired navigation in your report, click the Save As button, select an SAP NetWeaver Portal folder (such BEx Portfolio), and save to make a bookmark of the query. You can then access your bookmark by

clicking BEx Portfolio on the left side of the portal screen (Figure 4).

Figure 4 Access the QueryNedBM1 bookmark in SAP NetWeaver Portal

Click the bookmark to access your saved report. Using the links circled in Figure 4, you can also carry out other tasks with the bookmark. For example, you can download the bookmark to access it offline by clicking the Download link. You can also send the bookmark to a colleague and subscribe to it so the system notifies you if your colleague updates the link.

View and Save Dashboards in the Portal

As Figure 1 illustrates, you can also incorporate queries and views into dashboards or cockpits, which are Web templates that provide additional UI features. In fact, dashboards are the best way to provide information to most users. Bookmarks in dashboards allow different navigations for different dashboard users. Featuring tables, charts, and usability features such as tabs, dashboards have many ties to bookmarks and query views.

In SAP NetWeaver Portal, click My Portfolio on the left side of the screen. Then click Online Link to access the personalized dashboard (Figure 5). The system retrieves the current data, including the user-specific variables and navigation. You can access static versions of the previously executed dashboard (with user-specific variables) by

clicking the dashboard icon next to the dashboard name in the portal.

Figure 5 Access both the static and current versions of the dashboard in the portal

Use this static dashboard if you want fast access to the data and you do not need to re-execute the queries against the SAP NetWeaver BW database. Be aware that you might be accessing a slightly older version of the data. You could also download the static dashboard for offline access.

Figure 6 shows the online version of my personalized dashboard. For my example, I want to filter sales data by sold-to party. Select a sold-to party from the Pick a Sold To drop-down list, and then select a query view from the Pick a Query View drop-down list. I was able to save my preferred navigation by clicking the Save Personalization button in the dashboard. You can also right-click the query and select Save View from the context menu.

Figure 6 The online version of a basic dashboard

You can also save the personalized dashboard as a Bookmark to your Internet Explorer Favorites by clicking the Bookmark button. When you access the dashboard by using the Internet Explorer Favorites link, the system requires you to enter your login credentials for authentication if you are not already logged in.

Add Bookmarks to the Dashboard

Figure 7 shows the complete BEx Web template in the layout view of the BEx Web Application Designer. The layout includes BUTTON_GROUP _ITEM_1, which provides access to the button commands. Select the five commands

shown in Figure 8 to add these buttons to your template.

Figure 7 The Web template in layout view

Figure 8 The important commands that relate to bookmarks are circled

To ensure that the dashboard always opens to your personalized view, right-click in the query template to access the Properties screen. Select Web Template from the drop-down list and then click the Web Template Parameters tab. Select the Use Personalization check box to enable the system to always look for your preferred navigation.

Personalization can be thought of as an internal (hidden) bookmark linked to your user ID. (Figure 9).

Figure 9Select the Use Personalization to ensure that the system checks for your preferred navigation

Use BEx Broadcaster to Share Saved Navigations

In SAP NetWeaver BW 7.0, you use BEx Broadcaster to share dashboards that contain bookmarks. BEx Broadcaster either sends the finished static version of the dashboard or just the online link to SAP NetWeaver Portal folders or via an email to selected users.

BEx Broadcaster is a Web-based application that you can access in the portal by using standard content roles or by using the Tools menu on the BEx tool set (Figure 10). In this example, I created a portal link to my dashboard in

Figure 6.

Figure 10 BEx Broadcaster setting to distribute the Web template to the My Portfolio link in the portal

After you execute the broadcast (or schedule the broadcast for repeated execution), the system populates the assigned portal folder with the default version of the Web template data. To access the personal navigation, you must use the Online Link option shown in Figure 5.

Because I addressed more than your original question, I would like to summarize some points below.

Views are saved navigations of the data in one query Bookmarks save Web template dashboard navigation. You can access bookmarks via the portal or your

browser favorites.

You can broadcast links to dashboards via email or SAP NetWeaver Portal

The personalization option in the Web template acts like a bookmark tied to your user ID

If you had to classify them, bookmarks target end users and query views target the power user and the Web template designer. Your goal should be to minimize queries. Then use these views on Web template dashboards, which in many cases could be delivered to users via BEx Broadcaster.

Note

To find out more or fine tune your knowledge, the appropriate SAP training class is BW306 “BI - Enterprise Reporting, Query and Analysis (Part II).”

Create a Web Interface for the BEx Map  

by Lori Vanourek, BI Specialist, BI Product Management, SAP Labs

Learn how to use the Web Application Designer to create templates for interactive maps. By using only two settings, you can provide three levels of interactivity.

Categories: BEx, Reporting, Web Application Designer

In the previous issue of BW Expert, I showed you how to set up the data for using the BEx Map.1 Now I'll describe how you can use a couple of settings within the Web Application Designer to create templates that allow maps to interact with various Web items (tables, graphics, etc.) within your Web template on three levels:

1. Each Web item is autonomous and does not influence, nor is it influenced by, other Web items. 2. Web items such as tables influence Web items such as maps or vice-versa (uni-directional).

3. Maps and tables influence each other (bi-directional).

I have chosen this topic because customers often don't realize how much control they have when it comes to the interactiveness of their Web templates. This article will provide a concise guide to getting exactly the behavior you desire from your Web items, thereby shortening your testing time by minimizing “trial and error” when building your template. The trick to a successful Web template is to clearly understand how its settings cause the various Web items within it to affect each other.

You need a basic understanding of the Web Application Designer to follow along, as I've focused on two settings in the Web Application Designer: Map Interaction Controls and Affected Data Providers. They let you achieve the three different levels of interactivity.

Tip: You can find all Web item settings by clicking on the object in your Web template and then clicking on the Web items tab in the Properties box. If working with a map, be sure to click on the appropriate map layer first, since each map layer can be configured individually.

I will show you how to set up your Web template for each of these three interactivity levels, but first let me tell you what the Map Interaction Controls setting is and how it works.

Map Interaction Controls This setting determines if the map will influence other items in the Web template. It offers two options.

The most important option for this article, Click on Map to Filter Data Providers (see Figure 1), allows a user's navigation on the map to influence other Web items such as tables or charts. For example, say you are looking at a map of the United States, and below the map is a table that breaks down sales by state and product code. With the

Click on Map to Filter Data Providers setting on, you can click on the state of California, and the query in the table below it will filter to show only the sales by product code for that state.

Figure 1 Enable the Click on Map to Filter Data Providers setting

Since you could have multiple items in the Web template, you might want the map to influence a table but not influence a chart or another Web item. Because of this, the Click on Map to Filter Data Providers option works in conjunction with the second of the two Web Application Designer settings mentioned earlier, Affected Data Providers, which I will describe in the next section.

The other option, Click on Map for Normal Context Menu (also shown in Figure 1), will not influence other items in the Web template.

Affected Data Providers A Web template can have data coming in from a number of different sources; each source is mapped to a unique data provider within the Web template.

When dealing with a map, the Affected Data Providers setting (shown in Figure 2) works in conjunction with the Click on Map to Filter Data Providers setting. It allows you to specify exactly which data providers navigating on the map will influence. For example, say that you have a Web template with four Web items in it: the map (fed by data provider 1), a table (fed by data provider 2), a bar chart (also fed by data provider 2), and a pie chart (fed by data provider 3). You want the map to affect the bar chart and the table, but you do not want it to affect the pie chart. To accomplish this, you would use the Click on Map to Filter Data Providers setting in conjunction with the Affected

Data Providers setting, where only data provider 2 is selected. Building on the California example from above, if the bar chart graphs sales by state and the pie chart graphs returns by state, then clicking on California would filter the bar chart to show only sales for California, while the pie chart would continue to show returns for all states.

Figure 2 Check off the appropriate data providers

When dealing with Web items other than maps, the Affected Data Providers option works the same as described above. Since you are not dealing with a map, however, it does not require the Click on Map to Filter Data Providers setting. For example, take your California scenario and flip it around. If you drill down on your table to show, say, only values for California, then you want your map to show only figures for California. In this case, the Affected Data Providers setting will have data provider 1 selected (the data provider that feeds the map). The result of drilling down on the table will be:

The map will be filtered to show only California data The bar chart will be filtered to show only California

The pie chart will remain intact, showing all states

Note: The reason the bar chart is affected in the scenario above, even though its data provider (data provider 2) is not selected in the Affected Data Providers setting, is because it shares the same data provider as the table. If two Web items share the same data provider, then they automatically influence each other since they come from the same DataSource.

Settings Guide for the Three Levels of Interactivity Now that you have an understanding of the two interactivity settings, you are ready to set up your Web template for the BEx Map. Here's what you need to do for each interactivity level:

Level 1. Each Web item is autonomous —it does not influence, nor is it influenced by, other Web items.

Each Web item has a unique data provider. The Map Interaction Controls setting is set to option Click on Map for Normal Context Menu, and the

Affected Data Providers setting does not have any data providers selected.

The other Web items in the Web template have nothing selected for the Affected Data Providers setting.

Level 2. One Web item, such as a map, affects another Web item, such as a table, but the table does not influence the map (uni-directional).Scenario 1: A table influences a map, but the map does not influence the table.

Each Web item has a unique data provider. Select Click on Map for Normal Context Menu for the Map Interaction Controls setting.

Make sure that the Affected Data Providers setting does not have any data providers selected. The data provider for other Web items such as a table feeds the map selected in the Affected Data Providers setting.

Other Web items such as a table have the data provider that feeds the map selected in the Affected Data Providers setting.

Scenario 2: A map influences a table, but a table does not influence a map.

Each Web item has a unique data provider. Select Click on Map to Filter Data Providers for the Map Interaction Controls setting.

Make sure that the Affected Data Providers setting has the data provider for the table selected.

Make sure that other Web items—such as another table—have no data providers selected in the Affected Data Providers setting.

Tip: If you would like to influence the extent of geographic data that a map displays (in other words, only display countries for which there is data rather than display, say the entire continent of Europe), you can use the Extent of the Map setting. If, for example, you have data for Germany only, you would use the Data Only option. (See Figure 3.)

Figure 3 Select Data Only to tie the data drill-data to the map

Level 3. Maps and tables influence each other (bi-directional)

All Web items share the same data provider. Select Click on Map to Filter Data Providers for the Map Interaction Controls setting.

Select Click on Map to Filter Data Providers for the Map Interaction Controls setting.

Choose the data provider for the table selected under the Affected Data Providers setting.

For other Web items, such as another table, select the the data provider for the selected map in the Affected Data Providers setting.

You should now be able to set up the BEx Map for the Web with the interactions between map and data that you need.

1 To recap, the BEx Map is a part of the BEx Analyzer within Business Explorer that allows you to analyze geographic data. For example, you can evaluate customer data starting at a regional view and then drill down to a state, county, or city view if you wish. This aids users in the decision-making process by showing patterns and trends from a geographic perspective.

Create an Interactive BW Report Catalog  

by Yu (James) Hong, Senior Consultant, BearingPoint Inc.

Discover how to make a report catalog using a BW virtual InfoCube and ABAP table interface technology.

Categories: ABAP, BEx, Reporting, Web Application Designer

Key Concept

Managers can more easily make informed decisions if they refer to a report catalog that provides a quick overview of all available BW reports in various business areas such as Controlling (CO), Sales and Distribution (SD), and Customer Relationship Management (CRM). The report catalog makes BW reports more visible in a global company. It also provides users with easy access to help documents associated with each report and a link to quickly run reports.

In a global enterprise system, BW reports on almost every area of the business. Hundreds if not thousands of BW reporting roles serve different business needs and store reports in different business areas. Because you typically add and implement new reports on a phase-by-phase basis, it is challenging to update the user community about newly available reports.

For these reasons, new and existing BW users may benefit from a catalog of all the available BW reports and their help documents in different business areas. The report catalog also lists the owners of each reporting role so that users can request access permission from them. I’ll describe what a BW report catalog is, explain its components, and then demonstrate how to set one up using a BW virtual InfoCube and ABAP table interface.

What Is a BW Report Catalog?

The purpose of a BW report catalog is to give users a central place to view and launch all available BW reports as well as their help documents. A BW report catalog is essentially

a BW Web report created against a virtual InfoCube. You model the virtual InfoCube according to the information in

the report catalog. Figure 1 shows an example of a report catalog. You base this report on the virtual InfoCube that includes several characteristics, including functional areas such as Financial Accounting (FI) and subareas (e.g., Accounts Receivable [AR] and Accounts Payable [AP] within FI), Web report name, query name, and report author. You can also model the virtual InfoCube to include other characteristics such as available date and last changed date.

Figure 1 A report catalogclick here to view a larger version of this image

In Figure 1, a subarea equals a BW reporting role where you can publish a Web report or query. Most companies use BW reporting roles to organize and publish BW reports for the users in different business functions. In the example, a subarea is the term the report catalog uses to mimic the BW reporting role. In addition, you can also expand reporting roles that the InfoObject calls to include additional attributes such as reporting role owner. You can activate the attributes as navigation attributes at the InfoObject and InfoCube level.

As illustrated in Figure 1, the report catalog includes fields for Functional Area Role, Report Tech. Name, Report Help Doc., and Report Author. The report catalog contains more characteristics in the InfoCube than you see on screen. This enables users to slice and dice the report catalog in the same manner as other BW reports.

This report catalog has two great features. One is the help icon in the Report Help Doc. column linked to the report

help documents, and the other is the report icon (to the left of each report name in the Report Tech. Name column)

that launches a particular report. You can enable these features using the ABAP table interface class. The system populates the links and icons for every row during the query runtime. Before I explain how to create these two features, let me describe some of the components involved.

Tip!

Since the report catalog is an SAP NetWeaver BW Web report, you can quickly publish it to SAP NetWeaver Portal using a standard SAP iView.

Report Catalog Components

The report catalog uses the following components: a BW virtual InfoCube, an ABAP table interface class, SAP Web Application Designer (SAP Web AD), and BEx.

A BW virtual InfoCube is an InfoCube that contains no physical data, but gives queries direct access to data according to the structure that the virtual InfoCube defines. The ABAP table interface class is an ABAP class that enables you to modify the content, display, and navigation options of individual cell data (e.g., characteristic values, column headers, value cells) in the BW Web report.

The report catalog uses the ABAP table interface class to enable interactive features such as the link to launch a report and the help document for the report. You must redefine the characteristic method in the ABAP class to support these two features. The report catalog itself is a BW report based on the BW query. Web AD and BEx create the Web report and the report catalog query. Now that you know what’s involved in creating a report catalog, I’ll show you how to do it.

You’ll need to follow four steps to create the report catalog:

Step 1. Use a Z table to store the information for the report catalog.

Step 2. Use a virtual InfoCube to link to the Z table.

Step 3. Create an ABAP table interface class and redefine its characteristic method to insert the HTML source code and the GIF link in the characteristic method.

Step 4. Create a query-called report catalog in the virtual InfoCube and then create a Web report based on the query.

Create the Report Catalog

Step 1. Use a Z table to store the information for the report catalog.

Every row in this table contains the Web report name, query name, reporting role, help template name, or other relevant information. In this case, query field and Web template field are the keys that the table requires to store information for every template or query published in the reporting role. To create the Z table, go to transaction SE11

and type ZREP_CATALOG in the Transp. table field to see the table definition screen in Figure 2.

Figure 2 The field definition page of the tableclick here to view a larger version of this image

The field definition page of the Z table provides the definitions of query, template, owner, role, and other fields the report catalog uses. In this table definition screen in Figure 2, type WEBTEMPLATE in the first row of the Field column and then check the check boxes for Key and Initial allowed (Initi…). Continue to define the other data fields such as REPORT_TYPE and CHANNELROLE. Do not check the boxes for Key and Initial allowed for these data fields.

Figure 3 shows an individual table entry in the Z table. The table entry shows a Web template and its corresponding query, the role that publishes the report, the last changed date, and other information. In this particular entry, the Web

template name and the query name are MSD_C03_Q5002. A role called Z:V_RP_SLSFORCEREPORTS publishes the report.

Figure 3 An individual table entry in the Z tableclick here to view a larger version of this image

You must gather the above information from the BW report developers in each area. Then, use transaction SE16 or SM30 to maintain the information for the reports. You should collect detailed data about the reports in each area, such as the information on functional area, subarea, owner, and help document linked to the Web report. You can then use the Z table as a data source for the report catalog’s virtual InfoCube.

Step 2. Use a virtual InfoCube to link to the Z table.

This virtual InfoCube reports on the information in the ZREP_CATALOG table. First, create an InfoSource that you can use in your virtual InfoCube via transaction RSA1 and menu path Modeling>InfoSource. Name your InfoSource

ZIS_RP_CATALOG (Figure 4). This InfoSource mimics all the characteristics and key figures that the virtual InfoCube uses.

Figure 4 InfoSource linked to table ZREP_CATALOG to support the virtual InfoCubeclick here to view a larger version of this image

Next, create a virtual InfoCube and connect it to the InfoSource ZIS_RP_CATALOG. Enter transaction RSA1, follow menu path Modeling>InfoProvider, and create your InfoCube (Figure 5). Select type SAP RemoteCube and direct

this InfoCube to an InfoSource (in my example, ZIS_RP_CATALOG).

Figure 5 Create virtual InfoCube ZC_RP_CAT as an SAP RemoteCube pointing to the InfoSource ZIS_RP_CATALOGclick here to view a larger version of this image

Note

When you update or add a report to this Z table, a query in the virtual InfoCube automatically reflects the changes to the table.

Figure 6 shows that the InfoObjects for query, template, role, and other InfoObjects comprise the virtual InfoCube for the report catalog. Next, use transaction RSA2 to create a transactional DataSource to point to table

ZREP_CATALOG (Figure 7). Enter the settings shown.

Figure 6 Virtual InfoCube associated with table ZREP_CATALOG to support the report catalogclick here to view a larger version of this image

Figure 7 DataSource linked to table ZREP_CATALOG to support the virtual

InfoCubeclick here to view a larger version of this image

Step 3. Create an ABAP table interface class and redefine its characteristic method to insert the HTML source code and the GIF link in the characteristic method.

Now that you’ve performed the back-end configuration, you have to set up the front end to develop and design the report catalog. You must define an ABAP class in the back end to support two of the catalog’s features: launching both the report and help documents in new windows.

The HTML code of the table item in the Web report template that you will configure in step 4 references the ABAP class you create in this step. The ABAP class changes the content of the report catalog based on the ABAP code defined in the characteristic method.

Create an ABAP class called ZCL_TABLE_CLASSREP using transaction SE24 or SE80, as shown in Figure 8. The system prompts you to enter the class name and the source class to copy from. Name the class name ZCL_TABLE_CLASSREP and its source class CL_RSR_WWW_MODIFY_CLASS (Figure 9). After that, specify the inherited class as CL_RSR_WWW_MODIFY_TABLE in the Properties tab for the class. In Figure 9, notice that the

superclass is CL_RSR_WWW_MODIFY_TABLE.

Figure 8 Create an ABAP class called ZCL_TABLE_CLASSREPclick here to view a larger version of this image

Figure 9 The attribute for the table interface class — note that the Superclass is CL_RSR_WWW_MODIFY_TABLEclick here to view a larger version of this image

In Figure 1, Report Help Doc. is also a characteristic in the virtual InfoCube. Each BW report has a Z table entry that stores the help document name. Thus, the name for the help document serves as a characteristic value for characteristic Report Help Doc. The ABAP code uses the document name to construct the URL. The code of the

ABAP table interface class references this characteristic value. Figure 10 shows the new window that opens the help document for a particular report when you click on the help icon.

Figure 10 Pop-up help window that opens when you click on the help iconclick here to view a larger version of this image

To enable the help feature of the report catalog and change the cell contents to contain the GIF link, you have to redefine the characteristic method under the table interface class. In the left navigation menu of Figure 9, go to Methods>Redefinitions. Double-click on the characteristic method and add the code to the method. The code uses

two characteristics of the virtual InfoCube, the Web template 0TCTWEBTEMP and the help document name ZREP_HELP.

The ABAP code concatenates the values of 0TCTWEBTEMP and ZREP_HELP to construct HTML URLs. When running the report catalog, BW dynamically inserts these URLs. Figure 11 shows the ABAP code that adds the characteristic method to support the help document link and the query run link.

The code in Figure 11 constructs the URL in Figure 12 and generates every row in the report catalog at runtime. When you click on the link for the URL in Figure 12, a new window displays a template (HELP_TEMPLATE in this

case). The template could be a generic one like HELP_TEMPLATE, but it also can be very specific to each report depending on how you configure the ABAP code logic.

METHOD CHARACTERISTIC_CELL .*CALL METHOD SUPER->CHARACTERISTIC_CELL* EXPORTING* I_X* I_Y* I_IOBJNM* I_AXIS =* I_CHAVL_EXT =* I_CHAVL =* I_NODE_IOBJNM =* I_TEXT =* I_HRY_ACTIVE =* I_DRILLSTATE =* I_DISPLAY_LEVEL =* I_USE_TEXT =* I_IS_SUM* I_IS_REPETITION =** I_FIRST_CELL =

RS_C_FALSE** I_LAST_CELL =

RS_C_FALSE* I_CELLSPAN =* I_CELLSPAN_ORT =* CHANGING* C_CELL_ID =* C_CELL_CONTENT =* C_CELL_STYLE =* C_CELL_TD_EXTEND =* .DATA: PATH TYPE STRING, L_CELL_CONTENT TYPE STRING, IMGPATH TYPE STRING, LINKPATH TYPE STRING, LAUNCHTEMPLATE TYPE STRING, HELPTEMPLATE TYPE STRING, URLPREFIX TYPE STRING, URLPATH TYPE STRING, FILTER TYPE STRING.PATH = 'MIME/Bex/Icons/’.URLPREFIX = GET_URL( ).IF I_IOBJNM = 'ZREP_HELP’. CLEAR L_CELL_CONTENT.

CLEAR C_CELL_CONTENT. IF I_CHAVL = '#’. HELPTEMPLATE = 'HELP_TEMPLATE’. ELSE. HELPTEMPLATE = I_CHAVL. ENDIF.* Initialize the linkpath CONCATENATE URLPREFIX '&CMD=LDOC&TEMPLATE_ID=’ HELPTEMPLATE INTO LINKPATH. CONCATENATE '’ INTO URLPATH.* Initialize the img path CONCATENATE ' ’ INTO IMGPATH. CONCATENATE URLPATH IMGPATH ' ’ INTO L_CELL_CONTENT. C_CELL_CONTENT = L_CELL_CONTENT.

ENDIF.

IF I_IOBJNM = '0TCTWEBTEMP’. CLEAR L_CELL_CONTENT. CLEAR C_CELL_CONTENT. CLEAR LINKPATH. CLEAR URLPATH. LAUNCHTEMPLATE = I_CHAVL.* Initialize the linkpath CONCATENATE URLPREFIX '&CMD=LDOC&TEMPLATE_ID=’ LAUNCHTEMPLATE INTO LINKPATH. CONCATENATE '’ INTO URLPATH.* Initialize the img path CONCATENATE ' ’ INTO IMGPATH. CONCATENATE URLPATH IMGPATH ' ' ' ’ I_CHAVL INTOL_CELL_CONTENT. C_CELL_CONTENT = L_CELL_CONTENT.

ENDIF.ENDMETHOD.

Figure 11 Source code in the characteristic method to insert the HTML code

&a href= "/sap/bw/BEx?SAP-LANGUAGE=E&PAGENO=1&REQUEST_NO=1&CMD=LDOC&TEM-PLATE_ID=HELP_TEMPLATE" target="_blank" >

Figure 12 HTML code to launch help documents

The process works similarly for the other feature of the report catalog, launching a Web report in a new window

(Figure 13). Figure 14 shows the URL source code that runs the Web report.

Figure 13 Launch the report window by clicking on the report icon in Figure 1click here to view a larger version of this image

< a> >< Height="15" alt="Launch Report" SRC="MIME/Bex/Icons/b_query.gif" border="0" ><img>

Figure 14 HTML code to launch the Web report

Step 4. Create a query-called report catalog in the virtual InfoCube and then create a Web report based on the query.

After defining the ABAP class, you need to create a query-called report catalog and a Web template. The Web report refers to the ABAP class created in step 3.

Note

To download the code in Figures 11 12, 14, and 16, visit the Downloads section of BW/BI Expert's Web site at www.BWExpertOnline.com.

Figure 15 shows the query created in BEx Query Designer. Next, create the Web report (Figure 1) in the report

catalog Web template in Web AD. Enter the HTML code that modifies the table item in Figure 16 in the HTML tab of Web AD.

Figure 15 The query for the report catalogclick here to view a larger version of this image

<object><param name="OWNER" value="SAP_BW"/><param name="CMD" value="GET_ITEM"/><param name="NAME" value="TABLE_1"/><param name="ITEM_CLASS"

value="CL_RSR_WWW_ITEM_GRID"/><param name="DATA_PROVIDER" value="DP"/><param name="CAPTION" value="Report

Catalog"/><param name="BLOCK_SIZE" value="0"/><param name="SHOW_PAGING_AREA_TOP"

value="X"/><param name="MODIFY_CLASS"

value="ZCL_TABLE_CLASSREP"/><param name="HELP_SERVICE"

value="ZPRINTING"/><param name="HELP_SERVICE_CLASS"

value="Z_PRINT_HELP_SERVICE"/>ITEM: TABLE_1

</object>

Figure 16 HTML source code for Web item in the report catalog

In the HTML section of the Web report for the table item object, insert the parameter modify_class = ZCL_TABLE_CLASSREP. The ABAP class ZCL_TABLE_CLASSREP in Figure 16 is the one created in step 3. This table item used the parameter modify_class in the Web report, so at runtime, BW calls the back-end ABAP class when the table item appears.

Custom Program Grants Users Easy Access to Both BEx Analyzer 3.x and SAP NetWeaver 2004s  

by Bryan Koetting, BI Consultant, Teklink International

When migrating to SAP NetWeaver 2004s, your users may want to access both the new and legacy versions of BEx Analyzer until they get used to the new program. However, users accessing BEx Analyzer via single-sign on with transaction RRMX cannot choose which version of BEx Analyzer to launch. Use ABAP code to add a selection screen so users can choose their version of BEx Analyzer.

Categories: ABAP, BEx, Reporting

Key Concept

BEx Analyzer in SAP NetWeaver 2004s has changed substantially. It is now more integrated into Microsoft Excel. Some new features include the direct use of Excel formulas and formatting and the ability to build applications with the new Design Toolbar. Therefore, you cannot open workbooks saved in the new BEx Analyzer release in the older legacy version (commonly called 3.x), and you must migrate workbooks created in 3.x to use them in SAP NetWeaver 2004s.

To ease the upgrade and migration process to SAP NetWeaver 2004s, SAP provides and supports both versions of BEx Analyzer. Most users choose to use both versions to adjust to the new version and wait for the technical team to migrate existing 3.x query objects to SAP NetWeaver 2004s. Also, many SAP implementations support multiple BI clients, involving a combination of BW 3.x and SAP NetWeaver 2004s.

The SAP NetWeaver 2004s SAPGUI front end provides two versions of BEx Analyzer: the 3.x legacy version and the SAP NetWeaver 2004s version. Users may run queries created under either version with either tool, although they can only edit queries with the version in which they were created.

While users grow accustomed to the new version of BEx Analyzer, they probably want to access both versions of the program. However, in SAP NetWeaver 2004s, the only way to specify which version of BEx Analyzer starts with

transaction RRMX is by a global setting on the SAP NetWeaver 2004s version (Figure 1). You can access this setting only after you launch BEx Analyzer in SAP NetWeaver 2004s.

Figure 1 Global Settings for SAP NetWeaver 2004s BEx Analyzer

The default setting is to launch the SAP NetWeaver 2004s version, an inconvenient configuration for anyone wanting to use both versions of BEx Analyzer with transaction RRMX. Consequently, I developed custom ABAP code to allow users to specify the version. This makes supporting both versions of BEx Analyzer much easier, especially in single sign-on (SSO) environments. Many SAP users do not launch and sign on to BEx Analyzer directly from the start

menu of their PC. Rather, they launch BEx Analyzer via transaction RRMX from the back end, which uses SSO.

Note

You cannot use BEx Analyzer in SAP NetWeaver 2004s to edit queries as you can in the 3.x version. You must edit using BEx Query Designer in SAP NetWeaver 2004s. You cannot edit queries created using the new version of BEx Query Designer with the 3.x version of BEx Analyzer, although you can display or embed older queries in workbooks. Likewise, you can display or embed 3.x queries in workbooks in SAP NetWeaver 2004s BEx Analyzer.

BEx Analyzer Global Setting

Figure 1 illustrates the Launch legacy version from RRMX flag in the Global Settings screen from BEx Analyzer in SAP NetWeaver 2004s. When running RRMX from a BW 3.x client, the 3.x version of BEx Analyzer always launches (as of SAP NetWeaver 2004s front-end patch 7). Therefore, BW 3.x systems ignore this setting.

SAP NetWeaver 2004s provides the capability to use a special Windows registry entry on the client PC to externally control the global setting. SAP does not create this registry entry automatically; users must create and populate it.

This registry entry is: HKEY_CURRENT_USER>Software>SAP>BEx>Analyzer>LAUNCH_VERSION (Figure 2). If you’re not familiar with the Windows registry, don’t worry about what this entry means or how to create it. The programs I’ll provide will create and update this entry automatically.

Figure 2 Registry key for BEx Analyzer LAUNCH_VERSION set to LEGACY

When this registry entry is populated with a value of LEGACY, your PC automatically turns on the Launch legacy version from RRMX flag in Figure 1 that enables the legacy version of BEx Analyzer. It also grays out this setting so you cannot edit it.

When the registry entry is populated by any other non-blank value (such as 04S), then your PC automatically removes the check in the Launch legacy version from RRMX flag and locks you from editing it. If this registry key entry has a blank value or if you have not created the registry entry, then the Launch legacy version from RRMX flag works as originally installed and is open for editing. Note that the registry entry value is not case sensitive. Next, I’ll describe how I used this undocumented feature to solve my problem.

You can manipulate the registry entry in several ways. The most direct way is with the standard Windows program regedit.exe. However, this solution is difficult and most companies restrict use of that program since you can potentially damage your PC’s configuration. In my sidebar “Use Method RegWrite,” I’ll explain another method of updating the registry.

This method uses a Microsoft Visual Basic Scripting Edition (VBScript) program on the PC that you can run from an ABAP program before users launch transaction RRMX. However, I decided against this method because it requires a separate file on the user’s PC, which someone could delete accidentally.

The best method for my solution uses a standard ABAP class within BW called CL_GUI_FRONTEND_SERVICES. This class provides a number of methods to perform PC functions with ABAP, such as displaying and deleting files or uploading and downloading files. One of the methods in this class is REGISTRY_SET_VALUE, which allows you to manipulate the PC registry with ABAP. You can find additional documentation about this class in Class Builder, transaction SE24.

Using Class CL_GUI_FRONTEND_SERVICES, I wrote two ABAP programs called ZRRMXOLD and ZRRMXNEW using ABAP Editor, transaction SE38. ZRRMXOLD sets the LAUNCH_VERSION registry entry to LEGACY and then calls the program that launches BEx Analyzer. This launches the 3.x version of BEx Analyzer. Program ZRRMXNEW sets the LAUNCH_VERSION registry entry to 04S, and then launches BEx Analyzer, which brings up the SAP NetWeaver 2004s version. Then, I assigned each of these programs to transaction codes in SE93, which I named ZRRMXOLD and ZRRMXNEW. Now, instead of using transaction RRMX, a user can enter either transaction ZRRMXOLD or ZRRMXNEW to control which version of BEx Analyzer to launch.

Program ZRRMXOLD

Figure 3 shows program ZRRMXOLD. It sets the LAUNCH_VERSION registry entry to LEGACY and then submits (calls) the program that launches BEx Analyzer. This launches the 3.x version of BEx Analyzer. Create this and all

programs in ABAP Editor, transaction SE38.

*&————————————&mdash;————————————————

—————-**& Report ZRRMXOLD*&*&————————————————————————————————&mdash;—-**&*&*&————————————————————————————————&mdash;—-*

REPORT ZRRMXOLD.

data key type string value'Software\SAP\BEx\Analyzer'.data root type i value CL_GUI_FRONTEND_SERVICES=>HKEY_CURRENT_USER. "=1data returncode type i.data reg_value type string. CALL METHOD cl_gui_frontend_services=>registry_set_value EXPORTING ROOT = root KEY = key VALUE_NAME = 'LAUNCH_VERSION' VALUE = 'LEGACY' IMPORTING RC = returncode EXCEPTIONS REGISTRY_ERROR = 1 CNTL_ERROR = 2 ERROR_NO_GUI = 3 NOT_SUPPORTED_BY_GUI = 4.

CALL METHOD CL_GUI_CFW=>UPDATE_VIEW* EXPORTING* CALLED_BY_SYSTEM = EXCEPTIONS CNTL_SYSTEM_ERROR = 1 CNTL_ERROR = 2 others = 3.

submit RRMX_START_EXCEL.

Figure 3 Program ZRRMXOLD sets the registry entry to LEGACY and launches BEx Analyzer

After you create ZRRMXOLD, enter transaction SE93 to assign program ZRRMXOLD to transaction code ZRRMXOLD. In Figure 4, the initial screen for SE93, enter ZRRMXOLD in the Transaction Code field and click on

the Create button. This takes you to the screen in Figure 5.

Figure 4 Enter ZRRMXOLD in the Maintain Transaction initial screen

Figure 5 Choose the Program and selection screen (report transaction) option

Note

All programs are available in the Downloads section of BW Expert’s Web site, BWExpertOnline.com.

Note

Check with your company’s PC desktop administrators before implementing any functionality that updates registry entries. Company policies on this vary widely, and most likely they will want to test and verify any solution that involves the registry.

Enter the Short text and choose the Program and selection screen (report transaction) option. Clicking on the enter icon takes you to Figure 6. Enter ZRRMXOLD in the Program field and choose the Classification and GUI

support options shown. If you’re entering this in a development environment, when you save the entry the system prompts you for a package and a transport request. Enter these in accordance with your company’s policies.

Figure 6 Maintain the Classification and GUI Support options

Program ZRRMXNEW

The code for program ZRRMXNEW is included on BW Expert’s Web site. The only difference from the code for program ZRRMXOLD is on the line VALUE = 'LEGACY'. Instead, program ZRRMXNEW contains the line VALUE = '04S'. Likewise, the steps to assign program ZRRMXNEW to transaction code ZRRMXNEW in SE93 are not illustrated here, but you can use Figures 4-6 as a reference.

Program ZRRMX_CHOOSE

Once I had a workable solution, my two programs and transaction codes, I thought I would develop an alternative technique with a slightly different ABAP program. This presents users with a selection screen in which they can indicate the version of BEx Analyzer to launch, and then launches it (Figure 7). I named this program ZRRMX_CHOOSE, and I assigned this to transaction code ZRRMX using transaction SE93 (as illustrated in Figures 4-6). Some users might prefer this solution because it only involves one ABAP program and one transaction code.

The code for this program is located on BW Expert’s Web site.

Figure 7 Selection screen for program ZRRMX_CHOOSE, transaction ZRRMX

Use Method RegWrite

One way to set registry entries on the PC is with a VBScript program that calls method RegWrite of the WScript.Shell Windows object (a standard Windows object contained in file wscript.exe, usually found in c:\windows\system32). Figure 1 shows a simple VBScript program to update the registry. (If you search the Internet for “wscript.shell regwrite,” you’ll find other examples.) You can execute this VBScript program directly on the PC or

from an ABAP program within BW using Method EXECUTE of Class CL_GUI_FRONTEND_SERVICES (as described in the article).

Figure 1 VBScript program to update LAUNCH_VERSION registry

Customize the Standard Web Template to Save Time and Effort  

by Mukunda Krishnaswamy, Principal Architect, Enterprise Systems, American Standard Companies, Inc.

Great-looking reports don’t just happen. They can take a lot of your precious time and gobble up development resources. BW ships with a Web template that allows you to rapidly deploy customized reports that are sure to be a hit with your end users and reduce your development efforts.

Categories: BEx, Reporting

Key Concept

The standard BW Web template 0QUERY_TEMPLATE can be modified to meet the specifications of your end users. Modifications can be made to toolbar buttons, the context menu, the navigation block, and more. The standard template is available instance-wide to rapidly publish queries with a consistent graphical interface.

A standard template is available in BW to display queries with a Web browser that allows you to take full advantage of various distribution options. When you execute a query in the Web browser either through BEx Analyzer or BEx Query Designer, the standard Web template is available to display the results enabling the rapid publication of queries as Web reports.

Employing the standard Web template efficiently can be a big help as you develop user interfaces. It allows you to save time developing and publishing Web reports that have a consistent appearance and functionality. Providing familiar Web reports also plays an important role in enhancing user experience. In addition, the template can provide relief in terms of your user training efforts, and it promotes faster acceptance of your BW applications.

I’ll give you an overview of how and where you can modify the BW standard Web template. I will also discuss some of the techniques you can use to customize and enhance it to meet the needs of your business environment. You’ll understand how the standard template decreases custom development efforts and how it increases consistency in the look and feel of your BW reports.

BW Standard Template

0QUERY_TEMPLATE has a number of functions such as the ability to display reports as tables or charts and export data to spreadsheets via the CSV format. It has three basic parts:

Headline

Toolbar

Web items

The headline displays the query description used in BEx Query Designer and the toolbar buttons support commands to interact with the Web items such as tables and filters. Toolbar buttons also enable additional functionality. For

example, the information toolbar button (Figure 1) allows Group 3 items to display query information, filters, and variable values while hiding all other Web items.

Figure 1 Standard template toolbar with the information button highlighted

Before customizing 0QUERY_TEMPLATE, SAP urges users to copy it and maintain a backup of the original. Remember to monitor your customization activities and protect any changes during upgrades.

To create a copy of the standard Web template, open 0QUERY_TEMPLATE in Web Application Designer (Web AD) and use the menu path File>Save As. I saved my copy of 0QUERY_TEMPLATE as MYCOMPANY_QUERY_TEMPLATE for this article.

Customize Your Standard Template

A number of standard template attributes are customizable along with the context menu available in the template. Set

the check boxes on the Web AD Web Item tab under the General heading to define various attributes (Figure 2). These attributes determine a range of functions, from whether warnings will be displayed to the read mode for data to device-based output optimization.

Figure 2 Web template attributes are customized in the Web Item tab

While the context menu in the template supports a host of features, some may not be relevant to your end users. The Web Item tab allows you to customize context menu settings and configure each entry by setting flags in the Entries in Context Menu section (Figure 3). Set the Always Display option to make the item available in a report’s basic menu or designate it to be displayed only in the Enhanced Menu. Web items can also be hidden from users

altogether using the No Display setting.

Figure 3 Web template context menu

Customize Web Items

You can customize individual Web items in the standard template via Web AD. For example, you can decrease or increase the space allocated to the navigation block by setting its width via the HORIZONTAL_ALIGNMENT and

HORIZONTAL_NUMBER attributes (Figure 4). Decreasing the space allocated to the navigational block will make the report data more accessible and could help minimize scrolling.

Figure 4 Customize navigation block

Customized Web items can be saved to the library for efficient reuse in other Web templates. After you make the changes to the Web items in your standard template, use the Save in Library button to add the customized item to

the library (Figure 5). Create the library object by providing a name and description.

Figure 5 Save the customized item in the library

Better Toolbar Buttons

The toolbar can be altered to meet end-user demands. For example, some may find functions such as bar charting hard to use. You can remove the button related to bar charting in the toolbar section of the template. Likewise, additional toolbar buttons can be developed to enhance the end user’s experience. Last January, for example, I described a JavaScript function that simplifies the BW bookmark process (see “Make BW’s Bookmark Functionality a One-Step Process,” January 2004, for more details). The new function is evoked from the toolbar by adding the new

button described in Figure 6.

Figure 6 New toolbar button calling a custom JavaScript function

Tip!

While Web AD supports many tags, it does not support all HTML tags and JavaScript. Frame tags, for example, are not supported by Web AD, but a page containing frames can be uploaded directly to the server and then work fine. You may not be able to use some graphical editing features like those needed to modify a table Web item attribute if the scripts or tags in the standard template are not supported by Web AD. If your editing functionality is not supported, edit any HTML code associated with the template in a text editor or HTML editor, then upload the file using the Web Template>Upload to Sever menu path in Web AD.

Specify Style Sheets

Style sheets are used in BW to separate presentation elements such as font style from the main Web template HTML code. The BW default style sheet in the standard template is BWReports.css, but it may not always be adequate for your end users. For example, it does not print reports properly that exceed a width of one page. Many find it helpful to add another style sheet to the standard template to handle printing. Style sheets better suited for printing Web reports are available that offer smaller fonts.

To add a style sheet, open your query template in Web AD and follow the menu path Insert>Print Style Sheet. Alternatively, you can directly enter the script into the HTML of your company’s customized template via the Web AD

(Figure 7).

Figure 7 Add style sheet to facilitate printing

You can also select a different style sheet from the palette of style sheets included in BW or add your own custom style sheet. Use transaction SE80 and select the MIME Repository button to review the available style sheets

(Figure 8) or to add your own style sheet into the repository.

Figure 8 Style sheets in MIME repository

Configure BW to Use Your Query Template

It is a simple task to configure your system to use a customized template. Transaction RSCUSTV11 allows you to

specify the standard Web template, style sheet, and template attributes (Figure 9) for your BW instance.

Figure 9 Transaction code RSCUSTV11

Enter the name of your custom template in the Web Template field. The name of the appropriate style sheet, including the path information is then entered into the Style sheet field and the library object name is inserted in the

Web Template Props field. BW will use your Web template, specified style sheet, and template attributes instead of the default settings after this step. Note that the settings made directly to the Web templates will override the standard settings.

Your Company Logo

You can add a logo or other graphical element to your query template in two steps. First, upload the image to the Customer/Images directory in the MIME Repository using transaction SE80. Then, add a link to the image in the

headline section of your Web template as shown in Figure 1. This method gives the you ability to link standalone BW reports to your company portal, BW report menu page, or any other Web page you choose.

Figure 1 After uploading the image, add the circled code to insert a company logo into the report header

Alternatively, you can add your company logo to a style sheet instead of the standard template. This approach makes the logo visible in every Web template that uses the modified style sheet, including templates that you develop using Web AD.

Develop Dynamic Dashboards with BEx  

by Rajeev Kapur, BI Executive, BSI, and Alexander Thomas, Application Developer (February 2009)

SAP BW has all the tools necessary to deploy a dynamic dashboard that shows custom content for each user. Discover some of the concepts inherent to making a dashboard successful and how you can use SAP BW to deliver them.

Categories: Analytics, BEx, Reporting

Key Concept

You can personalize single variables or all variables in a Web application so that you do not need to manually update your variable settings. For example, this is helpful in situations in which you want a value automatically assigned to a variable based on the user ID. You assign the variables to a value permanently or temporarily until you remove the personalization.

Dashboards are great data visualization tools for an executive leadership team (ELT). However, each ELT user is going to see the same data with a different perspective. Personalization is a great way to store each user’s information in the system and show data values specific to that user when he enters the dashboard.

Using variables allows you to wait until the Web application that has the variable is displayed in the Web browser before you add values to a query. Personalization allows you to pre-fill the value of a variable.

Many applications can help you create personalized dashboards. However, we can show you how to develop these personalized dashboards right in BEx Query Designer. See how to create a custom dashboard that depicts KPIs to

enable quick decision making with a top-down view using multiple levels and detailed link to transaction data. Although this article is based on SAP BW 3.5, the concepts also apply to SAP NetWeaver BI Service Pack 15.

Set Up Personalization

Create a regular query in BEx Query Designer with a variable and execute it to see the screen in Figure 1. Right-click

the personalization icon and select Personalize to save a parameter to your user ID. Next time you run this query, that box will be pre-populated.

Figure 1 Standard variables entry screen for a BEx query

Behind the scenes, personalization is then loaded into the Business Content DataStore object (DSO) 0PERS_VAR. For dashboard purposes, you can create a flat file DataSource and load personalization for users directly into the

DSO using the Business Content DSO 0PERS_VAR to store personalization data. Table 1 shows key fields in this DSO.

FieldUse

TCTUSERNM

ID of user used to log into the systemTCTVARNM

Variable name from the query

TCTLOW Value of the variable that you want to use for personalization

Table 1 Noteworthy fields from 0PERS_VAR

Use the Table Interface Class

The table interface class is an integral tool to the development of our dashboard. Whether it’s adding a BW value to a JavaScript variable or customizing the way your data looks in tables, effective use of the table interface class can add function and value to your dashboard. The table interface class expands a developer’s ability to deliver customized Web templates to the users.

Use standard SAP class interface CL_RSR_WWW_MODIFY_TABLE to create a custom class for your Web template. This allows the developer a much larger toolset for customizing how data is displayed in SAP BW. The class contains the following methods shown in Figure 2:

ATTRIBUTE_CELL: Modifies the attribute data properties

CAPTION_CELL: Modifies the header row over characteristic data

CHARACTERISTIC_CELL: Modifies the characteristic data properties

DATA_CELL: Modifies the key figure data properties

Figure 2 The four methods you use to create the custom class

Create a Link to Transaction Data

You can use the table interface class CHARACTERISTIC_CELL to help create the URL within the dashboard (Figure

3). In our example, the dashboard application we want to create is related to Project System (PS). The transaction data is related to resources in cProjects, which has a URL with the parameter Project ID as standard configuration.

IF I_X = 3.

DATA:

s_current_system_id TYPE string,

CASE s_current_system_id.

WHEN 'DB1'.

s_server_to_call = 'http://url id'.

WHEN 'QB1'.

s_server_to_call = 'http://url id'.

WHEN 'PB1'.

s_server_to_call = 'http://url id'.

ENDCASE.

Figure 3Example code in table interface class CHARACTERISTIC_CELL to assist in creating a hyperlink connecting to another SAP transaction system

Create a Window to an External Application Server

In our example, we want to link comments from the project manager to the dashboard to provide real-time feedback on a project’s status. This external data is an ASP.NET/ SQL application server that contains a table with strings that are too long (>60 characters) to load into SAP BW. Using the table interface class with other SAP BW tools helped us accomplish our goal.

The page we want to show in our SAP BW environment is dynamic. Therefore, we must pass some parameters to the ASP.NET/SQL application server — in our example, only a project number is required. Using the table interface on one of our tables of SAP BW data, we implemented a JavaScript call to save a specific key figure (in our case, the

project number) to a JavaScript variable, which acts as an identifier to launch the page (Figure 4).

CONCATENATE C_CELL_CONTENT '' into C_CELL_CONTENT

Figure 4 JavaScript call to save the key figure to a JavaScript variable

On the ASP.NET/SQL side, we created a new, minimalist-style Web template to match the style of the calling

template (Figure 5). This makes the ASP.NET/SQL application seamless with the SAP BW application (Figure 6). It is important to simplify the template as much as possible so that your external data matches the objects around it. For example, the IFrame allows you to specify the dimensions and coordinates of the viewing window, but under certain circumstances the frame may scroll if the underlying page is larger than the frame size, even with scrolling disabled.

Figure 5 A simple ASP.NET/SQL Web template

Figure 6 The final Web template

An IFrame is an HTML device, similar to a frame that allows you to view data from another Web page within the same window. This means that while it appears that you’re looking at just one Web page, the browser is reading HTML code from two separate locations. By using the IFrame, you can simply launch the external data next to the BW data and the end user never knows the difference. We scripted the creation of this IFrame so that we could dynamically select the called subordinate template based on the unique identifier (project number, in our case) discussed above.

When you have finished this setup, it is time to generate the IFrame on the calling template. We created a JavaScript function to use the document.write function with the HTML code to pair the URL string stub with the identifier (Figure 7). We then call this function wherever in the template we want our IFrame to appear. This location must be called sequentially (in the Web template HTML, top to bottom, left to right) after the table whose interface is saving the key

figure value (Figure 8).

function createIframe(int){ var url="http://www.url.com/template.aspx?currentItem="+int;

document.write('frameborder=0 marginwidth=0 marginheight=0 scrolling="no">'); }

Figure 7 IFrame code to launch external data with the BW data

Figure 8 Function to create your IFrame where you want it on the page

Exception Reporting with Text Colors in the Dashboard

For some purposes, the table interface might not be enough. However, you can still use this functionality with a scripting language that can do further manipulation. For instance, it’s simple enough to color a numerical key figure, or even the cell containing a numerical key figure, based on its value with an exception. However, if you want to do much more than that, you’ll need another way.

By using JavaScript imbedded in our table interface class, we can do virtually anything. In Figure 9, we use a numerical key figure to populate the third column with a text key IF I_X = 9. For this particular requirement, the specific number isn’t important — it is important into which category this number falls. We were able to show just what bucket this piece of data falls into by using a script imbedded into our table interface class, as shown in Figure

10. By doing so, we can control that cell using the original value with a script built into the template. This can be a good option for a variety of reasons, because while the ways you can manipulate the data cell can be constrained somewhat in the table interface, JavaScript allows you virtually unlimited access to the cell, the table, and the various structures therein.

Figure 9 Key figures are assigned both text values and exception reporting capabilities

concatenate '' into C_CELL_CONTENT.

ENDIF.

Figure 10

Code to add the text key IF I_X=9

Select Multiple Filter Values Before Executing a Query

Applying key non-SAP BW technologies can be important in developing a highly customized dashboard. In the previous section we discussed how scripting could bring value to your dashboard. You can improve this further by using standard HTML coding.

Creating your own filters, whether using standard HTML objects or customized JavaScript, can improve the look, feel, and usability of your dashboard. The goal we had was to give users the ability to select values from multiple filters and only then execute the query. By default, SAP BW executes the template with every filter selection, which can be problematic and time-consuming if you want to make several selections at once.

We created a JavaScript object that allows for multiple selections per InfoObject on which we filtered. Although the coding of such an object is out of scope for this article, we will discuss how to pass information through the URL string to the application server, and allow you, the coder, to decide how to use this information.

First, start with HTML. You can build the entire URL string without using HTML, but we found that using HTML form components made for easier integration with the HTML that SAP BW produces. When using a form with method GET, all elements of that form appear in the URL string as &name=value. SAP NetWeaver Application Server (SAP NetWeaver AS) knows to look for these commands and interprets them according to a predefined set of rules.

To begin, we created our form with some initial information that SAP NetWeaver AS needs to know to get back to this

page (Figure 11).

Figure 11

The header information needed to initialize filters

The data provider input is best set to the data provider you are using to generate your filters. Set the target data providers in the filter properties. Also notice the use of type="hidden" for all the inputs in Figure 11. Hidden inputs do not show up on the rendered final page, although in some cases they may cause a vertical space to be entered.

Figure 12 shows the final view. Note that the hidden inputs do not appear.

Figure 12

Multiple filters work together. The system applies them when you click on the Submit button.

You can work around this by simply placing the inputs in your HTML next to some text or object that takes some vertical space. Hidden inputs are preferred for anything you don’t want your users to change or see.

Next, name the InfoObjects that correspond to each of the filters (Figure 13). The value of each input is equal to the name of the corresponding filter. The number following FILTER_IOBJNM_ corresponds with the number following the

FILTER_VALUE_ in Figure 14.

Figure 13

Filter information for the object IDs

Figure An example of the SAP-generated code for a filter with ONLY_VALUES

14 selected, surrounded by user-added

To break down this code segment, it is important to understand what is generated by the SAP system, what is

entered by the developer, and to which variables to pay particular attention. All the tags shown in Figure 13 must be entered by the developer. The data passed in these tags is entered onto the URL string when the form is submitted. It lets the application server know that there is filter information for the specified InfoObject and tells it to associate that object with a filter number.

Next, in Figure 14 we have encapsulated antag within the

Display Characteristic Values by Key with Longer Text Descriptions  

by Iliya Ruvinsky, BW Consultant, NESS, A.T.

When displaying a characteristic by key and text, the BEx Query Designer automatically displays the shortest available text from the InfoObject's text table. But what if you want to longer descriptions? The author presents a way to automatically provide long text descriptions with key without taking drastic steps such as deleting text table entries.

Categories: BEx

BEx Query Designer has a number of options for displaying characteristic values. Depending on an InfoObject’s definition, you can display a name or key for a characteristic value, a combination of both, or display nothing at all. You can also provide a short, medium, or long name or description so users can more easily identify the characteristic. While the list of options is complete, you’ll have to take additional steps if you want to the system to automatically display a characteristic with its key and a long name.

BEx automatically selects the shortest text available from an InfoObject’s text table when displaying a characteristic by key and text. When a text table has a short, medium, and long text field, the short text displayed. If the text table has medium and long descriptions, BEx defaults to the medium text field. The system displays the key and long text only when no short or medium field is in the InfoObject’s text table.

If you want to display a long description along with a characteristic’s key automatically, the short and medium fields must be eliminated when maintaining the InfoObject. If you do this, however, you may face other headaches. Eliminating descriptions means they won’t be available if they become necessary at some future date, forcing you to recreate them. This results in a circular problem because the newly created short and medium fields must be deleted if it becomes necessary to display a characteristic’s key and long text automatically in BEx.

People are also squeamish, with good reason, about eliminating fields from a text table, especially if the table is already filled with data and the InfoObject is part of any fact table or InfoProvider in your system. A lot of work must be done to reactivate and load data into the text table after these text fields are gone. The process includes adjusting transfer rules and communication structures, deleting and recreating the whole text table, and so on.

I’ve discovered a sure-fire way to provide long text descriptions automatically for characteristics displayed with their key without eliminating any fields in the text table. Instead, I use display attributes to exhibit the longer text in BEx reports along with the key, which allows you to make sure your users view characteristic values with meaningful names. My solution has proven itself effective in many projects I’ve been associated with and has satisfied more than one client.

The Solution

Using Administrator Workbench in concert with your R/3 system, you can work around the problem. Let’s take a quick peek at my method, and then I’ll provide you with the details.

For this example, I’ll use the financial statement item InfoObject 0CS_ITEM, its text DataSource position 0CS_ITEM_TEXT, and its InfoSource item 0CS_ITEM. The financial statement item — which is represented by the term ITEM in objects, DataSources, etc. — is the fundamental account assignment of the consolidation system. It forms the basis for consolidation data entry, posting, and reporting in the transaction data for the consolidation InfoCube.

For my solution, you first build a generic DataSource of master data called YITEM_DISP_ATTR_TEXT, while using a view, V_FCIW_FT101, for the extraction that normally feeds the 0CS_ITEM_TEXT DataSource. Next, create a new characteristic, ZITM_ATTR, in Administrator Workbench and assign it to characteristic 0CS_ITEM as a display attribute. Replicating the DataSource YITEM_DISP_ATTR_TEXT into BW and assigning it to the 0CS_ITEM InfoSource creates a new communication structure and new transfer rules. After adjusting the transfer rules to provide proper data delivery and creating an InfoPackage, you load the master data for 0CS_ITEM. This master data is able to display the item characteristic with long descriptions in BEx reports.

Create a DataSource

The first step is to create a generic DataSource for the master data based on the same view, table, and extraction structure as a standard text DataSource. Because different DataSources use different structures to extract data, this step can be tricky.

In the R/3 system, use transaction RSO2 to reveal the Data-Source’s structure or follow the menu path Customizing for the Extractors>Maintain Generic DataSources in BW. Select the Texts button in the Maintain Generic DataSources screen and enter the name of the standard DataSource feeding your characteristic’s text table. To identify the View/Table, the extraction structure (ExtraktStruktur), or the Function Module on which the text DataSource is built (Figure 1), click on the display icon. In my example, the 0CS_ITEM_TEXT DataSource is based

on view V_FCIW_FT101.

Figure 1 View V_FCIW_FT101 feeds the 0CS_ITEM_TEXT text source

Return to the Maintain Generic DataSources screen and set the Master Data Attributes button. Enter the name of the generic DataSource being built and click on the Create button. At the Create DataSource for Master Data attribs. screen (Figure 2), enter the name of the View/Table or extraction structure (ExtraktStruktur) and assign a DataSource tree in the Applic. Component field. You also must fill the three Texts fields (Short description,

Medium description, and Long description), or the system will not allow you to save the new DataSource.

Figure 2 The circled field, and extraction details must be filled in before saving the new DataSource

After saving the settings, the system prompts you with the Create Object Directory Entry screen. From the drop-down menu, select the appropriate attribute for the Development Class field and click on the save icon. The Prompt for transportable Workbench request screen pops up. Although the Request window is filled as the default setting, I advise you to create a Workbench request dedicated to your new DataSource. First, click on the Create request

button, and in the next screen, enter the appropriate description and save it (Figure 3).

Figure 3 Create a new Workbench request for the new DataSource

The next screen allows you to choose which fields in your new DataSource will be available to the InfoPackage.

Check the applicable fields in the Selection column of the Data Selection screen (Figure 4). The checked items appear for selection when the InfoPackage is created in Administrator Workbench.

Figure 4 Set the fields in your new DataSource available to the InfoPackage

The new generic DataSource has now been created and packed and is ready to be transported to your test and production systems. It feeds the display attribute for the characteristic value that requires the longer name and key. In my example, the name of the master data DataSource is YITEM_DISP_ATTR_TEXT. Later, it will be mapped to the display attribute ZITM_ATTR, which is created next. Replicate the newly created DataSource in Administrator Workbench to activate it.

Create ZITM_ATTR

After activating the new DataSource, create a custom characteristic InfoObject (ZITM_ATTR) in Administrator Workbench. Double-click on the new InfoObject for access to the screen to customize the characteristic (Figure 5). On the General tab, enter CHAR - Character String in the Data Type field and 60 in the Length field to set a 60-

character maximum for the string. Check the Lowercase letters box.

Figure 5 Custom characteristic properties

Note! If you don’t check the Lowercase letters box, the system will not allow you to load data unless all of characters in the long text field are converted to uppercase letters. BW forces you to use the uppercase convention in technical names such as TOUPPER in the transfer rules, which convert all characters to uppercase when they are displayed.

In the Master data/texts tab, uncheck the With master data and With texts boxes. These are set by default when the InfoObject is created, but are not needed for this custom characteristic. Leave the other tabs in the screen intact and press Ctrl+F3 to activate the InfoObject.

ZITM_ATTR must be assigned before it acts as the display attribute for the characteristic 0CS_ITEM. Originally, 0CS_ITEM had no attributes, so you must set the corresponding check box in the Master data/texts tab to create a

master data table, which allows access to the Attributes tab (Figure 6).

Figure 6 Assign ZITM_ATTR to 0CS_ITEM as a display attribute

Assign DataSource YITEM_DISP_ATTR_TEXT to the business content InfoSource 0CS_ITEM. As a result, a new set of transfer rules is created along with a new communication structure.

Now, make the final connection among all parts of the puzzle by mapping InfoObject ZITM_ATTR to the TXTLG field in DataSource YITEM_DISP_ATTR_TEXT. Map the standard long text field (TXTLG) coming from the generic DataSource to InfoObject ZITM_ATTR inside the transfer rules screen. In BW, the corresponding InfoObject is

0TXTLG (Figure 7).

Figure 7 Text DataSources use text fields TXTSH or TXTLG represented by InfoObjects 0TXTSH and 0TXTLG in BW

Note that the Short and Long Description fields are part of text DataSources only. The system recognizes the fields TXTSH for short text and TXTLG for medium and long text. In BW, these always map to InfoObjects 0TXTSH for short text and 0TXTLG for medium and long text.

View V_FCIW_FT101 feeds the generic master data DataSource YITEM_DISP_ATTR_TEXT in the example in Figure 7. The view was designed to feed the standard text DataSource 0CS_ITEMTEXT and contains the standard TXTSH and TXTLG description fields, so the system recognizes them regardless of the DataSource type.

Create an InfoPackage and load the data. If the text in your characteristic is language dependent, enter the language at the InfoPackage selection screen. If you fail to take this step, you risk receiving an error message during the load process indicating that you are attempting to load duplicate records. You also could receive an error message about invalid characters contained in the text. If this occurs, you must use transaction RSKC to permit extra characters in your BW system.

The last step is to insert the characteristic you want to display the key and longer name for into one of the reporting areas inside the BEx Query Designer. In this example, characteristic 0CS_ITEM is inserted into the rows area.

Right-click on the characteristic and choose Properties. In the Properties for Characteristic Item screen, enter key in the Display As field and click on the OK button, which returns you to the previous screen. Right-click on the

characteristic again and select Attributes in the menu. You will see your newly assigned attribute (Figure 8), which allows the long text of the characteristic to be displayed along with its key.

Figure 8 The newly assigned attribute to be displayed in report

Display Text Longer Than 60 Characters in Web Queries  

by Nitin Kulkarni and Vikas Babbar, Patni Computer Systems

All InfoObjects have a length limit of 60 characters. However, users often want access to longer text. Discover a workaround to display text of more than 60 characters in Web queries.

Categories: ABAP, BEx, Reporting, Web Application Designer

Key Concept

A Business Server Page (BSP) application is a complete functional application similar to a classic SAP R/3 transaction. Rather than viewing these applications using SAPGUI, users view them in a Web browser. HTTP or HTTPS access the application across the network, which means that you can use standard products such as firewalls and proxy servers.

BW users often turn to BW-based Web queries to display document-level details. For example, vendors often access BW reports through the Web and need to view long text stored on purchase orders or delivery documents. However, length limitations on BW InfoObjects restrict how much data users can display in BW Web queries. You can display text greater than 60 characters in BW Web queries by enhancing the context menu of Web queries and using a Business Server Page (BSP) application in the back end.

SAP Web Application Server includes BSP, a page-based programming model with server-side scripting as well as server page technology for developing, designing, and implementing Web applications. Server-side scripting enables

direct access to all elements in the application server (such as function modules, database tables, ABAP Objects, and remote function modules).

To display text greater than 60 characters in BW reports, you must enhance the context (right-click) menu on BW Web queries by modifying the Web template to call the BSP application. In turn, the BSP application calls a remote function module in R/3 to retrieve the text and present it in a pop-up window. You must set up a separate BSP application for each field (such as delivery number) for which you want to display the enhanced context menu. Then, all users see the new option in their context menu.

Using this technique, you can avoid loading long text in multiple BW InfoObjects because you retrieve the data directly from R/3. Therefore, you avoid any loading problems (such as taking text into multiple InfoObjects and problems in dealing with valid character sets) due to permitted character checks. In addition, BW only retrieves necessary data for display. Users who do not have access to R/3 (e.g., external vendors) can see necessary information in BW Web queries through SAP NetWeaver Portal. We developed the application on BW 3.5, R/3 4.6, and SAP Enterprise Portal 6.0. It still worked after upgrading to SAP NetWeaver 2004s and mySAP ERP Central Component (ECC) 6.0. We expect our technique would work for any version of R/3 4.6 and up, BW 3.0B (and above), and Enterprise Portal 6.0 (and above).

Let’s examine a business scenario and walk through a step-by-step method to display long text in BW Web queries.

Business Scenario and Steps

Company X sends parts for repair to its vendors. Vendors have access to run BW queries through SAP NetWeaver Portal. Necessary authorizations are in place to allow vendors to view data only in BW reports that relate to them. The text of the deliveries stores some useful information and vendors want to view this information in their BW Web query. To do this, they must follow these steps:

Step 1. Create a BW Web query. Create a BW query in BEx and create a Web template from the BEx Query using Web Application Designer (Web AD). When you launch this query in the Web browser, the query displays a selection screen like any standard BW Web query. When you enter the desired selection such as vendor number or delivery

date, the Web browser displays the output. In Figure 1, we ran the query using the vendor number and delivery date selections to restrict data to one month for one vendor. This Web query displays the delivery number and other details such as item number, delivery quantity, and confirmed quantity.

Figure 1 Web query displays the delivery number and other details

Step 2. Make HTML code enhancements in the BW report Web template. After creating the Web template, you need to change generated HTML code to add to the context menu that appears when you right- click on a BW report field. Also, you need to add code to read the delivery number where you place the cursor. In the example, we need to read the delivery number, because in the scenario report users want to view long text stored against the delivery.

Add the code shown in Figure 2 in the object tag of the Web template. Access the object tag by opening the Web template you created for the BW report in step 1. In the HTML tab, you can see the tag. In Figure 2, notice the circled lines. The first two lines that you insert enhance the context menu with an option called Display Long Text. The third line calls the DisplayText function when users select the Display Long Text action. The fourth line indicates that this is the first customer parameter. For the nth customer parameter, the value changes to n and parameter names end with n (e.g., CMENU_FUNCTION_n, where n is the customer parameter number). The fifth inserted line indicates the field on which to add the context menu on the report. The sixth line indicates that the enhanced option is visible while the seventh line indicates that the enhanced menu appears at the bottom. In Figure 2, it is the delivery number (e.g.,

InfoObject 0DELIV_NUMB).

Figure 2 Add this code to the HTML tab of the Web template

The code in Figure 2 added an extra entry to the parameters of the Web template called Display Long Text. When users click on this option, BW passes the control (it calls the function display text) to the JavaScript function DisplayText.

The function DisplayText contains the code in Figure 3 to call the BSP application in BW. We’ll explain how to create BSP applications through ABAP Workbench (transaction SE80) later. The code in Figure 3 shows the

JavaScript function. Look for the <HEAD> tag in the HTML coding. This code calls the Web page http://WebaddressXX/z_read_text/ select.htm to pass the value of the delivery number through parameter 1. (Note that WebaddressXX stands for the server address.) At this point, the control is passed to the BSP application page in BW. The BSP application creates, writes, and generates this page (http://WebaddressXX/ z_read_text/select.htm). This code also controls the size of the pop-up window (here, 480 x 325) as well as properties such as the scrollbar.

function DisplayText(parameter, cell_type, filter, parameter1,parameter2,item, dataprovider, x, y) {

var url;var url1;var url2;var flag;flag = false;

url1 = (SAP_BW_URL_Get()+ "&CMD=BOOKMARK");createCookie('URL1',url1,1);

url = "http://WebaddressXX/z_read_text/select.htm?&var1=parameter1&gv

_value1=" +parameter1;

window.open(url,'mywin',"width=480,height=325,menubar=0,scrollbars=0,resizable=0"); var indx;var found;}

Figure 3 JavaScript function DisplayText

Note

For more details, read the how-to paper about enhancing the context menu (How to Enhance the context menu in Web Applications) on the SAP service Web site https://websmp105.sap-ag.de/bi under Services & Implementation>HOW TO…Guides>Guide List SAP BW 3.0B/BW 3.1 Content.

Now, when users execute a query, BW adds Display Long Text to the end of the context menu (Figure 4).

Figure 4 Right-click on an entry in the Delivery field to see the Display Long Text option

Step 3. Create function module Z_READ_TEXT in R/3. Z_READ_TEXT calls standard function module READ_TEXT. We could not use SAP-delivered function module READ_TEXT because it is not compatible with Remote Function Calls (RFCs) and needs to be called from BW. In your R/3 system, go to transaction SE37, create function module Z_READ_TEXT, and maintain the following settings:

Attributes tab: Select processing type Remote-Enabled Module

Import tab: Add import parameters CLIENT, ID, LANGUAGE, NAME, OBJECT, and ARCHIVE_HANDLE

(Figure 5)

Figure 5 Enter these import parameters to the function module

Tables tab: Enter the LINES parameter (Figure 6)

Figure 6 The LINES table passes results (e.g., text about the delivery) back to the calling program

Source code tab: Add the code in Figure 7

CALL FUNCTION 'READ_TEXT' EXPORTING* CLIENT = SY-MANDT

id = ID language = language name = name object = object

* ARCHIVE_HANDLE = 0* LOCAL_CAT = ' '* IMPORTING* HEADER =

tables lines = lines

* EXCEPTIONS* ID = 1* LANGUAGE = 2* NAME = 3* NOT_FOUND = 4* OBJECT = 5* REFERENCE_CHECK = 6* WRONG_ACCESS_TO_ARCHIVE = 7* OTHERS = 8 .ENDIF.ENDFUNCTION.

Figure 7 Code to call standard function module READ_TEXT to get text about the delivery. The LINES table stores the text and BW passes it to the calling program, the BSP application in BW.

Step 4. Create a BSP application. Write a BSP application using ABAP Workbench, transaction SE80. In this

example, we developed an application called Z_READ_TEXT (Figure 8).

Figure 8 Choose BSP applications from the drop-down menu to create the application

Each BSP page includes several areas (Figure 9). The Layout tab contains the code that dictates the page’s

appearance. The Event Handler tab manages user actions (events) on the page. The Page Attributes tab lists all data parameters the page uses and those that the system transfers to successive pages.

Figure 9 The different tabs: Properties, Layout, Event Handler, and Page Attributes

Event Handler: OnInitialization Event

The system processes the OnInitialization event handler directly after the BW report calls the page. In our example, initialization is run when the request from the Web report accesses the page (i.e., when users right-click on the context menu and click on Display Long Text). The OnInitialization event handler implements data retrieval. The Page Attributes tab stores the data so that the layout and other event handlers can access it.

The OnInitialization event calls the RFC-enabled function module Z_READ_TEXT created in step 3. Figure 10 shows ABAP code to customize the event handler to retrieve the delivery document text from R/3 using function module Z_READ_TEXT. The variable l_rfcwa stores the R/3 destination. This function module passes ID ZBUY,

language EN, name gv_name (delivery number), and object VBBP.

Figure 10 ABAP code to customize the event handler to retrieve the delivery document text from R/3 using function module Z_READ_TEXT

The RFC from the function module uses the delivery number from attribute value gv_value1 passed to the BSP page through the URL of the BW Web query and fetches text for the delivery number. The text is passed by BW to the automatically defined page attribute gt_line in the form of an internal table. This page attribute is read internally in BW on the layout of the page and displays the text in a pop-up window.

In the Page Attributes tab, specify the page’s data parameters (Figure 11). Declare variables gt_line and gv_value1 as automatic page attributes by checking the Auto check box. These attributes automatically get values from calling URL or via the navigation process from other pages. Here, variable gv_value1 receives the delivery

number from the Web report and gt_line stores the text read from R/3. You use page attributes to store data

that the event handler determines. You can use the page attributes to make the data accessible to layout processing and the remaining event handlers.

Figure 11 Specify the page’s data parameters in the Page Attributes tab

Layout

You control page display using server-side scripting in the layout. To ensure clean development, you must separate layout and presentation from processing logic. Therefore, scripting for the static details of a page is part of layout processing, while the dynamic processing steps are set in the different event handlers.

Figure 12 specifies the page title Long Text for the Delivery with the delivery number appearing adjacent to the title. (The variable gv_value1 stores the delivery number.) You also can specify the text color. From the next line

onward, the code lets you display the long text for the delivery number passed from the OnInitialization event handler.

Figure 12 Specify the page title Long Text for the Delivery

Note

You can read SAP documentation to further understand BSP coding and details: http://help.sap.com/ saphelp_nw2004s/helpdata/en/e9/bb153aab4a0c0 ee10000000a114084/frameset.htm.

Results

When users right-click on the document number after running their query, they see the enhanced menu with Display Long Text as the last option (as Figure 4 shows). The selected delivery number is passed to the BSP application.

The BSP gets the text by calling RFC in R/3 and displays text in the pop-up window (Figure 13).

Figure 13 A pop-up window appears with text associated with delivery. You can see that there is no limit on the number of characters displayed.

Note

If you would like to learn more about creating layouts, SAP Education offers this class in the US: BW306 BI – Enterprise Reporting, Query and Analysis (Part II). For more information, go to www.sap.com/useducation.

Distribute Pre-calculated Web Reports More Quickly Using Value Sets  

by Satish Chalasani, Independent BW/SEM Consultant

Some reports require two queries where the second query needs the results of the first. In situations where such a report must be run repeatedly for distribution to many people, this can result in slow performance due to a large number of database accesses. By using a pre-calculated value set rather than a pre-query variable, you reduce the number of database hits and improve performance.

Categories: BEx, Event and Process Chains, Reporting

Imagine this scenario: You have a requirement to create an Excel/Web query that answers the question, “What is the value of orders for a group of customers during a certain time period?” The data is in an InfoCube that contains customers, ordered quantity, and sales value at the header and item levels. The resulting report needs to be sent by email at the same time each month to the sales representative responsible for these customers.

Your only option to send the report automatically at a scheduled time is to run it in batch mode. The process appears simple: A Web report based on the query is run offline using BW's Reporting Agent, and the results are downloaded using the Download Scheduler found in BW 3.0B. The query results are then delivered by email as an Excel/Web report attachment to the inbox of the sales representative or the customer.

You have two choices for calculating variables in batch for your query: pre-query variables or pre-calculated value sets. The two are similar, in that both allow you to perform an initial query and use those results as variables in a second query. With pre-calculated value sets, however, the values for the variable are pre-calculated and stored. They can then be shared across multiple subsequent queries, whether online or in batch mode. A pre-query variable calculates the variables for the initial query for the first and every subsequent report request. For reports like the one in my example, the pre-calculated value set can significantly increase performance by dramatically reducing the

number of database accesses needed. Figure 1 illustrates the differences between pre-query variables and pre-calculated value sets.

Figure 1 With a pre-query variable, a pre-query asks for the top 10 customers from the master data table in the database. The second, main query then uses that list to match the customers to receivables using data in an InfoCube. This happens at run-time for every person who should receive a report every time a report needs to be sent by batch. With the value set, the first of the two queries is executed once and stored as pre-calculated data. This happens only once, and not at run-time, no matter how many people receive reports. The second, main query then uses that pre-calculated data for every subsequent request.

For example, say you want to understand the relationship between your top 10 customers and their receivables. You need to write two queries—the first gives you the top 10 customers from the sales InfoCube, and the second gives you the receivables information for the top 10 customers. The second query uses a replacement path variable with the results of the first query. In this case, the first query (top 10 customers) has to be executed before the second query has the list of customers to select their receivables. If this method of analysis is used often and by several people, performance can be compromised if you use a pre-query variable to get the results for the first query. If you use a pre-calculated value set to get the results for the first query, they can be shared by several users and reports.

BW has had the value set query capability since Release 2.1C, but few BW practitioners use it because it is not well understood and some of the settings can be tricky. Using the example above, I'll walk you through the step-by-step process to create a value set query and then deliver the final query results in batch using Reporting Agent and Download Scheduler. I will use data from InfoCube 0D_SD_C03, which is part of the delivered SD (Sales and

Distribution) module demo content in BW. It is not necessary to change the data model of the InfoCube for this example.

Step 1. Create a Query Create a BW query and place characteristic Sold-to party (0D_SOLD_TO) in the Rows section of the Query Designer screen as shown in Figure 2. I will use this characteristic through the rest of this example. Save the query and execute it to make sure it is producing the results as expected. Since you did not use any variables or restrict

Sold-to party, it should produce a report for all sold-to parties in the InfoCube.

Figure 2 Create a BW query in Query Designer

Step 2. Create a Value SetYou want to run this report for a particular customer group, which you want to calculate in advance (or in batch) to make it available for the sales query. You can use any criteria to determine the customer list. My example uses the country attribute of the sold-to party (0D_SOLD_TO). I want a list of all sold-to parties in the U.S. To follow along, create a value set and populate it with values based on this specific criteria.

Go to the Reporting Agent section of the Administrator Workbench (transaction code RSREP). Here, you create a value set for 0D_SOLD_TO with the value for the sold-to customer country as USA. Navigate to the Value set area and choose Value set. Here you can create a value set for any characteristic. Click on the Create new setting button and enter the technical name of the value set and a brief description. I used Z_USCUST for the technical name and American Customers for the description.

Select the Parameter tab and enter the name of the characteristic for which you want to create a value set

(0D_SOLD_TO), as shown in Figure 3. You need to enter the name of the query that you used to generate the values in the value set—all sold-to-parties in the U.S. In the BEx analyzer, I created the query Z_CUSTOMERS_US_VALUESET under InfoProvider 0D_SOLD_TO to provide the desired customer list for

the value set. The query doesn't need any key figures, but be sure to add the characteristic for which you are trying to calculate the value set. You can also use conditions or a complex formula variable in this query to produce the desired list of values for 0S_SOLD_TO. If your value set query needs a variant, specify the variant name.

Figure 3 Enter the name of characteristic for which you are creating value set

Now save and activate the value set. After activation, BW generates the value set and creates a table named /BIC/OB00000008 for it. This table stores the surrogate IDs (SIDs) of the characteristic values for this value set. The value set contains only the SIDs that point to the actual characteristic table with values for the characteristic.

Tip! In BW Release 3.0B with support pack 7, you can schedule this InfoPackage using a process chain (transaction code RSPC). To populate the value set, you ideally want to schedule this after a succesful load of the data target on which your value set query is based. All the Reporting Agent jobs (value sets, pre-calculating Web templates) can be linked easily using process chains.

Step 3. Schedule the Value Set in a Scheduling PackageOnce you have defined the Reporting Agent settings, you have to assign them to a scheduling package for the background run. You want to calculate the values in the value set after each master data load to 0D_SOLD_TO to keep the data in the value set current. Create a new scheduling package and give it a name. The scheduling packages are displayed on the right side of the Reporting Agent. Since this name appears on the Job Overview screen, you should follow your job-naming conventions or just give it a meaningful name. In this case, the name of the job in Job Overview (transaction code SM37) will be RAZ_CUSTVS_JOB. Note that the names of all Reporting Agent jobs have the RA prefix.

Once this value set has been generated and run, you can see an overview of how many values it has generated, which query was used, when the generation took place, and if it is active in table RSRVTABLEDIR (Figure 4). Use

transaction code SE11 to view this table.

Figure 4 View a value set's status using table RSRVTABLEDIR

Step 4. Create a Variable for 0D_SOLD_TOTo use this value set in your query, you next must create a variable for 0D_SOLD_TO. Use the BW Variables Wizard and create a new variable for characteristic Sold-to party. My example uses Z_VSUS for the variable name. Click on

the Next button and choose a variable that represents a precalculated value set (Figure 5).

Figure 5 Choose a variable for the pre-calculated value set

Click on Next again and specify the name of the value set (Z_USCUST). Do not enter the name of the table generated by the value set. Now save the variable and BW automatically knows to refer to the SIDs created for the value set. This variable can have one or more values depending on the pre-query used to generate the value set.

Step 5. Create a Query Using the VariableNow you can create a query using this variable. Go to the Query Designer and select the variable Z_VSUS created in

the previous step to restrict Sold-to party (0D_SOLD_TO). Save the query and execute it. If you have set the variable to be ready for input, it will appear in the selection screen with the default value set. You can change the default if

necessary. Click on the drop-down menu for the variable shown in Figure 6, and you will see all the available value sets for this characteristic. This technique can also be used to supplement variants in a query.

Figure 6 Available value sets for American customers

Execute your query. As Figure 7 shows, the results generated are only for the values in the value set. Notice the text next to Sold-to party in the text elements; it displays complex selection, which means it was not entered by a user.

Figure 7 Value set query results

You now have all the steps for writing queries using value sets. The following steps show you how to deliver the reports generated from those queries to the sales rep who insists on receiving them only by email.

Step 6. Create a Web TemplateThe report will be delivered to the sales rep responsible for the U.S. as an Excel attachment. To do this, the first step is to create a Web template using the query you created in the previous step. You use the Reporting Agent to pre- calculate this Web template. Launch the Web Application Designer and create a Web template with the Table Web item. Use the query created in the previous step as the DataProvider for the Table Web item. Be sure to give a name to the data provider (I used SALES_VS_US); the downloaded files will be prefixed by this name (e.g., SALES_VS_US_00001.XLS). Execute the template and you should see the results in Excel format as shown in

Figure 8.

Figure 8 Query results in Excel format

Step 7. Pre-calculate the TemplateTo send this report by email, you must pre-calculate the template using the Reporting Agent. Go to the Reporting Agent (transaction code RSREP) and go to the Web Templates area. In the first screen, you will see all the roles

assigned to you and the Web templates in those roles. Open your Favorites folder and find the template created in the previous step (assuming that you have saved it there).

Figure 9 Enter a technical name and description for the Web template

Right-click on the Web template and select New setting. Give it a technical name and a description, as shown in Figure 9. Click on the Parameter tab and specify what formats of the report need to be pre-calculated. If you just want to pre-calculate an Excel report, select Excel. In some scenarios you want to send the pre-calculated Excel file by email and also give internal users access to the pre-calculated data via the Web. In Figure 10, I've chosen both Excel and HTML for the Web browser options. Both options pre-calculate the data, so there is no need to check the

Data option.

Figure 10 Specify the formats in which you want the reports pre-calculated

You have to specify all the users and roles that need access to the pre-calculated data. Since you are going to use a value set to determine the value of the variable for your query, specifying a control query is not necessary. Save and activate your Reporting Agent setting. Now you need to create a scheduling package to execute this Web template in the background. You can use process chains to schedule this package. Most likely you want to schedule this package after a data load to the InfoCube or the ODS against which the query is executed. The name of the job will

be the name of the scheduling package prefixed by RA. The process chain shown in Figure 11 explains how to automate the pre-calculation of Web templates once the initial setup is completed.

Figure 11 Process chain for automating pre-calculation of Web templates

Tip! If you are pre-calculating many Web templates, watch out for the size of the cluster table RSIXWWW. This table needs to be reorganized on a regular basis. You can use the report SRA_CLUSTER_TABLE_REORG to do so.

Step 8. Make the Pre-calculated Data AccessibleOnce the package is executed, you can access the pre-calculated data by adding the parameter DATA_MODE = STORED or STATIC to the Web address. DATA_MODE = STATIC or STATIC_HYBRID produces the same results as STORED or STATIC, the difference being this mode will execute the query if there is no pre-calculated data available.

http:///sap/bw/BEx?sap-language=EN&bsplanguage=EN&cmd=ldoc&TEMPLATE_ID=Z_OFFLINE_US&DATA_MODE=STORED

Tip! As of BW 3.0B support pack 9, you can reduce the time it takes to access a pre-calculated Web template by using this URL instead of the above. The old procedure required two roundtrips to the Web application server; the new procedure needs only one trip to the server.

You can also see the results in the Administrator Workbench using transaction code RSRAPS. Here you see the results of pre-calculation for every time the report was pre-calculated. You can also export the HTML or Excel file to your desktop or send it by email by right-clicking on it and following the menu options.

Tip! Regardless of which data mode the Web template is executing, a login to BW is required and all security checks are implemented.

Step 9. Download the Files Sending this report by email to the sales representative is a two-part process that you can automate with good results. First, use the BEx Download Scheduler to download the precalculated report to the BW server. The BEx Download Scheduler is a tool that simplifies the task of downloading the pre-calculated HTML and Excel files from the BW server. The BEx Download Scheduler is delivered as part of the BW 3.0B front-end software. SAP says that the Download Scheduler is compatible with prior releases of BW.1 Navigate to Start>Programs Business

Explorer>Download Scheduler. Log into your BW system at the prompt. The next screen, Figure 12, shows all the pre-calculated packages assigned to you. If you don't see any packages here, go back and make sure you've specified a role or user name in the Web template setting.

Figure 12 All pre-calculated packages assigned to you

Click on Next and select what you want to download from the screen shown in Figure 13. I have selected both Excel and HTML files to be downloaded to the BW server. You can download to any network resource or to your desktop. If your BW system is running on Microsoft Windows, you should be able to easily map the BW server to a network drive. If you are on a UNIX system, which is what I'm using for my example, you need software (like Samba) to map the UNIX directories to Windows NT. Your UNIX system administrator best does this job.

Figure 13 Selection screen for reports to download

In the next step you can choose to download immediately or schedule the download. If you want to do this on a regular basis, you can schedule the download in regular intervals.

Tip! The scheduled task to download reports is controlled by the Windows Task Manager and will appear under the directory C:/WINNT/TASKS if you are using Microsoft Windows. If you are using an external job scheduler, you can probably integrate this job into your BW job schedule.

Tip! Scheduling in the BEx Download Scheduler refers to the point in time the pre-calculated reports are downloaded from the BW server to the desktop PC. You cannot schedule scheduling packages in the Reporting Agent using BEx Download Scheduler.

Tip! You can only download those pre-calculated files for file formats and devices that were scheduled in the Reporting Agent. If you select a file format or device in the BEx Download Scheduler that is not selected in the reporting agent settings of the pre-calculated Web template, you cannot download any files.

Step 10. Send the Report by EmailNow that the files are downloaded, you can send them by email to an individual or a distribution list. Now you can use either the SAPConnect functionality, a UNIX script, or a Windows-based program to automate sending email messages. I will demonstrate how to use SAPConnect to send the downloaded Excel report by email.

I'm assuming that you have already configured SAPConnect—a process beyond the scope of this article. You can configure SAP's Web Application Server 6.10 onwards for SMTP, a standard email transfer protocol. You need two programs to send email from BW, which I've provided. The first program checks if a file has been downloaded, and the second program sends the file by email and then deletes it after it has successfully been sent. You can find the source code for both of the programs on the BW Expert Web site (www.BWExpertOnline.com/docs/download.html).

The process chain shown in Figure 14 shows how to automate the use of these ABAP programs.

Figure 14 Process chain for automating the sending of reports using the ABAP programs

If you have to send this report every month, schedule the Download Scheduler to run on the first day of the month. The job to look for the file can be scheduled in BW to run every hour on the first day of the month. As soon as it finds the file it raises an event and this event triggers the email job, which emails the file and deletes it. You can also combine these two programs into one by checking for the file in the email program. To reuse these programs for emailing different files, create variants with the file names.

1 If you aren't on BW 3.0B, you can find Download Scheduler on the SAPGUI version 6.20 CD. You may also download it from service.sap.com/swcenter.

Empower Your End Users with Accurate BW Reports  

by Philip Botterill, SAP NetWeaver Application Consultant

Use standard BW functionality to show end users the accurate last load date and time for each report. This saves time for end users, who can see at a glance whether or not they need the report information.

Categories: ABAP, BEx, Reporting

Key Concept

A class is a type of ABAP program. In the context of my solution, I use the class to change the cell contents of the results table. More specifically, the class changes the cell content of the status characteristic. Instead of displaying the key code from the status ODS object, the table interface passes an image string that converts to an icon in the Web application.

In my example, BW creates a report to display the characteristic value as a traffic light icon (for example, a green traffic light instead of displaying the number 10). This helps the end users visualize the data in a more intuitive way.

End users at my company often ask, “How recent is the data that I see in my report?” They want to know when BW extracted data from its source systems. If you have developed Web-based reports, you may have seen the “status of data” information that you can include as part of a text element Web item.

However, this information has a number of limitations. First, users only see the information after they access the report. If you have not loaded the data into BW since the users last looked at the report, they can’t realize it until they’ve spent time to open the report. Secondly, complex BW system architecture involving ODS objects, InfoCubes, and MultiProviders can make the SAP standard “status of data” option misleading.

For example, a MultiProvider can have many different InfoCubes from which it can access data. A BEx query built on this MultiProvider might only access data from some of these underlying InfoCubes. The SAP standard “status of data” information displays the date/time of the underlying InfoCube loaded the longest time ago. For example, InfoCube A was loaded on January 1, 2005, at 9:00, InfoCube B on January 9, 2005, at 7:00, and InfoCube C on January 9, 2005, at 9:00. Because InfoCube A contains no key figures for this BEx query, but is part of the MultiCube,

the date and time that the user sees are incorrect (Figure 1).

Figure 1 In this MultiCube, the date and time that the user sees are incorrect

Note

If you have developed BEx workbooks, you can display the “status of data” information via the standard BEx Toolbar Layout menu path Text elements>Display all.) For more information, refer to http://help.sap.com/saphelp_nw04/helpdata/en/f1/0a55abe09411d2acb90000e829fbfe/frameset.htm.

I’m going to show you how to provide end users with an accurate last load date and time for the information that each report contains. End users see a single status report listing all BI reports, along with the corresponding last load date

and time. If your business has defined KPIs (e.g., a report loaded daily), you can even display a traffic light status for those particular reports. Both end users and BW system administrators can use this status to quickly identify where problems lie in the system and what reports those problems impact. The solution leverages standard BW technology and works for BW Release 3.0 and up, including SAP NetWeaver 2004s.

Key Components

The solution involves five key components. Other elements of the solution include flat files, master data, and request tables (Figure 2).

1. A mapping ODS object that you load with the mapping of reports to data targets (such as ODS objects, InfoCubes, or InfoObjects). The ODS object also contains the command that BW should update these data targets, as well as some other technical information.

2. A BEx-enabled ODS object that takes data from the mapping ODS object and determines the true last load date and time by reading the standard, SAP request monitor tables. This is the so-called status ODS object.

3. Some ABAP coding that updates rules into the status ODS object. This ABAP coding determines a number of interesting status codes such as loaded on time, not loaded on time, and monitor status. (SAP documentation also refers to monitor status as QM status, status of request, and status in the monitor.) Although end users cannot see these codes, BW administrators can display them to help resolve problems that impact the availability of reports.

4. A BEx query that presents the data the mapping ODS object stores.

5. A Web template that calls the table interface to present a traffic light icon based on the report’s status.

Figure 2 Key components of the BI report availability solution

The end users see an output as shown in Figure 3. Remember, you decide how much or little of this information you want to show in the end report. I’ll show you how to create two different versions of the Web template, an expert version for BW administrators (showing the technical information relating to a report status), and a standard version (showing only a date/time and traffic light) for the wider user community. You can follow the same steps for both versions, except the standard version requires one additional step.

Figure 3 Status of data report

Mapping Exercise

I will take you through these steps in more detail. Before starting on the system development, you should do the following:

1. Make a list of all the reports you would like to output in the final status report 2. Analyze and record the data flows that supply data to each of these reports

I recommend that you record these data flows in Microsoft Excel as Table 1 shows.

Report (30)

Data targets (30)

Comm. structure

(40)

Data target (type) (1)

Data load

frequency (17)

Daily Sales Report

InfoCube B Comm Structure x C 24

Daily Sales Report

InfoCube C Comm Structure y C 24

Daily Sales Report

ODS Object Q Comm Structure z O 24

Table 1 Record the data flow. Numbers in the top row indicate the maximum size of that field in the flat file.

The Data load frequency column should contain a number that shows how often to update the data target. This is a frequency in hours. If BW should update the data target daily, the value is 24. If it should update the data target weekly, enter a value of 168. Be sure to include all relevant data targets for each report in the file.

Remember that the data target column should only contain true data targets (objects physically loaded with data) and not other InfoProviders, such as MultiProviders or InfoSets. For example, if you build a report on a MultiProvider, you only need to include the relevant data targets in that MultiProvider (not the actual MultiProvider itself).

You also should include all data targets relevant in a data flow that is supplying data to a report. Figure 4 illustrates a possible data flow scenario in which BW reports an accurate last load date, time, and status for a BEx query. In this example, the BEx query’s technical name is YQUERY1. The corresponding mapping file must contain at least one

entry in the report column for YQUERY1.

Figure 4 Mapping for report availability solution

Three different data targets are involved in the data flow pertaining to YQUERY1. These data targets are two basic InfoCubes and one ODS object. The InfoCube’s technical names are YINFO1 and YINFO2. Both InfoCubes have their own update rules. More specifically, the ODS object YODS1 feeds YINFO1, and the communication structure YCOMM2 feeds YINFO2 directly. You therefore must add two entries to the corresponding mapping file for these two InfoCube updates. You can see these two entries on the last two lines of the corresponding mapping.

Note that the technical name for the communication structure, which loads InfoCube YINFO1 is 8YODS1 (i.e., the technical name of the source ODS object prefixed with an 8). You must include an entry in the corresponding mapping file for the data loaded into ODS object ODS 1 (technical name, YODS1). The communication structure YCOMM1 feeds this ODS object directly. The first line of the corresponding mapping shows the entry for this part of the data flow.

You should also note the entries in the Data target (type) column of the corresponding mapping file. The entries relating to the updates to the InfoCubes require a C in this column, and the updates to ODS objects require an O in this column. These entries ensure that the status check the system conducts when loading the data from the mapping ODS into the status ODS performs all relevant checks. For example, a status check for an ODS object includes a data activation check, but the same check is not required for an InfoCube. Conversely, the status check for an InfoCube includes an aggregate rollup check, but an ODS object does not require the same check.

Figure 4 shows the corresponding mapping for just one query or report. In a production system, this mapping flat file likely contains many more entries, as you may want to check the status of many BW queries. If, for example, you have a second BEx query (YQUERY2) that uses exactly the same data flow, then you can simply copy and paste the three lines in the mapping flat file and change the new report cells to YQUERY2. Once this mapping is complete you

have the data to input into the mapping ODS object. Save the Excel file in a CSV format. To convert the file extension from .xls to .csv, use the menu path File>Save As…, name your file “mapping.csv”, and choose the type CSV (Comma delimited).

Create Report Availability Solution

Now, I’ll show you how to build the necessary objects in the BW system.

Step 1. Create InfoObjects

First, create some custom InfoObjects to use as building blocks. I’ll also use some SAP standard business content InfoObjects (with the prefix 0). You might need to install these in your system, or you may have already installed them. I find that the quickest way to create InfoObjects is to run transaction RSD1. This takes you directly to an InfoObject maintenance screen. Table 2 contains a list of all required InfoObjects and their settings. Create each

InfoObject with these settings (Figure 5). Note that the system automatically populates the Data element field based on the technical name of your InfoObject.

InfoObject technical name

InfoObject Short and Long Description

Data Type Length

YREPORT Report Char 30

YBISTAT Status Char 2

YTARGET Data target Char 30

YTARGTYPE Data target type Char 1

YFREQ Frequency of upload Key figure 17

YDLL Date last loaded Char (ref 0DATE) 8

YTLL Time last loaded Char (ref 0TIME) 6

0CALDAY Business Content    

0TCTCOMSTRU Business Content    

0TCTSYSID Business Content    

0TCTREQUID Business Content    

Table 2 Create these InfoObjects with the settings shown here

Figure 5 Create each InfoObject using these definitions

You must manually maintain text master data for InfoObject YBISTAT. This helps explain the status codes to the BW system administrators. Go to the master data maintenance screen in Administrator Workbench (RSA1). Select Modeling area in the navigation window, then select the InfoObject from the functions window and locate the InfoObject in question via the standard search function. Choose the Maintain master data option. You should make

the text entries for the status codes one at a time (Table 3).

YBISTAT

Description

10 Loaded on time

20 Load in QM error

30 Not loaded on time

35 Not loaded

40 Rollup incomplete

50 Change run required

60 InfoObject inactive

Table 3 Maintain text master data for InfoObject YBISTAT

Step 2. Create ODS Objects

Now create two ODS objects using the newly created InfoObjects. To create the ODS objects, use transaction RSDODS (or RSAl>Modeling>Create ODS Object). Note that the status ODS object has the BEx flag enabled

(Figure 6).

Figure 6 Define the status ODS object

For the status ODS object, enter the ODS object’s technical name, YSTATUS. Click on the Edit button. Enter Status ODS and click on the Create button. On the right side of the screen, expand the Settings area. Make sure that a check mark appears to the right of the BEx Reporting entry, as shown in Figure 6. This may be the default setting depending on your system version. Right-click on the Key fields folder and choose the Insert InfoObjects option. Enter the InfoObject’s technical name YREPORT and click on the continue icon (green check mark). Expand the Key fields folder to check that this InfoObject is now part of the ODS object.

Next, right-click on the Data Fields folder and choose the Insert InfoObjects option. Enter the InfoObject technical names YBISTAT, YDLL, YTLL, 0TCTREQUIDB, and YTARGET. Click on the continue icon. Finally, click on the save, check, and activate icons to finish creating the status ODS object.

Now, create the mapping ODS object by following the steps detailed above. Give the ODS object the technical name YMAPPING and the description Mapping ODS. This ODS object should not have the BEx Reporting setting check box enabled, because you do not use this ODS object for reporting purposes. When creating the InfoObjects, include these four ODS object key fields:

YREPORT YTARGET

0TCTCOMSTRU

0TCTSYSID

Also include these six data fields:

YTARGTYPE YFREQ

YBISTAT

YDLL

YTLL

0TCTREQUID

Step 3. Create InfoSource for Mapping ODS Object

Next, build the InfoSource and update the rules to load the CSV file into the mapping ODS. Use transaction RSA1 and go to the InfoSources area within the modeling section. Right-click on an appropriate InfoArea and choose Create InfoSource. Choose the Flexible Updating in any Data Target (Except Hierarchies) button.

Enter the InfoSource name YMAPPING, enter the long description Mapping InfoSource, and click on the transfer icon (green check mark). Right-click on the InfoSource and click on the Change option. In the InfoObject fields, type in

the InfoObject technical names as shown in Figure 7. Click on the save and activate icons. Click on the Yes button in the pop-up window that asks if you want to activate all independent transfer programs.

Figure 7 Define the mapping InfoSource

The InfoSource needs to connect to a source system, in this case the flat file source system (Figure 8). Click on the communication structure collapse icon to collapse the communication structure area of the InfoSource change screen. Expand the transfer structure/transfer rules area of the InfoSource change screen by clicking on the transfer structure/transfer rules expand icon. Choose the source system drop-down menu and select your system’s flat file source system. Click on the Yes button in the pop-up window asking if you want to assign the YMAPPING

DataSource to the YMAPPING InfoSource. Click on the activate icon to activate the transfer rules.

Figure 8 Connect the mapping InfoSource to a source system

When loading flat files into the BW system via the flat file interface, you must put the transfer structure fields in exactly the same order as they are in the flat file. You can re-order the fields easily by going to Administrator Workbench, selecting Modeling area in the navigation window, and then selecting InfoSources in the functions window. Locate the InfoSource YMAPPING via the standard search function. In change mode, click on the move to

cursor position icon to re-order the items. Alternatively, you can highlight the row you want to move and put the

cursor where you want to move it. Remember to save and reactivate the transfer structure by using the activate icon after you make these changes.

Step 4. Create Update Rules for Mapping ODS Object

Create update rules that transfer the data from the InfoSource into the mapping ODS. In Administrator Workbench’s

modeling area, right-click on the mapping ODS object, YMAPPING, and select the Create Update Rules option. Select the InfoSource you created in the previous step. The system then should propose an appropriate update mapping rule since your InfoSource and ODS object contain the same InfoObjects. Some InfoObjects are included in this ODS Object only for technical reasons. These InfoObjects were included so the update rule could use them later in the status ODS. Check and activate the new update rules.

Note

Most BW systems have a defined flat file source system. If yours does not, simply create one using the create source system option (refer to the SAP help page http://help.sap.com/saphelp_nw04/helpdata/en/99/424e38363fe658e10000009b38f889/frameset.htm).< /td>

Step 5. Create InfoPackage to Load Mapping ODS Object

In Administrator Workbench’s modeling area, right-click on the mapping ODS object YMAPPING. Expand the InfoSource to display the DataSource, right-click on it, and select Create InfoPackage…. Be sure to point the Info- Package to the correct CSV file name and location; for example, C:\mapping.csv. (Use the standard drop-down menu leading to Windows Explorer.)

Now schedule the InfoPackage and check that BW loaded the mapping ODS with data. Depending on your ODS settings, you may also need to activate the data in the mapping ODS manually. To do so, right-click on the ODS object and choose Activate data in ODS. Finally, check that the contents of the ODS match the CSV file input.

Step 6. Create Update Rules for Status ODS Object

Create update rules that transfer the data from the mapping ODS object into the status ODS object. Do this by right-clicking on the status ODS object and selecting the context menu option Create update rules. Click on the InfoCube button and enter the mapping ODS object name YMAPPING into the InfoCube field, then click on the Continue

button. The system should propose appropriate update rule mappings (Figure 9).

Figure 9 Create update rules for the status ODS object

You also need to create a start routine to determine the status for each report. I included some additional InfoObjects in the mapping ODS object in Figure 8. BW does not populate them in the mapping ODS object. BW requires these InfoObjects in the mapping ODS object so that the system-generated communication structure 8YMAPPING has them too. This communication structure needs these InfoObjects so that the ABAP coding on the start routine for the update rules to YSTATUS has them available to update.

Now determine the values and populate them using ABAP coding. Because I included these additional InfoObjects in the mapping ODS object, which acts as the DataSource, these InfoObjects are available to use in the start routine.

In the update rule maintenance screen of Administrator Workbench, click on the Create start routine button. Enter the ABAP code from my custom program (PROGRAM UPDATE_ROUTINE) into the start routine. Click on the check icon and check the syntax, then save and activate the update rules.

Test your new update rule by loading the data from the mapping ODS into the status ODS. Click on the mapping

ODS and select the option Update ODS data in Data Target… (Figure 10).

Figure 10 Load the data from the mapping ODS into the status ODS

You should also schedule the InfoPackage CCCC_FULL to periodically load the data from the mapping ODS into the status ODS. In a production system you might choose to schedule this InfoPackage to run hourly so the end users always can see the current status of the BI reports. The status ODS should now contain data. If necessary, manually activate the data in the ODS object (right-click on the ODS object and choose Activate data in ODS…).

Step 7. Create Your BEx Query

You now can make your BEx query display the results of the data you just loaded into the status ODS object. Run transaction RRMX from SAPGUI to launch BEx Analyzer and create a new query (Figure 11). See SAP help file

http://help.sap.com/saphelp_nw04/helpdata/en/ba/45583ca544eb51e10000000a114084/frameset.htm for more information.

Figure 11 Define your BEx query

At this stage, you now have an accurate last load date and time for each BW report (Figure 12). This may meet end-user requirements. If you want to display the data in an even more user-friendly way, move on to step 8 to create a Web template and traffic light icons to represent the various status codes.

Figure 12 BEx ad hoc query results

Step 8. Create Web Template Class and Table Interface (optional)

First, create a new Web template using the BEx Web Application Designer (Web AD). Enter your user name and

password to log on to the BW development system. The system automatically opens up a new template (Figure 13).

Figure 13 Create a Web template including table item

Drag the generic table item from the left side of the screen to the right. Link the table item to the BEx query you created earlier by entering the query name into the Query/View field of the table properties (in the Generic tab at the bottom of the screen). Change the properties of the table item to include a reference to a class called YICONS

(Figure 15). Just type YICONS in the Class Interface field, which is empty by default.

Figure 14 If your BW system is older than Release 3.5, add the highlighted line of code

Note

You can download the file PROGRAM UPDATE_ROUTINE.doc from the Downloads section of BW Expert’s Web site, www.BWExpertOnline.com.

Tip!

If you want to display the status as an icon later on, set the properties of this InfoObject to display key and text in the query definition. You can do this by right-clicking on the YBISTAT InfoObject within the columns area. Select the properties option and choose the Display As setting Key and Text.

The YICONS class contains the ABAP code that changes the characteristic value for InfoObject YBISTAT from a number to a traffic light icon. This change happens at Web application runtime because BW calls the table interface class in much the same way that other areas of the SAP system call a user exit.

Note

If your BW system is older than Release 3.5, you need to manually enter the additional code into the table item object tag. Add this by clicking on the HTML tab on the right side of Figure 14 and enter the highlighted line of code.

Figure 15 Change class YICONS

Note

SAP introduced the start routine in BW Release 2.0 so users could access the entire contents of a data package during data loading. The start routine is similar to a user exit. BW calls the start routine once for each data package of a data load request. It can be more efficient to perform data transformations on the entire contents of each data package rather than on a record-by-record basis in the update rules. BW bases the structure of the start routine’s data package on the communication structure upon which the update rule is built. See the SAP help file http://help.sap.com/saphelp_nw04/helpdata/en/21/894eeee0b911d4b2d90050da4c74dc/frameset.htm for more details.

Create the class in Class Builder by returning to BW’s GUI and running transaction SE24 (you need a developer key to do so). Choose the Class button and enter a description; for instance, Class to create traffic light icons. Now you need to change the class so that it inherits the properties of a so- called superclass. This borrows as much of the SAP standard coding as possible and enables you to add a few lines of specific coding to create the traffic lights.

Choose the Properties tab in Class Builder and click on the Superclass button. Enter the value CL_RSR_WWW_MODIFY_ TABLE in the Superclass field. At this stage you should check the class by clicking on the Check button. You also should save the class. Next, click on the Methods tab. Place the cursor in the

CHARACTERISTIC_CELL field and click on the Redefine button. Finally, add the ABAP code shown in Figure 16 and then save and activate the class.

IF I_IOBJNM = 'YBISTAT'.IF I_FIRST_CELL = 'X'. "only pass icon for key displayCASE I_CHAVL.WHEN '10'. "loaded on time

c_cell_content = ' '.WHEN OTHERS. "other errors

c_cell_content = ' '.ENDCASE.ENDIF.

ENDIF.endmethod.

Figure 16 ABAP code to create traffic lights

Return to Web AD and execute the Web template in your Windows browser. The Web application now should display

a traffic light icon corresponding to the data’s status (Figure 17).

Figure 17 The Web application now displays traffic light icons

If you would like to keep multiple requests in the status ODS object, then you should add an additional time-stamp InfoObject into the status ODS object. BW populates this time-stamp characteristic via update rules each time it loads the ODS object. You then can add this characteristic into your BEx query as a drill-down characteristic to report historical data. This enables you to analyze which reports are most consistently available and which reports most often cause problems.

Enhance Web Analyzer in SAP NetWeaver 2004s for Added Flexibility  

by Prakash Darji, SAP NetWeaver Regional Implementation Group (RIG), SAP Labs LLC

You can enhance BEx Web Analyzer to meet specific business requirements. One popular enhancement adds a toolbar button to open the variable screen dialog where you can adjust filter values.

Categories: BEx

Key Concept

BEx Web Analyzer is a Web-based tool that performs ad hoc analysis in SAP NetWeaver BI environments. Web Analyzer helps minimize the footprint for query development because business users can use Web Analyzer for ad hoc scenarios without building lots of queries.

SAP NetWeaver 2004s provides expanded functionality for tools such as BEx Web Analyzer, so in many cases, customers use Web Analyzer out of the box. Still, some companies face unique or complicated requirements for which they may choose to enhance Web Analyzer.

I’ll explain how to make an enhancement in SAP NetWeaver 2004s that adds a button for variable screens where users can specify their filter values. This button takes users back to the variable screen from Web Analyzer. You also can make similar enhancements with BW 3.x.

Although this is a simple enhancement, I’ve had many customers ask about it. You can achieve this functionality through the context menu, but a button on the toolbar is more intuitive. If it is important to your customers to use variable screens often, then this might be a good option. If you are not using a lot of variables in your BI reports, this enhancement may not be for you. Keep in mind that this example illustrates how to enhance the template, and that you can use a similar process for building your own enhancements.

Examples of other enhancements include the ability to control print parameters. In SAP NetWeaver 2004s, printing is dynamic with Adobe PDF printing. Still, some companies may need specific printing formats, or may direct users to a particular user interface. Therefore, you can customize your template to add a button to the toolbar to open the print properties dialog. At the end of the article, I’ll discuss some other types of enhancements you may want to consider. You can extrapolate the logic in my example to create your own customization.

For an overview of the functionality in different releases of Web Analyzer, see the sidebar, “Web Analyzer’s Evolution.”

Add a Button for Variable Screens

I’m going show you how to add a button that takes users to the variable screen dialog. To perform this enhancement, you need a couple of tools, including Web Application Designer (Web AD) in BW 3.x or SAP NetWeaver 2004s. You also need an ABAP program. If you run BW 3.x, use RS_TEMPLATE_MAINTAIN to open Web applications in a text editor. If you’re on an SAP NetWeaver 2004s system, use RS_TEMPLATE_MAINTAIN_70 for this purpose. The steps I present are for SAP NetWeaver 2004s, so use the programs I mentioned for BW 3.x instead if you’re on that release.

Step 1. In transaction SE38, execute program RS_TEMPLATE_ MAINTAIN_70. This program allows you to edit

Web applications built within SAP NetWeaver 2004s (Figure 1).

Figure 1 Execute program RS_TEMPLATE_MAINTAIN_70

Step 2. Enter template 0ANALYSIS_ PATTERN and click on the execute icon (Figure 2). The 0ANALYSIS_PATTERN template is the Web application that defines Web Analyzer. Open this template and copy it.

Click on the Save as button to create a copy of this template to edit.

Figure 2 Open and copy the 0ANALYSIS_PATTERN Web template

Step 3. Specify ZANALYSIS_ PATTERN as the template and click on the green check mark (enter) icon (Figure 3). This new template, ZANALYSIS_PATTERN, is the enhanced version of Web Analyzer. You then see the

messages in Figure 4. These messages are not typically OK in Web applications, but because Web Analyzer is a template, the system does not assign the data provider initially. You can assign the data provider at run time.

Figure 3 Save the template as ZANALYSIS_PATTERN

Figure 4 Messages that you see after saving the Web template

Step 4. Launch Web AD to edit the new Web template. Click on the open icon to open your new Web application. Choose the BUTTON_TOOLBAR_2 Web item (Figure 5). This item has the list of buttons available in Web Analyzer that appears after the drop-down box. In the Web Item Parameters tab, choose the help selector to the right of 6

Export to CSV (Button) to launch a wizard and define the new button (Figure 6).

Figure 5 Choose the BUTTON_TOOLBAR_2 Web item

Figure 6 Choose the help selector for 6 Export to CSV (Button) to define the new button

Step 5. Edit the parameters. In the wizard, update the Caption and Quick Info to Variables by typing over the existing text. This names the button that the Web application displays. Next, choose the Command help selector in

Figure 7. This launches the command wizard to define the action to occur when users click on this button.

Figure 7 Update the parameters

Step 6. In Command Wizard, choose Open Variable Dialog and click on the Next button. The OPEN_VARIABLE_ DIALOG action launches the variable screen. Select the OK button. This confirms that you want to perform this action. In the next screen, choose OK again. Now you have defined this button completely. Click on the save icon to save the Web application. Ignore any messages that may pop up.

Step 7. Replace the default Web template with your new Web template. Go to transaction SPRO and click on the SAP Reference IMG button. Choose menu path SAP Customizing Implementation Guide>SAP NetWeaver>Business Intelligence>Report-relevant Settings> BEx Web>Set Standard Web Templates to set the standard templates.

The default template is 0ANALYSIS_ PATTERN, so you need to change the setting to the new template. Enter

template ZANALYSIS_PATTERN in the Ad-hoc Analysis field and click on the save icon (Figure 8). This ensures that all Web applications launched from within SAP NetWeaver BI use your enhanced template by default.

Figure 8 Enter template ZANALYSIS_PATTERN and click on the save icon

Step 8. Invalidate the cache. You must perform this step so that the system recognizes the change to the default Web template. Go to transaction SMICM, the central Internet Communication Manager (ICM) control. Invalidate the cache via menu path Goto>HTTP Server Cache>Invalidate>Global in System.

Step 9. Adjust portal settings. Log into SAP NetWeaver Portal. Go to Content Administration>Portal Content>Content Provided by SAP>Platform Add-ons>Business Intelligence>iViews>BEx Web Analyzer>Open>Object. Anyone entering Web Analyzer through this portal should use this enhanced application, so

you need to modify some settings. Go to Content – BEx Web Application to open Property Editor (Figure 9). This area controls the properties of the Web application.

Figure 9 Select Content – BEx Web Application

In Property Editor, update the BEx Web Application Query String field to point to ZANALYSIS_PATTERN instead

of the default 0ANALYSIS_PATTERN (Figure 10). This ensures that all users who launch Web Analyzer from the portal launch the enhanced application.

Figure 10 Overwrite the default template 0ANALYSIS_PATTERN by changing it to ZANALYSIS_PATTERN

Step 10. Test your new Web template. Navigate to Business Intelligence>Business Explorer>BEx Web Analyzer. Web Analyzer should now have the new button that you enhanced to launch the variables screen. As you

see, the enhancement is available (Figure 11).

Figure 11 Web Analyzer now includes a Variables button

Other Types of Enhancements

Now that you know the steps to create an enhancement, I’ll discuss what other types of enhancements you could make. Starting with BW 3.0, you can make an enhancement that creates bookmarks. Another typical enhancement allows you to save to your browser favorites. You also could enhance printing capabilities.

Within BW 3.5, typical enhancements include removing the broadcasting tab and adding the “Print to Excel” solution. You also might want to remove the send button to remove broadcasting capabilities, because some companies do not allow ad hoc broadcasting to their user community.

Within SAP NetWeaver 2004s, you may want to customize the Web Analyzer template to save query views. Currently, the save button only saves Knowledge Management (KM) documents to the BEx Portfolio. You can enhance this button to save query views, providing users with more flexibility.

Another way to enhance Web Analyzer is to change the print button to exclude a dialog. When you choose the print button from Web Analyzer, the system launches a dialog to allow users to enter print settings. Many customers may want to default values such as fit to page, landscape, or half-inch margin. Web Analyzer can specify these parameters so that when users click on the print button, documents print to PDF with no dialog for user input.

Currently, Web Analyzer shows a finite number of rows and columns. In some cases, you may want to alter the default property to show all rows and columns that your query returns. This way, users do not have to scroll through pages.

These are just a few ways to enhance the standard template. I’m sure that you can use the knowledge you gained from this article to develop others if your business requirements demand them.

Note

If you run into any problems during this process, check the online help at http://help.sap.com/saphelp_ nw2004s/helpdata/en/0d/af124 03dbedd5fe10000000a155106/ frameset.htm.

Web Analyzer’s Evolution

BW 3.0 contains the first version of Web Analyzer that uses the default Web template 0QUERY_TEMPLATE. This template’s toolbar contains images for control options and a navigation block for setting filters (Figure 1). If you need to customize Web Analyzer in BW 3.0, refer to SDN’s how-to guide at

https://www.sdn.sap.com/irj/servlet/prt/portal/ prtroot/docs/library/uuid/a249a990- 0201-0010-e18e-b2f5ed135497.

Figure 1 BEx report in BW 3.0 Web Analyzer without enhancements

In BW 3.5, Web Analyzer contains two default Web templates, 0ADHOC or 0ANALYZER. These templates use a tabular approach to segment and display more information in your Web application. In addition, control options use buttons instead of icons. The look and feel also differ from BW 3.0: The navigation block is on the left instead of the

top so that the screen can display more information about each report (Figure 2).

Figure 2 BEx report in BW 3.5 Web Analyzer without enhancements

Within the BI capabilities of SAP NetWeaver 2004s, Web Analyzer uses default Web template 0ANALYSIS_ PATTERN. Web Analyzer is one of the portal capabilities of SAP NetWeaver 2004s and allows you to perform ad hoc analyses on top of various BI data providers. BEx Web Analyzer contains many new analytical options for business experts. For example, users navigate using drag and drop, and can create exceptions and conditions using a wizard. This Web Analyzer template adds even more real estate on the screen by minimizing the control area to one toolbar with buttons that launch dialogs (Figure 3). For details about this version of Web Analyzer, see the online help page http://help.sap.com/saphelp_nw2004s/helpdata/en/0d/af12403dbedd5fe10000000a155106/

content.htm.

Figure 3 BEx report in SAP NetWeaver 2004s Web Analyzer without enhancements

Ensure Business Access Segregation by Automatically Generating SAP NetWeaver BW Analysis Authorizations  

by Jonathan D. Griffith, SAP NetWeaver BW Subject Matter Expert and BI Solutions Center Tools Team Lead, FirstEnergy Corp. (October 2009)

Learn about an alternative method for creating and maintaining complex business access segregation rules that does not involve having your employees manually assign and revoke SAP NetWeaver BW roles with every employee job transfer. Through the use of analysis authorizations and security data models, you can update your SAP NetWeaver BW security automatically to reflect the latest changes to users as well as business rules governing data access.

Categories: Analytics, BEx, Security

Key Concept

The SAP Business Explorer (BEx) suite of products (including BEx Query Designer and BEx Analyzer) is part of the SAP GUI front-end installation that allows end users to create, maintain, and execute queries to retrieve information from the SAP NetWeaver BW data warehousing platform. IT developers can use transaction RSA1 to create and maintain the data models that house this information within SAP NetWeaver BW. You can maintain the security surrounding these models via transactions such as RSECADMIN and PFCG.

Recently, I was approached by a security project manager for assistance with how FirstEnergy (FE) could use its SAP NetWeaver BW implementation to achieve overall corporate business objectives and more efficiently secure access to information among its separate business units. FE had just completed a series of SAP technical and functional upgrades that included going from SAP BW 3.0B to SAP NetWeaver BW 7.0 and implementing HR structural authorizations within SAP NetWeaver BW. To satisfy the current business and security objective, we extended this HR structural authorizations model to automatically generate authorizations from data outside of SAP HR.

The true objective was to lower the high-maintenance required to provision data access within SAP NetWeaver BW. FE conducts business operations in a utility regulatory environment. One consequence is that we must restrict data access among five business unit groups in a controlled manner. The main group, shared services, has open access to all data while another group, employees on extended disability, has no access. The other three groups — regulated entities, energy affiliates, and regulated commodity sourcing — each has different access rights depending on relevant regulatory considerations.

Limitations with the Previous SAP BW 3.x Security

In the past we were limited to the SAP BW 3.x security constructs, which required data to be segregated into separate data models for ad hoc query access, or separate queries saved to restricted reporting roles. This was more than sufficient for our business unit and regulatory needs. Depending on the complexity of the rules governing the data segregation we had to maintain distinct restricted queries, maintain distinct transactional data targets, or maintain distinct sets of the entire data model including master data and all the supporting extraction, transformation, and loading (ETL) mappings and processes.

Analysis Authorizations Overview

SAP introduced the concept of analysis authorizations with the SAP NetWeaver BW 7.0 platform. These authorizations allow you to define security as granular as is necessary, including the most granular — row level. Instead of maintaining separate and distinct data models to ensure data segregation, you only need to define analysis authorizations to give users access to data with certain values. This automatically restricts the users from data not having those values. 

Analysis authorizations allow for you to define complex security. For flat or value authorizations, you can define specific values that are permitted — for example, company code values of 1234 and 1235. The value 1236 would not be permitted unless the authorization contains the single character value symbol +. For example, if you use 123+, the values 1230 through 1239 would be permitted. You can add other special characters to the authorized values:

* specifying any string of values

123* would allow 123, 1230, 123A, 123999, and so on 

: specifying that the characteristic in question could be aggregated. Even if all the underlying values were not authorized, the system allows the query as long as the unauthorized characteristics are not individually displayed in the result set (whether in a free characteristic or left out of the query definition altogether)

# or undefined value that allows the query to display values that are blank (‘ ’) or yet to be determined

If those are not flexible enough for deriving authorized values, you can use variables to determine allowed values. You can also use a catch-all 0BI_ALL analysis authorization (much like the SAP_ALL authorizations for SAP

transaction-/role-based security) that is typically granted to developers or administrative personnel in non-production systems.

For hierarchy authorizations, analysis authorizations allow for the flexibility to define security at each leaf or node or to specify that security for a leaf should be inherited from the nodes above. Furthermore, you can allow only the first n levels of a hierarchy to be displayed, ensuring that, similar to the aggregation (:) flat authorization, specific characteristic values are not displayed. You can still use the characteristic to derive general trends concerning the data.

To use analysis authorizations, enable the SAP NetWeaver BW 7.0 analysis authorization scheme within the SAP NetWeaver BW IMG. You can use transaction SPRO or follow menu path SAP Reference IMG> SAP Customizing Implementation Guide > SAP NetWeaver > Business Intelligence > Settings for Reporting and Analysis > General Settings for Reporting and Analysis. Execute the analysis authorizations and select a concept. From this screen (or from transaction RSCUSTV23), set the analysis authorization mode to Current Procedure with Analysis Authorizations. Use transaction RSD1, enter the characteristic name, and choose Maintain. Then activate the AuthorizationRelevant flag from the Business Explorer tab within the characteristic maintenance screen for each

characteristic you would like to secure (Figure 1).  

Figure 1 Activate authorization relevance

Use transaction RSA1 and go to the Business Content screen. You need to activate at least the following three business content characteristics: 0TCAACTVT (activity in analysis authorizations), 0TCAIPROV (authorizations for

InfoProvider), and 0TCAVALID (validity of an authorization). Last, you need to create analysis authorizations with allowed values within RSECADMIN.

The main concept to understand with respect to analysis authorizations is that with the exception of display hierarchies and key figures, the system only displays a query result if the executing user has analysis authorizations to all the values contained therein. Otherwise, if some values of the user’s results are outside of the authorized values, the only thing displayed is an authorization error message such as You do not have sufficient authorization.  

You need to complete three steps after you make a characteristic authorization relevant.

Step 1. Create an authorization variable. Within BEx Query Designer, right-click on the appropriate characteristic, choose Restrict, and select to display the currently available list of variables — as opposed to Single Values or your restriction value History. Next, click on the New Variable button. An Authorization Variable is a special type of variable created in the same way as any other BEx variable, but with different properties (Figure 2). The system populates this type of variable with the allowed values for the users at query runtime. This means that when a user executes a query with this type of variable, he or she sees the selection screen with the authorized characteristic values already

pre-selected (Figures 3 and 4). If users have not previously restricted the characteristic, they can adjust their queries to work with the new authorizations by simply including the variable as a query restriction.

Figure 2 Edit variables in BEx 3.x

 

Figure 3 Populated authorization variable in BEx 3.x selection screen

 

Figure 4 Populated authorization variable in SAP NetWeaver BW 7.0 Web Analyzer selection screen

Step 2. Ensure that when you create the variable, you select the Ready for Input property. You can see this setting in the screen in Figure 2. This allows users to further restrict the values of the characteristic requested for their query result in the event that the authorized list is too extensive. This setting does not allow the user to see more data than they are authorized to see. 

Step 3. Create these variables using the last version of the BEx used by your organization. In other words, if your users have both BEx 3.x and 7.0 queries, create the variables in BEx Query Designer 3.x.

Reduce Maintenance

Next you need to configure the SAP NetWeaver BW system to generate the authorizations each night, taking into account any changes that may have occurred with respect to master data access classifications, or the organization structure and the employees therein. SAP delivers two clear models for automatically generating these analysis

authorizations: one using data from the HR module (Figure 5) and one using data from the CO module (Figure 6).

Figure 5 HR-based analysis authorization generating model

 

Figure 6 CO-based analysis authorization generating model

As I mentioned in the introduction, FE had implemented the HR-based model to secure its HR data models within SAP NetWeaver BW. For the current business and security objective, I extended this HR model beyond employee data and HR characteristics. We needed HR employee and organization data to determine the security restriction classification and thus the access group for each user. We needed a lower-maintenance method to secure non-HR data using this information, coupled with security groupings of non-HR characteristics, such as plant and company code.

Determine User to Analysis Authorization Assignments

Developers within HR had configured our SAP ERP shared services instance to maintain the security classification relationship of each organizational unit within the HRP1001 table, and each classification’s text value in the HRP1000 table. I extracted these values into SAP NetWeaver BW so that I could repeatedly map each employee to a security classification through that employee’s organizational unit. Not all of our SAP NetWeaver BW users log on with their employee IDs, so we needed to extract an additional relationship from the PA0105 table that mapped each employee to an SAP NetWeaver BW user. We then extracted these mappings via an SAP NetWeaver BW generic function module DataSource and loaded them into a copy of the HR template DataStore object (DSO) 0TCA_DS04, which I called ZTC_DS14 (Figures 7 and 8). These screens represent the information displayed within transaction RSA1

when displaying (Figure 7) and managing the (active) contents (Figure 8) of the InfoProvider ZTC_DS14.

Figure 7 User to analysis authorization assignment DSO

 

Figure 8 User to analysis authorization assignment DSO populated

Contractors and special or test IDs posed another issue. We do not define contractors as employees in our SAP systems. Instead, each contractor ID is associated with a placeholder position within our SAP ERP shared services instance, which in turn is associated with a particular security classification. Another extract from HRP1001 satisfied the contractors, and we fed this data into ZTC_DS14. We map special IDs, including those IDs temporarily activated for testing purposes, by maintaining the 0EMPLOYEE master data within SAP NetWeaver BW. You need to create a new master data record manually by maintaining the master data of characteristic 0EMPLOYEE from transaction RSD1 with a number greater than any used employee number. You then give that record an OrgUnit and UserID mapping. When these IDs are no longer needed for testing, you delete their mappings so the IDs no longer have access. Then these special IDs are loaded into ZTC_DS14 via the same automated mechanism as normal employees.

After you complete this step, each user in SAP NetWeaver BW is associated with one of the analysis authorizations that is generated by the processes that I’ll discuss next.

Determine Flat Analysis Authorization Values

The ideal method for maintaining the mapping of security classification groups to authorized characteristic values is to maintain an additional attribute on each authorization-relevant characteristic so the maintenance effort would be incurred whenever you created any new master data. Based on the impact that would have on our mature SAP ERP and SAP NetWeaver BW landscapes, I decided to maintain the mappings within classification hierarchies (Figure

9). 

Figure 9 Example classification hierarchy

In these hierarchies, there is a node for each security classification with the appropriate characteristic values and intervals. The drawback is that these hierarchies have to be maintained in each SAP NetWeaver BW environment unless a hierarchy download/upload DataSource exists for each characteristic. Because you only need to maintain these hierarchies when updating business rules or policies governing security or creating new master data, this maintenance effort is still easier than current maintenance procedures. Placing these values in a hierarchy that users can see and verify was also far more manageable than maintaining the values within the sensitive RSECADMIN analysis authorization maintenance transaction.

Using a second generic function module extractor, these classification hierarchies are automatically loaded into ZTC_DS11. ZTC_DS11 is a copy of the HR template 0TCA_DS01. The system also automatically duplicates the classification values for each characteristic used as a reference characteristic in other authorization-relevant characteristics during the ETL processing into ZTC_DS11.

Determine Hierarchy Analysis Authorization Values

I wrote a third generic function module extractor, a copy of the HR template 0TCA_DS02, to automatically populate ZTC_DS12 that houses hierarchy (i.e., non-flat) authorization values such as node and leaf-level access. You can

see the structure and contents of ZTC_DS12 in Figures 10 and 11.

Figure 10 Analysis authorization hierarchy authorizations assignment DSO

 

Figure 11 Analysis authorization hierarchy authorizations assignment DSO — populated

The logic in this function module includes a selection of the contents of ZTC_DS11 into an allowable values internal table, followed by a selection of each hierarchy record (excluding the classification hierarchies) for each authorization-relevant characteristic into another internal table. I then traverse each hierarchy from the bottom up to populate the set of allowed leaves or nodes. The logic considers a node authorized if its value is allowed (in the case of a non-0HIER_NODE) and/or each of its children (subordinate hierarchy nodes or leaves) was allowed. Determining all the necessary values for the DSO requires you to review the hierarchy analysis authorization SAP Help documentation.

Create Meaningful Text Descriptions for Each Analysis Authorization

The last DSO I created and populated automatically via another generic function module extractor was ZTC_DS13, a

copy of the HR template DSO 0TCA_DS03. You can see the structure and contents in Figures 12 and 13. I load hard-coded short, medium, and long text descriptions for each FE security classification analysis authorization within another generic function module extractor, taking advantage of shared function group constants.

Figure 12 Analysis authorization texts DSO

 

Figure 13 Analysis authorization texts DSO — populated

Nightly Processing, Troubleshooting, and the New Query Development Process

I put all the loads in sequence within an SAP NetWeaver BW process chain via transaction RSPC. First, the process chain executes the loads to populate the FE security classifications, including their texts, followed by OrgUnit and Employee attributes from an SAP ERP system. Next the DSOs ZTC_DS11 through ZTC_DS14 are emptied and re-loaded with the most updated information. Lastly, the process chain generates the analysis authorizations by calling the program RSEC_GENERATE_AUTHORIZATIONS, which is part of the RSECADMIN functionality, with a variant

housing the input DSOs ZTC_DS11 through ZTC_DS14 (Figure 14). After the chain executes, you can verify the contents of each DSO as well as the analysis authorizations in RSECADMIN. You can see an example of the process chain by going to the Downloads section at the bottom of this article.

Figure 14 FE security classification analysis authorization generation program variant

Transaction RSECADMIN should show something similar to Figures 15 and 16 when displaying the contents of generated analysis authorizations, and something similar to Figure 17 when displaying the assignment of the analysis authorizations to users. Notice that the screens in Figures 15 and 16 list the authorization-relevant characteristics, but the screen in Figure 15 shows that Intervals and Node values exist whereas the screen in Figure 16 shows that each characteristic has the * within the box in the Intervals column, which denotes full authorization. The values displayed for each characteristic in these analysis authorizations equate exactly to the values maintained

in the FE classification hierarchies shown earlier. Figure 17 verifies that the authorization ZFE 3 was not only automatically generated, but it was properly assigned to the user B1857.

Figure 15 Example generated analysis authorizations with restricted characteristic value access

 

Figure 16 Example generated analysis authorization with unrestricted characteristic value access

 

Figure 17 Example generated analysis authorization user assignment

 

Note

If you face issues with the contents of these authorizations or users’ access rights, RSECADMIN also has numerous logging and troubleshooting capabilities that you can learn about via the SAP Help documentation. 

After the new authorizations are in place, users with restricted access need to ensure that their queries restrict the authorization-relevant characteristics to only values that they are allowed to query. The easiest way for you to accomplish this is by adding authorization variables to their queries. You can see a high-level, end-to-end view of the process created to generate these new authorizations by going to the Downloads section at the bottom of this article.

Exceptions to the Model

To allow unlimited access to some data models, you can override the analysis authorizations by including the InfoObjects 0TCAACTVT and 0TCAIPROV within another analysis authorization, along with the characteristic to allow all access. In the case of the RSECADMIN authorization maintenance screen shown in Figure 18, the exception is for 0PLANT. For the allowed values Intervals of 0TCAIPROV, simply include the InfoProviders contained in the excepted model. You can see and maintain the list of these Intervals by clicking on the green square bracket

icon to the right of the authorization InfoObject, such as 0TCAIPROV in Figure 18.

Figure 18 Example of an exception analysis authorization

Another option for exceptional access is with the use of IDs that were part of Virsa FireFighter technology, which now lie in SAP GRC Access Control. These IDs can allow broader access than normal, but with complete logging and auditing available to interrogate actions taken while being used, such as which queries were executed.

At FE, SAP security personnel create and maintain the specific authorizations in coordination with directives from corporate policy and compliance personnel. Compliance personnel then review and approve the authorizations prior to the SAP security team implementing them.

Everything You Need to Know About Formatting Part I: BEx Analyzer and BEx Query Designer  

by Ned Falk, Senior Education Consultant, SAP America

SAP NetWeaver BI 7.0 has increased formatting options over SAP BW 3.5. Learn how to create custom workbooks in SAP NetWeaver BI 7.0. Also, find out about other enhancements, including creating company default workbooks for logos and corporate formatting.

Categories: BEx, Reporting

Key Concept

New in SAP NetWeaver BI 7.0, are improvements to the concept of a customized default workbook in BEx Analyzer. In addition to the logos and formatting controls available in SAP BW 3.5, you can also add buttons and other graphical user interface features to carry out specific tasks, such as to toggle the status of an exception or a condition.

SAP NetWeaver BI provides expanded options for formatting queries and reports in both the Web and Excel (BEx Analyzer) worlds. In this three-part series, I will discuss the choices you have for formatting. In this first part, I focus on BEx Analyzer and the formatting control available in queries. This includes discussion of enhanced key figures and cells in BEx Query Designer as well as default workbooks (logos, formatting control, and default properties for items).

The second article focuses on workbook themes, Excel controlled formatting, and the Formula mode and its formatting possibilities. The third article covers the Web, including portal themes, style commands, enhanced key figures, display options for exceptions, and an overview of the new format-intensive BEx reports.

Highlighted Display Setting

Before I go into the options you have for customizing the default workbooks, I want to bring your attention to a setting that’s changed with SAP NetWeaver BI 7.0. In previous versions of SAP BW, if you wanted to make a particular cell show up in bold font, you set the display to Emphasis in the key figure properties for the cell. In SAP NetWeaver BI

7.0, the Emphasis setting is now referred to as Highlighted Display, as shown in Figure 1.

Figure 1 Highlighted Display setting

The query designer uses the Highlighted Display setting to control how the key figure cells appear in the report output. In the next section, I’ll show you how to get more creative with your workbook design to alter how your finished query looks.

Note

For more information about using BEx Analyzer in SAP NetWeaver BI 7.0, refer to Anurag Barua’s article, “SAP

NetWeaver BI 7.0: Design in No Time with New BEx Analyzer Control Objects,” in Volume 5, Number 10 in the BW/BI Expert knowledgebase at www.bi-expertonline.com.

Designing Default Workbooks

For BW 3.x users, designing a workbook is a new concept because only SAP NetWeaver BI 7.0 BEx Analyzer has a design toolbar in which you can include design elements similar to, but less numerous than, those of the BEx Web Application Designer. You could start from a blank sheet and design a new workbook using the BEx Analyzer toolbar. However, I recommend using an existing default workbook and customizing it to meet your needs. This process involves these five steps:

Step 1. Open a query in BEx Analyzer

Step 2. Clear out the data provider that feeds the default workbook

Step 3. Customize the workbook

Step 4. Set the global settings

Step 5. Test your work

In my example, I am working with an exceptions and conditions report in which the user must be able to quickly spot which incoming orders have problems. Although the default workbook shows orders falling under exception in shaded boxes, it can be difficult to pick these out in the standard template. In my custom version, the highlighted fields have an identifiable border around them, plus larger text.

Step 1. Open a query in BEx Analyzer. Figure 2 shows some of the important icons in BEx Analyzer. To open a

query, click on the open icon and then select a query. In my example, I selected an exceptions and conditions query, which I use to monitor incoming orders. Opening an existing query allows you to use a default workbook as a backdrop for your new query. To see the technical details of the workbook, you need to access the Visual Basic (VB) code and BEx design items. Although you do not necessarily need to change the existing SAP workbook features, it is good to know how to change them.

Figure 2 Important BEx Analyzer icons

Figure 3 shows the default workbook that you see when you open a query. Although it’s easy to spot the Status of Data field, it is more difficult to find the key date for the time-dependent master data. In this case, you need to know

to click on the Information button, but this is not readily apparent to the user.

Figure 3 Default workbook that appears when you open a query. The shaded orders are technically bolded, but the bolding is faint.

Let’s take a quick look at the VB code for this SAP default workbook to understand how it works (Figure 4). VB, like many languages, uses reusable modules of code. You activate the code when you click on or hover over the buttons. To view this code, add the VB toolbar to the workbook by going to View>Tool Bars>VB Tool Bar and use it to view

the code. In the code, you can see the reused code where the code calls Module 1, 2, or 3 at various times.

Figure 4 VB code for the query showing code for Module1

Step 2. Clear out the data provider that feeds the default workbook. In BEx Analyzer, click on the workbook

settings icon to bring up the screen shown in Figure 5. Click on the Data Provider tab to view all the data providers available in the workbook.

Figure 5 Workbook settings — Data Provider tab

Next, you need to clear all the data out of this data provider because a background workbook should not have data. Select the data provider that appears in this tab (in my example, DATA_PROVDER_1) and click on the Properties button on the bottom right corner of the screen.

This brings you to the data provider properties settings. Here you must eliminate the underlying source from

DATA_PROVIDER_1 so you are left with just a shell workbook for logos and formatting. Click on the delete icon to delete the initial query from your default workbook. Save this workbook with the name CORPORATE_DEFAULT in a custom BI role called ZGUI_ADMIN.

Step 3. Customize the workbook. For my example, I want to change the colors of exceptions and the style of enhanced key figures in Excel. To help with the latter, SAP provides a workbook with an example of all the provided custom styles. This workbook is installed on your PC when you install the Excel BEx Add-In for BI. The name of the workbook is SAPBEXS.XLA. On my PC, this file is located at C:\Program Files\Common Files\SAP Shared\BW.

Open this workbook, shown in Figure 6.

Figure 6 When you click on a cell, the name of the style appears in the top right corner

Adjust the Style

In my example, the SAPBEXexcGOOD1 style shows up as dark green, whereas the SAPBEXexcBAD9 style shows up as dark red. This could be troublesome for people who are red-green colorblind. To provide another way to tell the styles apart, you can add a border around the SAPBEXexcBAD9 style to make these cells stand out more.

Go to Format>Style in Excel to change the styles. Then select SAPBEXexcBad9 for the Style name and click on the Modify button (Figure 7). In the Format Cells screen that appears, click on the Border tab, and select a border for the cell. In the Font tab, I customized the font appearance for styles ending in Emph (emphasized/bold, such as

SAPBEXaggDataEmph) so that they are bolder and in a larger font.

Figure 7 Select the style

After you customize the SAPBEXS.XLA workbook, save it as a new workbook called CORPORATE_STYLES_WB.XLA. You can place it on the server in the the ZGUI_ADMIN role.

Next, merge the customized styles from this workbook with the styles on the workbook called CORPORATE_DEFAULT. Make sure to click on the Merge button from the CORPORATE_DEFAULT workbook in Figure 7, not the CORPORATE_STYLES workbook. This merges the styles you changed on your version of

SAPBEXS.XLA and overwrites the SAP defaults.

Tip!

Web template designers could also reuse the ZGUI_ADMIN role to store reusable Web items. Although storing templates and storing Web items are separate uses for the role, the users involved in these tasks might be the same and they both involve corporate defaults.

Add Material to the Query

Now you can insert a logo in your workbook. This can be useful for BI teams that create workbooks for different divisions of the same company. The logo makes it easy to see whose workbook you’re running. SAP uses picture files for some of the backgrounds, so you might have to adjust their sizes to make room for the logo. I also recommend adding a feature that allows users to toggle between the exceptions and conditions set by the query designer.

Finally, I would add the key date (the data of the time-dependent master data used on the query) to the upper right corner of the screen. This key date shows the master data effective date that was used with the transaction data. For example, if you used a key date of 01/01/1986 for a 2006 country sales report, you might get sales for East Germany. The same report for 2006 with a key date of today would show Germany, as East German master data is no longer valid.

To add the new Key Date field, click on the design icon in BEx Query Designer. Next, locate a position on the workbook and click on the cell to select the area on the workbook where you want the Key Date field to appear.

Then, click on the access the text design item icon . In Figure 8, click on the Constants tab, select Display Key

date, and click on OK. Your workbook should now show a Key Date field in the area you selected.

Figure 8 Add a text element for the Key Date field

Add a Button

The next improvement is to add a button to your own worksheet that contains a list of all the exceptions and conditions contained in the query. To accomplish this task, you add an Excel button. Then you connect the button to a macro that takes the user to the new sheet.

First create the new sheet by going to Insert>Worksheet in Excel. Right-click on the new worksheet and rename it Exceptions And Conditions. Next, in Excel’s forms toolbar, click on the create-a-button icon to create button called Exceptions and Conditions. Inserting this button automatically prompts Excel to record a macro (Figure 9). Click on

the Record button, navigate to the Exceptions And Conditions worksheet, and then stop the recording of the macro by clicking on the stop icon.

Note

Adding the Exceptions And Conditions worksheet is one example. If you know VB, you can add other options, such as hiding rows dynamically.

Figure 9 Record a macro connected to the Exceptions and Conditions button

Now let’s add the exception and condition items to the macro. Select a cell, click on the design icon, and select the

exceptions and conditions item icons . In this part you add buttons to the Exceptions And Conditions worksheet that can take the user to the table or chart views of the workbook. To do this, copy and paste the appropriate buttons from the SAP default workbook. Your resulting sheet should look like the one shown in Figure

10. Make sure you save your workbook to avoid losing your work.

Figure 10 The Exceptions And Conditions worksheet

Step 4. Set the global settings. Click on the global settings icon and select the appropriate options under the Select Default Workbook tab (Figure 11). If you are the responsible administrator, you can also select the check

box for Global Default Workbook to enable all users to see this workbook as the default if they elected to use the default in their systems.

Figure 11

Global settings

The selections you make in the Global Settings screen are stored in table RSRWB- TEMPLATE (Figure 12). In this example, I set a global default template, which is the one with the blank user ID. Only one is possible for your whole system. Some users are using different templates as their default. For example, FalkN has a default different from the one set as the global default. Users can override the default by opening a different workbook and setting it as the

default by clicking on the Use Current button in Figure 11.

Figure 12

Table RSRWBTEMPLATE

It might be necessary to pre-assign a specific default workbook to a specific user (not just the global default). In some cases, power users may need more than one global default, such as in a large company with many divisions, each with a different logo. Direct entry into the RSRWBTEMPLATE table is not allowed by most users, so you need an ABAP program. I suggest the one available on SDN at https://www.sdn.sap.com/irj/sdn/thread?forumID=134&threadID=96854&messageID=1069494#1069494.

Step 5. Test your work. Log in to the system and open a query, which should reflect the improvements you made,

such as adding a logo and buttons. Figure 13 shows an example of a customized workbook. Compare this to the standard workbook in Figure 3 to see the new customizations.

Figure 13 The query shows the improvements added to the workbook

Note

To learn more about workbook design consider taking SAP Education class BW306 (BI — Enterprise Reporting, Query and Analysis: Part II).

Formula Variables Offer a Low-Cost Alternative to Cell Definition in Financial Reports  

by Soumya Mishra, Sr. Consultant, Deloitte Consulting LLP (April 2009)

Find out how you can use formula variables with hierarchies to define individual cells in a report. This six-step process offers a low-maintenance alternative to developing custom query structures in BEx Query Designer, a pre-requisite for the cell definition feature.

Categories: BEx, Reporting, SAP ERP

Key Concept

Variables are query parameters that you define in BEx Query Designer. They are filled with values when you execute the query or Web application. Formula variables represent numeric values that you can use in formulas. In

addition, you can also use formula variables to select conditions and exceptions.

Often companies need to produce balance sheets and income statements as part of statutory, regulatory, and management reporting requirements. In many SAP implementations, companies typically use SAP NetWeaver BW (formerly SAP NetWeaver BI) to produce these statements. Two widely used approaches to produce these statements are:

a. Using structures in BEx Query Designer: This approach has high development and maintenance cost

b. Using a general ledger (GL) account hierarchy in BEx Query Designer: This approach has low development and maintenance cost

Companies typically need to define individual cell in these reports, based on the individual hierarchy node. In approach (a), you create a query structure to build the GL account structure and key figures are part of a second query structure. Using custom GL account structures can result in high maintenance costs in global implementations. For example, if you need to add a new structure element or GL account to the query structure, you need to make the changes in all the affected SAP NetWeaver BW queries.

Subsequent rollout to other countries causes the maintenance cost to increase even further. As you add more structure elements to the query structure, it becomes challenging to keep the SAP ERP Central Component (SAP ECC) Financial Statement Versions (FSVs) and SAP NetWeaver BW query structures in sync to avoid reconciliation issues.

However, in approach (b), you use a GL account hierarchy instead of a query structure to create the GL account structure. This allows you to avoid the fixed structures from approach (a). Changes to the reporting structure are handled in the SAP ECC FSV, which is extracted as a GL account hierarchy. No changes to the individual query structure are required. Because the changes originate from the FSV in SAP ECC, reconciliation between SAP ECC and SAP NetWeaver BW is not a major challenge. There is no standard way to define an individual cell based on hierarchy nodes, so I developed a way to handle this requirement using formula variables while still following the cost-effective approach (b). I’ll show you the step-by-step approach I used with SAP NetWeaver BW 7.0.

Business Example

In the retail industry, an income statement often displays % of Net Sales as a separate column. This column displays the percentage share of an individual node (text and posted nodes) in the GL account hierarchy to the Net Sales text

node (Figure 1). Because Net Sales is also part of the GL account hierarchy, companies often compare the individual elements in an income statement against the Net Sales amount.

Figure 1 A sample income statement hierarchy

The % to Net Sales column has two separate requirements:

The Net Sales (including the posted nodes) result should be 0

For text and posted nodes, the result should be the percentage of the Net Sales text node

To meet this business requirement example I need to define an individual cell in a report.

The prerequisites for developing financial statements using approach (b) are:

The FSV is created in SAP ECC per the company’s chart of accounts

The FSV is extracted as a GL account hierarchy from SAP ECC to SAP NetWeaver BW

The GL account hierarchy is used in the query to create the financial statement structure in SAP NetWeaver BW

Note

The technical design details of approach (b) are out of the scope of this article. This document focuses on addressing the challenge of defining an individual cell while still following best practices for producing financial statements.

The Six-Step Process

Step 1. Create the first formula variable using BEx Query Designer. Go to the Rows/Columns tab, right-click, and select New Formula from the context menu. Right-click the new formula, Formula 1, and select Edit. Create a formula

variable in the General tab by right-clicking Formula Variables and selecting New Variable (Figure 2).

Figure 2 Create a new formula variable

Step 2. In the pop-up screen that appears after selecting New Variable, provide the technical name and description of the formula variable in the General tab (Figure 3). Then choose the Processing By and Reference Characteristic

values shown in Figure 3.

Figure 3 Select values for the Processing By and Reference Characteristic fields

The formula variable is created for the GL account hierarchy. In a hierarchy, there are text nodes known as non-posted nodes (identified by folders in the GL account hierarchy in Figure 1) and actual GL accounts, known as posted nodes (identified as green triangles below the folders in the GL account hierarchy in Figure 1). Because this formula variable is created for the GL account hierarchy, I used G/L Account as the reference characteristic. I selected processing by Replacement Path because both non-posted (text nodes) and posted nodes (GL accounts) are required to define an individual cell.

Step 3. From the Replacement Path tab select the Replace Variable With, Replace With, and the offset values as

shown in Figure 4. The formula variable replaces the text nodes with numeric values. Use the option InfoObject for Replace Variable With and External Characteristic Value Key for Replace With to replace the text nodes with numeric values.

Figure 4 Set up the replacement rule for the formula variable

SAP NetWeaver BW generates the technical name of the text nodes by concatenating the FSV technical name and a sequential random number. SAP NetWeaver BW uniquely assigns the numeric numbers to each text node, and thus no two text nodes have the same technical name. With the help of formula variables, you can replace the text nodes with the unique sequential numbers from the technical text node name.

Offset Start determines the start of the numeric value. I entered Offset Length as 4 because it is safe to assume that the income statement/balance sheet hierarchy will not have more than 9999 text nodes. If you apply this process to any other management report that has more than 9999 text nodes in a hierarchy, you need to select the offset length

accordingly. In Figure 5, the technical name of the non-posted nodes follows the naming convention of four letters (the FSV technical name from SAP ECC) followed by a sequential random number.

Note

The 0HIER_NODE InfoObject (used for text nodes in a hierarchy) is treated as an external characteristic for the characteristic InfoObject with an active hierarchy. This is important because you can replace external characteristics using the replacement path processing type for formula variables.

Figure 5 A section of the GL account hierarchy showing technical names for text nodes

Step 4. Create the second formula variable for the posted nodes of the GL account hierarchy, using the settings

shown in the General tab in Figure 6.

Figure 6 Set up the second formula variable

Step 5. From the Replacement Path tab select the Replace Variable With, Replace With, and the offset values as

shown in Figure 7.

Note

If you select Interpret Result as Boolean Value, the formula variables are replaced either with 1 or 0 depending on whether the formula variable has been successfully populated or not. In my example of the formula variable ZHVAR_CK, if Interpret Result as Boolean Value is checked, then the formula variable returns 1 for the posted node and 0 for the text node.

Figure 7 Set up the replacement rule for ZHVAR_CK

In this example, the formula variable ZHVAR_CK is replaced with Key instead of External Characteristic. This formula variable replaces the posted nodes with GL account master data values. Because the GL account is compounded with the chart of accounts, the technical names of the nodes are populated by concatenating the master data values of the chart of accounts and the GL account.

As shown in Figure 8, the technical name of the posted nodes follows the naming convention of four letters (LCOA from chart of accounts) followed by the master data value of the 0GL_ACCOUNT InfoObject. Offset start determines the start of the numeric value (e.g., after the four letters and defined as 4). In this example, the offset length is 10 because the 0GL_ACCOUNT InfoObject has a length of 10. The offset length is for the node technical name and not for the actual InfoObject.

Figure 8 A section of GL account hierarchy showing the technical values of posted nodes

Depending on the offset length, you can replace a portion of the GL account master data values with numeric values. For example, accounts starting with 22 are profit and loss (P&L) accounts and the identifier for sales accounts is 11. In this case, the first four letters of the sales GL account are always 2211. You can opt to choose the offset length as 4, so that all the sales accounts are replaced with the numeric value of 2211. This helps you identify sales accounts more quickly in the GL. Using 2211 also enables you to write a less complex formula if you have to perform anything specific to sales accounts in the BEx query. Depending on the design of the chart of accounts, you can change the formula variable offset length to handle the requirement more flexibly.

Step 6. Create the query using BEx Query Designer. I created a sample query to simulate the business scenario described in approach (b). The GL account InfoObject 0GL_ACCOUNT is restricted with the sample GL account hierarchy. I created two calculated key figures, Hier Var EC and Hier Var CK, to explain how the formula variables

work with the sample hierarchy created for this example (Figure 9).

Figure 9 Sample query with two calculated key figures: Hier Var EC and Hier Var CK

In the Rows section in the sample query, I used G/L Account as the drill-down characteristic and restricted it with the financial statement version (extracted as a GL account hierarchy in SAP NetWeaver BW). In the Columns section, I used sample restricted and calculated key figures for the purpose of this business scenario. The following sections explain each restricted and calculated key figure in detail.

In Figure 10, refer to the first column highlighted in light green. The calculated key figure is created using the formula variable ZHVAR_EC (formula variable for text nodes). This formula variable returns the numeric values from the technical name of the text nodes. For the posted nodes (GL accounts), this variable returns X (error) because this variable is based on external characteristics.

Figure 10 Query results with the sample test data

Next, refer to the second column, highlighted in dark green. I created the calculated key figure using the formula variable ZHVAR_CK (for posted GL account nodes). This formula variable returns the GL account master data values, excluding the chart of account value. For the non-posted nodes (text nodes), this variable returns 0 because it is based on the characteristic key (the text nodes’ technical values are not available in 0GL_ACCOUNT master data).

Note

The first two dummy columns in the report should be hidden while creating the production query. These two columns are unhidden in the sample query to explain how the formula variables work with the hierarchy. Also, Figure 10 shows the technical name as the description because text master data was not loaded for the GL accounts for this example.

In Figure 10, the Sales column shows the basic key figure 0SALES from the InfoCube. The % of NetSales column shows the different components of the P&L hierarchy as a percentage of NetSales. This column has values populated in all the cells. However, as per the business requirement, all elements of NetSales, including the text node, shouldn’t display any value for % of NetSales. The % of Net Sales – Final column displays the same values as the % of NetSales column, except for the columns highlighted in orange (text node NetSales and all posted nodes under NetSales).

How to Create the NetSales Restricted Key Figure

The hierarchy node is restricted to the NetSales text node (refer to node ZFSV4 in the GL account hierarchy in Figure 1) and key figure is restricted by the basic key figure Sales. The % of NetSales calculated key figure is created by using the %A function available in BEx Query Designer. The % of NetSales calculated key figure is defined as (‘Sales’ %A ‘NetSales’). To create the calculated key figure % of Net Sales – Final use the definition in

Figure 11.

Figure 11

Define the % of NetSales – Final calculated key figure

The definition has two parts:

NOERR (((‘Hier Var EC’ <> 4) * ‘% of NetSales’))

The formula variable ZHVAR_EC replaces the text nodes with the corresponding numeric values from the technical name (as highlighted with light green in Figure 10). The technical name of the NetSales text node is ZFSV4. The formula variable ZHVAR_EC returns 4 for this text node. Condition (((‘Hier Var EC’ <> 4) returns 1 for all text nodes except NetSales. The result of the first part for a text node (except NetSales) is equal to the % of NetSales key figure. For a posted node, variable ZHVAR_EC returns X, which is converted to 0 by using the NOERR function. Thus, the result of this section of the formula for a posted node is 0.

(‘Hier Var CK’ > 0) * ((‘Hier Var CK’ < 51) XOR (‘Hier Var CK’ > 60)) * ‘% of NetSales’

Formula variable ZHVAR_CK replaces the posted nodes with the corresponding numeric value from the technical name (as highlighted in dark green in Figure 10). Condition (‘Hier Var CK’ > 0) returns 0 for all text nodes because the formula variable ZHVAR_CK returns 0 for all text nodes (as highlighted in dark green in Figure 10). The result of this section of the formula for a text node is 0. For a posted node condition (‘Hier Var CK’ > 0) returns 1. Condition ((‘Hier Var CK’ < 51) XOR (‘Hier Var CK’ > 60)) returns 1 if one of the conditions is true. For example, for a node with GL Account 51, this condition returns 0 because both conditions used in the XOR statement are false.

Help Your Queries Run More Quickly Using the OLAP Cache  

by Gary Nolan, Platinum BW Consultant, SAP America, Inc.

Your users can benefit from one another when they run similar queries thanks to the online analytical processing (OLAP) cache. It is designed to store the results set used by certain queries to improve system performance. The system quickly reads from past query results stored in the cache rather than from the InfoCube or aggregate. It must be maintained properly along with the queries that use it for the OLAP cache to reach its fullest potential. Here's how.

Categories: BEx, Performance, Reporting

Key Concept

Frequently used queries, if configured to do so, are automatically saved into the OLAP cache when the user initially runs the query. The same or similar queries are read from the OLAP cache after the initial query is run, typically providing better performance. Storage options are available for query results and can be optimized to best meet the needs of the system as well as for the individual queries.

It goes without saying that all BW customers are concerned about query performance. Of all the tools and methods to improve query performance, one of the most underused is the online analytical processing (OLAP) cache.

The OLAP cache was introduced in BW 2.0B expressly to improve query execution. It allows data that supports certain queries to be stored or “cached” in the main memory or distributed to an application server or a network. After a query is run, the results are stored and available to similar queries that run at a later time. The OLAP cache offers significant performance gains over other techniques such as aggregates when it is configured correctly. Moreover, its benefits can be expanded if qualifying queries are enabled to fully access cached data.

As with most performance improvement techniques, however, costs are associated with caching. Penalties are incurred when data is organized and retained in the cache. It is important to make sure the OLAP cache is configured properly to minimize any drag it may place on the system. To learn about the essentials of configuring the OLAP cache, refer to Ned Falk’s article, “OLAP Cache: Does It Have to Be Configured?” in the April 2004 issue of BW Expert.

I will provide you with an overview of the storage options available with the OLAP cache. Then I will introduce you to a couple of new terms and discuss how to manage your cache. Lastly, I will show you how to make sure the queries you’re running are best able to access cached data so they can perform at their highest level. In an upcoming article for BW Expert, I will discuss how to use a reporting agent to prefill the cache in batch, providing more efficient cache usage and better performance.

Choose the Cache Mode

The query cache mode determines if and how a BW system actually caches query results. It is set either as an InfoCube default or individually by query. The best caching options depend on several factors including how often a query is requested, the query complexity, and how often data is loaded. In general, queries that make good candidates for caching are complex and popular with users and run on a data set that is not often refreshed.

Queries created and run by a small user group that never uses the same query variables twice do not execute faster from the cache. There is no repeated query data set to be read and the system incurs the overhead of filling a cache that is rarely, if ever, employed. It would make more sense to turn off the cache for this type of query. The query author must determine if multiple users run the same query for the same results sets before the data is reloaded. The cache is not automatically turned on or off by the system.

Note that data in the cache is stored until the system determines that it is invalid. Cached data automatically becomes invalid whenever data in the InfoCube is loaded or purged and when a query is changed or regenerated. Once cached data becomes invalid, the system reverts to the fact table or associated aggregate to pull data for the query.

Use the Query Monitor via transaction RSRT to set the cache by query (Figure 1). The mode determines if the cache is used and there are five different modes of query cache.

Figure 1 Cache settings in the query (transaction RSRT)

0 Cache Is Inactive — no cache is available for queries in this mode.

1 Main Memory Cache Without Swapping — entries are cached into a shared memory and cannot be moved (or swapped) to a flat file or cluster table when the memory cache is full. If the memory cache is full, then no cache is saved.

2 Main Memory Cache with Swapping — query results are cached into shared memory and swapping data is supported.

3 Persistent Cluster/Flat File Cache for Each Application Server — entries are saved into a cluster table or flat file on each application server. In a multi-server environment, the cache is saved on each application server.

4 Persistent Cluster/Flat File Cache Across Each Application Server — a cluster or flat file is shared by all application servers to query results. This setting is preferred when multiple application servers are used in a BW landscape.

You can see the cache settings for all queries in your system using transaction SE16 to view table RSRREPDIR

(Figure 2). The CACHEMODE field shows the settings of the individual queries. The numbers in this field correspond to the cache mode settings above.

Figure 2 Cache mode settings for queries in table RSRREPDIR (transaction SE16)

To set the cache mode on the InfoCube, follow the path Business Information Warehouse Implementation Guide (IMG)>Reporting-Relevant Settings>General Reporting Settings>Global Cache Settings or use transaction

SPRO (Figure 3). Setting the cache mode at the InfoCube level establishes a default for each query created from that specific InfoCube.

Figure 3 Cache setting in Customizing by InfoCube

Main Memory vs. Application Server

Notice that the cache options allow information to be cached either in main memory or persistently on an application server. Main memory cache saves query results sets in the system’s shared memory, which takes memory resources away from other BW processes. Persistent cache keeps a persistent copy of the cache in tables so cache can be shared across users, and even across application servers. More information about these settings is available in Falk’s “OLAP Cache: Does It Have to Be Configured?” article noted earlier.

Main memory cache is typically not used in a large BW environment because it requires a great deal of memory to be allocated to cache. In an active BW environment, persistent cache is used across application servers. This allows the cache to be saved either to a cluster table or binary large object (BLOB) table. BLOB tables allow for faster access than cluster tables. If available in your release and database, the optimal setting is to cache across application servers on BLOB tables. In Support Pack 22 of BW 3.0B, all supported databases can use BLOB tables.

Subset Cache

Now that you have a basic understanding of what the cache does and where it stores information, let’s look at how it saves data. I’ve coined a couple of terms to describe two key components of the cache functionality: verbatim and subset cache. These two terms describe the two ways the system accesses its cache.

The system uses what I call verbatim caching to store data once the cache is enabled. All queries not set to option 0 use verbatim caching and enjoy its benefits when subsequent queries run that match the original query exactly.

The subset cache refers to reading a smaller results set from a larger buffered result cached from a previously run query. The subset cache typically provides better performance than verbatim cache because more queries are eligible. All queries that are a subset of larger queries will use the subset cache, while the verbatim cache is only invoked when there is an exact query match.

Note that it is important to make sure that subset cache is enabled whenever possible because if it’s not enabled and the cache is turned on, the system automatically reverts to verbatim cache. I will explain later how to make sure that the subset cache is enabled.

Note

You can find more information on subset cache in SAP note 751402.

Let’s take a look at an example of subset cache. After setting the cache mode to one of the four options, I run a query of material group sales for the last fiscal year drilled down by division. The results set for that query is saved into the cache. Another user runs a similar query for division 10, also for the last fiscal year. The system knows that division 10 is in my results set, so it uses the subset cache for the second query. The second query benefits from my earlier query run, yielding better performance and quickly freeing up the system for more complex queries.

As long as the larger buffered query includes a later query’s data, the system reads from the cache instead of the aggregate or InfoCube fact table when the subset cache is employed. Because data in the cache is available, the system does not have to go to the source, making the process much quicker. Except for the quicker performance, the user experiences no difference between a query using the cache and one that doesn’t.

Subset Cache Requirements

For the subset cache to be active, data cached for the initial query run must appear in its result area. In the example above, the division category must be in the results set of the original query for the system to use the subset cache when running the second query. It must appear either in the rows or columns in the results set of the query. If the division category is not shown in the results set of the report, then it is ineligible for the subset cache.

Only queries that use free characteristics can benefit from the subset cache and results set data must appear either in the rows or columns. Query filters and values in the variables not shown in the results set are not saved, so they are not available to the subset cache. The bottom line is that you must have the values appear in the results set for the system to use the subset cache. In my example, the division category must be in the results set of the original query for the system to use the subset cache when running the second query for division 10.

If I run a sales query for the past fiscal year and use the filter criteria of material group, the material group is not the drill-down characteristic for the query and no material group data is shown in the results set. In this case the query is not eligible for use in the subset. If another query runs for a specific material group for the past fiscal year, the system cannot use the subset cache because the material group is not shown in the results set.

Note

The system will never merge caches or read from two different cache entries. To use the cache, the system must read from one cached query.

Enable the Subset Cache in BEx

Most queries use variables to allow dynamic filtering, but settings in the BEx variable editor allow the data to be available in the subset cache. To use the subset cache, check the box for the Can be changed in query navigation

setting on the variable creation screen of the Business Explorer (BEx) for every variable (Figure 4). Once set, the entered values in the query can become values in selection conditions in the free characteristics rather than filter values.

Figure 4 Variable setting Can be changed in query navigation in the variable creation screen in BEx

If a variable in a query does not have the Can be changed in query navigation setting checked, its associated characteristic is ineligible for subset cache and uses only verbatim cache. This limits the usefulness of the cache.

Let’s go back to my earlier example. Now, I run a query of material group sales drilled down by division for the prior year and prompt users for a division entry in the variable screen. A user enters in division 10 and 20 in the initial query and the results are saved into the cache.

Another user then runs the same query for division 10. If the division variable setting was set to Can be changed in query navigation, the system knows that division 10 is in my pervious cached results set, and thus uses the subset cache for the second query. If that option was not set for the division variable, the system would not use the cache at all because there is no data in the verbatim cache and the subset cache is not enabled.

It is advantageous, then, to have all your variables set to Can be changed in query navigation, but it alters query behavior slightly. If turned off, variable values act as a filter and are not shown on the query. The variable values are filter values only and cannot be altered. If the option is on, the variable values appear in the free characteristic drill-down as a selection criterion and can be changed by selecting filter values while running the query.

You can check all existing variables in your system to see which are changeable during query navigation. Use transaction SE16 on table RSZGLOBV. Find all version A variables (they have an A in the OBJVERS field) and check the DYNCHANGE field. An X in the DYNCHANGE field means that the variable’s Can be changed in query navigation setting is active and eligible for subset cache (Figure 5). If the field is blank, then the variable’s Can be

changed during query navigation setting is inactive and ineligible for subset query cache.

Figure 5 Variable table RSZGLOBV with DYNCHANGE entries

Using the subset cache in BW can substantially improve query performance. Monitor the statistics InfoCubes to get an idea of the best cache candidates and set a baseline service level for these queries. Implement the cache and monitor the query for improved runtimes.

Home Page Framework Integrates Your Dashboards for Easy User Access  

by Brian Hether, Manager of Data Warehousing, The Washington Post

A home page framework links your dashboards and BW tools such as BEx Browser and BEx Analyzer. This framework offers some portal benefits to those who have not yet implemented SAP NetWeaver Portal. Find out how to create the home page framework and set up your dashboards so your users can quickly switch from the dashboards to the BW tools.

Reporting, Web Application Designer

SAP provides several tool sets to organize information for users, including BEx Browser for query access; BEx Analyzer to analyze queries in Microsoft Excel; BEx Web Analyzer to display query results and schedule queries to run; and Web Application Designer to create HTML-based Web templates and dashboards to display query results.

Providing quick and easy access to key information when you are supporting many departments can be challenging. How do you organize access to 500 different queries so all parts of the business have the same ability to zero in on what they need? One way is to develop an indexed home page from which the users can jump into subsequent levels of detailed information. From this home page, you can present users with answers and make it easier for them to find additional information.

For example, when reviewing data in dashboards users may need to access tools such as BEx Browser, BEx Analyzer, BEx Web Analyzer, and Web Application Designer (Web AD). The basic dilemma is that these tools are not integrated in a way that allows users to navigate seamlessly among them. You can go to BEx Browser, run a query, and end up in BEx Web Analyzer. However, you cannot then go to a dashboard. From a dashboard you can see query results, but you can’t return to BEx Web Analyzer or BEx Browser.

When designing a solution to overcome this, I had several other factors to consider at my company — we did not have SAP NetWeaver Portal to integrate the tools, we wanted zero footprint (no additional software installed on users’ desktops), and the access and navigation steps for the users had to be easy. The home page framework satisfies those needs and provides a way for users to navigate between the BW tools and dashboards. To see how this option compares with using a portal, see the sidebar, “Using a Home Page URL vs. SAP NetWeaver Portal.”

First I’ll explain how to set up the home page framework, and then I’ll show you how to organize multiple master dashboards using Web AD and BEx Web Analyzer in BW 3.5. The master dashboard allows users to view query results from the first few tabs and run queries from the last tab, which then renders results in BEx Web Analyzer. From here, they can click on the Go to Analytics Home

link to return to the home page to choose a different dashboard. Users cannot get lost or stuck in a dead-end with this framework because both the master dashboard and BEx Web Analyzer have links to take them back to the Analytics home page.

Since we developed this process in BW 3.5 we have upgraded to SAP NetWeaver 7.0. The framework works well in this new environment, but we have not yet recreated the steps with SAP NetWeaver BI 7.0 tool sets. The steps as outlined are for BW 3.5 users or sites that have SAP NetWeaver 7.0 without SAP NetWeaver Portal installed.

This design is scalable to dozens of master dashboards with hundreds of tabs. It does not need a portal, yet it has some of the benefits associated with portals — for example, the user simply needs BW login credentials and a browser. The dashboards in this article work on Internet Explorer 6.0 and Firefox 2.0.

Develop the Home Page Framework

I’ll use the example of setting up an Analytics home page for three lines of business: Automotive, Real Estate, and Jobs. The framework consists of a home page from which you can call multi-tab

Figure 1). From the dashboards, you use the last tab to run queries that BEx Web Analyzer renders. Both the dashboards and BEx Web Analyzer have URL buttons to take the user to the Analytics home page.

Dashboard framework path

Glen Leslie’s article, “Quickly Build Impressive Dashboards in SAP BW 3.5,” (Volume 2, Number 9) in the BW/BI Expert knowledgebase describes how to use Web items in Web AD to create Web templates. He also introduces the concepts of master templates and sub-templates. He further defines the sub-templates into headers, footers, and tabs.

First let me show you how to use Web AD to create a simple home page consisting of URLs that you activate by clicking on a button. The URLs take you to individual master dashboards that have a specific business theme. In this example, I’ll show you how to segregate the three areas of the business into buttons that lead to the main dashboards.

I have three distinct lines of business so I’ll use Web AD to insert a table with two columns and two rows, which gives me four cells to use. I’ll leave one cell blank. To insert the table, click on the insert table icon, and then click on the OK button. Then, insert another table with one row and one column in each table cell in which you want a button. This allows better format control of the

buttons and of the overall page design by forcing any format changes (e.g., size or spacing) to stay within the designated space and not run into the other parts of the table. Figure 2

the table structure should look like.

Two-by-two table with one-by-one tables inserted into three of the cells

When you’ve finished setting up the table, create the header for the page. This home page becomes the starting point for all your users, so you may want to enlist a graphics expert to create an appropriate header with your company logo. I’m just using text for my header – Analytics Home Page.

HTML tab in Web AD to see the page’s HTML code. Insert the button code in Figure 3 into the HTML code at the point where the tables are defined. In Figure 3, the last line shows the color assignment (#800000), the size (3), and the text set to Automotive.

”BEx?sap- language=EN&bsplanguage=EN&CMD=LDCO&template_id=Z_MAST_AUTO_DASH”

> Automotive

Button code

Repeat this process for the other two buttons for Real Estate and Jobs. After you finish, the layout page looks like Figure 4. You can view the full HTML code for the page in the

www.bi-expertonline.com.

Finished layout of the Analytics Home Page

Set Up the Master Dashboard

Each time you click on a button on the Analytics home page the system calls up a master dashboard. Adding a link to the standard header allows the user to go back to the home page easily.

Following the design standards that Glen Leslie’s article outlined, place a button in the standard header sub- template that appears on every dashboard. In my example, the standard header is a single line, multi-column table. I placed the URL link in the last cell. In this case, the URL link invokes the template ID named Z_MAST_ANALYTICS_HOME_BWEXPERT. The button code to add

. Insert it into the code where the tables are defined, as you did with the code in Figure 3.

”BEx?sap- language=EN&bsplanguage=EN&CMD=LDCO&am

p;template_id=Z_MAST_ANALYTICS HOME_BWEXPERT”

> Go To Analytics Home Page

Code to add URL link

A multi-tab dashboard design can have two or more tabs, depending on the business area complexity. Regardless, a best practice is to make the last tab a role-based tab so users can run queries themselves. This also allows power users and other query developers to propagate queries to the correct dashboard because you can assign a unique role to each master dashboard. In my example, the automotive master dashboard has an automotive role assigned to the last tab.

Alternatively, if I didn’t have a requirement to secure one department from another, I could assign a generic role to each dashboard from which many folder options would be available (e.g., one folder would be for automotive queries). This option is useful when all departments are allowed to run queries from any line of business — for example, if you permit the automotive side to run queries that show real estate results.

Role Menu in the Standard tab in the upper left side of the screen (Figure 6). Drag and drop it to the tab that you are working in. To assign a specific role to the Web item, click

tab and select List of Roles. This brings up the list of all the roles you can use for your Web page. Select the one you need and click on the OK button.

Select the role for your role-based tab

When the dashboards are in use, running a query from the Role tab opens the BEx Web Analyzer, which renders the query results. The last step to the framework is to add a link to BEx Web Analyzer that takes users back to the Analytics home page when they are done with the query.

Add a Link to BEx Web Analyzer

To add a link to the master dashboard, use the standard BEx Web Analyzer template called 0ANALYZER, which is the default template for rendering queries. 0ADHOC is another popular template 0ANALYZER, but I like 0ANALYZER because it provides links to save and execute query views. 0ADHOC lets you save query views, but you cannot run previously stored views

0ANALYZER template, go to transaction SE38 and execute program RS_TEMPLATE_MAINTAIN. Enter 0ANALYZER in the Technical Name field and execute. Then click on the save as icon and enter a new name, such as ZTWP_0ANALYZER. Refer to David Fox’s article, “Create New BW Web Printing Controls Your Users Will Love,” (Volume 2, Number 3) in the

www.bi-expertonline.com for the details about this step.

Now rerun the program RS_TEMPLATE_MAINTAIN and call up ZTWP_0ANALYZER. Looking through the HTML code, you can see that ZTWP_0ANALYZER is really a master template that calls several sub- templates for various parts of the page. For this exercise, you need to edit the sub-template 0ANALYZER_LINKS to insert the new link that takes the user back to the Analytics home

ZTWP_0ANALYZER, use the search icon and find 0ANALYZER_LINKS. Change the name to ZTWP_0ANALYZER_LINKS. The line you are editing should look like the code

when you are done.

ITEM: ANALYZER_LINKS

Edited code for link

Save your work and using RS_TEMPLATE_MAINTAIN again, edit ZTWP_0ANALYZER_LINKS. Insert the code in Figure 8 right above the

command that appears four lines from the bottom and save. Figure 9 shows what the ZTWP_0ANALYZER_LINKS template should now look like. You can see the new link to the far right.

EN&CMD=LDCO&template_id=Z_MAST_ANALYTICS_HOME_BWEXPERT” >

GoTo Analytics Home Page

Figure 8 Code to add to ZTWP_0ANALYZER_LINKS

Figure 9 ZTWP_0ANALYZER_LINKS with the Go To Analytics Home Page link

The last step is to make the ZTWP_0ANALYZER template the default template so all users who run a query get this BEx Analyzer version. Using the transaction SPRO, follow IMG menu path SAP NetWeaver>SAP Business Information Warehouse>Reporting-relevant Settings>BEx Web>Set Standard Web Templates. Execute the line item and enter ZTWP_0ANALYZER for the Ad-hoc Analysis field (Figure 10).

Figure 10 Name the new default template

Now that all the pieces are in place the Analytics home page is ready to use (Figure 11). From Web AD, execute the Analytics home page master dashboard and save the URL to your favorites in the browser. You can also now email this URL link to other BW users or publish the link to a portal or intranet.

Figure 11

Completed Analytics home page

Figure 12 shows a sample of a master dashboard with a standard header template that includes a link back to the Analytics home page, a standard footer template with technical information, and seven sub- templates.

Figure 12 Real Estate Advertising Unit (RAU) master dashboard

Using a Home Page URL vs. SAP NetWeaver Portal

Using a home page URL takes less time than setting up SAP NetWeaver Portal — you can get BW up and running fast without waiting for the portal to come online. The home page approach also requires fewer resources. The BW team can set up the home page URL themselves because it requires only light HTML coding.

Additionally, by making use of the zero footprint dashboard design, you are positioned to take advantage of a portal product should you implement one in the future. The home page design allows you to publish BW information as an iView from Web AD. When you have a portal in place, you can integrate the iView into it.

However, the home page approach has some drawbacks. For example, you cannot secure the dashboards by name, which means that all users can access the dashboards. Instead, you enact security at the query or InfoProvider level. Users can click on a link from the home page, but they receive an authorization failure message on the dashboard for individual queries.

To alleviate this problem, use the Role item filtered for Web templates. For this process, you create a series of folders under a particular role and publish master dashboards to the folders. A user then opens the folder on the home page and sees a master dashboard link. In effect, using Web AD to assign the role Web item as the home page mimics BEx Browser.

Note

For more information about this topic, attend SAP Education course BW305: Business Information Warehouse: Reporting and Analysis (SAP BW 3.5) or BW306: BI Enterprise Reporting, Query, and Analysis: Part 2 (SAP NetWeaver BI 7.0).

How to Report What Hasn't Been Selling  

by Rob Oliver, BW Team, Barclays Capital

BW reports are great for situations when things are in flux, but what happens when conditions are static? You can deliver sales figures, for example, for products that are selling but it's more difficult to report on products that are not moving. Because you can use a MultiProvider that employs InfoObjects as InfoProviders, BW 3.x provides the technology. Here's what you need to do to set up the objects in the Administrator Workbench and create the queries in the BEx Query Designer to generate these types of reports.

Categories: BEx, Reporting

Key Concept

When activated as an InfoProvider, InfoObjects have default key figure Number of Records, which has a one value for each record in the master data table. Designing a query that includes the Number of Records value allows you to more accurately report on dynamic business situations.

During my first BW implementation in 1999, one of the critical questions that cropped up was: “Gee that’s a great system, but can it tell us what we’re not selling?” The company was interested in sales figures, but it also wanted to identify what products were not moving as well as those customers that weren’t buying. It could then determine why and remedy the situation. For various reasons, both system and budgetary, the team I was on five years ago was unable to deliver this type of reporting with BW 1.2B. The question, however, stuck with me.

Recently, the business at my current employer made me revisit the issue. This time, with a little ingenuity and the feature set offered in BW 3.x, I discovered that it’s a simple process to track what’s selling and what’s not. By using an InfoObject as an InfoProvider, I found a key figure value that supports reporting on items that do not have values posted against them.

The approach is based on a feature in BW 3.x that allows the use of InfoObjects as InfoProviders, and is accomplished in four basic steps:

Identify the InfoObjects to use for non-posted reporting (product, customer, etc.)

Set the appropriate objects as InfoProviders

Create a MultiProvider with these InfoObjects and the relevant InfoCube

Create a query with conditions to display only those items with zero activity

Let me walk you through these steps and show you some things to watch out for. First, I’ll show what objects you’ll need to create and maintain in the Administrator Workbench. Then, I’ll explain how to create the query you’ll need in the BEx Query Designer. With very little effort you’ll be able to give your users reports on both what’s selling and what’s not.

How It Works

Before I get into the actual maintenance, let’s look at how the system can deliver this type of information. When activated as an InfoProvider, InfoObjects have a default key figure called Number of Records with a value of one for each record in the master data table. This default key figure can be used for reporting purposes.

Because InfoObjects in BW 3.x can be set up as InfoProviders, an unrestricted query can be designed to use the Number of Records values and display every record in the master data table. Similar queries can also be created to report on the master data with filters, variables, drill-downs, etc., so that they are performed on an attribute such as a list of all products within certain product groups.

Setting InfoObjects as InfoProviders by itself won’t allow users to report on items that do not have values posted against them, however. You also must create a MultiProvider that includes an InfoCube that uses the same InfoObject defined as the InfoProvider to record facts. With this arrangement, you can design a query that not only sees when something has posted in the fact table, but also when it has not.

The MultiProvider allows you define a query to display all the products or customers, not just those with values in the InfoCube. This is accomplished by including a column for the Number of Records values along with another column that has the sales values, or posted amount, or whatever key figure is required. You then set a condition for this column when designing your query that only displays zero values. Once this condition is activated, presto, the zero value records are displayed.

What to Do

InfoObjects for the non-posted values you want to display must first be activated as InfoProviders so they will include the Number of Records default key figure. Maintain the InfoObject either from the InfoObjects tab on the Administrator Workbench or go directly to the maintenance screen via transaction code RSD1. Note, for this example I have chosen to use object 0PROFIT_CTR.

Next, go to the Master data/texts tab for the InfoObject (Figure 1). The check box near the bottom of the screen with the description Character. is data target/InfoProvider is grayed out. While the flag cannot be selected, it can be updated depending on the entry in the InfoArea field adjacent to the text. Defining an InfoArea as an InfoProvider in

the Administrator Workbench sets the flag when the refresh icon is clicked on (Figure 2).

Figure 1 The check box is grayed out but can be updated by the entry in the InfoArea field

Figure 2 When an InfoArea is defined as an InfoProvider and refreshed, the flag is set

After the InfoObject is maintained as an InfoProvider, create the MultiProvider with the relevant InfoCube and InfoObject. Right- click on the InfoArea where the MultiProvider is being grouped and select Create Multiprovider. Select the required InfoCube in the InfoCubes tab, then click on the InfoObjects tab and set the flags for the object (or objects) to be checked for non-posting. For this example, InfoObject 0PROFIT_CTR, and an InfoCube containing profit center transactions have been selected.

Clicking on the check mark at the bottom of the screen displays the InfoCube Creation screen. Proceed as usual creating your InfoCube by selecting the required objects. Keep in mind, however, because the purpose of this new InfoCube is to identify items that haven’t been posted, the number of objects should be kept to a minimum. For this example, it is restricted to only InfoObjects 0PROFIT_CTR and 0ACCOUNT, along with their compounding objects

(Figure 3).

Figure 3 Keep the number of objects to a minimum when creating the MultiProvider

Click on the Dimensions... button to create one dimension for each object and its compound key. Assign the objects to the appropriate dimensions in the Assign tab, and click on the green check mark to return to the main InfoCube definition screen.

Use the Identification button to access the Identification of Characteristics Involved screen (Figure 4). Set flags

in the “Equal to” column (Equ...) for the objects available in the MultiProvider. Most will be selected.

Figure 4 Set flags in column Equ... for the objects available in the MultiProvider

In this example, note that 0PART_PRCTR has not been selected. Because the data is being examined to determine which centers have not been posted to directly, partner profit centers have not been included. 0PART_PRCTR may be relevant for other analyses, but I excluded them from this example for purposes of simplicity.

After making the character selections, click on the check mark icon to get back to the main definition screen, then click on the same icon in the next screen, and activate the InfoCube. Refreshing the InfoProvider screen displays the

new MultiProvider in the Administrator Workbench (Figure 5).

Figure 5 The new MultiProvider is displayed the in the Administrator Workbench after the InfoProvider is refreshed

Note

Because this development involves existing InfoCubes and data objects, and only a virtual InfoCube — the MultiProvider — has been created, there is no need to load any data before creating a query.

Define the Query

Once the InfoCube is activated, you create the query in the BEx Query Designer that returns data only for the non-posted profit centers. Include only those objects such as filters, free characteristics, and rows that exist in both InfoProviders. Note in Figure 6 that only Controlling Area, which includes the InfoCube and a compound key to

0PROFIT_CTR, and 0PROFIT_CTR have been included.

Figure 6 Include only the objects that exist in both InfoProviders in your query

Other objects that may be required such as account numbers can be included as restrictions within the key figures so that they only restrict the relevant InfoProvider. For example, 0ACCOUNT can be included within the first three columns to restrict the key figures because without it, the accounting postings could all balance to zero. To avoid this, the key figures have been split into credits, debits, and balances.

The Key Figure column for the master data provider is relatively simple. It includes just the key figure Number of Records (1ROWCOUNT) that provides a value of one for every master data record stored on the BW system. As a result, when a query is executed, a record will be returned for every master data item even if there are no transactions.

The Non-Posted column uses the formula shown in Figure 7. It records a value of one for the sum of absolute values that is not equal to zero. This column is used by a condition to display only records where the value of column

Non Posted Center is not equal to one.

Figure 7 The formula yields a value of 1 for the sum of absolute values not equal to 0

Create the required query condition by clicking on the conditions icon and selecting New. Enter an appropriate description and set the single characteristics or combinations of characteristics button. Check the Profit Center

box and click on the New button on the right.

Note

Absolute values (ABS) have been selected in the Mathematical Functions folder to accommodate instances where the sum of credit and debit values may equal zero for certain centers.

This activates the pull-down boxes grayed out in Figure 8 where you select the key figure on which the condition operates. In this example, the Non Posted Center formula is selected for the Structure column along with Not Equal to for the Operator column and 1 is entered for the Values column. Clicking on the Transfer button moves the

selection up as shown below. Click on OK and save the query, which makes the condition effective when the query is executed.

Figure 8 Clicking on the Transfer button moves the column selections up

The end result is shown. If required in Figure 9, the columns can be hidden so that the report just returns a list of centers.

Figure 9 A report with items that do not have items post against them. If required the columns can be hidden so

that the report just returns a list of centers.

I recommend that when you first deploy this functionality, you keep it simple. It can then be applied to InfoCubes and InfoObjects as required by the business to return more information on products or clients, for example, which are not generating sales.

How to Select the Best Tool for Developing Management Scorecards from SAP NetWeaver BW  

by Derek L. Johnson, Program Manager — Analytics and Reporting, Delivery Operations, SAP America, Inc. (March 2009)

When you don’t need a comprehensive management scorecard application, consider options beyond SAP BusinessObjects Strategy Management or Strategic Enterprise Management-Corporate Performance Monitor Balanced Scorecard. Depending on your requirements, BEx Web Application Designer, SAP NetWeaver Visual Composer, or Xcelsius can also address your company’s management scorecard requirements. Find out when to use each option and how to create optimized scorecards for your management teams, with particular emphasis on using Xcelsius.

Categories: BEx, Reporting, SAP BusinessObjects, SAP BusinessObjects Planning and Consolidation, SAP NetWeaver Visual Composer

Key Concept

A management scorecard provides a broad overview of a company’s performance by comparing its results against internal goals or external benchmarks. Management teams can then use this information to help evaluate their performance and assess which areas may need additional attention. Unlike a comprehensive solution such as the Balanced Scorecard — which aligns with the company’s strategies and integrates with goals, initiatives, and value drivers to gain the benefits of managing your business with dashboards — the management scorecard typically highlights problems, but does not reveal the root cause drivers for further exploring and addressing the issues.

Now that many companies have broadly implemented SAP NetWeaver BW to extract data from their SAP and non-SAP systems, they are moving from standard reports to analytics, dashboards, and management scorecards. This evolution is important as companies start to look at their strategic objectives and analyze how their business initiatives and processes are aligned to meet their goals. The management scorecard is the final report card for many companies to inform management about how their company is performing.

Note

As of the writing of this article, SAP has moved to a new naming convention for SAP NetWeaver Business Intelligence (SAP NetWeaver BI). This is now SAP NetWeaver Business Warehouse (SAP NetWeaver BW).

SAP BusinessObjects Strategy Management and Strategic Enterprise Management-Corporate Performance Monitor (SEM-CPM) provide a comprehensive solution for managing business strategy that includes integrating a company’s goals, strategy, and initiatives into an actionable plan. However, many companies do not need to wait to implement these more comprehensive solutions to use their SAP NetWeaver BW data to track their performance. Also, you do not need to rely on spreadsheets to display this information when SAP provides a richer standard toolset to manage and display this information.

It can be difficult to determine the right tool to compose a management scorecard. Choosing the right tool largely depends on your available tools, skilled resources, and your organization’s sophistication with these types of applications.

I’ll provide a framework to help you choose the right tool and explain how to create effective management scorecards upon which your executives will come to rely. The sidebar “Tips for Designing an Effective Scorecard” provides 10 tips that apply to any management scorecard, regardless of which tool you use.

What Is a Management Scorecard?

Before discussing the SAP tools for creating management scorecards, I’ll discuss the six basic reporting layers that

you can use to communicate information out to the business (Figure 1). The top three layers broadly cover the different types of dashboards that management can use to handle its business. I focus primarily on the management scorecard, which is typically strategic in nature.

Figure 1 Six basic layers of reportable data: reporting type vs. degree of summarization

If you start at the lowest levels of the reporting triangle (application and unstructured data) and move up, you find that information is generally more summarized so that you can show a broader perspective of the business and business processes. For the purpose of this discussion, these layers are defined as follows:

Application data and unstructured data and analysis: This is data that is stored in various SAP and legacy applications, documents, and Web sites that may provide insight that is not structured in a way that business users can easily digest. These layers serve as raw data for the other reporting layers.

Standard/ad hoc reporting: Typically a table or graph of information related to a particular business process. This corresponds to a typical BW query developed using BEx Query Designer that may also be used for ad hoc analysis.

Operational analytics: An analytic typically relates application information and several reports that are used to monitor business processes that tend to be operational in nature. These applications could include planning and forecasting activities along with traditional applications to monitor sales or human resource (HR) actions. These types of applications are typically built using BI Integrated Planning (BI-IP), SAP BusinessObjects Planning and Consolidation, SAP NetWeaver Visual Composer, Xcelsius, and BEx Web Application Designer (BEx Web AD).

Note

As of the writing of this article, SAP has moved to a new naming convention for SAP Business Planning and Consolidation (SAP BPC). This is now SAP BusinessObjects Planning and Consolidation.

Tactical dashboard: Although some overlap exists between an analytical application and a dashboard, dashboards are often thought of as a way to monitor related business processes and are tactical in nature. An example of this is an HR dashboard in which the application tracks metrics related to retention, headcount, and promotions. These applications tend to be a little broader than analytics, but are not intended to provide a comprehensive view of the business. You typically build these types of applications using SAP NetWeaver Visual Composer, Xcelsius, BEx Web AD, and SEM-CPM Management Cockpit.

Management scorecard: A management scorecard provides a broad overview of the company and is typically aligned with its strategic objectives. A scorecard usually shows how the company is performing on a particular key performance indicator (KPI) and compares this information to either an internal or external benchmark. You usually build scorecards using SAP BusinessObjects Strategy Management, but you can also use SAP NetWeaver Visual Composer, Xcelsius, and BEx Web AD.

Key Elements Required for an Effective Scorecard

Because of ongoing time pressures for many executive teams, it is critical that the scorecard be well designed so that it is intuitive to use and efficiently communicates information. Ideally, executive users need to be able to scan the scorecard in less than a minute to get an overall understanding of the business and may spend another two to three minutes looking at specific issues. With these time constraints, it is critical that the scorecard design is both concise and precise.

At a minimum, a scorecard should contain the following elements:

KPI: metric that is being measured

KPI value: value to indicate how the metric is tracking

KPI target: value to indicate what value the organization is expecting

Time period: typically a calendar month, quarter, or year that indicates what time period was used to calculate the metric

Alert: indicator on how the KPI is performing

Data relevancy: indicates when the data was last compiled

Some additional items that you should consider include:

Organizational unit: important if you are generating multiple scorecards (can be a profit center or profit center group)

Variance: difference between actual and target KPI values

Variance %: calculate the percentage value that actual KPI value is tracking to target KPI values

Links: links to other sources of information that may provide more information about the performance of the metric

Trend chart: shows how a metric is trending over time

How to Choose Scorecard Metrics

In most cases, your company’s experience with management scorecards dictates the amount of time required to come up with a list of appropriate metrics. Do not underestimate the time that it takes to develop the metrics set and gain management buy- in for these metrics. It can take as long to come up with this list as it is does to implement and roll out the scorecard.

Depending on your industry and your corporate strategy, you may have a defined list of metrics to use when starting the process. If this is the case, your job may be easier. However, it is still beneficial to either engage internal or external management consultants to help with this process and to apply a framework to ensure you are measuring the right elements. At the very least, you may be able to see what other companies are measuring through participation in trade associations.

Two metric frameworks that can be useful for compiling a list of strategic KPIs are the balanced scorecard method and “Metrics that Matter.” The balanced scorecard method, described in the book The Balanced Scorecard by Robert Kaplan and David Norton, is the most common method for determining a set of management metrics. Companies in any industry can apply the balanced scorecard framework. The process involves reviewing your company’s strategy through a series of lenses to come up with sets of KPIs. These lenses traditionally include:

Financial

Learning and growth

Human capital

Customer

Internal processes

When you select KPIs for each of these areas that align with your overall company strategy, management gains a more comprehensive view of the organization than by just looking at one area, such as financials.

The other framework that I have found especially useful is “Metrics that Matter,” which Thomas E. Lah explains in his book Mastering Professional Services. The framework is especially well tailored to professional services firms. The author suggests looking at metrics based on whether they indicate how the business has performed (lagging indicators) versus how the business will perform in the future (leading indicators). Also, you can classify the metric by whether it will measure investment or efficiency. If you also consider which part of the business you want to measure, you can start to include metrics that provide a good overview of how the company is performing and how it will be performing in the next several months.

Three Key Criteria to Assess Your Management Scorecard Needs

The right tool depends on what your company expects from strategy management. If your company has experience with actively managing its strategy, then SAP BusinessObjects Strategy Management is the right option. SAP

BusinessObjects Strategy Management helps integrate your company’s goals, strategies, and initiatives together so that they are actionable and can be distributed across your organization.

Unfortunately, many companies and departments are new to management scorecards or have minimal needs that may make moving to a full application unnecessarily difficult. Using the SAP NetWeaver BW suite of tools can provide a bridge to an eventual implementation of SAP BusinessObjects Strategy Management in the future. It is a way to introduce some structure to strategy management by leveraging tools that you may already be using.

To determine which tools you want to use, you should consider the following questions:

User requirements: Do you need to align your company’s initiatives with your strategy to make your strategy actionable? What is the organizational commitment associated with maintaining strategy information at all levels of management? Who will have access to the application and how will the scorecard information be communicated to the organization?

Data sources: Does all your data reside in SAP NetWeaver BW? Does the scorecard require multiple queries to get the data or is the data already consolidated an InfoProvider? Do you need a form or application to add external data to the scorecard?

Development resources: Who are you expecting to develop the technical solution, your business analysts or your IT department?

With these requirements in mind, I will explore the available tools by looking at several scenarios to help you find the right fit for your scorecard application (Table 1). A brief overview of each of the potential scorecard tools is provided in the sidebar “ Tools for Building Management Scorecards from SAP NetWeaver BW.” Many of you are probably already familiar with BEx Web AD and may have also worked with SAP NetWeaver Visual Composer. For most, Xcelsius is probably a new tool. To get a quick primer on Xcelsius, refer to Anurag Barua’s article “ Accelerate the

Creation of Powerful Dashboards in Xcelsius,” which was posted to the BI Expert knowledgebase in November 2008.

Tool

Characteristics When to use

SAP BusinessObjects Planning and Consolidation

New addition to manage planning scenarios

Allows end users to design sophisticated planning and consolidation scenarios

When you need to enter non-SAP data into the scorecard and there is no way to automate the extraction of this information

SAP BusinessObjects Strategy Management

Comprehensive application for managing a company’s strategy

Application integrates goals, strategy, KPIs, and initiatives

When a comprehensive strategy management solution is required

SEM-CPM Balanced Scorecard

Comprehensive application for managing a company’s strategy

Application integrates goals, strategy, KPIs, and initiatives

Established product with a long history of use

When a comprehensive strategy management solution is required

When scorecard and framework are going to be distributed to many layers inside the corporation

SAP NetWeaver Visual Composer

Model-driven development environment

Deploys through the portal using Adobe Flash

When you want a pretty visual design

When integrating data from multiple sources outside of SAP NetWeaver BW

BEx Web AD and BEx Analyzer

OLAP functionality for detailed analysis

Deployed on the Web or in a Microsoft Excel workbook

When integrating data from a limited number of sources that are modeled in SAP NetWeaver BW

Xcelsius

Models generated in an XML version of Excel that is easy to manipulate

Deploys an Adobe Flash file that you can embed in Word, PowerPoint, Outlook, or PDF

Provides the most control over the scorecard’s visual aesthetics

When you want to embed a scorecard into Microsoft applications

When integrating manual data and SAP NetWeaver BW data

Table 1 Quick summary of the tools that you can use to develop management scorecards

One of the most interesting things about Xcelsius is its ability to use Excel workbooks in the design. Developers or businesspeople who are comfortable with Excel can quickly develop data models that they can use to generate sophisticated scorecard, dashboard, or analytical applications. Because Xcelsius can receive an Excel file as input, this is an excellent tool for prototyping management scorecards to encourage management buy-in.

Management Scorecard Scenarios

Now that I have discussed the various tools for creating a management scorecard, I will look at a few typical scenarios that dictate the use of a particular tool.

Scenario: Replace legacy strategy management application

Tool: SAP BusinessObjects Strategy Management

Imagine consulting a company that has been trying to manage its strategy through various tools and processes. It has had some success, but the company wants to have tighter alignment of its strategy and execution. Assuming that the company understands what KPIs it wants to measure and that it is capturing the information, the company may be able to gain more efficiency by linking its key corporate initiatives and projects to its strategy. If this is the case, the best tool would be SAP BusinessObjects Strategy Management.

SAP BusinessObjects Strategy Management allows users to create programs and initiatives that are tied directly to their strategy. Users can then maintain project management information about these initiatives, such as milestones, resources, budgets, and status. Because the information is contained in one application, it is easy to monitor a company’s KPI (i.e., management scorecard) and track the actions that the company is taking to improve or maintain its results.

Scenario: Have existing SAP NetWeaver BW data and want to integrate external dataTool: SAP NetWeaver Visual Composer

Suppose you are at a company that has efficiently modeled most of its data into an SAP NetWeaver BW system. You need to create a management scorecard using data stored in SAP NetWeaver BW, but you also need to include data

from a legacy SQL Server application. At this point, you could expand the SAP NetWeaver BW data model to include the SQL Server data or you could use an application such as SAP NetWeaver Visual Composer to harmonize information from multiple sources to produce your scorecard.

This is a good example of when to use SAP NetWeaver Visual Composer: to create the scorecard when you need to consolidate data from several systems and do not want to add the data to your SAP NetWeaver BW system. Because of SAP NetWeaver Visual Composer’s development environment, it is easy to create or use existing BAPIs to help structure the data from multiple sources.

Although the development environment for SAP NetWeaver Visual Composer is relatively easy to use, the developer has minimal control over the output. Tables and charts in SAP NetWeaver Visual Composer have a certain look to them that you cannot alter that much. I am a strong proponent of minimizing excessive formatting in these types of applications, so I usually restrict the use of SAP NetWeaver Visual Composer to dashboards and analytics.

Scenario: Leverage existing SAP NetWeaver BW data using current toolsTool: BEx Web AD and BEx Analyzer

Companies that have a comprehensive SAP NetWeaver BW system may strongly prefer to stick with a tool that is well known. This is a great strategy if you are already storing most of your data in SAP NetWeaver BW and it is modeled appropriately. Because many companies have dedicated reporting power users, there is a strong chance that you have in-house technical skills to create the queries required for the scorecard. You should be able to add the alerts with minimal difficulty.

Despite a team’s familiarity of use, based on my experience, BEx Web AD is not always the best tool to create the scorecard. Although it is technically possible to create scorecards with this tool, there are some limits to how the scorecard is formatted. Using BEx Web AD often requires further data modeling to get the data structured appropriately. Also, you cannot add data outside the system without redesigning parts of your system. For these reasons, BEx Web AD is not the best option for a long-term solution. However, if you need to show the metrics in a hierarchy, BEx Web AD is currently the best tool to create the scorecard.

Overall, BEx Web AD is a useful tool to help evaluate the data stored in your SAP NetWeaver BW system. You can use it to start prototyping the pieces that may be included in your final scorecard. Generally, I find the BEx Web AD and BEx Analyzer tools are most useful for preparing operational analytics and standard reports.

This type of solution can be extended when using the BEx Web AD with remote or virtual InfoCubes that can read SAP or legacy systems for data. This allows users to quickly access management data without having to extract and store the data in a permanent data model. This is especially convenient when the data is being continuously updated.

Scenario: Rapidly prototype a management scorecardTools: SAP BusinessObjects Planning and Consolidation, SAP NetWeaver BW, and Xcelsius

The management team is interested in creating a management scorecard for its department, but is not exactly sure about the metrics that it plans to measure and from where it will source this data. Worse yet, the team needs this scorecard embedded in a PowerPoint for an offsite meeting.

Because Xcelsius can import an Excel file as part of the data model design, you can develop the metrics and layout quickly using Excel. With this strategy, it is easy to change scorecard metrics to meet changing requirements and generate a Flash file that you can embed into a PowerPoint file for the meeting or post to your portal as a Web page.

Figure 2 shows an example of such a scorecard.

Figure 2 Sample scorecard created using Xcelsius

After completing the initial design, the next step of the design process should use Web services to minimize the ongoing maintenance of generating the application. You can use SAP BusinessObjects Planning and Consolidation to enter plan and target data for your scorecards. The SAP BusinessObjects Planning and Consolidation development team has released an Xcelsius add-in and white paper, “How to Use Business Objects Planning and Consolidation data in Xcelsius,” which outlines how to connect an Xcelsius application with this product.

A similar approach to the one described for SAP BusinessObjects Planning and Consolidation is to use standard Remote Function Calls (RFCs) within SAP NetWeaver BW. These Web services can then be called by a .NET or similar development technology that can reformat the output of these Web services and format them in a way that allows Xcelsius to understand the data. Although the technical details of connecting SAP NetWeaver BW to Xcelsius are beyond the scope of this article, it can be accomplished through the use of Web services or SAP BusinessObjects toolsets. SAP development is planning on releasing a standard interface between SAP Netweaver BW and Xcelsius later in 2009.

Note

Here are some other references you can refer to when planning your management scorecards:

Caincross, Scott, Darji, Prakash, Johnson, Derek L, “Visual Composer or BEx? Pick the Right Tool for the Right Application,” which was posted to the SAP Insider archive in July 2006

Kaplan, Robert S., and Norton, David P., The Balanced Scorecard (Cambridge, MA: Harvard Business School Press, 1996)

Lah, Thomas E, Mastering Professional Services ( Westerville, OH: Press Services Professional, 2005)

How to Use Business Objects Planning and Consolidation (Version for SAP NetWeaver) Data in Xcelsius , which was posted to SDN on January 2009

Tips for Designing an Effective Scorecard

I have found it very helpful to carefully plan the scorecard’s layout and color schema. Following the general approach given in Thomas Lah’s book, I generally like to keep the background colors and layout design as simple as possible. Also, I like to use muted colors for graphics, except where there is an exception in the data that needs to be highlighted. This allows the user to scan the scorecard quickly and identify where additional attention is required.

While in the past I have created fancy scorecards with vivid colors and complex controls such as dials and sliders, the end result can be counterproductive. A fancy interface with large fonts and flashy graphics will encourage users to treat the application as a toy and disregard the data. Also, complex controls, when not absolutely needed, can dramatically increase the amount of training and support required for the application.

Here are 10 tips to help you create a simple but effective scorecard design:

Tip 1. The design guidelines are intended to create a simple scorecard layout in which the emphasis is correctly placed on the information being presented and not on fancy controls or graphics.

Tip 2. Background color should be neutral, but not bright white.

Tip 3. Font colors should be minimized to two or three colors. These colors should all be neutral (e.g., grey, dark blue, or black). The only area where you want color is for alerts to make them easy to identify when the executive scans the scorecard.

Tip 4. Font types should be professional. If the font is not appropriate for an email to your boss, then choose another font. Good choices include Arial, Courier, Times New Roman, and Verdana.

Tip 5. Font size should be modest. Although it is easy to make title fonts large in a scorecard, this can make the overall scorecard look like a cartoon. Title fonts should be 10 to 14 point, metric descriptions 8 to 12 point, and informational text 6 to 8 point.

Tip 6. Divide the screen into four quadrants and then position the most important information in quadrant 1, followed by quadrants 2 and 3 with the least important information in quadrant 4 (Figure A). I typically use quadrant 4 to show charts, detailed data, or ancillary information about a process. Note that I am making a distinction between the quadrants and a scorecard’s floor plan. A floor plan refers to how the data is grouped together for the actual presentation of the information. A typical floor plan can have between one and six areas in it. If I overlay the scorecard in Figure 2 in the main article with the quadrant information presented in Figure A, you can see the areas

of the scorecard I am trying to emphasize (Figure B). In this case, the graph in quadrant 4 is de-emphasized.

Figure A Areas in which information has the most effect

Figure B Overlay of the scorecard floor plan with quadrants showing what areas have the most influence

Tip 7. Limit the scorecard to one screen to avoid scrolling. You can use tabs and buttons to provide access to more screen space if required.

Tip 8. Avoid complex controls such as sliders or dials because these controls may not be intuitive to use and frustrate users.

Tip 9. When graphing data, use bar charts or line graphs instead of pie charts or gauges. Pie charts take extra time to decipher and gauges take up a lot of space to convey a small amount of information.

Tip 10. Highlight alerts in a scorecard so they really stand out. If you are using red/yellow/green traffic lights to indicate the performance achievement of a metric, make sure that the lights have different shapes to accommodate

colorblind users.

back to article

Tools for Building Management Scorecards from SAP NetWeaver BW

SAP BusinessObjects Planning and Consolidation: SAP released this relatively new planning and consolidation tool, which tightly integrates with SAP NetWeaver BW, in October 2008. Business users can create planning scenarios using an Excel interface that writes data to an SAP NetWeaver BW InfoProvider.

SAP BusinessObjects Strategy Management: A separate application that is specifically built to manage a company’s overall strategy throughout the entire organization. This tool uses goals, metrics, and initiatives to make the strategy actionable. Scorecards and dashboards that can leverage your SAP NetWeaver BW investment are provided with this tool. This is a longer-term application that should be used to manage a company’s overall strategy.

SAP NetWeaver Visual Composer: A Web-based application development environment that you can use to create composite analytic applications rendered within SAP NetWeaver Portal. SAP NetWeaver Visual Composer connects analytical and transactional information from SAP and non-SAP systems and places them within the context of a business process. A notable feature of SAP NetWeaver Visual Composer is that it is a model-driven application development environment producing meta-applications that can be rendered and presented in Flash, HTMLB, traditional Web Dynpro, or even as a voice application.

BEx Web AD: A desktop application that you use to create Web applications and analytic applications with SAP NetWeaver BW information by employing tables, charts, and graphs.

Xcelsius: An SAP BusinessObjects desktop application that uses the Excel XML structure to model the data. You can use multiple Excel commands to make the model dynamic. Plenty of controls are available to make complex applications. Applications are rendered to a Flash .swf file that is embedded in Word, PowerPoint, Outlook, Adobe PDF, or simply as a file.

back to article

Make Users Smile with Better Running F4 Searches  

by Shreekant Shiralkar and Bharat Patel, BW System Managers, Bharat Petroleum, India

F4 search is a popular tool to find characteristics for filtering. It generates a list of values that can be used for limiting query results so that users can find just what they're looking for. While popular, F4 can add to your system overhead and cause end-user dissatisfaction if proper maintenance is not observed.

Categories: BEx, Performance, Reporting

Key Concept

Defining InfoObjects correctly in the Administrator Workbench is crucial if your F4 search is to function properly. Settings available on the Business Explorer (BEx) tab of the InfoObject maintenance screen determine how certain calls are made on the database when InfoObjects are used to filters, which affects F4 functionality.

Filtering is critical to query runs because they allow users to limit their reports to specific areas of interest such as material, customers, or regions. Pressing the F4 key launches a function that searches the system and lists all the

characteristic values relevant for a particular query’s filtering. While F4 searches are common, they gobble up precious processing resources. Any problems with the F4 feature can be exacerbated quickly because often this search tool is used over and over as query results are reevaluated with filtering.

In addition to system overhead penalties, generating F4 lists can be a sore spot with users. BW system administrators are familiar with users grumbling when they attempt to find codes and filter values with the F4 search. “I want to filter a particular material value but the list did not provide it,” they moan, while others lament, “I was forced to memorize the material codes because it takes too long for F4 to provide a list.” Using F4 search also can be excruciatingly slow, so end-user dissatisfaction has the potential of being a real problem.

The time it takes your BW system to generate an F4 list depends on a variety of different settings and options. Its ability to return a list ranges from very quickly to very slowly depending in part on the settings made when creating or maintaining an InfoObject.

You can improve your F4 search response time and alleviate end-user suffering when designing InfoObjects. You can take additional steps to enhance F4 search performance when creating and maintaining a query or Web application.

We have detailed the options available at the InfoObject level that enhance F4 search performance along with settings for InfoProviders that allow F4 to run better. We also give you a clear understanding of what your system is doing when it generates these lists so you can optimize your strategy. In the “Additional Ways to Improve F4 Performance” sidebar below, we show you some things to be aware of when creating queries that influence the F4 search, along with options available in the Web Application Designer (Web AD) that can affect F4 performance.

InfoObject Design

The F4 search is affected by settings made on the BEx tab in InfoObject maintenance screen, which is accessed via the Administrator Workbench using transaction code RSD1 (Figure 1). You can also follow the path

RSA1>Modeling>InfoObject and choose Change in the Context menu after selecting the appropriate InfoObject to access the screen.

Figure 1 InfoObject settings on the BEx tab affect the search response time

Three options are available for the Query Execution Filter Val. Selection field on the BEx tab that directly affect F4 searches. Let’s look at the various settings and see what advantages and disadvantages each option offers. We will then explain why the system behaves differently for each setting.

The Only Posted Values for Navigation setting limits an F4 search to the values related to the query’s navigation state. It is the recommended setting if you’re working with less savvy BW end users who may have trouble identifying

applicable values or are confused when faced with long lists of characteristics. This setting yields the slowest performance in terms of the F4 search.

Only Values in InfoProvider is a better option if you need a list of characteristic values for a variable that is limited to the transactional records in the InfoProvider that a query is being executed against. This setting is ideal for restricting users to the appropriate source when data is available in different InfoProviders with different values. For example, let’s say you have an InfoCube with billing data for Europe and another for the US. Each sales office will have different values, so by using this setting a variable can be restricted to the correct values.

The Values in Master Data Table setting allows users to list all possible characteristic values when they run F4. We recommend that you use it when you have transactional records for almost all the values across InfoProviders and users are aware of the relevance of the values for the navigation state.

While the Values in Master Data Table setting is the fastest F4 search setting, you need to be aware of a couple of situations when using it. Users with authorization restrictions may have an F4 list returned with all the values from the master data table, but a subsequent query may not report the result. Instead it will generate an error message informing the user of the authorization restriction. Likewise, users may select values from the master data table that are not valid for the current query due to other restrictions. There may not be any records for an InfoObject in its underlying InfoProvider designed for a query, so the system returns a “no applicable data found” message.

F4 and InfoProviders

You can also define the F4 search capabilities for a specific InfoProvider by selecting the Structure Specific InfoObject Properties option (Figure 2) in the Extras menu of the Edit InfoCube screen (Figure 3). The options

are set in the F4 query column and do not require a global change at the InfoObject level.

Figure 2 Define the F4 search capabilities for a specific InfoProvider

Figure 3 Settings correspond to BEx tab options

The Values in Master Data Table setting lists all the values from the master data table and is designated with an M in the F4 query column. The D setting corresponds to the Only Values in InfoProvider option and provides the values in the dimension table. Values are restricted to the navigational state of a query and designated with a Q for the Only Posted Values for Navigation option.

Settings in Action

Let’s look at the role the settings play in the internal behavior of your BW system to understand how and why they affect F4 search times.

For this demonstration, we are using InfoCubes as InfoProviders. We designed three different InfoCubes each with the characteristic ZA_CUS representing Customer and ZA_LOC for Location both with master data and text. In addition, the three InfoCubes have the time characteristic 0CALMONTH and a key figure Quantity.

We included one more characteristic for Material with master data and text in each InfoCube. To illustrate how F4 searches perform differently, we used three different InfoObject settings for the Material characteristic. The InfoObject ZA_MAT represents the Only Posted Values for Navigation setting. The ZC_MAT InfoObject is set to Only Values in InfoProvider and ZD_MAT signifies the Values in Master Data Table InfoCube setting. The Material master data loaded into the three InfoObjects is identical.

Table 1 illustrates the master data values and text for InfoObjects ZA_CUS, ZA_LOC, and ZA_MAT (as well as

ZC_MAT and ZD_MAT). We show the values in just one table for the sake of this demonstration. In reality,

master data is stored in a number of tables depending on the settings used for an InfoObject when it’s created. Likewise, the SID values are not shown to keep the example from being too complicated.

ZA_CUS values

ZA_LOC values ZA_MAT values

Customer Text Location Text Material Text

100100 Customer 100100 1000 Location 1000 10000 Material 10000

100111 Customer 100111 2000 Location 2000 20000 Material 20000

100112 Customer 100112 3000 Location 3000 30000 Material 30000

100113 Customer 100113 4000 Location 4000 40000 Material 40000

100114 Customer 100114 5000 Location 5000 50000 Material 50000

100115 Customer 100115 6000 Location 6000 60000 Material 60000

100116 Customer 100116 7000 Location 7000 70000 Material 70000

100117 Customer 100117 8000 Location 8000 80000 Material 80000

100118 Customer 100118 9000 Location 9000 90000 Material 90000

100119 Customer 100119        

100120 Customer 100120        

100121 Customer 100121        

100122 Customer 100122        

100123 Customer 100123        

100124 Customer 100124        

100125 Customer 100125        

100126 Customer 100126        

100127 Customer 100127        

100128 Customer 100128        

100129 Customer 100129        

100130 Customer 100130        

100131 Customer 100131        

100132 Customer 100132        

100133 Customer 100133        

100134 Customer 100134        

Table 1 InfoObject master data values with text

The fact table contains the following:

Customer transactions are from 100100 to 100125 and from 100131 to 100135 Locations transactions include 1000, 2000, 2500, and 8000Material transactions are 10000, 20000, 50000, 55000, 70000, and 90000CALMON values are all 200401;QTY values all equal 100

Three Queries

We also created three queries, one for each Material InfoObject. We restricted the Customer characteristics to the values 100100 to 100114. We used Location and Calendar Month to define rows, Quantity for the lone key figure, and Material as a free characteristic.

The Material characteristics were changed for each query run. Initially we used InfoObject ZA_MAT, replaced it with

ZC_MAT in the second query, and finally ZD_MAT. After executing the query (Figure 4), we filtered for specific values to demonstrate the influence of the different settings.

Figure 4 Initial query results prior to filtering

When we filter using InfoObject ZA_MAT, the system limits the list of values to two (Figure 5) because of the settings made in the BEx tab. In the Only Posted Values for Navigation, the system checks the current navigational status of results of the query when the filter for Material values is applied. It discovers that there is a filter on Customer

code (ZA_CUS), which, as noted earlier, filters on values 100100 to 100114.

Figure 5 Filter result for Only Posted Values for Navigation setting

When users filter on ZA_MAT, the system first takes the ZA_CUS filter navigational step, and then retrieves the values for material. The values for ZA_CUS in Table 1 show that customers 100100 to 100114 have only transacted for materials 10000 and 20000. The results of this sequence are displayed in Figure 5 and the system ignores all the other material codes.

In the background, the Only Posted Values for Navigation setting (like all BEx tab settings) determines the search strategy the system uses to locate master data values when the query output is filtered with ZA_MAT. All database calls including the search strategy are SQL-based. We have posted the SQL statements for each of three Material InfoObjects in the Download Section of the BW Expert Web site (www.BWExpertOnline.com).

When data is retrieved from the database, an SQL statement joins the appropriate tables. Depending on the number of tables involved, these SQL statements can be complex and data retrieval time may be long. SQL statements are generated by the system and are transparent to the user.

Filtering on ZA_MAT, the system accommodates the navigational steps and creates temporary tables to collect the filtered values. It creates a temporary table and stores SID values for the Material codes to be filtered after the appropriate join is made on various tables in the database for the InfoObject ZA_CUS. Temporary tables are created by the system and named automatically. Again, the procedure is transparent to user.

When executing the second query, which is designed with exactly the same characteristics and key figures, ZA_MAT is replaced with InfoObject ZC_MAT. It is set to Only Values in InfoProvider in the BEx tab. When we filter on

Material using this InfoObject, the system returns the values shown in Figure 6, which correspond to Material records in the fact table.

Figure 6 Filter result for setting Only Values in InfoProvider

Filtering on ZC_MAT, the system ignores the navigational steps and locates the SID information from the master data referring to the dimension table value. Overhead is reduced because the system does not create a temporary table.

Executing the last query and filtering on ZD_MAT, the system returns the values in Figure 7. Once again, the query is designed with same characteristics and key figures as the earlier ones, but ZD_MAT is defined using the Values in

Master Data Table option. This time the system has to perform less joins to retrieve the list of values for material. It does not need to check the InfoProvider data or current navigational steps.

Figure 7 Filter result for Values in Master Data Table

Table 2 displays the results of the three BEx tab settings. Note that the number of records is inversely proportional to the amount of time it took for system to return its F4 search list.

Setting

No. of recordsResponse

time (milliseconds)

Only Posted Values for Navigation 2 15.321

Only Values in InfoProvider 7 5.536

Values in Master Data Table 11 4.507

Table 2 Response time for BEx tab settings

Remember that this comparison is for a very small number of entries in the master data table, dimension table, and fact table. In real life, the table sizes are very large and hence the response time taken by the system to return the list of values will be much different in each of the three settings.

Additional Ways to Improve F4 Performance

In addition to the InfoObject Query Execution Filter Val. Selection settings, you have other ways to improve F4

search performance. The Query Def. Filter Value Selection field in the BEx tab (Figure 1) controls the default values for characteristics when selecting the filter values for query definition. If the Only Values in InfoProvider setting is used, then the F4 search list is limited to the characteristic values available in the InfoProvider at the time of query definition. When the Values in Master Data Table setting is used, all the master data is listed for query definition.

Note that when a filter is defined in the BEx Query Designer, the F4 search list corresponds to the Query Def. Filter Value Selection setting on the BEx tab. When performing query maintenance in the BEx Query Designer, the Only Values in InfoProvider flag is set automatically in the Selection Condition screen for a filter (Figure 2) when the Only Values in InfoProvider option is selected. You can click on the Only Values in InfoProvider flag and remove it to view the entire list of master data values using F4.

Web AD provides another avenue for defining the F4 list values. When using the Generic Navigation Block Web item to design Web application templates, the Read Mode option allows you to set the same M, D, and Q values available for defining an InfoObject (Figure 3). Like with the InfoProvider setting, these Web AD values do not require a global change at the InfoObject level, only at the Web application level.

For more information concerning F4 performance, see the following SAP notes:

748623 Input help (F4) has a very long runtime—recommendations

661251 Filter value selection displays too few/too many values

581802 Variable dialog boxes: performance of the F4 help

581079 Performance for the F4 help of navigation attributes

626887 F4 variables and InfoObject settings.

Figure 1 The Business Explorer tab provides Query Def. filter Value Selection options mirrored in the BEx Query Designer

Figure 2 The F4 list of characteristic values can be changed by setting the flag in filter Selection Condition screen in the Query Designer

Figure 3 Web AD provides another avenue to make F4 search settings specific to a Web application

 

Shreekant Shiralkar is a certified SAP BW and SD application consultant and a faculty member at the Sapient Academy, where he teaches BW courses. His experience includes working with petroleum companies in India. Currently, Shreekant manages the BW system at Bharat Petroleum, India. He can be contacted at shiralkarsw@bharatpetroleum.com.

Maximize the Value of Your BEx Reports with Custom Exception Symbols  

by Stuart Chambers, BI Consultant, Innogence (September 2009)

It can be difficult to interpret the standard traffic-light exception symbols when you quickly scan a report. Find out how you can replace these symbols with something more meaningful, such as a medal to indicate sales success.

Categories: BEx, Reporting

Key Concept

Analysis Web Item parameter modification modules provide a straightforward customization platform. In particular, the exception symbol module allows you to replace the standard SAP exception symbols (generally traffic lights) with relevant symbols. By inserting a simple reference to standard SAP code in the XHTML tab of your template, you can quickly increase the relevance and use of your reports.

As companies try to get more out of their existing systems, they want to extract more value from BEx Web Application Designer (BEx Web AD). One way to do this is to increase the relevancy and use of reports by making some quick visual changes. I’ll help you accomplish this with your existing toolset.

Before reading this article, you may want to read my previous article, “Take the Challenge Out of BEx Report Formatting: It’s Easier than You Think.” This second article extends the content covered previously and uses the same scenario-based process to provide you with the knowledge and skills required to customize your exception symbols.

I will use the example of an existing sales executive performance report. This is a monthly report indicating the metrics used to assign monthly bonuses. The national sales managers have issued a directive for their report to be made more visual. They want the current exception symbol to be replaced with one that creates a more relevant visual reference.

I will show you how to solve this problem by following these three simple steps:

Step 1. Identify the exception that needs a new image

Step 2. Define the new exception symbol and load it into the MIME Repository

Step 3. Add the new exception symbol to the XHTML and adjust the parameters to suit the report requirements

Note

The following example applies to SAP NetWeaver BW 7.0 Support Package 7, Patch 1, Revision 473 and onward. The functionality may not be available with earlier versions.

Step 1. Identify the exception that needs a new image. Embedded in the BEx Web Application Designer (BEx Web AD) template is a query that contains the exception that needs to have its image replaced. Open the query in BEx Query Designer by following menu path Start > Programs > Business Explorer > Query Designer and then select the

Exceptions tab. The system displays the existing exception (Figure 1).

Figure 1 The existing exception in the query referenced in BEx Web AD

It is important to note the level assigned to the exception (Good, in this example). You use this level later in the implementation of the XHTML code. The code you will be implementing replaces all current Good images within the query with a new, relevant image.

Note

Unless defined, all other exception level symbols remain as the standard SAP image.

Step 2. Define the new exception symbol and load it into the MIME Repository. Ensure that a .gif file that represents the image you wish to use as an exception symbol has been created. In this scenario, I am going to use a medal to replace the Good exception symbols. I selected a medal because the business wanted any sales manager (who may or may not be familiar with the report) to be able to scan the report and instantly associate the exception symbol with the person who has achieved success. The current green traffic light exception symbol does not project what the

exception symbol is aiming to convey. A medal, which is commonly associated with achievement and success, was considered more appropriate.

Note

Make sure the pixel dimensions of your image are appropriate — each line of your analysis grid that has an exception symbol automatically expands to meet the size of the image.

In this scenario, I am going to replace the current symbol used for a Good exception. To do this, you need to load the new image into the MIME Repository, which stores all the images, styles sheets, scripts, and icon objects for use in an application.

To open the MIME Repository, use transaction SE80 and click the MIME Repository tab. Navigate to the directory

/SAP/BW/CUSTOMER/IMAGES, right-click the Images folder, and select Import MIME Objects (Figure 2).

Figure 2 Import the MIME objects

Fill in the details on the Shared tab, and then click the save icon (Figure 3). The image is loaded to the MIME Repository, where it can be referenced in step 3.

Figure 3 Enter the information for the new symbol you want to use for exceptions

Step 3. Add the exception symbol module to the XHTML and adjust the parameters to suit the report requirements. Applying the exception symbol parameter modification is a relatively simple process. It is a matter of calling a piece of standard SAP Java code and using parameters to make it behave as you desire. To do this, navigate to the XHTML tab of your BEx Web AD template. The name of the module to be implemented is com.sap.ip.bi.rig.ExceptionImage.

Each parameter modification module is data provider specific. The piece of code in Figure 4 identifies the Data Provider for which I want to change the exception symbol.

      <bi:ANALYSIS_ITEM name="ANALYSIS_ITEM_1" designwidth="400" designheight="200" >

<bi:DATA_PROVIDER_REF value="DP_1" />

    </bi:ANALYSIS_ITEM>

Figure 4 Identify the Data Provider that uses the new exception symbol

Insert a line after bi:DATA_PROVIDER_REF value="DP_1" /> and insert the code in Figure 5 into the XHTML.

         <bi:ANALYSIS_ITEM name="ANALYSIS_ITEM_1" designwidth="400" designheight="200" >

              <bi:DATA_PROVIDER_REF value="DP_1" />

                <bi:MODIFICATION type="CHOICE" value="MOD_SINGLE_MODULE" >

                    <bi:MOD_SINGLE_MODULE type="COMPOSITE" >

                        <bi:ACTIVE value="X" />

                        <bi:MOD_SELECT type="CHOICE" value="MOD_GENERIC_MODULE" >

                            <bi:MOD_GENERIC_MODULE type="COMPOSITE" >

                                <bi:MOD_REFERENCE value="com.sap.ip.bi.rig.ExceptionImage" />

                                <bi:MOD_PARAMETER_LIST type="ORDEREDLIST" >

                                    <bi:MOD_PARAMETER type="COMPOSITE" index="1" >

                                        <bi:MOD_PARAM_NAME value="ALERT_GOOD" />

                                        <bi:MOD_PARAM_VALUE type="CHOICE" value="IMAGE" >

                                            <bi:IMAGE value="bwmimerep:///sap/bw/mime/customer/images/medal.gif" />

                                        </bi:MOD_PARAM_VALUE>

                                    </bi:MOD_PARAMETER>

                                </bi:MOD_PARAMETER_LIST>

                            </bi:MOD_GENERIC_MODULE>

                        </bi:MOD_SELECT>

                    </bi:MOD_SINGLE_MODULE>

                </bi:MODIFICATION>

                <bi:EXCEPTION_RENDERING value="SYMBOL" />

            </bi:ANALYSIS_ITEM>

Figure 5 Code to change your exception symbol

The code in Figure 6 shows the addition and manipulation of the parameters. In this code, I have defined the alert level that is subject to the exception symbol change, and also the image that replaces the exception symbol, as defined in step 3.

              <bi:MOD_PARAM_NAME value="ALERT_GOOD" />

               <bi:MOD_PARAM_VALUE type="CHOICE" value="IMAGE" >

               <bi:IMAGE

value="bwmimerep:///sap/bw/mime/customer/images/medal.gif" />

Figure 6 Define the alert level for the exception symbol change

Note

You can define images for the nine standard alert levels that are available in BEx Query Designer using the parameter value name Alert_1 (representing Good 1) to Alert_9 (representing Bad 3).

After you insert this code into the XHTML, click the correct and format icon on the BEx Web AD toolbar and save

your BEx Web AD template. Then execute the BEx Web AD template (Figure 7).

Figure 7 The new medal exception symbol replaces the old traffic light exception symbol

The exception symbol displayed now is no longer the standard SAP image, but a custom image. In my example, the medal is relevant and adds value to the report. This satisfies the users’ demand for a visually pertinent report, delivered at minimal cost.

Monitor Your Queries and Workbooks  

by Iliya Ruvinsky, SAP BW Consultant, NESS A. T.

It’s a challenge to identify when a workbook or query was changed if many consultants are working on a project. You need that information when you are deciding which workbooks to transport. Learn about a method to monitor workbook changes.

Categories: BEX, Reporting, Transports, Update and Transfer Rules

Key Concept

In BW, it is important to have instruments for object monitoring. These tools are not a standard part of current versions of BW (3.0-3.5). You can use the application described in this article as part of your object monitoring strategy. It can provide you with a quick and easy understanding of the relationships among InfoCubes, queries, and

workbooks.

Many BW projects have large groups of consultants heavily engaged in the development of Business Explorer (BEx) or Web Application Designer (Web AD) reports. Projects of this type usually encounter control and transport architecture problems.

For instance, picture this scenario. Ten people are working simultaneously to develop 20 BEx reports in a day. The reports are then transported to your test and production environments. After six months, BW BEx architecture involves hundreds of queries and workbooks that are constantly rebuilt and updated according to end-user demands. Every day these updates and corrections must be transported from development back to test and production environments, along with the newly developed reports.

When working in this type of environment, you might ask yourself, “Who developed this specific workbook? When was it developed? Who has changed it and when? Which queries are related to which workbooks and vice versa? How many queries or workbooks were developed since yesterday or last week?”

In addition to these questions, you are faced with another problem: transporting work-books and queries. If you and your coworkers develop 400 workbooks, nobody wants all of them to be nested into a transport because 90 percent of them are unchanged. The time required to organize such a transport could be an hour or more, which could cause the system to generate a time-out error. To prevent confusion, you should know exactly which queries and workbooks were developed or changed at a certain point in time and take only the modified ones into a transport.

To solve these problems, I’ve created an application called the MONitoring Application (MONA). It allows you to easily identify all queries and workbooks that are new or have changed. I have implemented MONA in the three largest customer sites in Israel, and the people responsible for controlling such processes are very happy with that solution.

In a two-part series, I’ll show you how to use MONA to make BEx reports that monitor and control your changed queries, workbooks, and InfoCubes. This article covers workbook monitoring and transport control. My next article will concentrate on the relationship among InfoCubes, workbooks, and queries.

Why Use MONA?

Normally, at the end of the day, report developers must develop a list containing information about queries and workbooks that they changed or created during the day. Once all the lists are collected, the person responsible for transport delivery must create a transport containing all these queries and workbooks. If you have many workbooks, the process of finding and inserting them into a transport request could take a lot of time.

You can omit all of these steps by using a part of MONA called Workbook Monitor. The process becomes simple. At the end of the day, the person responsible for transport creation and delivery uploads an ODS and runs a report that filters all workbooks that were created or changed during the day. Report developers no longer need to develop lists.

The primary purposes of MONA are:

To improve monitoring and control of data upload processes from source systems into BW

To increase the effectiveness of report and workbook development and to simplify the process of transports

To understand, at a glance, the relationships among InfoCubes, BEx queries, and BEx workbooks

Although MONA is helpful under many circumstances, the application is crucial when working under the following conditions:

Massive development and support of reports/workbooks provided by a large team of developers

Frequent reports/workbooks redesign and transports from development to production systems

Many InfoCubes with several workbooks and queries based on them

You can create the whole MONA application in a short development time, one to two weeks, using a number of BW-based tables. The tables RSRWBINDEX, RSRWBINDEXT, RSRWORKBOOK, and RSRREPDIR collect information about relations among InfoCubes, queries, and workbooks in the BW system. They also contain information about the changes in these relations. You can access all of these tables via transaction SE10 in your BW system. Here is what each table contains:

RSRWBINDEX — data about workbooks: IDs, creation time, change time, person who last changed them, etc.

RSRWBINDEXT — workbook IDs and their titles

RSRWORKBOOK — data about which query belongs to which workbook

RSRREPDIR — information about queries, types of reporting components (key figures, variables, etc.) for each query, InfoCubes, who queries belong to, query versions (active/modified/revised), and many other kinds of analysis-related metadata

Advantages of Workbook Monitor

Now I’ll focus on the first part of the MONA application called Workbook Monitor, which deals with workbook control. No strict dependency exists among MONA’s parts. You can choose to implement any combination of the parts according to your specific needs. For example, by implementing the workbook control functionality, you could gain control over the processes of checking and monitoring the creation and subsequent transportation of newly created or newly changed workbooks to test and production systems.

Figure 1 is an example of a report in Workbook Monitor. You can filter a Workbook Monitor report by date and time. Those parameters filter the workbooks that were changed since the selected date and time chosen. The report then presents only those workbooks that are relevant for transport.

Figure 1 A Workbook Monitor report

The Workbook Monitor part of MONA observes all workbooks and breaks down the information about them by workbook ID, date and time of creation, date and time of change, person who created the workbook, person who last changed the workbook, and the object status (active/inactive/modified, etc.). The Workbook Monitor application also

facilitates workbook transports. The other advantage of Workbook Monitor is that you can avoid overusing the metadata repository (transaction RSA1). Although you can get information about interrelationships between queries, query elements (such as key figures, structures etc.), and workbooks at the system level via the metadata repository, you cannot get the whole picture at a glance.

The report presents information such as Statistical data UID (the workbook ID), Last Changed at (Date), Last Changed By, Last Changed at (Time), Created at, and Created by.

Create Workbook Monitor

I created MONA using a number of ODSs and InfoSets designated for workbooks development monitoring and transport delivery. Using these structures, you can monitor what queries are related to which workbooks and InfoCubes via reports.

To implement the Workbook Monitor part of MONA, perform the following steps:

Step 1. Call transaction SBIW. In the SBIW screen, expand the Generic DataSources part of the tree and click on the Maintain Generic DataSources entry. This takes you to the Maintain Generic DataSources screen.

Enter the name for your generic DataSource in the Transaction data field, My_Transaction_DataSource, for example, and choose the Create button. This takes you to the next screen, Create DataSource for Transaction

data: MY_TRANSACTION_DATASOURCE (Figure 2). Fill in all of the fields as shown in Figure 2 and click on the save icon. The system will prompt you to choose a package.

Figure 2 DataSource details

Step 2. Choose a package. In this example, I chose zsys. Fill in the appropriate package attributes and save. Note that you must configure a package or use an existing one. Use transaction SE80 to create a new package or choose from the existing ones. After assigning your DataSource to the package, the system automatically prompts you to the change request screen.

Step 3. Create a change request. This request will be assigned to the package for further delivery of the DataSource to your test and production systems. You can choose an existing change request or create a new one. I recommend creating a new one rather than putting different kinds of developments in one request. The system automatically assigns the change request number. You just have to give it a name. It also automatically assigns the

object directory entry after choosing a package. Click on the save icon. The system brings you the DataSource: Customer version Edit screen after submitting the change request.

Step 4. The screen prompts you to choose which of the DataSource fields will be available for the Selection Criteria screen of the InfoPackage. Check the boxes of the Selection column to display fields in the InfoPackage Selection Criteria screen. To hide fields on this screen, check the corresponding boxes in the Hide field column. Click on the save icon to return to the previous screen. You receive the system message “DataSource has been saved successfully.”

Step 5. Use transaction RSA13 to get to the source systems inside BW. Choose your BW source system and right-click on it. In the context menu, choose the Replicate DataSources entry. The system activates the DataSource you’ve just created and it is ready to connect to the InfoSource.

Step 6. Use transaction RSA12 to go to the Administrator Workbench InfoSource screen. Right-click on the relevant part of the InfoSource tree and choose Create. Create an InfoSource to map all the fields that come from the

DataSource into the ODS. First create a communication structure to include all the fields (Figure 3).

Figure 3 Create a communication structure

Step 7. Map all the fields via the transfer rules of the InfoSource without any transformations (Figure 4). The

process of mapping involves filling the InfoObject column on the left part of the InfoSource screen with the InfoObjects responsible for the fields from your InfoSource.

Figure 4 Map the fields that come from the DataSource into the ODS via the transfer rules

Step 8. Transaction RSA11 brings you to the InfoProvider screen in Administrator Workbench. Right-click on the relevant part of the InfoProvider tree and choose Create ODS Object. Create an ODS with all the necessary

InfoObjects to receive data from your DataSource via your InfoSource (Figure 5).

Figure 5 Create an ODS

Step 9. Create update rules for your ODS. Right-click on the ODS you’ve just created and choose Create Update Rules. Enter an InfoSource name that will feed your ODS via update rules.

Update Rules

Once you’ve created the DataSource, InfoSource, and ODS, you need to adjust the ODS’s update rules to load data properly. The problem with the DataSource is that fields that represent time and date are in the form of Universal Time Converted (UTC). They must be translated into the “normal” date and time format via two ABAP routines. These ABAP routines are implemented in ODS update rules. They transform date and time data and upload it into the ODS in the readable format. The whole process is presented next.

ABAP code is required to describe the conversion of date and time in the fields, which represent the date and time at which workbooks were changed. The code takes effect each time the ODS is updated and the date and time data is formatted just before it is uploaded into ODS. The code in Figure 6 converts the UTC date format into “normal”

yyyy:mm:dd date format, which is readable. The Start Application Server Date field contains the date of the last workbook change.

Figure 6 CONVERT_TO_DATE code

Next, convert the time into a readable format using the code in Figure 7. The Start Application Server Time field contains the date of the last workbook change. This code converts the UTC time format into “normal” hh:mm:ss time format, which is readable.

Figure 7 CONVERT_TO_TIME code

To add the code, go to the Update Rules change: Rules screen by expanding the triangle under your ODS and clicking on the green update rules icon (Figure 8). Revise your update rules by changing the fields Start Application

Server Date to CONVERT_TO_DATE and Start Application Server Time to CONVERT_TO_TIME.

Figure 8 Change your update rules

Click on the Ty. column. Choose the Routine option from the five options and enter the name of your code, CONVERT_TO_DATE (Figure 9). This brings you to the Change Routine screen. In this screen, add the code to the

routine as shown in Figure 10. Repeat the process with the CONVERT_TO_TIME code.

Figure 9 Choose the Routine option

Figure 10 Enter code to modify date routine

Workbook Monitor Report

To update your ODS with data, you must create a BEx report to monitor and transport your workbooks. Use transaction RRMX to enter the BEx Analyzer screen for report creation. The structure of the BEx report is simple, as

shown in Figure 11.

Figure 11 Structure of the BEx Workbook Monitor report

Note the two variables Start Server Date (ZSTARTDT) and Enter Change Time (ZTIME). Both of the variables are of the user entry/default value type. Configure them to filter as greater than or equal to by clicking on the Value Range option in the upper left corner of the selection screen. In the Options tab, choose the Greater than or Equal to option to configure your variable to filter the report by all values greater than or equal to those entered into the Variables prompt when reporting.

This allows the user to filter by specific dates and times. Thus, if users want to see all workbooks that have changed since 01/04/2005 at 00:00:00, they enter these parameters into the Variables prompt and run the report. The results,

along with the variable parameters report, are presented in Figure 12.

Figure 12Resulting Workbook Monitor report that displays all workbooks that have changed since 00:00:00 of 01/04/2005

Transport Your Workbook Monitor Reports

When you open the report you created in the “Workbook Monitor Report” section, perform the following steps:

Step 1. Use transaction RSA1 to go into Administrator Workbench. Choose the Transport Connection tab. Choose Workbook and click on the drop-down arrow to the right. Double-click on Select Objects inside the Transport Connection screen to get the Input Help for Metadata screen.

Step 2. Click on the Object Name tab to choose all workbooks IDs. Then click on the filter icon to get to the Determine Values for Filter Criteria screen. Choose the multiple selection icon to go to the Multiple Selection for Object Name screen.

Step 3. Copy and paste workbooks IDs. Copy the workbooks IDs from the Workbook Monitor report (created in the “Workbook Monitor Report” section) and paste them into the Multiple Selection for Object Name screen (Figure

13). Submit the selection by pressing F8 or clicking on the copy icon. The transport delivers the exact workbooks that were chosen from the Workbook Monitor report, which was filtered by date and time to indicate those workbooks that were changed. The whole procedure is easy to operate and perform, and it saves a lot of time during transport organization.

Figure 13Copy and paste workbook IDs from your Workbook Monitor report into the Multiple Selection for Object Name screen

One Web Table Interface Class Fits All  

by Jin Freda, BW Developer, Becton Dickinson

Implement a flexible custom table interface class for enhancing BW Web reports to meet new and changing business requirements.

Categories: ABAP, BEx, Reporting, Web Application Designer

Key Concept

The table interface is a gateway for modifying ABAP-based object-oriented classes for use with Web templates. You can use the table interface to modify the presentation of a Web template or specific data sets. The key to the technique described in this article is to build all key elements in the custom table interface dynamically rather than hard coding them. This makes your table interface generic and flexible and allows you to avoid changing the coding in your table interface class when requirements change.

Many companies use custom Web reporting table interface classes to modify presentations and data sets. For example, a customer may need a high-level metrics dashboard containing one or multiple metrics summary reports (tables) with active exceptions (colored light bulbs). Each key figure in each table has a different icon. When you click on any one of them, a different detailed report displays. Each report has a different template and possibly a different data provider that may be restricted by a different combined characteristic filter based on the row you select. In the current practice, you hard code the key figure name, template ID, and data provider name, special icons path, and similar details in your table interface class. Therefore, you need to change the code when a requirement changes, but this process is tedious and time consuming.

I’ll introduce you to an innovative one-size-fits-all technique using object-oriented ABAP (ABAP Objects). No matter how often your business requirements change, you can avoid changing the coding in your table interface class by building a filtering string, JavaScript functions, and a hyperlink string, as well as changing a data cell dynamically. This one table interface class fits all needs. This technique works for BW 3.x.

Figure 1 shows a digital cockpit report with several icons such as line chart and information. (Note that this and all figures here contain demo data and do not represent actual company performance.) The icons in Figure 1 link users from a high-level report to a more detailed graph or report. This linkage occurs at the level of the hierarchy to which

users have drilled down. Click on the information icon to go directly to the detailed report for Plant 1002/100: BRK

STERILIZ VAC characteristic.

Figure 1Click on the information icon to go directly to the detailed report for Plant 1002/100: BRK STERILIZ VAC characteristic

The technique that I’ll describe accomplishes several main tasks with no hard coding. First, you set up the handshake between the template and the table interface class. This tells the table interface class what the Web template wants to do. Then you dynamically build the following:

A filtering string to retrieve only the data that you want

JavaScript functions to perform certain activities such as opening windows and linking to data providers

A hyperlink string in the data cell content so that the users see the specified icons and can perform actions on the Web report

The tricky part is how to tell the table interface class what you want to do from the Web template. Specifically, it conveys information including which key figures should have a special icon; which icons you want to allow users to click on; which data provider to use; and which template to open.

The name of the table item (an item in the template) is a perfect communicator between the table interface class and Web template. Since it is a string type, you can easily establish the handshake or language between the interface class and template by using some special characters (i.e., XX, YY, &&, *…. The details are in step 2 below). You need to establish the handshake before the development in table interface class.

Note

To discover other ways to enhance your Web table interface, see the SAP how-to paper “How to … Enhance your Web Query with the Table Interface” at https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/49dfeb90-0201-0010-a1a2- 9d7a7ca1a238. Also, refer to Joerg Boeke’s September 2004 BW Expert article “Modify Web Reports with the BW Table Interface.”

My technique includes these eight steps that I’ll explain in detail with examples:

Step 1. In the main template in Web Application Designer (Web AD), put all data providers in the main template

Step 2. Use the table item name in the main template to communicate between the template and the table interface class

Step 3. Create the new custom ABAP Objects class inherited from class CL_RSR_WWW_MODIFY_TABLE and redefine START, CAPTION_CELL, STRUCTURE_CELL, CHARACTERISTIC_CELL, and DATA_CELL methods

Step 4. In the START method, make a JavaScript coding string to dynamically build JavaScript functions to launch a template with a data provider and a filter

Step 5. In the CAPTION_CELL method, parse the communication string to an internal table based on the communication with the main template

Step 6. In the STRUCTURE_CELL method, fill in the X coordinate for all key figures that you are enhancing

Step 7. In the CHARACTERISTIC_CELL method, dynamically build a filtering string based on the Web Application Programming Interface (API) filter command structure

Step 8. In the DATA_CELL method, dynamically change cell content based on information in the internal table it_comm.

Step 1. In the main template in Web AD, put all data providers in the main template. The main template passes the data providers to the subtemplates. Make sure the data provider for the details page contains all of the row characteristics in the data provider for the main page to pass the filter string from the main page to the detail page dynamically. The detail page may contain more characteristics than the main page. I’ll show you how to perform this step.

Go to BEx Query Designer and open the query ZM_WEB_QM_MULTI_REG in the data provider for the main page (Figure 2). Also in BEx Query Designer, open the query ZM_WEB_QM_BSRDT in the data provider for the details page (Figure 3). The Rows area circled in Figures 2 and 3 have four characteristics in common: Region, Plant,

MRP Controller, and Material. Because both data providers contain these characteristics, the main page can pass the filters in any combinations of these four rows to the details page.

Figure 2 Open the query in the data provider for the main page

Figure 3 Open the query in the data provider for the details page

Note

To deploy a graphical template you click on the line icon in Figure 1 to show the trending. Different hierarchy levels (the row or characteristic you selected) need different data providers or queries with corresponding characteristics selected in the row setting. This means you must dynamically pass the corresponding data provider by hierarchy level to a graphical (in this case trending) template. For example, if you click on the line icon on the Region level row, the main template passes data provider RTR_ZSDREG; if you click on the line icon on the Plant level row, the main template passes RTR_0PLANT; if you click on the line icon on the MRP_CONTRL level row, the main template passes RTR_0MRP_CONTRL. Figure 4 shows these three data providers in template ZTPL_QM_WEB_REGION_TAB_V4 in Web AD and their relationship with queries. Figures 5, 6, and 7 show three queries with three different row characters (0PLANT, 0MRP_CONTRL, and 0MATERIAL) for three levels of trending (Region, Plant, and MRP Controller).

Figure 4 Three data providers in template ZTPL_QM_WEB_REGION_TAB_V4 in Web AD and their relationship with queries

Figure 5 Query for all plants trending per region

Figure 6 Query for all MRP controllers trending per plant

Figure 7 Query for all materials trending per MRP controller

Step 2. Use table item name in the main template to communicate between the template and the table interface class. This is the centerpiece of this technique because you can direct the table interface class through this communication string. For instance, you can say which key figures you want to have, when to include a special icon, which icons users can click on, which data provider you want to use, which template you want to open, and which JavaScript function you want to call. You can use some special characters to establish the handshake or language between the interface class and template.

Web Page Customization Table Interface Handshake

Now I’m going to explain the handshakes that the code uses to communicate between the template and table

interface class. Figure 8 shows an example of code for the table item name that includes several characters with different meanings.

Figure 8 Table item name

In Figure 8, the first two characters tell how to show the data cell content. Table 1 shows the possible options for the first two characters. You must pick only one combination of these characters. The third character of the table item name denotes the three options to tell how to search the key figures, as shown in Table 2. You must choose only one

option for this character. The fourth character allows you to choose from four different options that determine the type of icon to display. See Table 3 for these options. Note that you must choose only one option or use none of the options. Table 4 shows the special characters for different types of separators. You can you use these characters together based on how many key figures, definitions, and so on that you need to enhance. Finally, the six special

characters in Table 5 appear after XXXX in the item name in Figure 8. They allow you to choose which JavaScript functions you want to call.

Characters

Definition

EZ Change SAP’s original exception colors to green/yellow/red icons

EY Keep SAP’s original exception colors

DZ Erase all key figures in the table (i.e., hierarchy table)

Table 1 Definitions of the first two characters in the table item name (choose one option only)

Characters

Definition

PSearch key figure by description pattern(RE* [search key figure with partial description with wildcards])

F Search key figure with full description

X Search key figure with coordinate

Table 2 Definitions of the third character in the table item name (choose one option only)

Characters

Code Definition

T mime/BEx/Icons/lines.gif Trending icon

R mime/BEx/Icons/refresh3.gif Refresh icon

Imime/BCT/Icons/s_n_info.gif (is default icon also)

Information icon

Cmime/BCT/Icons/s_n_info.gif, mime/BEx/Icons/lines.gif

Combines both information and trending icons

Table 3 Definitions of the fourth character in the table item name (choose one option only or none)

Characters

Definition

YY Separator for each key figure

XXSeparator for each of five definitions: key figure description, data provider, template ID, icon, and function (**, functions listed in Table 5)

&& Separator for multiple data providers/templates/icons/functions

* If * appears in key figure description, it means the description is partialIf * appears in front of Template ID, this means Template ID is TemplateID_HierarchyLevelIf * appears in front of data provider, this means data provider name is DataProviderName _HierarchyLevel

Table 4 Definitions of the special characters in any position in the table item name

Characters

Function

DPDWE Pass data provider in different window, erase number

NDDWE Not pass data provider in different window, erase number

NDSWE Not pass data provider in same window, erase number

DPDWK Default; pass data provider in different window, keep number

NDDWK Not pass data provider in different window, keep number

NDSWK Not pass data provider in same window, keep number

Table 5 Special characters after XXXX in the item name. You pick only one option or none; the default is DPDWK.

Developers need to consider a couple of items when making handshakes and writing the code. Sometimes, key figures’ descriptions contain special characteristics (CR, <>) that the item name cannot accept. The solution is to use a partial name with * pattern instead of the full name. In addition, your code in method STRUCTURE_CELL needs corresponding changes from read table …. with key to loop at with CP pattern string comparison or use the X coordinate (the position of the X coordinate of a key figure) instead of the key figure’s description.

Also, a 256-character limit exists for the length of the item name. To overcome this limitation, you can enhance your interface class to take the prior key figure’s definitions as its default if they are same. You should make all data providers’ name as short as possible.

Step 3. Create the new custom ABAP Objects class inherited from class CL_RSR_WWW_MODIFY_TABLE and redefine START, CAPTION_CELL, STRUCTURE_CELL, CHARACTERISTIC_CELL, and DATA_CELL methods.

To complete this one-time process, start Class Builder in transaction SE24 (Figure 9). Enter ZCL_RSR_WWW_MODIFY_TABLE in the Object type field. Click on the Create button to see the screen in Figure

10. Click on the create inheritance icon and the Superclass field shows up (Figure 11). Enter

CL_RSR_WWW_MODIFY_TABLE in the Superclass field and save it.

Figure 9 Start Class Builder

Figure 10

Enter CL_RSR_WWW_MODIFY_TABLE in the Class field

Figure 11

Enter CL_RSR_WWW_MODIFY_TABLE in the Superclass field

Then, the Class Builder: Change Class screen automatically appears. Select the Methods tab (Figure 12). Select

the CAPTION_CELL method and click on the redefine icon near the right of the toolbar. Then you can enter the ABAP code in the method. The SAP how-to document “How to … Enhance your Web Query with the Table Interface” provides all of the detailed steps to create an inheritance class and redefine the methods.

Figure 12 Redefine methods START, CAPTION_CELL, STRUCTURE_CELL, CHARACTERISTIC_CELL, and DATA_CELL

Repeat this step for the START, STRUCTURE_CELL, CHARACTERISTIC_CELL, and DATA_CELL methods. For steps 4 through 8 below, you need to click on the Methods tab in Class Builder, select each method, and then add the code. You can download the entire methods to use in your system from the Downloads section of BW Expert’s Web site.

After you redefine the methods, you also need to create an internal table called it_comm to communicate with the Web template. To do this, switch to the Attributes tab. Click on the direct type entry icon (Figure 13). Then, type the code shown in Figure 8 in the Private section of the screen in Figure 14. The code defines the type t_comm

and internal table it_comm.

Figure 13 Click on the direct type entry icon

Figure 14

Structure of internal table it_comm

Step 4. In the START method, make a JavaScript coding string to dynamically build JavaScript functions to launch a template with a data provider and a filter. You must perform this step because this kind of function doesn’t exist in SAP business content. The DATA_CELL method (available on the Downloads section of BW Expert’s Web site) uses these functions as a part of hyperlink string so that when you click on this icon, a specified

page opens. Table 6 shows the JavaScript functions.

JavaScript function

Purpose

exec_template_dpfilter Launch a template with passing a data provider and filter in a different window

exec_template_filter Launch a template with passing filter in a different window

exec_template_filter_sw Launch a template with passing filter in the same window

Table 6 JavaScript functions

When you build JavaScript functions, you need to use Web API’s command sequence. A command sequence allows you to add new commands to an original command, which means you can change several objects in different ways with commands — for example, in this case, filtering a data provider for different criteria. The APPLY_CMD_ON_TARGET = "X" allows you to choose whether to use the subsequent commands in a new page

created by the main command. See Figure 15 for details.

* Make javascript coding string for functions, Launch a tem

plate with passing DP and filter in a different window concatenate ‘function exec_template_dpfilter( DP, template, filter) {‘ CRLF ‘chart_url=”’ url ‘“ + “‘ ‘&CMD=RELEASE_DATA_PROVIDER’ ‘&TEMPLATE_ID=” + template + “‘ ‘&DATA_PROVIDER=” + DP + “‘ ‘&APPLY_CMD_ON_TARGET=X’ ‘&CMD_1=DATA_PROVIDER=DP_INTERFACE’ ‘&FILTER_COLLAPS=’ ‘“ + filter;’ CRLF ‘openWindow(chart_url,””,”dependent=no”,”800”,’ ‘“600”,”true”)’ ‘ }’ CRLF into l_coding.* create javascript functioncall method set_javascript_function exporting i_name = ‘exec_template_dpfilter’ i_coding = l_coding.

Figure 15

Partial START method to make a JavaScript coding string to dynamically build JavaScript functions

Step 5. In the CAPTION_CELL method, parse the communication string to an internal table based on the communication with the main template. N_ITEM_NAME equals the item name I use to communicate with the main template. Because it contains my long communication string that methods can’t easily read, you need to parse, or split, it to the readable internal table it_comm you created in step 3. The parsing process is based on the handshake you made in step 2 (Tables 2 and 4) to separate the information of the entire table for each key figure by YY and separate the information of the key figure to each definitions (key figure description, data provider, template, icon, and function) by XX. Then the parsing process keeps the key figures in the communication internal table it_comm for the

STRUCTURE_CELL and DATA_CELL methods to use. Figure 16 shows the coding details.

split N_ITEM_NAME at ‘YY’ into TABLE it_string. LOOP AT it_string INTO w_string. check sy-tabix > 1. split w_string at ‘XX’ into w_comm-tx w_comm-dp w_comm-tpw_comm-gn w_comm-fn.*If no DP or templateid or function is defined, take the priorKF’s DP or templateID or function as the default. if w_comm-dp <> ‘’. w_dp = w_comm-dp. else. w_comm-dp = w_dp. endif.……………..* check by X Coordinate or description if N_ITEM_NAME+2(1) = ‘X’. w_comm-xx = w_comm-tx. elseif N_ITEM_NAME+2(1) = ‘F’ or N_ITEM_NAME+2(1) = ‘P’. CONDENSE w_comm-tx NO-GAPS.

TRANSLATE w_comm-tx TO UPPER CASE. endif.

Figure 16

Use the CAPTION_CELL method (only partially shown) to parse the communication string to the internal table

Note

Command RELEASE_DATA_PROVIDER is a Web API command that displays a copy of the status of data provider DP in a new window with the template. For detailed information about these commands, reference SAP documentation of Web API. Go to http://service.sap.com/bi and click on Documentation. Then, select SAP BW 3.5 Documentation Enhancements>3.5 Web API Reference.

Step 6. In the STRUCTURE_CELL method, fill in the X coordinate for all key figures that you are enhancing. First, search the key figure you are enhancing with the condition based on the handshake for the third character of N_ITEM_NAME you made in step 2, and then fill in the X coordinate in it_comm-XX for each key figure that you just found (meet the condition). The DATA_CELL method (on BW Expert’s Downloads section) uses the X coordinate of

the key figures to locate the hyperlink string on the correct cell. See Figure 17 for the coding details.

w_string = I_TEXT. CONDENSE w_string NO-GAPS. TRANSLATE w_string TO UPPER CASE.* if decription is provided, X Coordinate needs tobe filled if N_ITEM_NAME+2(1) = ‘F’.* Fill in the X Coordinate for these keyfigs read table it_comm into w_comm with key tx = w_string. if sy-subrc = 0. w_comm-xx = I_X. modify it_comm from w_comm index sy-tabix. endif.* if decription is provided, X Coordinate needs tobe filled elseif N_ITEM_NAME+2(1) = ‘P’.* Fill in the X Coordinate for all keyfigs which contains the patten in w_comm-tx loop at it_comm into w_comm where xx = 0. if w_string cp w_comm-tx. w_comm-xx = I_X. modify it_comm from w_comm index sy-tabix. exit. endif. endloop

Figure 17

Use the STRUCTURE_CELL method (only partially shown) to fill in the X coordinate for all key figures that you are enhancing

Step 7. In the CHARACTERISTIC_CELL method, dynamically build a filtering string based on the Web API filter command structure. In this step, dynamically build filter strings for each characteristic and its value depending on the active row to filter a data provider for different criteria for later DATA_CELL method using the filter command structure FILTER_IOBJNM_N=IObjName to specify the technical name of the characteristic and FILTER_VALUE_N=CharValue to set the filter value. If you use hierarchy nodes, you need to specify the node characteristic name as 0HIER_NODE, i.e., FILTER_NODE_IOBJNM_1=0HIER_NODE. For detailed information

about these commands, reference the Web API SAP documentation referred to earlier. See Figure 18 for the coding details.

* Build a filter string for Data_Cell CONCATENATE ‘=’ I_IOBJNM ‘&’ INTO W_STR. IF l_filter CS W_STR . W_FDPOS = SY-FDPOS + 1. l_filter = l_filter+0(W_FDPOS). W_FDPOS = SY-FDPOS - 1. l_iobjNo = l_filter+W_FDPOS(1). concatenate l_filter I_IOBJNM ‘&FILTER_VALUE_’ l_iobjNo ‘=’ I_CHAVL into l_filter. ELSE.* If IObj name not exist in filter string, increase 1 on Index n andcontinue to build filter string l_iobjNo = l_iobjNo + 1. concatenate l_filter ‘&FILTER_IOBJNM_’ l_iobjNo ‘=’ I_IOBJNM ‘&FILTER_VALUE_’ l_iobjNo ‘=’ I_CHAVL into l_filter. ENDIF.* if it is a hierarchy IF I_HRY_ACTIVE = ‘X’ AND I_NODE_IOBJNM = ‘0HIER_NODE’. concatenate l_filter ‘&FILTER_NODE_IOBJNM_’ l_iobjNo ‘=0HIER_NODE’ into l_filter. ENDIF.* If * at the front of TemplateID, Template = TemplateID_HierarchyLevel & W_LEVNM = HierLevel W_LEVNM = I_IOBJNM.

Figure 18

Use the CHARACTERISTIC_CELL method (only partially shown) to dynamically build a filtering string based on the Web API filter command

Step 8. In the DATA_CELL method, dynamically change cell content based on information in the internal table it_comm. First, change cell content from standard exception color to color light bulbs if the item’s name starts

with EZ or DZ, or keep the standard color depending on your requirements. See Figure 19 for the coding details.

IF N_ITEM_NAME+1(1) = ‘Z’. path = ‘mime/Customer/Images/’. IF N_ITEM_NAME+0(1) = ‘D’. l_num = ‘’. “ remove 0s for dashborad ELSE. IF C_CELL_CONTENT CS ‘’ . W_FDPOS2 = SY-FDPOS + 1. ENDIF. IF C_CELL_CONTENT CS ‘“>’ . W_FDPOS1 = SY-FDPOS + 2. ENDIF. W_LEN = W_FDPOS2 - W_FDPOS1 - 1. IF W_FDPOS1 > 0 AND W_LEN > 0. L_NUM = C_CELL_CONTENT+W_FDPOS1(W_LEN). ELSE.* For precalculated query which keyfigs has no context menu L_NUM = C_CELL_CONTENT.

ENDIF. ENDIF.* Replace exception colors to color light bulbs

Figure 19

Use the DATA_CELL method (only partially shown) to change exception colors to any icons

Secondly, get information from communication internal table it_comm, build the hyperlink string dynamically with a JavaScript call and with the specified icon, then replace the cell content with it for the key figure that you are enhancing. For example, add a calling JavaScript function exec_template_dpfilter with data provider w_comm-dp,

template w_comm-tp, and filter parameter coding in , also add in . Replace the key figure’s cell content with this

long hyperlink string so that when you click on this icon, a specified page opens. See Figure 20 for the coding details.

read table it_comm into w_comm with key xx = I_X.check sy-subrc = 0.* && = Separator for multiple DPs / Templates / Icons / Functionssplit w_comm-dp at ‘&&’ into TABLE it_dp.……………………………………….LOOP AT it_tp INTO w_tp. w_TABIX = sy-TABIX. read table it_dp into w_dp index w_TABIX.……………………………………………………………. w_comm-dp = w_dp.……………………………………………………………… if strlen( w_comm-dp ) > 1.* If * at the front of DP, means DP = DP_HierarchyLevel, i.e. DP_ZPRODH1 IF w_comm-dp+0(1) = ‘*’ and W_LEVNM <> ‘’. w_comm-dp = w_comm-dp+1. if W_LEVNM ca ‘__’ . w_pos = strlen( W_LEVNM ) - 3. do w_pos times. if W_LEVNM+w_pos(2) = ‘__’. w_pos = w_pos + 2.

Figure 20

The DATA_CELL_2 method (only partially shown) dynamically builds the hyperlink string

Figure 21 shows the result in the main metrics dashboard. When you click on the information icon on the right side of

green light bulb on the third row, the detailed report is open just for plant 1002/100.

Figure 21 Show exceptions as colored lights

More Examples

You can change the standard exception colors to light bulbs as shown in Figure 21. Alternatively, you can keep the

standard exception colors as shown in the highlighted boxes in Figure 22.

Figure 22 Keep the standard exception colors

In addition, you can have many hyperlinks with any specified icons for any key figure (Figure 23). You can also have

many hyperlinks with any specified icons without key figures (Figure 24).

Figure 23

Hyperlinks with specified icons with key figures

Figure 24

Hyperlinks with specified icons without key figures

Pinpoint the Cause of Data Inconsistencies to Ensure Precise Key Figure and Characteristic Values  

by Iliya Ruvinsky, SAP BW Consultant, Advantech Technologies

Although many people view troubleshooting as a random process, you can apply a systematic technique to verify data quality. Use these helpful suggestions to locate errors.

Categories: BEx, Data Extraction, Data Management, Event and Process Chains, Update and Transfer Rules, Web Application Designer

Key Concept

During the final phase of BW projects, developers verify data quality. Here, quality refers to consistency and preciseness of the key figure and characteristic values that BEx or Web Application Designer reports display.

BW developers must make sure that data from the source system has stayed consistent through to the final results and makes business sense. The source data travels into BW InfoProvider, through the Extraction, Transformation, and Load (ETL) engine, to BEx or Web Application Designer (Web AD) queries. Often, inconsistencies arise between the source (R/3 or other) and target (BW) figures. Developers must identify, interpret, understand, and — if the data differs from the expected values — correct the data.

Those responsible for development and data quality checking begin by searching for problems. I use a standard procedure to isolate errors. I will discuss my precise, systematic way of checking data quality. Once you’ve located the error, you can fix it yourself or work with your technical team to repair it. You could standardize and transform my procedures into your regular checking procedure. The following checklist helps me to efficiently check my data, especially when problems seem ambiguous.

Define the Problem

The first step is to define the problem. In this context, perhaps the BEx or Web AD report results are incorrect or do not match what you expected. You could subdivide the term incorrect results into three main categories:

1. Incorrect, missing, or unexpected characteristic values appear in the report. For example, master data (characteristic values) that appears in your BW report differs when you compare it to your source data within the R/3 system. For example, the 0CUSTOMER master data table lacks the customer number 10007767 in BW, but this number is active in the source system. Another problem might be that one of the attributes of the customer number 10007767 has a different status in BW as compared to the source system.

2. Incorrect, missing, or unexpected key figure values show up in the report. For instance, transaction data (from key figure values) differs between your source and target systems. For example, R/3 shows that the amount of sales for customer number 10007767 on February 2006 equals $28,000, while your BEx report shows $25,990.

3. The BEx or Web AD report brings no results when you expect data to show up.

Even though each of the three problems above might originate differently, you can locate the problem in a similar

way. First, you must understand and imagine the whole data flow process from source to target. Figure 1 depicts the stages and elements of this process.

Figure 1 Data flow from source system into BW

As data enters the system, BW transforms it with the following main components: the extractor and extract structure, transfer rules, update rules, InfoProvider, BEx report, and Web AD report. These are the most likely places for data quality problems to occur.

Sometimes you need to investigate elements that do not belong to the data transformation process, but rather serve as part of the overall data staging process. These include InfoPackages, process chains, and authorization issues. I’ll discuss them later in this article.

You should also consider business content extractor logic when investigating data quality concerns. I’ll concentrate on technical aspects of inconsistency problems, but remember that business logic, not technology, can also result in errors. Consultants often use SAP-delivered business content to reconcile an R/3 report to a BW report based on that same data set. Inconsistencies can result when you don’t validate how the extractor picks up data compared to the R/3 report.

For example, the standard extractors for sales orders assume that an order is closed when it is fully shipped and collect and present the data accordingly. However, many organizations don’t consider an order closed until it is invoiced. Such companies often customize their R/3 reports to reflect that status. The BW extractor won’t have that logic built into it, thus showing different information. Many data inconsistency issues boil down to the fact that they are trying to compare what amounts to apples and oranges because the systems look at different sets of data.

Each of the elements in the data extraction process could contribute to data distortion, resulting in incorrect report results. Refer to “The Extraction Process” sidebar in the Downloads section of BW Expert’s Web site at www.BWExpertOnline.com for more information. To find the problem, you should ask a number of questions to focus your investigation in the proper area. I use a list of areas where the problem might occur, from most to least common:

1. BEx

2. Web AD

3. Extractor and extract structure

4. InfoProvider

5. Transfer rules

6. Update rules

7. InfoPackage or process chain

8. Authorization issues

In some cases, step-by-step analysis is inevitable. However, you can follow this list to shorten your analysis time. I’ll explain the types of inconsistencies and internal logic that I use for each of these items.

Note

If the source system is not R/3, you have to check the extractor via DB Connect.

BEx

When end users misuse BEx reports, the program may display inaccurate data. Some of the errors result from faulty report navigation, drill-down breaks, filter parameters, and Report-Report Interface (RRI) jumping. One aspect of this functionality allows you to focus on specific characteristic values of a report and jump dynamically to a second report while using those values as filter parameters for the first report. It affects reports with characteristics, key figures, or both.

For instance, your BEx query might apply filters to incorrect characteristic values during the query run. Consequently, BW displays wrong or missing data in its reports.

Improper construction or usage of report elements or properties (e.g., structures, key figures, cells, variables, report structure) often cause BEx problems. The more complicated the structure of report, the higher the probability that you’ll use the query elements incorrectly.

The most common mistake is incorrect sequence of the results calculations, also known as a formula collision. Perhaps your financial statement report presents a balance sheet structured with calculated characteristics in rows and with calculated key figures as columns. For example, you might need to add first, and then divide. By axis X, you need to add figures before they intercept by axis Y, where you must divide the result. Obviously, the results would differ if you performed the steps out of order.

To search for problems in the BEx area, simplify the report as much as possible. While running the query, if the problem pertains to a specific key figure value or characteristic, make sure to present only this characteristic itself, focusing on the exact data slice, not the source. In other words, simulate the data snapshot presented in the source system as much as possible.

To accomplish this, first copy the original report exactly. Next, choose whether you want to simplify the copy of the original report or build a new one that uses the problematic characteristic and key figure. Your decision depends on the complexity of the specific report. In some cases, it might be faster to recreate the problem by building a new report.

If you decide to work with the report copy, remove all elements that might distort the result. I recommend that you remove all of the report’s restrictions first, including filters, variables, and calculated and restricted key figures. Then, depending on the complexity of the query structure, you should delete elements such as data cells, calculated characteristics, characteristic structures, hierarchies, characteristics, and basic key figures until only the problematic elements remain.

If you decide to build the new test report, try to include only those elements that seem to distort the data. For example, if certain key figure values appear incorrectly in conjunction with specific characteristic values, restrict the characteristic by those values only.

Web AD

Web AD is the second most common place for errors because the errors are found here but located elsewhere. If you encounter data distortions while using Web AD templates, you should first rule out the possibility that your problem stems from BEx, because BEx reports feed Web AD templates. Web AD compiles different BEx queries into one Web template; so most of its business logic and data manipulation comes from other areas of the data flow such as extractors, transfer rules, and BEx reports. Your Web AD errors likely stem from these sources.

Each Web item reflects the results of the single or multiple BEx queries or views, so if there are problems with the data consistency, check them first inside BEx. Coding enhancements can often distort report results. First, consider any specific requirements involving ABAP or Java coding that affect the query results directly (e.g., ABAP code using a table interface and business logic to change Web report data).

Extractor and Extract Structure

If you still find inconsistent results after performing the two previous steps, check the extractor. If BEx and Web AD present the data correctly, then the problem lies in BW. I always check the extractor after BEx and Web AD to ensure that the error is not at either end of the data life cycle. While BEx problems are the most widespread, extractor problems are easiest to identify because BW has not yet staged or transformed the data.

To check the extractor, enter your R/3 system and perform transaction RSA3 to open the Extractor Checker screen. Select the data you wish to view.

If you find incorrect data, then your problem might exist in either the extraction program or the source data. In the first case, check the selection criteria of the extractor. Do you use correct parameters? Sometimes errors arise because of incorrect date formats.

In the second case, check your source data consistency. It might be necessary to look directly at the output of your RDBMS tables or views that feed your extractor using specific RDBMS view tools. Are you seeing the correct part of the data? If so, you should investigate the elements of your BW chain. I would first examine the InfoProvider.

InfoProvider

Once you’ve checked BEx, Web AD, and the extractor, there’s a good chance that your problem is incorrectly uploaded data. I’ll list some frequent causes.

Perhaps your InfoCube’s structure is faulty. For instance, if the fact table definition contains redundant or an insufficient number of key fields, then that leads to improper data granularity and potentially incorrect aggregations. You should check for correct key figure definitions (such as aggregation type) or insufficient granularity of the InfoCube (e.g., lack of certain characteristics). For example, if you locate incorrect results based on a key figure, check the aggregation definition of the InfoObject that represents this key figure by double-clicking on the InfoObject inside Administrator Workbench (transaction RSA1).

You should also see if you uploaded the same data more than once accidentally. In this case, the system adds the same key figure values again, doubling the result. To check for and avoid the problem, use the reserved characteristic 0REQUID that calls the request ID inside the BEx report. If you see that the data from request 1001 is exactly the same as data from request 1000, then you’ve probably uploaded the same portion of data twice accidentally.

If the InfoCube carries aggregates, problems related to the change run of time dependent master data attributes and the aggregate rollup process can exist. You could check for this error by right-clicking on the InfoCube, choosing the

Rollup tab, and clicking on the Logs button (Figure 2).

Figure 2 Click on the Logs button

BW prompts you to choose to display logs for different functions; choose the Rollup option. For the change run problem, examine the process chain that defines the change run process. Use transaction RSPC and choose the relevant process chain. BW displays specific error messages if the change run failed.

The above problems, faulty structure and uploading the same data more than once, may affect ODS objects. Structural problems may also lead to incorrect data. For instance, the ODS key must have a unique combination of

values. To avoid the error, you must understand fully the structure of the specific ODS based on the data that comes from the source system. An incorrect ODS structure, along with inappropriate key figure or characteristics update types, distorts the figures, although you don’t notice the problem until the data quality check.

As you probably know, InfoObjects can represent three types of master data: attributes, texts, and hierarchies. Info-Objects represent only dimensional (non-transactional) structures. They store data by replacing it with new data from the source system with the same key fields. No aggregations or other key figure saving methods are allowed, although key figures can be a part of the master data attribute structure.

Because of the limited data storage and upload methods, the only type of InfoObject problems that could happen here is related to time or version dependency. Time dependency issues apply to all three types of master data, while version dependency relates to hierarchies only. When dealing with time or version-dependent data (e.g., master data attributes, texts, or hierarchy structures subject for change over time), you must use a proper key date or hierarchy version while running a BEx query.

Virtual InfoProviders are different types of SQL queries based on physical InfoProviders. Usually, virtual Info-Providers contain multiple types of physical or virtual InfoProviders.

To resolve data quality problems in virtual InfoProviders, first check each InfoProvider for the above-mentioned InfoCube and ODS problems. Then, if needed, investigate the structure of the virtual InfoProvider itself.

The way you check for and avoid the problem depends on the type of the virtual InfoProvider. Consider the three main types:

Virtual InfoCubes are InfoCubes that represent a logical view. They derive data from SAP, non-SAP systems, or user-defined function modules.

MultiProviders are InfoProviders that combine data from several InfoProviders for reporting. A MultiProvider contains no data; all data comes from the Info-Providers on which it is based. Multi-Providers combine data on a union basis. You must fully understand their construction to check for related data quality problems.

InfoSets are InfoProviders that combine data from a combination of ODSes and InfoObjects. InfoSets combine data on a join basis. Again, you must understand their construction to understand the related data quality problems.

Transfer Rules

One cause of incorrect data in transfer rules is incorrect InfoObject mapping. In this case, you must find an appropriate InfoObject to deliver data properly into the InfoSource. For instance, BW must translate data presented in Universal Time Converted (UTC) format from the source system into “normal” date and time format using an appropriate InfoObject (0CALDAY in this example) with an internal routine that automatically translates. Certain InfoObjects are equipped with the appropriate conversion routines, but you could end up with raw, incorrect data if not.

You could check for a conversion routine by double-clicking on the InfoObject in Administrator Workbench and

entering the appropriate conversion routine in the Convers. Rout. field on the General tab (Figure 3). Press F4 while in the conversion routine window to see the full list of routines with explanations of what they do. However, the explanations are not always satisfactory, so you might have to consult ABAP programmers to investigate the underlying code of the routine.

Figure 3 Enter your conversion routine in the Convers. Rout. field on the General tab

BW delivers DataSource fields to the InfoProvider via ABAP routines or formulas. An incorrect ABAP routine or formula might be to blame for your data errors, so check their consistency. To go to the Transfer Rules screen of Administrator Workbench, enter RSA1, select the InfoSources tab, and double-click on the Transfer Rules tab of the specific InfoSource. Here you should check an appropriate transfer rule of the suspected InfoObject, or click on the create start routine icon to see the code. As I said before, BW applies the start routine to the whole set of delivered data, while specific transfer rule ABAP routines relate to the specific InfoObject data delivery. Click on the

rule to go to the formula or routine (Figure 4). Depending on the makeup of your BW team and each person’s responsibilities, ABAP programmers or BW consultants should check the code. Also, remember to watch for incorrect start routines.

Figure 4 Check the ABAP routine

Update Rules

If the transfer rules present accurate data, you check the update rules of specific InfoProviders. Many problems that relate to the update rules include improper update type (while performing consistency checks for key figures). Depending on the InfoProvider type, check that you’ve selected the proper update method. For ODS, this could be addition, overwrite, or no update. For InfoCubes, select addition or no update only.

While performing consistency checks for characteristics (relevant for the data part of the ODS structure only), check the update method, which could be overwrite or no update. In the ODS settings, check the Unique Data Records check box in Administrator Workbench to implement an appropriate upload scheme. To do so, enter transaction RSA1, go to the InfoProviders tab, double-click on your chosen ODS, expand the Settings tab, and check Unique Data Records. If you check this box, BW posts only unique data records in the ODS object, making it impossible to

load data records into the ODS object if the key combination already exists. You should also check for incorrect start routines, ABAP routines, or formulas using the procedure described in the “Transfer Rules” section.

BW might read attributes of an InfoObject’s master data incorrectly, so check that the attribute data arrives from an appropriate InfoObject. Examine the update method for InfoObject inside the update rules. In some cases you see incorrect data because an inappropriate attribute appears instead of the correct InfoObject from the transfer rules.

InfoPackage

InfoPackage is a program containing parameters for data extraction. It defines the conditions for requesting data from a source system (for example, selection conditions, start conditions for data requests, options for updating data, and types of error treatment).

It’s important to check InfoPackages to make sure you’re uploading the right portion of data. Verify the correct update method (full, initial, or delta update, and, in the case of time dependent master data, time interval). These factors might affect whether BW uploaded the right records into data targets.

Also, check what data targets are updated using a specific InfoPackage. Sometimes, you might expect to see a certain portion of data uploaded and presented in your BEx or Web AD report, when in reality, that data arrived in the wrong InfoCube or other target. Inside Administrator Work-bench, double-click on the InfoPackage and choose the Data Targets tab. You see a list of the data targets updated by the InfoPackage. Check what targets are chosen for update.

Process Chain

A process chain is a logical grouping of linked processes (or jobs) scheduled in the background that you can trigger based on specific events. The dependencies that exist between each process dictate the order in which BW executes them. When activated, BW assigns each process to a system-generated event. You could check them by clicking on each job, observing what it should perform, and how it is performing it. Sometimes, the problem lies in the wrong sequence of the jobs and sometimes in the definition of the job itself. For example, the InfoPackage with the wrong selection criteria is part of the chain. In this case, you either change the criteria or the InfoPackage itself.

Factors that could contribute to data distortion include attribute change runs, ABAP programs, deletion of overlapping requests, InfoPackage execution, aggregate rollup, and many others. If your process chain controls data flow process, check those jobs.

Authorization Issues

Authorization restrictions on BEx/Web AD objects could result in missing data. Generally, authorization restrictions use roles in concert with BEx elements such as authorization variables to prevent users from seeing undesirable master data values or certain key figures. In most cases, BW provides an error message relating to the authorization problem. In rare cases when an error message is not informative enough but still shows an authorization problem, you should check the BEx authorization variable definition and the role restrictions via transactions RSSM or PFCG.

Prevent Users from Accessing Sensitive Data Using Authorization Restrictions  

by Graeme Smith, Principal BW Consultant, Unilog Ltd.

Securing information within an SAP BW system is necessary, but it can be difficult because of the massive volumes of sensitive data that are stored in the system. Learn how to develop authorization restrictions for

InfoObjects via transaction RSSM so end users can access only relevant data.

Categories: BEx, Security

Key Concept

SAP BW has two types of authorization objects. The Business Information Warehouse authorization object (RS) restricts BW users from completing certain functions such as creating queries or assigning them to roles. BW provides all the required authorization objects for this classification type so there is no requirement to create custom objects in this category.

The other type of authorization object, Business Information Warehouse — Reporting (RSR), restricts users from seeing certain data. BW does not provide standard RSR authorization objects so you have to create them yourself using transaction RSSM. See the article, “Use Authorization Objects to Provide Flexible BW Security,” by Raju Veludandi in the July/August 2004 issue of BW Expert for more details on authorization objects.

You can roll out SAP BW information to an end-user community in a variety of ways. The most widely used and effective means, however, is to empower users to access BW and run queries themselves. This requires the implementation of authorizations so users see only the data to which they should have access. For instance, you must protect HR data to ensure that only the head of an IT department can see the salaries and personal information for the employees within that department. You could also add authorizations so cost center managers only see the cost and spend figures for the cost center for which they are responsible.

I’ll walk you through the process of developing data authorization restrictions for InfoObjects within BW. I’ll also detail the process of implementing authorizations for both characteristics and key figures and point out when the process differs for each. I’ll focus on how to use the BW reporting authorization object RSR. In the characteristic authorization example, I’ll configure the system so that users are only allowed to see cost center CC00000010. For the key figure authorization example, the setup I’ll explain here allows users to view only the key figure 0AMOUNT.

Authorization Restrictions Overview

The steps to develop authorization restrictions are:

Step 1. Make an authorization-relevant InfoObject

Step 2. Create an authorization object

Step 3. Incorporate the authorization object into a role

Step 4. Set up the data restriction

Step 5. Apply the data restriction to InfoProviders

You use the BW-specific transaction RSSM to create authorization restrictions for characteristics, hierarchies, and key figures. Unless otherwise noted, the process is the same for restricting both characteristics and key figures.

Creating authorization restrictions for hierarchies is outside the scope of this article. Figure 1 shows a characteristic and key figure query prior to the addition of authorizations. The user has access to all the data.

Figure 1 The query prior to the authorization restriction

When restricting characteristics, users can view only the category or categories of the characteristics to which they have access. If users try to run a query with categories to which they do not have access, the query returns with an authorization error that does not allow them to view any data. After adding characteristic authorizations to the query in Figure 1, you would see the data only for the single cost center that has been hard coded into the authorizations (cost center CC00000010). The screen would display both key figures, Amount and Quantity.

Key figure restrictions work slightly differently. When entering the restriction value for key figures, you enter the key figures that users are allowed to see. When users run a query with key figures to which they don’t have access, the query returns an authorization error message. When the users select OK, the query runs and returns data for the key figures to which the users have access. However, any key figures in the report to which users do not have authorization appear blank.

After you implement key figure authorizations for the query in Figure 1, the query would have the same structure, displaying all cost centers and a column for each key figure. The authorization would blank out the key figures to which the user does not have access. In this example, users would see a blank Amount column and a blank Quantity column.

Step 1. Make an Authorization-Relevant InfoObject

This part of the process is required for characteristic authorizations and not for key figure authorizations because key figures have a standard object that defaults as authorization relevant. This example is based on a characteristic that has already been created. However, it is possible to make an InfoObject authorization relevant during the process of creating an InfoObject from scratch.

To complete this step, run transaction RSD1 and maintain the InfoObject on which to base your characteristic authorization. I use cost center object ZCCBWE in Figure 2. Select the AuthorizationRelevant check box located

on the Business Explorer tab of the InfoObject maintenance screen. When you have completed this, activate the InfoObject.

Figure 2 Select the AuthorizationRelevant check box

Step 2. Create an Authorization Object

For characteristic restrictions, BW provides standard authorization objects that restrict BW users from completing certain functionalities with the BW system and BEx/Web applications. However, no standard authorization objects exist for data restrictions, so you need to create them. The authorization object I’ll create is based on the InfoObject from step 1.

Go to transaction RSSM (Figure 3). To set up a characteristic authorization, enter the name of your authorization object, ZCCBWE in my example, in the Authorization Object field. Select the Object button, click on the create icon, and a screen pops up. Enter a description of the authorization object in the field provided and click on the enter icon

(a green check mark) and Figure 4 appears.

Figure 3 Enter your authorization object’s name

Figure 4 Enter a description of your authorization object and bring InfoObject ZCCBWE to the left

Now highlight ZCCBWE (the InfoObject that you made authorization relevant in step 1) on the right side of the screen in Figure 4, use the arrows to bring it over to the left side, and save. The right side of the screen provides a listing of all the InfoObjects that have been made authorization relevant and some standard BW objects.

For key figure restrictions, InfoObject 1KYFNM allows you to restrict the viewing of any available key figures. Unlike characteristic restrictions, where you select a specific authorization-relevant InfoObject (e.g., cost center, organization unit, profit center), all key figure restrictions use the same authorization object, 1KYFNM. You select the key figures you want to restrict at a later stage.

Go to transaction RSSM and enter ZCCBWEKYF, the name of the authorization object (Figure 5). Select the Object button and click on the create icon. Add a description of ZCCBWEKYF in the Authorization Object field and click on

the enter icon. In the screen shown in Figure 6, highlight InfoObject 1KYFNM on the right side of the screen, use the arrow to bring it to the left side, and save.

Figure 5 Enter the name in the Authorization Object field

Figure 6 Describe the authorization object and bring InfoObject 1KYFNM to the left

Step 3. Incorporate the Authorization Object into a Role

Now that you’ve created the authorization object, the next step is to assign the authorization object to the profile of a role. You need to use a role that already has all the relevant authorizations to run a query from a functionality standpoint and then add the new authorization object you have created to the profile of this role.

First, edit the role to add the authorization object to the profile (Figure 7). Enter transaction PFCG, type the name of the role (ZBWE in my example), and select the change icon (a pencil). Next, go to the Authorizations tab and select

the change icon next to Change Authorization Data to change the profile (Figure 7).

Figure 7 Edit the profile of the role by selecting the change icon on the Authorizations tab of role ZBWE

In the resulting screen (Figure 8), click on the Selection criteria button to add the authorization object restriction to the profile of the role. This takes you to the Change role: Insert authorizations screen (Figure 9). Expand the SAP Business Information Warehouse – Reporting folder. The authorization object ZCCBWE is displayed in this folder

(Figure 9) and ZCCBWEKYF is displayed in this folder in Figure 10.

Figure 8 Click on the Selection criteria button to add an additional authorization restriction to the role’s profile

Figure 9 Insert the characteristics authorization object, ZCCBWE (Cost Center BWE Authorization Object), into the profile of role ZBWE

Figure 10 Insert the key figure authorization object, ZCCBWEKYF (key Figure Restriction for BW Expert), into role ZBWE

Click on the red minus sign to the left of your authorization object to change it to a green plus sign. Insert the authorization into the role using the Insert chosen button at the top of the screen. This is illustrated in Figure 9 for characteristic authorization (ZCCBWE) and Figure 10 for key figure authorization (ZCCBWEKYF).

Step 4. Set Up the Data Restriction

Now that you’ve added the authorization object into the role, create the data restriction for the role. Use the change

icon to the left of the authorization object to select the value for the authorization (Figures 11 and 12).

Figure 11 Choose the change icon for the Cost Center authorization objectclick here for a larger image

Figure 12 Choose the change icon for the Key figure authorization object 1KYFNMclick here for a larger image

Figure 13 shows the selection box that appears when you have selected the change icon next to the authorization object. Select the correct authorization value by typing in the value or selecting the value from the drop-down list.

Select the correct value or values and save the authorization. This adds the restriction to the role (Figure 14).

Figure 13 Select the characteristic authorization value and save

Figure 14 The profile screen after entering the characteristic restriction value

Figures 15 and 16 show the same process of selecting the value for restricting which key figures may be viewed. Enter the key figure or figures to which the user has access. As with the characteristic restriction, you can either type in the values or select them from the drop-down box.

Figure 15 Select the key figure authorization value and save

Figure 16 Users with access to this role are only able to see the 0AMOUNT key figure

After you’ve added the data restriction, you must generate the profile using the red and white disk icon at the top of the screen. This also saves any changes.

Use the green back icon to go back to the maintain role screen. Click on the User tab and enter thename of the user who will be running the query.

Once you have added the user to the listing, complete a user comparison to update the user's profile. Select the User comparison button and the system displays a pop-up box. Select the Complete comparison button and save the role.

Use the back icon to return to the role maintenance screen. Save the role if prompted at any time.

Step 5. Apply the Data Restriction to InfoProviders

Assign the authorization object to the InfoProvider. Return to transaction RSSM and enter the name of the

authorization object (Figures 17 and 18). Select the Check for InfoCubes button. Click on the change icon.

Figure 17 Select the Check for InfoCubes button for authorization object ZCCBWE

Figure 18 Select the Check for InfoCubes button for authorization object ZCCBWEKF

Now select the InfoProviders for which the authorizations object should be in effect (Figures 19 and 20). Save to make the authorizations effective for the selected InfoProviders.

Figure 19 Select the InfoProviders for which characteristic authorization object ZCCBWE should be in effect

Figure 20 Select the InfoProviders for which key figure authorization object ZCCBWEKYF should be in effect

Execute the Queries

Now that you’ve set up the authorizations, run queries to ensure you get the correct result. For characteristics, users

need to restrict the query in relation to the authorization restriction you just configured, CC00000010 (Figure 21). You could either hard code the query in question by a variable entry or by creating an authorization

variable. It’s more flexible to use variables, because if authorization restrictions are hard coded, you have to maintain a query for each authorization restriction.

Figure 21 The restricted query

For more details, please see the “Enter the Authorization Restriction in a Query” sidebar on the Downloads section of BW Expert’s Web site, www.BWExpertOnline.com.

Once you have made the correct restriction in relation to the authorization, the query should bring back only authorized values. If the incorrect value is displayed an error message appears and the query displays no data, only the message “No Authorized Data.”

For the restriction of key figures, no additional work is required. Simply run the query and you are allowed to view the only key figures to which you have access according to the restriction, 0AMOUNT in my example. A warning appears informing you of the restriction in place (Figure 22). All key figures except 0AMOUNT appear blank in the query. The role in Figure 22 allows the user to view the amount field. The other key figure columns to which the user does not have access appear blank in the report.

Figure 22 Key figure warning message

 

Publish SAP BI Content More Easily with SAP Enterprise Portal 6.0  

by Glen Leslie, BI Product Manager, SAP Labs

Among the benefits of SAP NetWeaver ’04 is better integration between SAP BI and SAP Enterprise Portal (SAP EP). This overview explains what the integration of SAP BW 3.5 with SAP EP 6.0 Support Stack ’04 (and above) provides.

Categories: BEx, SAP NetWeaver Portal

Key Concept

SAP Knowledge Management (SAP KM) is a part of SAP BI that coordinates information within a company. It focuses on rationalizing, organizing, and making accessible unstructured corporate information and consists of two parts, collaboration and content management.

SAP NetWeaver ’04 provides greater compatibility between the SAP BW 3.5 and SAP Enterprise Portal 6.0 than earlier releases of those components. SAP EP 6.0 is better able to accommodate SAP BI content thanks to changes in the iView architecture and enhancements to SAP Knowledge Management (SAP KM), a component of SAP EP.

End users will find the process of publishing SAP BI content into the portal simpler using SAP BW 3.5 and SAP EP 6.0. They can publish SAP EP iViews from SAP BW 3.5 directly in the Business Explorer Web Application Designer (BEx Web AD), BEx Query Designer, or the BEx Broadcaster — this includes publishing of BEx Analyzer workbooks into SAP EP.

I’ll give you an overview of how SAP EP 6.0 integrates with SAP BW 3.5 along with new technical integration points. You will also have a good idea of how the new technology is similar as well as different from its predecessors. I’ll detail the variety of KM document and iView publishing targets that are available and provide you with a number of resources for more detailed information. I will also show you how to publish BEx Analyzer workbooks in the SAP EP 6.0 and demonstrate the portal-based BEx Showcase role.

Technical Integration

In terms of technical integration, SAP BW 3.5 is significantly different from previous SAP BI releases and it provides enhanced interaction with the portal. In SAP EP 5.0, the portal was aware of SAP BI, but SAP BI was not entirely aware of the portal. This is not the case with the new releases. When SAP EP 6.0 is connected to SAP BW 3.5, you maintain entries for SAP EP in the SAP BW 3.5 system. You also can maintain multiple entries when there are multiple target portals.

SAP BW 3.5 connected to SAP EP 5.0 behaves in many ways like an SAP BW 3.0B system, which I described in my September 2003 BW Expert article “Four Ways to Publish SAP BW Content to SAP Enterprise Portal.” SAP BW 3.5

system provides an option for this interaction (Figure 1).

Figure 1 SAP BW 3.5 options for SAP EP 5.0 publishing

SAP EP 6.0 differs from its predecessor in that the newer portal technology provides dynamic menu navigation via BEx Web item roles rather than iPanels. You can also publish directly from BEx Web Application Designer (Web AD) to SAP EP 6.0 instead of using an iView file upload. Full-screen iViews replace external services in SAP EP 6.0 and the Portal Content Studio manages portal content rather than requiring separate storage for roles, pages, and iViews as called for in SAP EP 5.0. Moreover, SAP EP 5.0 did not support Information Broadcasting-based portal publishing.

Java components allow the SAP BW 3.5 system to access and display contents of the portal as publishing targets for SAP BI content. In the BEx environment, open and save dialog boxes display various tools and available SAP EP roles as well as Portal Content Catalog (PCC) folders, documents, and folders from SAP KM. When saving, you can create iViews or documents directly from the BEx Web AD or BEx Query Designer without extra administrative steps in SAP EP. SAP BI Information Broadcasting allows you to generate documents and links in SAP KM folders. You also can visualize these documents and links using the delivered BEx Portfolio content in SAP EP.

SAP EP provides BI repository managers to connect the SAP KM repository framework to external content. As a result, the SAP BI server becomes another content source for the SAP KM repository.

This exposes metadata regardless if it is generated from SAP BI or if it is a Multipurpose Internet Mail Extension (MIME) document attached to SAP BI content. MIME is a standard that identifies the type of data contained in a file based on its extension, and MIME documents can be attached to meta-, master, or transaction data in SAP BI

(Figure 2).

Figure 2 KM repository managers for SAP BW

Publishing Targets

There are five publishing targets for SAP BI content: SAP KM documents, SAP KM document links, SAP EP collaboration rooms, and PCC as a BW Web application iView or as an SAP transaction. I’ll describe each target in more detail.

SAP KM Documents

SAP NetWeaver ’04 supports two classes of portal content: KM documents (contained in My Portfolio, Content Manager Repository View, and Collaboration Rooms) and iViews (Portal Content, Portal Roles).

The BEx publishing targets shown in Figure 3 include:

My Portfolio — publish as a document to a user’s private SAP KM folder

CM Repository-View — publish as a document to the public SAP KM folders accessible to people assigned to roles.

Collaboration Room — a special kind of SAP KM storage that has additional collaboration features available. I’ll explain this storage option in some detail below in the “Collaboration Rooms” section.

Portal Content — publish as an iView into the main PCC where it can be used by portal administrators and users as they design portal pages, worksets, and roles for content deployment (see the “PCC” subhead for details)

Portal Roles — publish directly to a specified pole in the portal

Figure 3 SAP BW 3.5 options for publishing to SAP EP 6.0

Note that the first three options publish content into SAP KM as documents. You cannot publish standard iViews within those options — the final two options allow for the creation of iViews.

SAP KM provides content management services to bring unstructured content to users. It also offers users document services such as unified search, subscriptions, ratings, adding of attributes, commentary, and classification capabilities. You can access remote documents via the repository managers or store documents in the Content Management (CM) data store within SAP KM itself.

SAP KM Document Links

Information Broadcasting provides content precalculation capabilities for posting documents as well as online links. Precalculation means that the SAP BI server executes and populates SAP BI content. This content is then pushed via the broadcasting mechanism. The result is that within SAP KM, precalculated broadcast content becomes an SAP KM document in public and private KM folders with full document services. Online links become SAP KM document links which link back to the source system and launch SAP BW 3.5 content (in this case).

With documents, the document content is accessible to SAP KM services, whereas with online links, only the metadata of the link is available. In addition to SAP KM services for documents, you can fully index and classify SAP KM documents in SAP’s Text Retrieval and Information Extraction engine (SAP TREX), allowing the contents to participate in enterprise searches. Beyond this, TREX can help you identify content for and assist in the structuring of the enterprise taxonomy. In this case, SAP BI content in the SAP KM repository would participate in this process. For more information on SAP TREX, please visit the BW Expert Web site’s Download Section and look for the link to TREX on www.sdn.sap.com.

CM Repository

Broadcasting content into SAP KM folders within SAP EP is a BEx Information Broadcasting option within SAP BI

(Figure 4). In the September 2004 edition of BW Expert, I wrote an article (“BEx Information Broadcasting in SAP BW 3.5 Puts Users Front and Center”) that offers more details.

Figure 4 BEx publishing options

The CM Repository View is the CM repository (which is a sub-directory of the SAP KM repository taxonomy used as a target for broadcasting). Using the CM Repository View, you can publish to public or private KM folders.

Collaboration Rooms

As I noted earlier, collaboration rooms are a special type of KM storage that further extend KM services by providing:

Asynchronous collaboration capabilities such as task management, discussions and threading, document feedback, and instant polling

Groupware integration of existing calendaring and scheduling applications

Synchronous collaboration features such as instant messaging and application sharing (WebEx, NetMeeting, etc.)

Incorporation of room parts for consistency of common functionality across rooms

Template-based room deployment for a consistent look and feel

Collaboration rooms allow companies to use SAP EP as a single point of entry for process-driven, unstructured, or ad hoc collaboration among employees and knowledge workers. You can find more information about SAP EP collaboration at http://service.sap.com/nw-collaboration.

PCC

A number of changes in the SAP EP 6.0 architecture affect SAP BI report authors and SAP EP administrators. The separate storage of iViews (Web applications as part of a portal page) and external services (Web applications as a whole portal page) have been unified in the SAP EP 6.0 PCC. It enables simple, common maintenance of all portal content objects and allows for a folder-based (taxonomy) structure within the PCC.

In SAP EP 6.0, iViews replace external services. iViews can contain a whole page and no longer have to be part of a portal page, meaning that iViews can exist without portal pages. This makes the configuration options for administrators and authors more flexible and simplifies the storage of content in the PCC, making it more accessible and less dispersed across numerous classifications (iViews, external services, pages, etc.).

Note

Because of the close integration of the BEx suite of tools and SAP EP, the use of iView files (.ivu) is no longer necessary and not supported for SAP EP 6.0. This feature continues to be supported when SAP BW 3.5 is connected to SAP EP 5.0. You can use URLs to integrate older versions of BW to SAP EP 6.0.

Portal Roles

SAP Role Migration has been replaced with Role Upload in SAP EP 6.0. Role Upload is an option within portal administration that uploads objects (e.g., roles and transactions) from ABAP-based SAP systems. For details on this functionality, see http://service.sap.com/nw-howtoguides>Portal, KM and Collaboration>Portal>Uploading and Adapting ERP Roles to SAP Enterprise Portal. This document applies to all ABAP-based SAP systems such as SAP BI.

Web Query/Template URLs and Bookmarks in SAP EP

Since SAP EP 5.0, URL-based integration (e.g., iViews defined from a URL) has been possible with SAP BI content. As mentioned in my 2003 BW Expert article on SAP EP 5.0 integration, it is best to set up BEx queries using the application type SAP BW Web application in SAP EP. This means that you configure SAP BI and SAP EP so the source SAP BI system has an alias on the SAP EP.

This configuration is preferred because portal sessions and system and cache management are available to known source systems. With SAP BW 3.5, the direct integration of the BEx suite of tools should reduce manual, URL-based iView creation. However, this functionality is still supported in SAP EP 6.0 should end users or administrators deem it necessary (if you were to connect an older version of SAP BI to SAP EP 6.0, for example).

The process to integrate SAP BI content via a URL is simpler than with SAP EP 5.0. You still use the iView Wizard method I described in the earlier article and select the SAP BW Web application template for the iView. Figure 5 shows how the administrative navigation to the iView Wizard has changed in SAP EP 6.0. Populate the BEx Web

Application Query String property with values displayed in the SAP BI query/template URL. The new, simpler format for this entry is as follows (where uppercase values should be replaced with the technical name for your template, InfoCube, query, or bookmark, respectively):

Figure 5 iView Wizard in SAP EP 6.0

For BEx Web applications: template_id=

For BEx Web Analzyer (e.g., default Web template) queries: infocube=INFOCUBE>&query=

For SAP BI bookmarks: bookmark_id=

You can obtain these values by launching a BEx Web query or template and inspecting the URL SAP BI inserts into the Web browser’s Web address toolbar.

The Flexible User Interface (Flex UI) in SAP EP 6.0 is an important part of how the viewing audience perceives portal content. You can configure the layout of content published into the portal in two ways. The administrator can standardize the layout for a corporate look and feel or you can allow individual users to customize it. Figure 6 shows

one possible layout for the content published to SAP EP. Figure 7 shows some of the options available by default in SAP EP for alternate views of the same content, in addition to custom layout sets defined by administrators.

Figure 6 Business Explorer showcase role in SAP EP 6.0

Figure 7 SAP EP Flex UI presentation options

Publish BEx Analyzer Workbooks to SAP EP

SAP BW 3.5 continues to support Microsoft Excel workbooks as an interface for analysis of data. BEx Analyzer workbooks can be used in Information Broadcasting scenarios. You can broadcast them as SAP KM documents when pre-calculated or as SAP KM document links when broadcasting as an online link. Publishing a BEx Analyzer workbook as an iView is different, however. iViews for BEx Analyzer workbooks are set up as SAP transaction iViews in the iView Wizard. In the iView definition, you must populate three properties to successfully execute the workbook from SAP EP:

Make sure that the System property contains the alias of the SAP BI server (e.g., define the system in the portal).

Set the transaction code property in the iView to RRMXP.

Populate the ApplicationParameter property with the value WBID=. To determine the workbook ID from the BEx Analyzer toolbar, choose OLAP Functions for Active Cells>Properties. The Information tab contains the Workbook ID of the BEx Analyzer workbook. Enter the value WinGui (default) in the GuiType property.

Now I’ll show you what the SAP BI content looks like in the new SAP EP Business Explorer Showcase role.

The Business Explorer Showcase Role

The SAP-delivered EP 6.0 role Business Explorer showcase (technical name com.sap.ip.bi.business_explorer_showcase) provides insight into the SAP KM document options described above and demonstrates new features of SAP BW 3.5 in SAP EP. In terms of overall functionality highlighted, the “My Portfolio” view shown in Figure 6 is a private (user-specific) sub-directory of the SAP KM folder taxonomy. The top two links are further sub-folders in the taxonomy and the bottom two links are SAP BW 3.5 broadcast content — a precalculated document on the left and an online link on the right. Figure 8 shows the entire public taxonomy

structure — the BEx Portfolio tab would be pointed to a node in this taxonomy, allowing broadcast content to fall into a consistent place within the overall taxonomy.

Figure 8 Administrator’s view of the SAP KM folder structure

 

Figure 6 shows the showcase role. This role demonstrates SAP BI content displayed via the new Flex UI in SAP EP 6.0. The first two tabs provide an example of the delivered Flex UI page layout called broadcasting. The role comes with the following content tabs:

My Portfolio — displays the contents of the private SAP KM folder, Personal BEx Documents (located in the SAP KM repository at /~Portal alias~/userhome//Personal BEx Documents).

BEx Portfolio — displays the contents of the public document folder, Public Documents (located in the SAP KM repository at /documents/Public Documents). Figure 8 shows this folder structure as seen from SAP KM administration within SAP EP.

BEx Web Analyzer — provides direct access to the SAP BW 3.5 default Web template.

BEx Broadcaster — provides Information Broadcast settings administration for the end user (described in detail in my September 2004 BW Expert article on Information Broadcasting).

Collaborative BI — contains iViews from SAP KM to display discussions, notifications, and public and private collaboration rooms. As mentioned above, collaboration rooms are a special type of SAP KM storage

with specialized services. As shown in Figure 9, this showcase role provides easy access into collaboration tools within the SAP EP. Discussion threads and notifications are also shown here. Note that notifications in Figure 9 appear in a sub-window simply to demonstrate what can be seen when you expand the Recent Notifications iView.

Figure 9 Collaborative SAP BI overview display

Delegated Administration in SAP EP 6.0

Delegating administration, distributing the administration of tasks and content in the portal to different administrators, allows for selective assignment of the tools, tasks, and content in the portal. This can help to solve the problem of exposing restricted company data while allowing for flexible administrative authority where appropriate. For SAP BI content, it means that administrators can delegate BI publishing tasks to the appropriate users without consistent, direct intervention on the part of the super administrator.

The flexibility of content administration is available because portal administration tools in SAP EP 6.0 are effectively iViews. These iViews are grouped into worksets, which are groups of logically related iViews that accomplish specific aspects of portal administration. Customer-defined worksets are not subject to any constraints other than those specified by corporate or project guidelines. SAP-delivered worksets in turn are provided in predefined sub-roles such as user administration, content administration, or system administration. A specific workset, Delegated User Administration, allows an administrator the right to create new users and assign roles without changing content and system settings. This workset can be configured during implementation, so you can change the authorizations of this workset if desired.

Delegated administration is particularly useful when considering the various responsibilities suggested in Table 1. Further information on this topic is available at

http://help.sap.com/saphelp_nw04/helpdata/en/a4/76bd3b57743b09e10000000a11402f/frameset.htm.

Publishing source

Publishing targets

Typical user Comments

BEx Query Designer 1, 2, 3, 5** Power user, query author Provides the means of directly publishing content to the portal in the SAP BEx Web Analyzer template (e.g., the default Web template for the SAP BI server).

BEx Web AD 1, 2, 3 Power user, Web content or dashboard author

Provides the means of directly publishing custom BEx Web AD template content to the portal.

BEx Ad-hoc Query 1*, 2*, 3 Casual users wishing to An instance of the Web AD Ad-

Designer (This method requires manual creation of the iView using the SAP BI URL and the SAP EP iView Wizard)

create simple Web queries hoc Query Designer Web item. The end user would have to launch the Web query and send the URL to a portal administrator to run the iView Wizard and create the iView based on this URL or run the Information Broadcasting Wizard after launching the query.

BEx Broadcaster (Wizard or BEx Broadcaster itself)

1, 2, 5 Casual users (Information Broadcasting is intended for use by the SAP BI mass audience, subject to your company’s deployment strategy.) Allows direct publishing into the SAP KM repository.

Note that the BEx Broadcaster allows you to choose whether content will be pushed to the portal as an SAP KM document or as an SAP KM document link (referred to as an online link in the Broadcaster).

BEx Analyzer (Excel) 1*, 2*, 4 Any end user who is able to determine the workbook ID of BEx Analyzer workbook. A portal administrator would be required to set up the display of the BEx Analyzer as an SAP transaction iView in the portal.

BEx Analyzer (MS Excel) workbooks are added as an SAP transaction into SAP EP.

SAP BI Web query/template URLs and bookmarks

1, 2, 3, 5** Any end user or administrator who is aware of the SAP BI URL string in the browser. A portal administrator would be required to run the iView Wizard and create the iView based on this URL or bookmark.

This option could be used when, for example, the content creator wishes to add additional URL commands to filter, drill down, or add variables and security.

1. SAP KM documents in public and private SAP KM folders2. SAP EP collaboration rooms3. PCC as an SAP BW Web application iView4. PCC as an SAP transaction5. SAP KM document links in public and private SAP KM folders* By running the Broadcasting Wizard** SAP EP must generate SAP KM document links for these options

Figure 9 Comparison of publishing options

Query View Web Items Increase User Functionality and Improve Performance  

by Ned Falk, Senior Education Consultant, SAP America

Query views offer you a powerful tool that can make life easier for end users and enhance overall system performance. You can maintain and name views so that end users more readily identify and access them. While they are very powerful, views are not used enough because many don’t know how useful they are.

Categories: BEx

Key Concept

The query view Web item is a predefined query state that navigates to specific, predefined tables or charts via a drop-down selection menu. One SQL query executes the view. This transaction would otherwise take at least four clicks or require a custom-coded command sequence.

Since the launch of BW 3.5, working with views has become much easier. This latest version of BW provides the new view selection Web item, so different global views can be swapped for a specific Web item on a page. In addition, with the appropriate Web item properties, you can allow end users to create and delete views. You can also target a Web item to receive the data from the global query view you select, such as a table or chart.

Views are beneficial because they deliver data more easily and efficiently. They ease navigation for analysts and basic users when they slice information in various ways. A sales manager, for example, can access a view and learn all about a customer group and month then switch to an individual sales representative, customer, and day — all in one click.

You can scale back query proliferation with views. Because queries are easy to create, many companies support a large number of power users in the same functional area who all create queries. Creating good queries is more difficult, however, so your resources may be wasted on maintaining mediocre or even worthless queries. Views mitigate these issues by offering an alternative to authoring queries for the masses. Users can create views tailored to their individual needs rather than deploying more queries. Views are navigations, so their proliferation does not pose the same problem that query proliferation does.

To understand exactly what this new Web item provides, I’ll introduce you to views and show you how to create them. I’ll also show you how views were deployed and accessed in previous versions of BW, along with how the new view section Web item uses them.

View Overview

Views come in two flavors: jump target and global. Jump target views are predefined navigations associated exclusively with Excel and BEx Analyzer workbooks. Because this type of view is tied to workbooks only, it does not work with the new view Web item, and thus is not the subject of this article.

Global views are linked to the query itself instead of being tied directly to workbooks. Because they are associated with the query, global views can be used as a source for feeding data to Web templates, or they can be accessed directly from within the BEx Analyzer, which makes them more flexible than jump target views.

Prior to the new BW 3.5 features, the personalization features in BW facilitated the creation of a few large queries with many variables and a lot of free characteristics. These free characteristics in turn supported many navigation states for the same query. With the personalization features in BW 3.0, a Web template can display individualized navigation for each user when it is opened. Access to predefined views allow users to quickly find subsequent navigational states after a Web template is executed initially.

Before you can use the new view selection Web item, some advance work is suggested. You’ll need to create some global views, for example. You should also ask your users directly what ways they like to see their data sliced and create the new views with this feedback. You may wind up with 10 predefined views for all who access a Web template, and then some custom views created by those who require further modification later on.

Create Views

Create views in advance with the BEx toolset, which is available in previous versions of BW. In the BEx Analyzer, navigate a query to the desired drill-down state and select Save view global after clicking on the save icon (Figure 1). You can also create views using the Tools menu in Web Application Designer (Web AD) by following the Tools>View Definition menu path to the appropriate option: Based on a Query… or Based on Another View…

(Figure 2).

Figure 1 Create global views in advance via the BEx Analyzer

Figure 2 Web AD allows you to create views in advance

There are several different ways to access views made in advance. Integrating the new view selection Web item into a formal information cockpit is the best way to deploy views, in my opinion. But there are other options. You can access views directly from within the BEx Analyzer using the open view option instead of the open queries setting. In addition, you can access views directly from within the Web analyzer Web item, which is also new to BW 3.5. Another way is to use some custom code that can be inserted in the HTML view of Web AD to access a view from a Web application.

The View Selection Web Item

In prior BW releases, much of the functionality supported by the new view selection Web item could be supported via a hard-coded HTML form. It was also possible in prior versions to hard code buttons, links, or tabs that swapped out different views for a specific data provider. These features use the custom code option and are discussed in the current WNABW7 SAP workshop. The new view selection Web item avoids this custom coding option.

The view selection Web item allows you to select a view for the source of the data and combine it with a table or chart

Web item (Figure 3). As noted earlier, to properly deploy the new Web item, you should create some views in advance and have an understanding of the item’s specific properties. Those are the only prerequisites.

Figure 3 The view selection Web item

Note

I have identified the view selection Web item properties and their parameters (Table 1). For a complete breakdown of the new Web item’s features, refer to http://service.sap.com/bw and follow the menu path Documentation>SAP BW 3.5 Documentation Enhancements>3.5 Web API Reference.

Attribute

Purpose/value

Affected Web item Identifies Web items that should accompany an initial query view when the template opens.

List of query viewsView selection drop-down box that lists query views and queries created in advance. It allows you to connect views to a Web item such as a table or chart saved in a library.

Display create/delete button

Allows users to create and delete their own views. This is accomplished via create and display icons, which must be deployed when this option is selected.

Keep filter values for query views

This button passes the filters of the navigation state you are in to the query or query view you selected in the drop-down box.

Table 1 View selection Web item properties

To create a Web template using the view selection Web item, the template needs the item along with a preexisting table item or other initial Web item, like a chart. In the example settings, OUR_TABLE_1 is the technical name of the

other Web item needed on the template (Figure 4).

Figure 4 Web template with view selection Web item

Most of the settings on this new Web item are intuitive. After clicking on the Web item in the layout view of Web AD, access the Property section of the Web Item tab. Flag the check box to select the listed feature.

To connect a view’s data to a display chart or table Web item, type the technical name of the Web table or chart in

the Affected Web Item field. I used OUR_TABLE_1 in this example. For the List of Query Views field, you need to reference a table or chart Web item that was previously saved in a library, along with a view to provide the data to that item.

Note

To save a Web item in a custom library, access the Save in Library button on the bottom of any Web item properties screen (in this case, a table or chart Web item). Now that you understand these settings, you can incorporate the item on a Web template (see the Predefined and Charts/Tables caption in Figure 4) to display the view’s data.

Web-Based View Creation

Let’s incorporate the advanced view creation options. One of the big advantages of the new Web item is the end user’s ability to create, access, and delete personalized views via the Web-based view creation tool. Access this new and improved view creation method using the Create icon on the view selection Web item. Once selected, the system branches to a Web-based view creation GUI. It allows navigation to the desired data and lets you connect a

table or chart to the output (Figure 5).

Figure 5 Web-based view creation

Note

As opposed to the views previously created and applied in the deployment of the view selection Web item, the views created by the Web-based view creation tool are only available to the user who created them. Be aware that the creation icon functionality did not work perfectly in the patch of the system I initially tested it on, so make sure you have the most current patch level.

Make the Most of Views

Here are some suggestions to help you optimize your view usage:

Create queries (to use on Web templates) with many free characteristics.

Create (in advance) a few global query views for your queries, as defined by user requirements.

Create information cockpits (Web templates with queries, graphs, charts, or links surrounding a subject area — e.g., FI AP cockpit). Make sure you deploy one or more view selection Web items on these templates to increase flexibility. Enable the user-created view option.

Take on the politically difficult task of reducing the number of query authors.

I’m sure you will find the new query view Web item a welcome feature in BW 3.5. It should make your life easier.

Quick Tip A New Way to Change Queries in SAP NetWeaver BI 7.0 BEx Analyzer  

by Muke Abdelnaby, Principal, Renaissance Partner Group, Inc.

Find out about the new Local Query Properties screen available in the SAP NetWeaver BI 7.0 version of BEx Analyzer. This new screen replaces the functionality previously offered with the Local View button and provides a simple interface for editing queries.

Categories: BEx

The BEx Analyzer Suite in SAP NetWeaver BI 7.0 includes some major changes for users who are accustomed to SAP BW 3.x. A key change is the way users can alter the output layout of a BEx Analyzer workbook. In SAP BW 3.x, you change the layout by selecting the Local View button option from the BEx toolbar. This button provides the user with a Change Query screen that has three sections: Columns, Rows, and Free Characteristics. To change the query layout, you needed to drag and drop each element from one section to another.

However, the Local View button is no longer available in SAP NetWeaver BI 7.0. Let me introduce you to the new features you can use to alter queries. In the redesigned BEx Analyzer, you now use new Local Query Properties dialog screen to change the query layout.

To access the new screen, right-click within a BEx Analyzer report and select Query Properties from the context

menu. The system displays a new screen called the Local Query Properties (Figure 1). This new screen makes it easier to alter the query layout because you can edit your query in one place rather than in several locations, as you had to do in SAP BW 3.x.

Figure 1 The new Local Query Properties screen

In the Local Query Properties screen, you have several query editing tabs available: Navigation state, Data Formatting, Presentation Options, Display Options, Currency Conversion, Zero Suppression, Properties, and Conditions. The Navigation state tab contains new query layout options, so let me introduce you to the new functionality available.

Change the Navigation State

You edit the query layout in the Navigation state tab. Although you could change the query layout in SAP BW 3.x, you had to move each characteristic or key figure individually. This made the simple alteration of a layout a little cumbersome and time consuming. In the new Navigation state tab, you can now quickly drag and drop multiple characters or key figures at once. You can also use the new up and down arrow icons to maneuver the location of the characteristics or key figures.

Edit Characteristic or Key Figure Properties

Also in SAP NetWeaver BI 7.0, you can now edit characteristics or key figures by selecting the element, right-clicking, and selecting Properties from the context menu. The system displays a new screen called the Properties for screen

(Figure 2). In this screen you can edit the characteristics or key figures all in one area by using the General,

Attributes, and Hierarchy tabs.

Figure 2 The new Properties for screen

In the General tab, you can edit and modify how the query displays and sorts the characteristics. For example, in this tab you can easily change the following:

The order and placement of the columns and rows

The text length (short, medium, or long)

The direction of the sort (ascending or descending)

In addition, the General tab features a new functionality called Result Acess, as shown in Figure 2. This setting allows you to limit the display of query results.

In the Attributes tab, select the attributes for the characteristics. If the characteristics contain a hierarchy, the Hierarchy tab appears to allow you to select a hierarchy itself or nodes from the hierarchy.

Quick Tip Effortlessly Toggle Between BW 3.X and SAP NetWeaver BI 7.0 BEx Analyzer  

by Anurag Barua, Independent Consultant

Support Package 10 for SAP NetWeaver BI 7.0 offers a simple way to switch between using the BW 3.x version of BEx Analyzer and the updated features in SAP NetWeaver BI 7.0’s version. This method does not require any custom programming and instead relies on IMG configuration.

Categories: BEx

Recently, I’ve encountered clients who use the SAPGUI and who want to be able to switch between the BW 3.x and SAP NetWeaver BI 7.0 versions of BEx Analyzer. I find that users typically have one of several reasons, both explicit and perceived, to revert to the BW 3.x version.

The new version’s look-and-feel (including the two new modes: design and analysis) is somewhat different than its predecessor’s, which presents a learning curve. In addition, SAP has added functionality, such as new design items. Users who have invested time and effort into building competencies around the BW 3.x version do not want to be distracted with new features they may not need immediately. Under such circumstances they consider it prudent to toggle to the older version instead of trying to pick BW 3.x features inside SAP NetWeaver BI 7.0.

Bryan Koetting’s article, “Custom Program Grants Users Easy Access to Both BEx Analyzer 3.x and SAP NetWeaver 2004s” (Volume 4, Number 10 at www.bi-expertonline.com), shows you how to switch between versions using a custom ABAP program. Prior to Support Package 10 of SAP NetWeaver 7.0, no configuration option existed to set the version of BEx Analyzer that the system should launch when you run transaction RRMX.

Now you can simply configure this in the IMG. I will show you this configuration activity and walk you through the other available options for setting a version. I’ll also tell you about a couple of important SAP Notes you should refer to before you implement this configuration.

Configure the Version in the IMG

Follow IMG menu path SAP Customizing Implementation Guide>SAP Net-Weaver>Business Intelligence>Settings for Reporting and Analysis>General Settings for Reporting and Analysis>Set BEx Analyzer Version. In Figure 1 you can see three version options available. If you select the first option, the system decides which BEx Analyzer version to invoke just prior to the execution of your query workbook. Selecting either the

second or the third option means that the system invokes the selected version upon running transaction RRMX for all users. It disregards in which version you designed your query/workbook originally and opens it in the specified version. Which setting you opt for is a combination of factors such as necessity, convenience, and organizational policy. As well, you have the ability to override the setting in the IMG by using other mechanisms, which I will discuss next.

Figure 1 Set the BEx Analyzer version

Adjust the IMG Settings

You can change the settings in the IMG in two ways. You can either change the global settings in BEx Analyzer or set a parameter ID in the data maintenance for the version you want to use.

Global Settings in BEx Analyzer

The first option is to change the global settings for the BEx Analyzer version. However, exercise caution before you follow this approach and make sure you understand its implications. A change in the global settings applies to all users of the computer and is permanent from the standpoint of any configuration activity in SAP. Also, if your IMG entry is set to launch BW 3.x, you do not get a similar global settings option in the BW 3.x BEx Analyzer to switch to the SAP NetWeaver BI 7.0 version.

Let’s assume that you set your BEx Analyzer version to Always SAP NetWeaver version of BEx Analyzer in the IMG (Figure 1). Then you run transaction RRMX and want to set the version back to BW 3.x. Navigate to BEx Analyzer>Global Settings, which takes you to the screen shown in Figure 2. Select the check box Launch SAPBW

3.x version of BEx Analyzer from SAP GUI (RRMX) and click on the OK button. Going forward, the system now only invokes the BW 3.x version of BEx Analyzer.

Figure 2 Revert back to the BW 3.x version of BEx Analyzer

Parameter ID in User Data Maintenance

Instead of changing the global settings, you can set a parameter ID to the desired version value in your user data maintenance. When saved, this setting takes precedence over the setting in the IMG for your user. (This information is mentioned briefly in the configuration entry screen in Figure 1). To do this navigate to System>User Profile>Own Data from any SAP screen.

Click on the Parameters tab in the Own Data screen and enter RRMX_VERSION as the parameter name (Figure 3). In the corresponding Parameter value field, you can enter a space (depending on the version called for in

workbook), 3X (always call BW 3.x version), or 70 (always call SAP NetWeaver BI 7.0 version). The three values correspond to the three options in the IMG configuration activity as shown in Figure 1.

Figure 3 Set a Parameter ID for the BEx Analyzer version

Setting the parameter ID makes sense only if you want to invoke a version that is different from the global IMG setting. For example, while it may be a policy (and thus a global setting) in your organization for all users to run the BW 3.x BEx Analyzer version, you may have a reason to always run the SAP NetWeaver BI 7.0 version. In this case, you would set the parameter ID to 70.

Helpful SAP Notes

SAP Note 970002 (“Which BEx Analyzer version is called by RRMX?”) contains information relevant to toggling the BEx Analyzer versions. Specifically, it talks about the options prior to this new functionality and prerequisites around BI/BW front-end patches. Make sure you read this note and ensure that the prerequisites (such as the version of the SAPBEXC.xla file) are in place to take advantage of this new feature. For example, the setting of the parameter ID RRMX_VERSION is possible only from Support Package 12 onward.

You may also want to consult SAP Note 1086904 (“BW 7.0 BEx: Transactions RRMX/RRMXP”) because it relates to the correction of a bug you encounter when you set the BEx Analyzer version to 3.x in the global settings (refer to Figure 2).

Note

For more information about this topic, consider attending SAP Education class BW305: Enterprise Reporting, Query and Analysis (Part I) for SAP NetWeaver BI 7.0.

Quick Tip Leverage BEx Analyzer Formatting and Presentation Capabilities in SAP BI 7.0  

by Penny Silvia, Director of Business Intelligence, MyITgroup

Find out about some of the new design options you have in SAP NetWeaver BI 7.0.

Categories: BEx, Reporting

SAP NetWeaver BI 7.0 offers users a variety of new — or greatly improved — features for managing the presentation of your reports and output from within the BI toolset. Perhaps the most improved tool in this area is BEx Analyzer and its new capabilities for creating formatted workbooks and reports. By taking a quick tour of these advances you can begin to gauge how to use these capabilities within your SAP NetWeaver BI system, what may still persist as a challenge, and what the future will hold for formatted reporting within the SAP NetWeaver BI landscape.

Previous versions of BEx Analyzer presented users with many challenges when it came time to create the final “report” — the physical piece of paper. Many users resorted to Visual Basic programming, macros, or the use of Excel look-up functions to create formatted, high-quality outputs. This resulted in very large workbooks (with dozens or more of hidden pages) that were too large to email or with workbooks that had so much code to manage the presentation that there was no longer any interactivity with the report for analysis.

Note

For more information about how to access and use these new features, refer to Ned Falk’s formatting series: “Everything You Need to Know About Formatting — Part I: BEx Analyzer and BEx Query Designer,” “SAP NetWeaver BI 7.0: Discover New BEx Themes and Excel Formatting Options,” and “SAP NetWeaver BI 7.0: Unlock a World of Formatting with Themes in BEx Web.” You find these articles in the BW/BI Expert knowledgebase at www.BW- BIexpertOnline.com.

Columns

With SAP NetWeaver BI 7.0 you can now leverage many of the traditional Excel capabilities for creating the presentation view of your workbooks. This allows you to do such things as inserting columns. You can use this new column either to manage the layout and presentation (by creating a break in your report) or you can insert a “local formula” in that column (where previously you might have used an Excel formula). These new local formulas within your workbook are linked to the logic of your BI query and update the results when you slice, dice, and navigate around your report. This capability dramatically reduces the amount of programming logic that you would have had to build into your workbooks previously and gives you the look that you want for your reports.

Cut, Paste, and Update

Another improvement in the BEx Analyzer Excel functionality is the ability to cut, paste and update result areas, creating an entirely new perspective for your report. Working with this new capability takes a little practice — and the trick is that you must convert to formulas before you can execute this function. By converting to formulas you can cut, copy, and paste sections of your output to new areas of your workbook. After you have created your layout, you can update the filter or restrictions sets of areas by simply typing over the old value.

For example, you can create a workbook that shows 2007 revenue, convert the result areas to formulas via the command in the drop-down menu, copy and paste the entire 2007 result area to another block (or another page), and type 2008 over 2007. The new 2008 block immediately updates with the 2008 numbers and the 2007 block stays as it was. The only drawback to this capability is that once you convert to formulas you no longer have the SAP NetWeaver BI OLAP (slice and dice) functions available. Also, once you convert to formulas you cannot change them back, so plan accordingly.

Design (Layout) View

A totally new aspect of the SAP NetWeaver BI 7.0 BEx Analyzer is the design or layout view. With the addition of a new tool bar to the BEx Analyzer menu, users can now go into a design view of the workbook and insert tables, graphs, radio buttons, drop-down boxes, and conditions/exceptions at whatever place makes the most sense for this particular report. Working within the design view looks and feels very much like working with the SAP NetWeaver BI Web Application Designer (Web AD), so you will find this an easily transferred skill with little training required. This new capability enables you to create a workbook that offers the capabilities that you need — in the design that you want.

Overall, these improvements to BEx Analyzer in SAP NetWeaver BI 7.0 represent huge advances to the capabilities of managing and presenting your workbooks and reports and should eliminate the need for a large portion of the coding and workbook maintenance that was previously required. You may still find that your requirements need more advanced solutions, however, and you can investigate leveraging the new Report Designer which delivers more pixel-level formatting but creates fixed Web-based output only (no OLAP). Beyond that you can also look at the toolsets and capabilities that are part of the new Business Intelligence Platform from SAP and Business Objects, which is due for integration later this year. In short, you have many options and the biggest challenge may be in deciding which one to use for which requirement.

 

Quick Tip MultiProvider Hints Optimize OLAP Processor Speed in BEx Queries  

by Duncan Foster, Information Strategy Consultant, CSC EMEA Northern Region

Storing many records in data targets can often become unwieldy or cause performance problems. Logical partitioning is a method for avoiding these difficulties. SAP recently introduced the little-known MultiProvider hints to improve the performance and usability of logical partitioning. Find out how to apply this functionality.

Categories: BEx, Performance

Logical partitioning is a commonly used technique to improve the manageability of data targets in SAP NetWeaver BI. The partitioning can be either homogenous or heterogeneous. In this article, I will assume you are familiar with the concept of logical partitioning.

Homogenous partitioning involves identical InfoProviders (normally InfoCubes) that hold different data slices. The most common example of this is two identical InfoCubes — one for data in this year and one for data in the previous year. You can find an example of homogenous partitioning by going to http://help.sap.com/saphelp_nw2004s/helpdata/en/43/5563cdf8a75f6be10000000a1553f6/frameset.htm.

Heterogeneous partitioning involves different InfoProviders with different structures. An example of this is actual data held using one set of characteristics and plan data held using a slightly different set of characteristics.

However, when you develop BEx queries based on MultiProviders with logically partitioned data targets, the Online Analytical Processing (OLAP) processor struggles with the task of optimizing the queries. To address this, SAP has introduced MultiProvider hints.

MultiProvider hints allow an SAP NetWeaver BI developer to provide information about how a MultiProvider is logically partitioned. With MultiProvider hints, you prevent the OLAP processor from wasting time looking for data that does not exist. The hints speed up BEx query execution by eliminating redundant InfoCubes, thereby allowing the OLAP processor to assess only the relevant query paths.

First, I’ll cover the special characteristic 0INFOPROV. This was previously the only way of steering the OLAP processor towards accessing information from the correct InfoProviders within a MultiProvider. Then I’ll show you how you can work with your developer to implement the MultiProvider hints. For SAP BW 3.5, you must be on Support Package 16 or later. For SAP NetWeaver BI 7.0, you must be on Support Package 05 or later. SAP Note 911939 provides additional information about the prerequisites for using MultiProvider hints.

Using 0INFOPROV

Let’s consider a MultiProvider (technical ID MYMULPROV). I logically partitioned it into three InfoCubes — current year actual, last year actual, and plan for all years (Figure 1). In a BEx query on this MultiProvider, you can use the special characteristic 0INFOPROV to restrict data to any combination of underlying InfoCubes. This characteristic 0INFOPROV is available in all BEx queries based on MultiProviders that are formed from more than one

InfoProvider. 0INFOPROV holds the technical name of the underlying InfoProvider delivering the records. SAP NetWeaver BI populates this characteristic at runtime.

Figure 1 Logical partitioning example

The query developer can use 0INFOPROV to restrict the data in a BEx query. The developer can use 0INFOPROV as a global filter to restrict all data to a limited number of InfoProviders. Alternatively, the developer can use 0INFOPROV in restricted key figures or selections so that these measures restrict their data to certain InfoProviders. Indeed, I have seen some developers create a user exit variable to specifically determine which InfoProvider restrictions to apply to the BEx query, based on other selections.

However, using 0INFOPROV for logical partitioning is not desirable for three reasons. First, it unnecessarily exposes the nuances of the data model at the BEx query level. Second, it adds to the configuration complexity of the BEx query and introduces the opportunity for error. Third, it increases the difficulty required to create BEx queries, which can be daunting to the BEx query developer — often power users, not technical specialists.

MultiProvider Hints

Instead of using 0INFOPROV, you can use MultiProvider hints. SAP has introduced this functionality as a more elegant way to address the issues with using 0INFOPROV. Essentially, MultiProvider hints provide a mechanism for the OLAP processor to determine quickly which InfoProviders the system should process within a MultiProvider that is subject to logical partitioning. You’ll need the help of a developer to configure it. Figure 2 shows the Data

Dictionary table RRKMULTIPROVHINT that the developer needs to populate.

Figure 2 MultiProvider hint table

The developer adds information for the following fields in Figure 2:

MULTIPROV: The technical name of the MultiProvider for which you want to provide a hint to the OLAP processor

CHANM: The technical name of the characteristic used to partition the MultiProvider (e.g., 0CALYEAR)

POSIT: The sequence with which the OLAP processor evaluates the characteristics (e.g., 1 for 0FISCVARNT and 2 for 0FISCYEAR)

Unfortunately, no transaction is available for maintaining the entries in this table. Therefore, the developer needs to input these manually.

After the developer adds these entries to the RRKMULTIPROVHINT table, the OLAP processor reads the table to determine the execution path for retrieving information from MultiProviders. In my example, the developer enters the data as shown in Table 1. Note that the POSIT field is very important because it influences the sequence of

characteristics that the OLAP processor uses. In my example, I use 0ACTPLN first because this determines whether the actual or plan InfoProviders are assessed further

MULTIPROV

CHANM POSIT

MYMULPROV 0ACTPLN 1

MYMULPROV 0FISCYEAR 3

MYMULPROV 0FISCVARNT 2

Table 1 MultiProvider hint table entries for the example

Theses entries ensure that the OLAP processor first uses the actual/plan indicator in its SQL command to find data. For a BEx query, which has a restriction on actual data only, this means that the OLAP processor spends very little

time looking for data in the plan data InfoCube. The OLAP processor next uses the fiscal year variant and fiscal year characteristics to look for data in the other InfoCubes that actually contain data.

Quick Tip

3 Frequently Asked Questions About BEx Analyzer  

by Anurag Barua, Manager, SAP Application Support, The Washington Post

Discover some common problems in BEx Analyzer and how to correct them.

Categories: BEx

In several years of working with BEx Analyzer, I often encounter the same few questions. I have compiled a list of three such questions and provided answers and solutions to each. These questions are not specific to any particular release, but they are more relevant to the BW 3.x track including BW Release 3.5. In an upcoming article, I’ll explain how to tackle more BEx Analyzer problems.

1. When I click on the InfoAreas tab in the Select Query window of BEx Analyzer, not all InfoProviders show up. Many query designers and super users assume this problem is a bug. I consider this one of the most common misconceptions about BEx. In fact, this is not a bug, but an outcome of the slightly hard to follow design. When you click on the InfoAreas tab on the left side of the screen (Figure 1), you see only those InfoAreas that have at least one InfoProvider with a built-in query. In other words, if you have not defined a query on an InfoProvider, this

InfoProvider does not show up on the InfoAreas tab.

Figure 1 Select queries in BEx Query Designer

When I click on the InfoAreas tab, the screen displays only a few InfoAreas. For example, when I expand the Financials Management & Controlling (0FMCO) InfoArea, (0FMCO>0FI>0FIAR), you can see that the screen lists both the ODS object (0FIAR_O03) and the InfoCube (0FIAR_C03). This result appears because you have activated one or more standard business content queries built on these InfoProviders, or you have designed at least one query on these InfoProviders.

To see all currently active InfoAreas and InfoProviders in your BW system, click on the create icon and then click on

the InfoAreas tab (Figure 2).

Figure 2 Create a new query in BEx Query Designer and then click on the InfoAreas tab to see all currently active InfoAreas and InfoProviders

2. When I run certain queries in BEx Analyzer, they take too long and time out. Long query runtimes (in the database, online analytical processing [OLAP] system, or front end) can stem from many places. Your Basis team may be able to help by tweaking the profile parameters to increase the timeout threshold. Refer to SAP note 557870 to learn more about BW query performance.

Let me share some of the common reasons I’ve found for long query runtimes:

Errors in data modeling could cause BW to generate extremely time-consuming SQL queries. In particular, you need to pay extra attention to your dimension tables.

If your report is running from an InfoCube, perhaps it is not sufficiently aggregated. This means you have to build aggregates on your InfoCube.

Check if your query is running against a RemoteCube. You should avoid this because such a query travels across the network to access information that is available in a different system, causing poor performance.

Your query may contain exceptions and conditions. Keep these to a minimum because they cause an additional overhead on the database and application servers and slow down the query.

Filter your query to ensure that you extract only the necessary data from the database.

If you are running the same query over and over again, you really do not need to fetch these results from the database. A data warehouse like BW should contain data that is relatively static over a period of time. This means that you should store your results in workbooks and refresh a workbook each time you need to run this query.

Your query results may contain too many or too complex hierarchies, thereby causing a significant delay. If you have a choice between hierarchies and navigational characteristics, you should choose the latter.

Use structures carefully as they relate to hierarchies. Some query designers tend to simulate hierarchies using structures when no such hierarchy exists in the online transaction processing (OLTP) or BW system. You may notice this when some characteristics are pulled into rows and columns and the Display as Hierarchies option is on. This technique could cause performance degradation. Instead of trying to simulate hierarchies, I advise you to maintain hierarchies in the OLTP or BW system and use them if required.

Your query may overuse structures and cells. While structures bring several benefits, too many structures with too many components organized in a hierarchical manner and too many filters or formulas can negatively affect performance. Also, if you use cells (and create filters or formulas), you need to remember that an independent query runs in the background for each cell, which could drag performance.

You may not have selected the read mode that best suits the needs of your query. You can do so in transaction RSRT. There are three read modes: A for read all data at once, X for read data during navigation, and H for read when you navigate or expand hierarchies. If you have several navigation steps and would like to drill down, I recommend that you use X mode to ensure that you only fetch the required data. Use A mode for queries that truly require all the data for any further analysis. Use H mode when your data contains large and complex hierarchies to prevent BW from displaying data in collapsed nodes.

3. Query results need to display millions of records, but Excel has a limit of about 65,000 records. This is a question that several query designers and end users have asked me, especially those who are new to SAP BW. Before I talk about the alternatives, I would like to focus on the need to display millions of records. As a query designer or end user, you may not have too much say in your data warehouse’s design, so my advice is intended for data modelers. If your primary purpose in BW is to analyze, do you really need millions of records to analyze meaningfully? You might want to take a look at the design of your data targets and think of ways to reduce the volume without losing the level of granularity you want. Compression and aggregation are two possible options.

If you cannot limit the result set to less than 65,536 records (the limit of most versions of Excel), Web reporting is the easiest and most convenient workaround. Two other options are also quite popular, although you may incur additional licensing costs:

In BW Release 2.1C Support Package 8 or higher, use either transaction RSCRM_BAPI or RSCRM_REPORT and send the output of the query to a flat file or a table. These transactions do not support all queries.

In BW Release 3.0A Support Package 7 or higher, use the OpenHub tool. Using an InfoSpoke, you can dump your results into a table or a flat file.

Quick Tip

4 Hints to Make BEx Analyzer Run Smoothly  

by Anurag Barua, Manager, SAP Application Support, The Washington Post

Query results in BEx Analyzer often display only a subset of an InfoObject's master data. Explore how to make your query display all of your master data. Also find out what to do when BEx Analyzer fails to display actual data, and learn how to insert a page break into query results. Several issues could prevent your BEx Analyzer data queries from successfully returning applicable data. Learn how to solve all of these problems.

Categories: BEx, Master Data, Reporting

Often, when users run an analytical query off an InfoCube, an operational data store (ODS) object, or a MultiProvider in BEx Analyzer, they want to report exclusively on the master data in one particular InfoObject (let's call it X). However, when users run the query on X, the system displays only a subset of X’s master data.

This is not an error. The master data your search displays relates to the transaction data in your InfoProviders. For example, if you report off one of your sales InfoCubes (0SD_C03 for example) and you want a list of all the materials your enterprise could potentially sell, you still see only master data pertinent to those materials that already have been sold.

Two ways exist to remedy this situation: reporting directly off the InfoObject or reporting off your original query. To report directly off the InfoObject, you have to alter settings in the Master data/texts tab of InfoObject Maintenance. Go to Transaction RSD1 and enter the name of an InfoObject. Click on the Display button to check the setting or the Maintain button to change these settings. "Next, click on the Master data/texts tab. To turn on the check box Characteristic is Data Target/InfoProvider, type the name of the InfoArea into the text box next to the check box for which this InfoObject acts as an InfoProvider. This makes it possible to run a query off the InfoObject directly. However, this approach requires additional work beyond just checking this box and specifying an InfoArea. BW developers have to create update rules for your InfoObject so you can load attributes and texts.

A less complicated option enables you to use your original query (based on your InfoCube, ODS object, or a combination of the two). If you choose this simple approach, the system displays all the master data relevant to the characteristic InfoObject in the original query without forcing you to create and run a new query exclusively off the InfoObject. In the Business Explorer tab of the InfoObject Maintenance screen, change the default value of the

Query Execution Filter Val. Selectn field (Figure 1) from the current option to Values in Master Data Table. This ensures that the system displays all master data regardless of the limitations your transaction data imposes on your master data.

Note

This option works in conjunction with the variables maintenance functionality in BEx . It affects the display of values when using F4 on the variable in the query selection screen, and not the query results themselves. If you select the option mentioned in the preceding paragraph, all the values in the master data table of that characteristic are available for selection regardless of whether they have corresponding transactional data.

Figure 1 Change the default value in the Query Execution Filter Val. Selectn field

Note

SAP now refers to ODS objects as DataStore objects. Because I wrote this article based on BW 3.5, I use the term ODS object.

Troubleshoot Problems in BEx Analyzer’s Data Display

BEx Analyzer users often gripe that certain cells displayed after the user runs a query contain the pound symbol (#) instead of actual values. BW displays # when it has not assigned a value to a characteristic. You may encounter this situation when you run queries on an InfoCube, ODS object, InfoObject (such as an InfoProvider), or a MultiProvider. The system displays # or another character or string as a default. You must understand why BW does not assign a value before I explain how to correct this.

Assume that your InfoProvider is an InfoCube. Characteristics are found in dimension tables, and key figures are found in fact tables. One or more dimensional characteristics may not have a value. This could be because transaction data you extract from the source system may not have a value for this characteristic (within the source system). Alternatively, your transformation (transfer/update/start routines) rules might not move any values to this characteristic. This also could be because you have had to add a new characteristic to a dimension after loading data. If you report on this InfoCube without making arrangements for populating this new characteristic, then this characteristic has no value.

Sometimes, the problem is not with the characteristic itself but with its attributes. An attribute may not have a value because the corresponding master data does not exist. For example, material is a dimensional characteristic and material group is one of its attributes. BW did not load a new material group (master data) ABC to which material XYZ belongs. This means that the material group for material ABC is still undefined when you report. The most proactive solution is loading master data of attributes frequently and before master data for characteristics.

Now that you know the cause, I’ll discuss the remedies. Your first impulse may be to filter or restrict the undefined symbol in the query itself. However, you should not filter this symbol directly because you may prevent the system from displaying valuable information.

Another remedy is to replace # with spaces or a meaningful description. To do this, attach your code directly to a query using a Visual Basic for Applications (VBA) macro. You can use this feature only with Excel workbooks. Run your query and follow menu path Tools>Macro>Visual Basic Editor (Figure 2). You then see the screen in Figure

3.

Figure 2 Create a VBA macro in an Excel workbook

Figure 3 VBA in macro SAPBEXonRefresh

Include the code in Figure 4 in VBA to replace every occurrence of # with the string Unknown. If you have not used Visual Basic or VBA before, talk to someone who has before you perform this step. Remember to save your query as a workbook to ensure the system invokes your VBA code and replaces your numbers when the workbook refreshes.

Dim x as rangeFor Each x In resultArea

If x.Value = "#" Thenx.Value = "Unknown"

End IfNext X

Figure 4 Code to replace every occurrence of # with the string Unknown

Increase Readability with Page Breaks

Users of BEx Analyzer often ask if they can insert a page break into query results after BEx displays a certain number of rows. Such a page break can increase readability of the results and fulfill requirements requested by various users.

No function in BEx Query Designer allows you to insert a page break. However, by using a VBA macro embedded in workbooks (SAPBEXonRefresh, which I described in Figure 3) you can insert the relevant code that causes the query results to break each time you reach the predefined limit set in the VBA macro. If you want to use this option, ask a technical resource with VBA macro skills for help.

Note

You can use the HPageBreak Object in VBA to insert horizontal page breaks in an Excel worksheet. You also can insert vertical page breaks. In that case, you might want to use the VPageBreak Object.

Troubleshoot Unsuccessful Data Queries in BEx Analyzer

BEx queries analyze data in InfoProviders. However, when you run a query in BEx Analyzer, sometimes it returns the message, “No Applicable Data Found,” even though you are confident it should return some data.

I have heard and seen this problem more times than I care to remember. Usually, the query does not return any data for one of the following reasons:

The InfoProvider from which you are reporting may be empty because you have not loaded any data to one or more of the data targets

The query may not have any data to return because there aren’t any records that match your selection criteria

Sometimes, even after you have loaded data to your InfoCube or ODS object, it may not be available for reporting. If you are using InfoCubes, you can ensure that the data is available. Place your cursor on the InfoCube and from the context menu click on the Manage button. The system then takes you to the screen shown in Figure 5. The

highlighted icon in the Request for Reporting Available column indicates that records in this request are ready for processing.

Figure 5 Requests tab of Manage Data Targets screen for InfoCube 0FIGL_C01

The Request for Reporting Available column must display this icon before a query can return any data. If the column does not display this icon, the system returns no data when you run a query on this InfoCube even though data may exist. When both the QM Status of Request after Update and Technical Status columns display green traffic lights, you can expect the Request for Reporting Available column to show this icon. If any of these columns displays a red light, however, that means there are errors in the field and the query is not available for reporting until those errors are fixed.

If you are using an ODS object when you load data, the system populates the new data/activation queue table. If you do not activate this loaded data, the system does not push it into the active data table and the log tables do not change. The technical name for a standard SAP-delivered business content ODS active data table follows the format /BI0/A[ODS_Name]00. In the case of the ODS object shown in Figure 6, the technical name of the active data table is /BI0/A0FIGL_O0600. Keep in mind that you can check the contents of this table (and the others) in the Manage Data Targets screen. Click on the Contents tab and the Active Data button (Figure 6). Since BW reports based on what is available in the active data table, this step is a prerequisite for data to be available for reporting. Also, as soon as the system activates the data in the ODS object, the system empties the new data/activation queue table. Additionally, if you intend to run queries directly off an ODS object, you must check the BEx Reporting option in the settings of the ODS object maintenance screen. To get to this screen, follow the menu path Administrator Workbench (RSA1)>Modeling>InfoProvider and highlight the desired ODS object. Click on the Settings tab and

check the BEx Reporting flag.

Figure 6 Manage Data Targets screen of ODS object 0FIGL_O06

In the Contents tab, make sure that data is available in the active data table for queries to return results by clicking on the Active Data button in Figure 6.

You can check the contents of the new data/activation table, the active data table, or the log table by clicking on the appropriate button, as shown in Figure 6. However, the spreadsheet icon in the Request is available for reporting column must show up in the relevant column for the ODS object, just as it would in an InfoCube column.

Sometimes when you report off an InfoCube, you actually report off an aggregate (a highly summarized view of data in an InfoCube) built on top of your InfoCube. The aggregate InfoCube does not contain data available for reporting unless BW loaded the new data packages in the InfoCube into the aggregate. This process of loading the data packages into your aggregates is called a rollup. Rollup activity is usually part of a process chain that your BW technical support staff creates and maintains. If you believe nobody performed this activity, you need to inform your BW technical support/ maintenance organization. You can perform one-time aggregate rollup by executing the ABAP report RSDDK_AGGREGATES_ROLLUP.

Sometimes, even though you have loaded data to the relevant targets and even though the data is available for reporting, your query may not return any records. When this happens, you may have specified values in your selection criteria that do not have any corresponding records or you may have set filters in your query that

unintentionally interfere with your query. Let’s say you have set a filter in BEx Query Designer on your company code to exclude company code 1000 and include all relevant records that were posted on or before fiscal year (FI) 2004. You may not realize that no documents have been posted for the FI 2004 or earlier with company codes other than 1000. This sort of filter prevents the display of query results because unbeknown to you, no data passes through this filter.

Quick Tip Add Pop-Up Messages to BEx Queries for Simple Validation and Feedback  

by Deepak Iyer and Ritesh Jogani, Patni Computer Systems, India

Use pop-up messages to provide validation feedback about a query directly within the query.

Categories: BEx, Reporting

With pop-up message screens, users can receive immediate feedback about the selection screen entries for the queries without having to run them separately in the BEx Query Monitor. Pop-up messages can include warning (W) and error (E) messages as well as success (S) and information (I) messages.

For example, say you have a report that lists all the open (unfilled) orders in your system and you would like the users to be able to look up open orders only from the current year (e.g., 2005). You could set a pop-up warning message to appear whenever users attempt to look up open orders for dates outside of the current year.

Pop-up messages require a one-time only, two-part setup. In this tip, we will show you how to set up a dummy variable CALMONTH to validate the user date entry in the open orders query. Then we will explain how to edit the code for CALMONTH in include ZXRSRU01 to create a pop-up warning message when users enter incorrect dates for open order queries. This functionality is available for BEx queries and workbooks (but not for Web templates) and is available in all releases of SAP BW.

Set Up the Dummy Variable CALMONTH

Start by creating a BEx query open orders with the time characteristic 0CALMONTH restricted by calendar year/month. Because we use CALMONTH only to validate the user date entries, you need to hide this dummy variable.

Step 1. Go to the BEx Query Designer. In the box on the left side, go to Dimensions>Time>Calendar Year/Month/Characteristic Variable/CALMONTH. Right-click on CALMONTH and select Edit from the pop-up

menu. In the SAP BW Variables Editor screen shown in Figure 1, make sure the Ready for Input option remains unchecked.

Figure 1 Hide the CALMONTH dummy variable

Step 2. In the BEx Query Designer, select the key figure Open orders. In Figure 2, restrict this key figure by

dragging the dummy variable CALMONTH from the left side of the screen to the right side of the screen.

Figure 2 Restrict the key figure 0D_OORVALSC by CALMONTH

Step 3. Hide CALMONTH. Select Always Hide from the Hide drop-down menu in the Properties of the Selection/Formula screen shown in Figure 3. You can access this screen by double-clicking on the key figure Open

orders.

Figure 3 Select Always Hide to conceal CALMONTH

Edit the Code for CALMONTH

Once you have edited the key figure, you can edit the code for CALMONTH to validate the user date entries (Figure

4). Access the code via transaction SE38; the code is written in include ZXRSRU01.

Figure 4 Variable CALMONTH in include ZXRSRU01

Note

Whenever you execute a BEx query, it executes the include ZXRSRU01 to perform the validation of user entries. This include is contained in function module EXIT_SAPLRRS0_001, a component of standard SAP Enhancement RSR00001 (BW: enhancements for global variables in reporting) in BEx.

As indicated by i_step = 2, the piece of code starting with the third line is executed for the variable CALMONTH only after the user enters the value in the selection screen for the dummy variable. The system then reads the value entered by the user in the selection screen and validates the value by comparing the current year and the year of the entered value. If it doesn’t match, then the system calls the three functions RRMS_MESSAGE_HANDLING, RRMS_MESSAGES_SHOW, and RRMS_MESSAGES_DELETE mentioned in the CALL FUNCTION lines to produce the pop-up message.

You can specify the type of message in the i_type line of code. In our example, we created a warning message type, indicated by the W.

Validate User Entry with a Pop-Up Message

Now we’ll show you how the validation pop-up message works.

Step 1. Save the query. Click on the white and green check mark icon in the BEx Query Designer screen.

Note

If you want to terminate the processing of the query after the pop-up message appears, you must include the statement RAISE again. in the code in Figure 4. This stops the processing of the query so you can return to the selection screen and enter a valid month and year.

Step 2. Add a technical name and description. Enter a technical name (ZPOPUP_Q01) and description (Query With Pop-Up Message) for the query in the appropriate fields. Click on the enter icon to execute the query.

Step 3. Run the query. In the selection screen that appears after executing the query (Figure 5), enter 01.2004 for

Calendar Month/Year and click on the execute icon.

Figure 5 Enter 01.2004 for the Calendar Month/Year

After clicking on the execute icon in Figure 5, the pop-up message shown in Figure 6 appears. Click on the green check mark icon shown in Figure 6 to further execute the query.

Figure 6 The yellow triangle icon indicates a warning message

Quick TipCopy Queries Between InfoProviders Painlessly  

by Joerg Boeke, syskoplan AG

Learn how to copy a query to a new InfoProvider even when the characteristics differ. This workaround, which uses the debug mode, saves time because you don't have to spend hours recreating a query you want to reuse.

Categories: BEx, Data Management

Perhaps, like me, you have spent countless hours successfully creating great queries that contain complex structures for a particular InfoProvider. Then, down the road, you find you need this exact query again for another InfoProvider, but the new InfoProvider has a single characteristic that differs from the one that was the object of your original query. Using SAP transaction RSZC (copying queries between InfoCubes), query definitions can be copied only for use on InfoProviders with the same characteristics. If the key bfigures and characteristics of the new InfoProvider do not match the original 100 percent, this standard method fails.

So close and yet so far, right? I’ll show you a way, however, to copy the query definition from one InfoProvider to another, regardless of the characteristics of the new target. This method works with both BW 2.x and 3.x installations.

You must bypass SAP’s BW original functionality in function RSZ_I_COPY_QRY_TO_CUBE by overruling SAP’s compliancy check in BW, which is a standard BW functionality. In this original SAP function, the receiver InfoProvider is checked to verify that all of the key figures and characteristics of the query to be copied are available in its design. It probes each tiny element of the query to make sure it is available in the target InfoProvider.

Characteristics, navigation attributes, and hierarchies that do not occur in the new InfoCube are then deleted from the query definition and SAP’s function tells you by help of dialog that the target InfoProvider is not compliant to your query.

This is a great check for BW beginners, but I like to use a workaround for SAP’s compliancy check of this function. The workaround uses the debug mode and calls for manually changing parameters in the debug mode. It should be reserved for experienced users because of the risk of manipulating a value that might have an output you cannot foresee. The workaround should be used when the regular transaction RSZC will not allow you to copy a query. I

recommend using transaction RSZC for your regular work.

Note

You have an alternative to the debug mode I describe in this article. You also could copy the complete function RSZ_I_COPY_QRY_TO_CUBE of SAP BW with transaction SE37. You then create a new customer function such as ZRSZ_I_COPY_QRY_TO_CUBE by hard coding the compliance check. Then you could pass this new function to beginners.

Though this method works extraordinarily well and has saved me many hours, be advised that it might be necessary to manually correct the query afterwards. This correction is automatically initiated when you open the query by help of Query Designer either via Windows>Start>All Programs>Business Explorer>Query Designer or via the Microsoft Excel BEx Analyzer. The system finds items missing in the query and deletes those characteristics or key figures from your target query design. The structures of rows and columns and free characteristics filters, etc., stay intact but you might want to swap key figures in your structures or add some more characteristics to free characteristics.

That ends the theoretical part of my article. Now it’s hands-on system time to learn how to use the debug mode.

Step 1. Bypass the standard functionality. Use transaction SE37 and enter the function module name RSZ_I_COPY_QRY_TO_CUBE. Set a breakpoint after the line Perform check infocube to manipulate the SAP BW original compliancy check. Search for and set the breakpoint at IF l_subrc <> 0 OR l_is_compliant = rs_c_false

(Figure 1).

Figure 1 Set the breakpoint to bypass the standard check

Next you enter the debug mode manually in a second SAP mode for transaction SE37. The fastest way to do it is to

type /ose37 in the transaction input window (Figure 2). Note that “/o” stands for opening a new mode or window.

Figure 2 Transaction input

In the function text box (Figure 3), enter the name of the function again. In the transaction window enter /h and press the return key to activate the debug mode.

Figure 3 Enter the function name again

Now press the F8 key or use the toolbar icon to execute your function.

The system stops in the first lines of the function. To proceed, press the F8 key once. At the next stop in coding, enter the InfoProvider name in the occurring dialog in your defined breakpoint as displayed in Figure 1. In debug mode, set the return parameter l_is_compliant to X by typing the parameter name l_is_compliant in the field name input box

(Figure 4).

Figure 4 Override the value manually

Type a capital X in the input field right after your variable name. Click the change icon (pencil) and run the program normally by pressing the F8 key.

Step 2. Copy the query. The system next asks you what query to copy (Figure 5). The system believes that the

target InfoProvider is compliant, but displays the objects that could not be found and copied (Figure 6).

Figure 5 Select the query

Figure 6 Errors shown during query copy process

In my example, the target InfoProvider does not have characteristic 0BILL_DATE, 0BILL_ITEM... in its design, so the copy functionality skips this characteristic from the target query. However, it also copies the query to its target. These errors, therefore, are shown for informational purposes but do not indicate that the replication was unsuccessful.

Step 3. Repair if necessary. If the query is missing items in structures due to missing characteristics or key figures in the cube design, as shown in Figure 7, proceed with the automatic repair when opening the copied query. It strips the missing characteristics or key figures from filters, free characteristics, rows, and columns. The only thing you might have to do manually is replace the items that have been stripped off. In my case I exchanged the missing

0BILL_DATE with 0CALDAY that is being provided in my target cube. If nothing has been removed, because the elements you use in your query all exist in the target InfoProvider, you are ready to use the query immediately.

Figure 7 Error message indicates missing objects

Remember to inspect the query manually afterwards by running the query to make sure you receive the proper values from SAP BW. You save hours by not having to recreate huge query structures, but the final check must still be made carefully.

Quick Tip

Decide When to Use Before or After Aggregation in Key Figures

by Gary Nolan, Independent BI Strategic Architect

The Before Aggregation setting calculates key figures differently than the After Aggregation setting in BEx Analyzer. Find out how they operate and where to find them in the system.

Categories: Aggregates, BEx, Reporting

To provide flexibility with calculated query key figure values and meet the demands of a user environment, you might want to calculate values in queries using different types of aggregation. Note that BW uses the Before Aggregation and After Aggregation settings in query processing. They do not relate to aggregates that improve performance.

The BW 3.x system can perform two different types of calculated key figure aggregation: Before Aggregation and After Aggregation. For example, a query might display a total price variance report. This report would calculate differently if calculated before aggregation versus after aggregation.

When BW calculates the report before aggregation, it calculates each variance individually on each line and then aggregates them together to form a variance. If BW calculates after aggregation, it adds the total price values and then determines the variance.

Depending on the formula, these two approaches can give widely different key figure results. Developers can set the type of aggregation individually on each calculated key figure. However, the system initially sets all key figures to After Aggregation by default.

Using the Before Aggregation setting, you can arrive at a calculation that you may otherwise not be able to perform. However, it may negatively affect your system’s performance. I’ll explain how this setting and the After Aggregation setting calculate their answers and discuss performance considerations.

How Before/After Aggregation Works

By default, the system performs an After Aggregation calculation. The calculated key figure formula multiples value A by value B. Using After Aggregation, the system adds up all the values for value A, then adds up all the values for

value B, and multiplies these sums together. In Table 1, the values yield 70 * 70 = 4900. This adds all the value A entries multiplied by the total of the value B entries.

Value A

Value B A * B

10 10 100

20 20 400

20 10 200

20 30 600

70 70 4900

Table 1 After aggregation values

Let’s see how the result differs by changing the calculated key figure to provide the value Before Aggregation. First, the system multiplies the value at the lowest level and then sums the resulting values. Next, the system adds these

results to produce a Before Aggregation result of 1300 (Table 2).

Value A

Value B A * B

10 10 100

20 20 400

20 10 200

20 30 600

    1300

Table 2 Before aggregation values

Figure 1 shows the same calculations in a real BW query. It displays two key figure values, one calculated Before Aggregation (called Total Before) and the other calculated After Aggregation (called Total After). Note that the

totals differ because of the Before/After Aggregation setting.

Figure 1 Note the different total values for the key figures Total Before and Total After. These figures have exactly the same formula, but the Before/After Aggregation setting differs.

Set the Before/After Aggregation Setting

You can find both settings in the query’s calculated key figure screen in BEx Analyzer. Locate the calculated key

figures on the left side of the screen. Right-click on your calculated key figure and choose Properties (Figure 2).

Figure 2 Use the Properties option to see the setting to reach the calculated key figure properties

Figure 3 Click on the Enhance button

The system brings up the screen shown in Figure 3. At the bottom of the screen, click on the Enhance button. The system then brings up a detailed screen showing the properties for the key figure calculation (Figure 4). You can toggle the Before/After Aggregation setting at the bottom of the screen using the option labeled Time of

Calculation. The system defaults this entry to After Aggregation.

Figure 4 Adjust the Time of Calculation setting to specify before or after aggregation

Limitations

You only can set the Before Aggregation option on Basis calculated key figures. In other words, the calculated key figure formula only can use this setting if the InfoCube stores each key figure in the calculation. You cannot use Before Aggregation if you are performing calculations using other calculated key figures in your formula. If you have calculated key figures in your formula, then the system grays out this option and does not allow you to choose it.

Disadvantages

There is a distinct disadvantage to setting calculated key figures to Before Aggregation. The performance of this

calculation is significantly slower than the After Aggregation calculated key figures because the system must perform multiple calculations for each value and then aggregate these values. Therefore, the system cannot use InfoCube aggregates. Thus, consider performance before setting this in an InfoCube with a large volume.

Note

If you would like to learn more about reporting, SAP Education offers these classes in the US: BW305 – SAP BW – Reporting & Analysis (for BW 3.5) or BW305 BI- Enterprise Reporting Query & Analysis (for BI NW2004s). For more information, go to www.sap.com/useducation.

Quick Tip

Filter on Multiple Selections of Multiple Characteristics and Key Figures  

by Rob Oliver, BW Team, Barclays Capital

Users who frequently work with large, drilled-down workbooks may want to focus on smaller areas to analyze. Rather than having to repeat individual filtering steps, they can achieve the same result with this tip.

Categories: BEx, Reporting

One of my most frequently offered tips to users is how to use Excel functionality to select multiple values of characteristics that you’ve already drilled down on in a workbook. This saves a lot of time compared to the alternative. It’s time consuming to use the Navigation Block (the group of cells displayed above the query results area containing all the characteristics in the query that the user can interact with using the context menu) to find and select all the desired values, especially if the master data table has a large number of values.

You can select multiple values of a single characteristic in BW 2.0B and BW 3.5. This technique also works across multiple characteristics in BW 3.5, and it does not affect the number of columns that Excel displays. You don’t need to alter configuration, settings, or transports. Just by changing the way you interact with queries when filtering by using the Ctrl key can help you work more efficiently.

Gain Ctrl

To select multiple values of a previously drilled-out characteristic, hold the Ctrl key while selecting the discrete values to filter. Figure 1 shows an expanded query, a section of an expense report with areas of IT, expense type, and account number for month and year to date (YTD). To drill down on the first and third business areas (General Office Costs and Premises Costs) for October and November (the monthly key figure), highlight these cells using the Ctrl

key. Next, right-click on one of the cells to see the context menu. Select the option Keep Filter Value. The selected values remain in the drill down. The system also moves the values to filter values in the navigation block.

Figure 1 Use the Ctrl key to select your fields and select Keep Filter Value

Figure 2 shows how the query changes when you apply multiple filters at once. The query contains the same number of columns (unlike selecting a single filter value) and you now can see only the selected filter values. The system also moves the values to filter values in the navigation block. The back arrow icon from the BW toolbar (in the upper right corner of the figures) removes all of the filters.

Figure 2 Apply multiple filters at once

Note

You only can use this feature when running queries in BEx Analyzer. It does not work on a Web template created using Web Application Designer.

Tip!

You can adopt other Excel type features for multiple cell filtering. In a trend report displaying columns with all 12 months, you can highlight certain months by holding down the Ctrl key and dragging your mouse.

Quick Tip: Hierarchy Variables Save Time and Frustration When Creating Reports  

by Frank Bulacher, BI Practice Manager and Partner, Enowa Consulting (April 2009)

A hierarchy variable enables users to simply select the desired hierarchy when running reports. Find out how to create one in both SAP BW 3.5 and SAP NetWeaver BW 7.0 using BEx Query Designer.

Categories: BEx, Reporting

Most people are familiar with the formula and text variables used for creating reports. However, did you know that variables for hierarchies also exist? Although they were available in SAP BW 3.5, not everyone is aware of the functionality these variables offer.

The purpose of hierarchy variables is the same as for characteristic variables. It allows users to enter a hierarchy in the variable screen of a report so that the query extracts limited data. You may have many hierarchies for an InfoObject. Say a user runs a report using a given InfoObject’s hierarchy. Instead of the user searching for and selecting the necessary hierarchy every time the user runs the report, you can give the user the ability to select the hierarchy before running the query, thus saving time.

Creating and using a hierarchy variable is quite easy, although the process is different in SAP BW 3.5 and SAP NetWeaver BW 7.0. I will show you how you can create them in both systems.

Hierarchy Variables in SAP BW 3.5

First, in BEx Query Designer, go to the properties screen of the characteristic for which you want to create the hierarchy variable. In my example, I used 0MATERIAL. Right-click the characteristic and go to Properties to view the

screen in Figure 1.

Figure 1 0MATERIAL properties

Select a hierarchy for the Hierarchy Name field by clicking the search icon . In the screen that appears, select the Variables check box. Click the create icon to access the SAP BW variables wizard, which guides you through the creation of a variable screen by screen. This is the same way you create characteristic variables. Click the Next

button to access the Details screen in Figure 2.

Figure 2 Set up the variable details

Here you select whether you want the variable to be optional or mandatory. Optional allows end users to leave the variable empty whereas Mandatory forces them to enter a value in the query’s variable entry screen. Note that Ready for Input is set by default. Click the Next button to continue to the Default Values screen.

From this screen you can define a value that is automatically populated in the query’s variable entry screen, which is helpful if you tend to use the same value to run reports (e.g., many users run reports using one hierarchy, such as consumer products). The end user running the report can overwrite the default value if needed. Click the Next button to continue to the Save Variable screen. Save the variable by clicking the Finish button (Figure 3). After saving, the

variable is now visible in the query variable screen under Hierarchy Name (Figure 1).

Figure 3 Save your new hierarchy variable

Hierarchy Variables in SAP NetWeaver BW 7.0

The new BEx Query Designer has all the property information in a frame on the right side of the screen. Click the

InfoObject (in my example, Material) to display the InfoObject properties (Figure 4).

Figure 4 View the InfoObject properties

Click the Hierarchy tab. In the Selected Hierarchy section, you can either choose an existing variable or create a new

one. To select an existing hierarchy, click the hierarchy icon . In the pop-up screen that appears, select Hierarchy Variables and either select one from the drop-down menu or create a new one by clicking the create icon

(Figure 5). For this example, I clicked the create icon to create a new hierarchy variable.

Figure 5 View the available variables or create a new variable

To create a new variable, click the create icon. The Change Variable screen that appears looks the same as the

screen for changing a variable (Figure 6). The difference is that the description is already filled in and other values are selected.

Note

The Replacement Path and Currency/Unit tabs are not available for hierarchy variables.

Figure 6 Create a new hierarchy variable

In the General tab, you have the following options:

Use Standard Text: Select this check box to use the description of the InfoObject text automatically (e.g., the text from 0MATERIAL would be Material)

Technical Name: The system pre-populates this field. Although you can change this, you should only do it if you have a good naming convention in place to identify that it is a variable and where it belongs. The SAP technical name always starts with a VAR_ and allows for a quick identification and search in the system. It is better to apply personalization in the description.

Processing By: Set this to Manual Input/Default Value to allow the end user to enter a value or a user exit (to fill the value automatically via an ABAP program).

Reference Characteristic: Set this to the InfoObject where the variable is defined (Material in my example). If the InfoObject references another InfoObject (base InfoObject), you can choose the base reference object instead (e.g., Sold-To is referenced to Customer [base InfoObject]).

Next, click the Details tab (Figure 7). In this screen you have the following options:

Variable Is: Determines if and how the user may or must enter values

Variable is Ready for Input: Select this check box to allow the user to enter values. If you do not select this, the user cannot see an entry screen when running the query.

Figure 7 Enter the variable details

Click the Default Values tab. Here you can enter or choose a hierarchy that users are likely to use to run the report. You can leave the default value empty or, if there is specific hierarchy with which the reports are run most of the time, then you can add this hierarchy as a default. The user can overwrite it if the report should be run with another hierarchy.

After you finish editing the tabs, click the save icon to save the variable. Now you can add the hierarchy variable to

the selected hierarchies. If you select Activate Hierarchy Display shown in Figure 8, the system adds the variable to the variable screen of the report.

Figure 8 Activate the hierarchy variable

Quick Tip: Ship Off Your Report via Email and Run It from Elsewhere  

by Sushrut Shrotri, Manager Specialist, BI Practice, Deloitte Consulting.

Here's how to move a BEx report from one client to another and then execute it on the new client.

Categories: BEx

Sometimes you need to move a BEx report from one client system to another. Doing so is easy. Using the save button in Microsoft Excel, save the executed report to your local drive. Now you can send this file via email or save it on a shared drive. To execute the report, simply open the file from its shared location/email. The Excel file opens displaying the report content.

If you want to refresh this report now or perform “slice and dice” analysis, simply start your Business Explorer Browser without closing Excel (usually: Start > Programs > Business Explorer > Analyzer). Click on Enable macros in the pop-up window, and you will see the BW reporting toolbar on your Excel report. Click on refresh and it will prompt you to select a system and log on to the correct BW system.

If you would like to share a report you built and saved in your favorites with another user without moving it to the role, simply save it as a local workbook.

Sushrut Shrotri is an experienced technology professional working in the Business Intelligence practice of Deloitte Consulting.

Quick TipSimplify Result Reporting with the Leaf Operator  

by Deepak Iyer and Ritesh Jogani, Patni Computer Systems, India

Use the leaf operator in a BEx query formula to show individual and result rows separately in a query.

Categories: BEx, Reporting

Sometimes when you run a BEx query, you need to differentiate how to treat the key figures in your report. Say you want to view the individual costs of several items in your inventory as well as the total cost of these items. In your query formula, key figures like quantity and cost must act differently for individual values and aggregated values.

In this case, you could use leaf, a Boolean operator that permits you to perform calculations in results rows. You can use the leaf operator for formulas as well as calculated key figures. This functionality works with all releases of BW. You apply the leaf operator at the query level in BEx Analyzer, so this functionality is available via the Web as well.

Figure 1 shows one way you can use the leaf operator for result reporting. Look at the Quantity column in the example report. Since the quantity units of the materials (each, per dozen) are different for each plant, you cannot

have a total Quantity value in the Result row. The system would display a junk value or XXXXX because of the different units. If you use the leaf operator, you can make these fields appear blank instead.

Figure 1 Blank Result rows. The elementary (individual) rows show the values with different units.

We will explain how to use the leaf operator with two different key figures. First, we will show you how to set the Quantity value in the Results rows to blank. Then we will describe how to aggregate the cost key figure so that the system rounds the Cost values in the Result rows to the nearest thousand dollars.

How Does the Leaf Operator Work?

The leaf operator is a minor functionality provided by SAP. Developers rarely use it, often because they are unaware of the functionality. You access the leaf operator when you set up a formula for a key figure in BEx Query Designer. Drag the required key figure Quantity to the Columns section. Right-click on Key Figures and select New Formula

(Figure 2).

Figure 2 Select New Formula from the menu for the Quantity key figure

Note

To use the leaf operator, your query must have at least one key figure displayed in the Columns section. The leaf

operator works on the result and line item rows of a particular key figure across characteristics in the rows.

In the Functions area, under Boolean Operators, select 1 with Individual Values, 0 with Aggregated Values

(Figure 3). This is the leaf operator. Click on the OK button to add the function to the formula.

Figure 3 Find the leaf operator in the Functions area under Boolean Operators

In Figure 4, the Formula area contains the leaf operator and the Quantity key figure. The formula is LEAF

(‘Quantity') * ‘Quantity'.

Figure 4 The leaf operator with key figure Quantity

The output result of the leaf operator in Figure 4 is 0 for Result rows, the real (inner) nodes of a hierarchy, and 1 for elementary rows. Elementary rows are the leaves of a hierarchy (the individual line items for each plant). You set the display of zeros to blank by changing the query property.

In BEx Query Designer, select the query and click on the query properties icon in Figure 5 to open the Query Properties screen. In the Number Format section, make sure you leave the Show Zeros as field blank. Click on the

OK button to save this setting. Now when the formula calculates a zero value for a quantity, the field appears blank in the report.

Figure 5 Make sure the Show Zeros as field is blank

Figure 6 shows another use of the leaf operator. Using the data from Figure 1, set different properties in the formula for the Result and elementary rows by using the leaf operator. For example, sometimes the value in the Result row is very large and occupies too much space in the layout. To make it easier for users (e.g., high-level managers) to

interpret the values quickly, round the totals in the Result rows to the nearest thousand.

Figure 6 Individual and aggregated values of the Cost key figureclick here for a larger version of this image

For the report in Figure 6, we employed a different formula in BEx Query Designer. This time, we used the key figure

Cost with the leaf operator and also introduced the command NOT LEAF (Figure 7).

Figure 7 The key figure Cost with the leaf operator

In the formula in Figure 7, the first section of the formula applies to the individual cost values, which will work normally. This section displays the cost values in the elementary rows (e.g., $250.00 and $350.00).

The second section applies to the aggregated Result rows. This section includes the NOT LEAF operator, which works completely opposite of LEAF. If the output of the LEAF (‘Cost') is 0 for the Result rows, then the output of NOT LEAF (‘Cost') is 1 for the Result rows. Thus, the ‘Cost'/1000 portion of the formula scales the values of the Result rows by 1000 for the Cost key figure so that the Result rows display the cost totals rounded to the nearest thousand.

Quick TipTurn Off Attributes in BW F4 Help  

by Joerg Boeke, Director of Business Intelligence, syskoplan AG

Have you been looking for a way to simplify or restrict access to BW F4 searches? Use this tip to choose which attributes to display in BW F4 help.

Categories: BEx, Reporting

While creating a query, Business Explorer (BEx) and Web reporting users often use the F4 search functionality to find specific customer ranges. Pressing the F4 key begins a search of the system that lists all the characteristic values relevant for a certain query’s filtering. This list helps users to select specific customer attributes to include in the

report. Figure 1 shows a query containing manual variable input for customers.

Figure 1 Query containing manual variable input for customers

However, it might not be a good idea for all users to see all information (such as classification categories) for a couple of reasons. Ad hoc reporting users, for example, sometimes are not allowed to see all attributes. Say that sales people at your company are not allowed to see specific key figures presenting rankings that are stored in the master data. F4 help reads the master data, so all attributes, even confidential classifications, are on display when sales people search using F4.

In addition, reporting users are often overwhelmed by the amount of attributes on display when performing a simple search. If end users are looking for one field using standard F4 help, they may navigate through many fields before

locating the right one (Figure 2).

Figure 2 F4 help screen

I’ll show you a way to choose what F4 help displays by adjusting the setting that determines the order for F4 help. This tip works for BEx and Web reporting.

Void the Values of Order for F4 Help

Go to InfoObject Maintenance in Administrator Workbench via transaction RSD1. Enter the InfoObject name and

select Maintain. Alternately, you can double-click on the InfoObject in Administrator Workbench (Figure 3).

Figure 3 Double-click on an InfoObject in Administrator Workbench

You see a column called Order for F4 Help (Figure 4). This column determines the order of appearance in the F4 help dialog (1 to N indicates the order from left to right). Enter a value of zero for those attributes that you do not want

to display anymore. Figure 5 shows the resulting F4 help that displays the Customer and Medium Description fields only.

Figure 4 Choose which attributes to display in F4 help

Figure 5 Resulting F4 help screen

Quick Tips: 22 Ways to Boost BEx Query Performance  

by Catherine Roze, Consultant, IBM Business Consulting Services

You don't necessarily have to leave the responsibility for query performance to your technical team. These tips could save you a great deal of trouble and make you a hero with your end users.

Categories: BEx, Performance, Reporting

Query performance is an important factor for any user who wants fast results. Query performance management need not be the exclusive domain of the technical BW team. True, query performance begins with data modeling of the InfoCube and ODS objects, but it doesn't end there. Power users and query designers can exercise a number of techniques to optimize the performance of BW Business Explorer (BEx)-based queries.

What follows is a series of practical tips and techniques to do that. I amassed them through personal experience, research, and other BW practitioners. Some of them will not only improve query performance, but will produce better result sets as well.1 Some of the tips that I will give you come with trade-offs. I've presented these query optimization tips and techniques—22 in all—according to the following levels:

At query and workbook level At query definition level (key figures, characteristics and attributes, and other query techniques)

Process and general recommendations

Note! The secret to query performance is to keep the number of result sets at a minimum. This reduces the amount of data selected from the database and avoids unnecessary database processing and data-transfer operations. Clearly, the data-transfer speed increases when the size of the result set decreases. As a rule of thumb, SAP recommends that you keep the maximum result set within a BEx query to 10,000 records.

Query- and Workbook-Level Optimization Tips and Techniques

1. Avoid complex queries that offer everything for every user. When a query becomes complex, go back to the basics and consider breaking it into multiple queries. You can also achieve the same result as the complex query by presenting the results in several worksheets of the same workbook. You might also consider linking several worksheets/workbooks using the report/report interface, a functionality in SAP BW (and R/3), to link reports for drill-down reporting. Note that this will improve query execution, but might increase development and administration overhead for the query.

2. Avoid using queries to produce large reports. As opposed to mainframe and operational reports, SAP BW is not aimed at providing large reports with a great number of details. Rather, BW is designed for OLAP (on-line analytical processing)—e.g., interactive slice-and-dice analysis. Users often print large reports solely to analyze exceptions such as what products or clients have a profit margin of less than 10 percent. Therefore, an exception report might better serve their needs than a large report. This might

require a cultural change and might take education on the part of the user.

3. If large reports do have to be produced, leverage the BW reporting agent to generate batch reports. These batch reports may be scheduled to run outside of business hours to minimize load during peak hours. You might also want to look for reports that are available in the operational system (R/3) to meet the reporting requirements. Another option would be to use third-party tools such as Crystal Reports to generate, publish, and print large tabular reports.

4. Save the query results in a workbook and refresh the data when needed. This strategy will prevent the same data from being unnecessarily fetched from the InfoCubes multiple times. This is especially relevant for queries produced for a large number of users and that do not require up-to-the-minute information.

5. Minimize the number of graphical objects such as charts and maps used in the workbook. The number of graphical elements saved in the workbook has a significant impact on resources and query run time. Let the end user create graphs as needed locally.

6. Select the right read mode. Three query read modes in BW determine the amount of data to be fetched from a database:

Read all data (all data is read from a database and stored in user memory space) Read data during navigation (data is read from a database only on demand during

navigation)

Read data during navigation and when expanding the hierarchy

Reading data during navigation minimizes the impact on the R/3 database and application server resources because only data that the user requires will be retrieved. For queries involving large hierarchies with many nodes, it would be wise to select Read data during navigation and when expanding the hierarchy option to avoid reading data for the hierarchy nodes that are not expanded. Reserve the Read all data mode for special queries—for instance, when a majority of the users need a given query to slice and dice against all dimensions, or when the data is needed for data mining. This mode places heavy demand on database and memory resources and might impact other SAP BW processes and tasks.

A query read mode can be defined either on an individual query basis or as a default for new queries using the query monitor (transaction RSRT). Process and General Optimization Tips and Techniques

7. Test new queries in the development system before running them in the production system. By leveraging the BW landscape, you will not impact the production system with less-than-optimal query definitions before they are fully tested and optimized. This might not be an option if the data needed to test and validate the query is only available in the production system.

8. If the same data is available in both the ODS and InfoCube, use the ODS rather than the InfoCube to define the query. If your goal is to do tabular reporting (no slicing and dicing, no OLAP) rather than using the InfoCube (OLAP query), leverage the ODS objects. Since the ODS object is based on a two-dimensional database structure, the number of database table joins will be minimal and the query will execute efficiently.

9. If the same query can be written from the original InfoCube (InfoProvider), avoid MultiProvider (MultiCube) queries. MultiProvider (MultiCube) queries require additional database table joins to read data compared to those queries against standard InfoCubes (InfoProviders), and you should therefore use them only when you have no other option.

10. Avoid queries against remote InfoCubes. Since a remote InfoCube is not managed within BW, but rather stored in the source system, executing a query against a remote InfoCube will require additional

communication and processing, thereby negatively impacting reporting performance compared to queries against objects stored in BW. If they have to be used, remote cubes will typically perform better if a small amount of data is in the remote InfoCube and a small number of users has access to it.

11. If Web reporting is available, use Web Reports rather than BEx Analyzer. Web reporting applications create less network overhead than BEx Analyzer, and using Web Reports typically results in better performance than BEx-based queries.

12. If using the BEx Analyzer, launch it from the Windows menu rather than from within the SAP BW menu (or via transaction code). Microsoft Excel, BEx, and the SAP BW front end are memory-intensive applications. You will achieve better memory management through Windows system management if the BEx Analyzer is initiated by Windows (through the SAP front-end menu or a shortcut created on your desktop) rather than by the SAP BW front end (SAPGUI).

13. Tune your PC for hardware and software optimization. Your query performance issues might be the symptom of a sub-optimal software or hardware configuration on your machine. Contact your local help desk for memory optimization (for example, adjusting virtual memory and page size). Your performance issues might also be resolved by adding memory to your system or replacing your machine with a faster one.

Query Definition-Level Optimization Tips and Techniques

14. Leverage calculated key figures rather than formulas. As compared to formulas that are evaluated during query execution, calculated key figures are pre-calculated and their definitions are stored in the metadata repository for reuse in queries. The incorporation of business metrics and key performance indicators as calculated key figures, such as gross profit and return on investment (which are frequently used, widely understood, and rarely changed), improve query performance and ensure that calculated key figures are reported consistently by different users. Note that this approach improves query runtime performance but slows InfoCube or ODS object update time. As a rule of thumb, if multiple and frequently used queries use the same formula to compute calculated fields, use calculated key figures instead of formulas.

15. Minimize the number of restricted key figures (RKFs) used in the query. RKFs result in additional database processing and complexity in retrieving the query result and therefore should be avoided when possible.

16. Use characteristics as free characteristics rather than in rows and columns. Minimize the use of characteristics in rows and columns to avoid increasing the amount of details in the initial query result. The more details in the initial query result, the larger the result set will be and the more unlikely that an aggregate will be found. Rather, use the characteristics required for navigation as free characteristics that can be used for drill-down. This strategy will accomplish the same goals, since different users typically have different preferences in terms of the order and contents of the drill-downs.

17. When multiple drill-downs are required, separate the drill-down steps by using free characteristics rather than rows and columns. This strategy results in a smaller initial result set, and therefore faster query processing and data transport as compared to a query where all characteristics are in rows. Note that this strategy does not reduce the result set that the user obtains from the query. It just separates the drill-down steps. In addition to accelerating query processing, this has the advantage of improving the presentation to the user by providing more manageable portions of data.

18. Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase.

19. If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The “not assigned” nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected.

20. Leverage filters as much as possible. Using filters contributes to reducing the number of database reads and the size of the result set, thereby significantly improving query runtimes. Filters are especially valuable when associated with “big dimensions” where there is a large number of characteristics such as customers and document numbers.

21. Minimize conditions-and-exceptions reporting. Conditions and exceptions are usually processed by the SAP application server that generates additional data transfer between database and application servers. If conditions and exceptions have to be used, the amount of data to be processed should be minimized with filters.

22. Minimize the number of reusable structures in the query. Reusable structures are predefined selection and layout criteria for rows and columns that may be reused in other queries and often contain a combination of key figures, characteristics, and formulas. They suffer from limitations similar to those of RKFs and formulas in terms of reporting performance, and you should therefore avoid them when possible. Note that this strategy improves query execution but might increase development and administration.

Applying these 22 tips and techniques should resolve the majority of your query performance issues. As a last resort, if you are still experiencing performance issues, then I suggest that you visit your technical team and the SAP Service Marketplace Web site (http://service.sap.com), as well as database, hardware, and system software documentation.

I'll leave you with one more piece of advice that won't improve BEx query performance, but might make your life a little easier: Provide education and training to your users and share some of these tips with them—for example, avoid large reports. You should also strive to manage your users' expectations. Explain to them what level of performance they can reasonably expect and what can and cannot be done to improve performance without major redesign and investment. They will then be better positioned to avoid creating unnecessary query loads and help you identify when a real performance problem occurs.

Depending on your circumstances, some of these tips and techniques might not apply

Quickly Build Impressive Dashboards in SAP BW 3.5  

by Glen Leslie, BI Product Manager, SAP Labs

You have a variety of options for creating and maintaining dashboards in SAP BW 3.5 including a new approach that significantly reduces your development efforts. The SAP Business Explorer (BEx) Web Application Designer in SAP BW 3.5 introduces the Web template Web item so you can easily design dashboards that your end users are sure to love.

Categories: BEx, Web Application Designer

Key Concept

A fundamental building block of the BEx Web Application Designer is the Web item. These are controls for displaying elements such as tables, charts, drop-down list boxes, radio buttons, check boxes, etc. in Web templates. SAP BW 3.5 provides roughly 30 Web items and each has a number of user-defined settings stored as SAP BW library items that can be quickly deployed repeatedly with minimal setup time.

You’ll find several new Web items in the SAP Business Explorer’s (BEx) Web Application Designer (Web AD) in SAP BW 3.5. The new Web template Web item acts like a template in a template that allows SAP Business Intelligence

(BI) Web content developers to quickly build and deploy dashboards (Figure 1), which are compact displays that render Web content graphically and easily.

Figure 1 The new Web template Web item

With the template-in-template Web item, a single template contains multiple sub-templates. Content developers who reuse design elements are able to make global changes via sub-templates to enterprise-wide Web and portals content. Developers are able to maintain a uniform master template that serves as a framework for others to add detailed content using the template-in-template approach, which promotes consistency of SAP BW Web applications

across an enterprise. The sub-templates readily accommodate existing Web templates created by SAP BW customers who often have invested precious resources in development.

The template-in-template concept builds on the idea of library items, which are user-defined settings for custom graphics stored in the system for later use. You can save various properties of a pie chart, for example, as library items so that it is quickly displayed as a 3-D graphic with labels formatted for currency and with specific color palette settings for each pie slice without a lot of development time.

The Web template Web item represents an advancement over the library concept in that it allows you to build discrete clusters of related Web items saved as a template and ready for inclusion in your master template rollout. Let’s say you are working with a so-called 2DD+T+C design, which features two drop-down boxes that control a table and chart that are next to each other, and you want to include that design in large number of templates. Instead of going into each individual template and adding the 2DD+T+C layout, you can simply include the entire layout in a master template.

Note that the concept of a master template is not specially defined within SAP BW or the Web AD — it’s simply a logical construct I used here to refer to a template that has other sub-templates embedded within it. Changes can be made to a sub-template and they are reflected in the design of the appropriate master templates that the sub-template is nested in. If your user community, for example, needs a third drop-down and a radio button group to be added to the template, you simply modify the sub-template with the 2DD+T+C layout and all master templates that contain it offer the updated design.

With template-in-template functionality there is no limit to the number of nested templates that can be created, giving developers full control over how they deploy their Web templates as components of larger Web pages or templates.

Go Beyond Frames

Because it does not require implementing frames, the template-in-template approach offers a significant improvement over previous dashboarding field solutions and other workarounds within SAP BW Web content. Frames are HTML tags () used by Web designers to layout a page providing separate areas of control such as the left panel or “pane,” right pane, header pane etc. Many developers avoid using frame tags because they can add to the complexity of Web page deployment.

Frames generally make navigating within a Web page hard to decipher for other developers. They don’t behave consistently across all browsers and Web pages. Many search engines — both corporate and Internet — either do not support frames or do not attempt to search Web pages containing frames. Whether you want to use frames or not, they are supported by the Web AD but not required.

Ease of Use

Figure 2 provides an example of the template-in-template design. The single master template contains five sub-

templates that accommodate the header, footer, and each of the three tabs (Tab1, Tab2, Tab3). Two of the tab sub-templates are hidden after a tab is clicked on for display. There’s nothing unique to SAP BW 3.5 about the master template or these sub-templates and no new SAP BW functionality beyond the template- in-template Web item is employed. What’s different about this construct is that a template placed in the new Web item acts as a pointer to another template on the SAP BW system. Any template can be executed individually assuming the proper authorizations are in place.

Figure 2 SAP BW template with multiple templates embedded

Creating and maintaining a tabbed dashboard is easier to manage using the template-in-template design. Figure 3

shows the Tab1 template from the above example in a dashboard. In the past, a Web author was required to cram all the Web items for all the tabs into a single template and juggle all those items as each tab was clicked on. In addition, all these design elements and code had to be manually copied and synchronized if they would be released in other templates.

Figure 3 Tab1 displayed as a standalone template

With the template-in-template feature, the author links SAP BW commands to hide or to show a tab. Figure 4 shows the developer’s template-in-template view of the master template in Figure 3. Each sub-template is uniquely identified by its technical name (TPL1, TPL2, and TPL3) specified in the Web item properties. Commands are tied to corresponding anchors via what’s know in HTML parlance as hyperlink references tags () in the master template so

that Tab1 controls sub-template TPL1, Tab2 controls TPL2, etc.

Figure 4 Developer's view of the template

All of this could be accomplished in previous releases of SAP BW 2.x and 3.x, but it took a lot more manual coding. Now entire templates can be worked on at one time, significantly reducing the amount code initially required as well as minimizing the re-coding effort needed to propagate changes as dashboard solution evolves.

Note

SAP provides documentation for different SAP BW style elements — not only for tab displays but for all elements available for a BEx Web template. Go to http://help.sap.com/content/documentation/netweaver/index.htm and click on the most current Support Stack documentation link. Then, follow Information Integration>SAP Business Intelligence>BI Suite (Business Explorer)>BEx Web Application Designer and click on BW Stylesheets on the left side of the screen.

I should point out that my layout uses three tables in the center portion of the master template to position the tabs, which makes the design a little tricky. An outer table holds the other two tables in place and the tab texts are contained in a one-row table with three cells. The three middle template placeholders are contained in a single cell table. The tables also provide styling for both the tabs and the template as the tabs are clicked. The template-in- template Web item supports other methods of formatting such as Cascading Style Sheets (CSS) and HTML

tags, which may offer a cleaner layout. I did not use them here because they would add complexity to the code in this example, but you can use them if you think they are helpful.

Template calls to the sub-templates are straightforward. Figure 5 on the previous page shows the HTML code in the BEx Web AD that hides or unhides one of the three sub-templates based on when a tab is selected. Initially, each line of code hides all three middle templates by using wildcards (‘*TPL*’). Next, it sets the command for the multiple

providers (Multi=X) to HIDDEN. The code then unhides the template corresponding to the appropriate tab when the tab is clicked on.

Figure 5 Code to switch templates

Hands On

Let’s look at the steps needed to set up the three-tabbed dashboard display in my example using the template-in-template Web item. I’ve included the code for this entire SAP BW Web template on the BW Expert Web site under the Download Section (www.BWExpertOnline.com) for those of you who have access to a SAP BW 3.5 system. Setting the dashboard up will require knowledge of how to code in HTML.

First, you need to create five templates on the SAP BW system with the following technical names: MYHEADER, TEMPLATE_1, TEMPLATE_2, TEMPLATE_3, and MYFOOTER. You can modify my code to reflect templates that you’ve already created, if you prefer to use existing templates. You will need to replace occurrences of “MYHEADER” with “YOURHEADER” where YOURHEADER is the technical name of a template you’ve created, and repeat this step for all of your other existing templates.

Open SAP Web AD on an SAP BW 3.5 system and create a new blank template by clicking on the icon. Switch to the HTML tab at the bottom of the display and paste the code from the Web site directly into the HTML tab of a blank Web template. Highlight the default code on this page and paste my code on top of it.

The table incorporates three SAP-supplied styles in BWReports.css (SAPBEXTbsTabs, SAPBEXTbsTabSel, and SAPBEXTbsBdyEdg), which assist manipulating the tabs as they are clicked on. Figure 6 shows how these styles are applied to the template to provide depth to the tabs and update the display when each tab is selected. SAPBEXTbsTabs governs the styles of the deselected tabs and SAPBEXTbsTabSel applies styles to the selected

tab. SAPBEXTbsBdyEdg controls a key design element: the styles for the top of the table below the tabs, which gives the impression that clicking on the tab brings forward the attached page.

Figure 6 Three SAP-supplied CSS in BWReports.css

Code similar to that in Figure 5 allows SAP BW to hide all the templates and make the appropriate one reappear. The system must be told now to apply the tab-selected style as opposed to the tab-deselected style. To do this requires one simple JavaScript call at the bottom of the HTML, right before the tag in the Web template code:

Of course, you must define what the function check_tab() is actually doing by including the code in Figure 7. First, set up an array of the template names in the variable check_items, which allows you to easily accommodate more tabs if needed. Then retrieve an array of properties into prop from the check_item(i) by making the JavaScript call,1 SAPBWGetItemProp(). Next loop through the array of prop elements, specifically checking items 0 and 1. If element 0 is HIDDEN (set by the SAP_BW_URL command in Figure 5), then set the variable hidden to true(1) or false(0), based on a test of whether or not element 1 is set to X. The last If sets the correct CSS style and document properties for each of the tab items. While it may look exotic to those familiar with Web coding and the Document

Object Model (DOM), the last IF statement can be found in any standard text on the subject and is indeed a standard call.<

Figure 7 Code to define function check_tab()

The method I’ve described is one of a number of ways that the tabs can be coded and it’s generic so you can easily adapt it to your needs.

If you’ve created a dashboard with SAP BW 2.x or 3.x, you can see that the new Web item gives you significant control with less administration. This is true for both the initial creation of content and in the propagation of that content throughout the enterprise. It’s not that you couldn’t build dashboards previously but that it’s clearly easier with this new functionality.

1 Supported SAP BW JavaScript calls are documented in the SAP BW Web API Reference guide. This can be found at http://service.sap.com/bw and follow the menu path Documentation>SAP BW 3.5 Documentation Enhancements.

R/3 Can Be Your One-Stop Shop for BEx Web Reports  

by Dr. Yasan Gooding, Information Systems Specialist, Valero Energy Corporation

Power users or developers with the appropriate authorization can connect end users to their BEx Web reports within R/3. This allows end users to perform detailed reporting and analysis from their current SAP session.

Categories: BEx, Reporting, SAP ERP, Web Application Designer

Key Concept

The role menu Web item permits users to access a Web menu that organizes Web reports in the same way as the folders in BEx Browser. This design benefits open environments that have little to no security restrictions in BW. More secure environments can use this function as well, since they establish roles and profiles based on user function. By selecting specific roles, users see a customized, uncluttered view of all their reports.

BEx Browser goes unused at some organizations because it’s difficult to regulate authorization roles and profiles while completing daily activities. In R/3, users often are afraid to branch out and use advanced BEx reports because they want to remain in their R/3 comfort zone. Users with BEx access often see a huge list of roles and folders and

are unsure which report to choose (Figure 1).

Figure 1 Typical BEx Browser display containing dozens of options

Users are more likely to take advantage of additional analytical tools in BW if they have easy access to them. By using the role menu Web item in Web Application Designer (Web AD) and the Favorites folder, analysts and business users can access BEx Web reporting and run reports in R/3. After you implement this procedure, end users can link directly to their specific roles and BEx Web reporting in R/3 or mySAP ERP Central Component (ECC). This technique works for BW 3.0 and Web AD 3.0 up to SAP NetWeaver 2004s.

I assume the following about your BW system: The roles are set up and a series of BEx Web reports exists that the end user accesses via BEx Browser, a portal, or an intranet.

Note

Depending on your organization, either a Basis or security team regulates and grants user role access. Each company sets up roles differently. Check with your Basis or security team to ensure that user roles and profiles are compatible with the procedure I describe in this article.

Configure the Role Menu Web Item

In Web AD 3.0 and up, the role menu Web item can link to all Web reporting in R/3. Execute Web AD (menu path Start>Business Explorer>Web Application Designer) and highlight the Role Menu Web item in Figure 2. The bottom of the screen has three tabs (Layout, HTML, and Overview). Select the Layout tab. Then, choose the Role

Menu Web item and drag it to the right side of the page. Web AD displays the Role Menu Web item as an HTML icon (Figure 2). The HTML icon appears as a menu when you access it in R/3. The next step is to customize what roles users should see.

Figure 2 Highlight the Role Menu Web item

If you look below the Web Items area in the left side of the Web AD screen in Figure 2, you see another area entitled Properties. Click on the Web Item tab. The values in the columns labeled Property and Value affect how the role menu Web item behaves. You can control several attributes by changing the values of those line items. Each line item represents a property of the Web item. Changing the value of the property alters how the Web item behaves on the Web. The List of Roles line item in Figure 2 allows you to assign specific roles or folders presently on BEx Browser to a more customized menu path that end users find easier to view.

Select Your Roles

Double-click on (List) in the Value column in Figure 2 to see the List of Roles screen (Figure 3). If you are unfamiliar with role maintenance and administration, this would be a good time to involve your Basis or security administrators in the process to assign the right roles to end users.

Figure 3 Click on the drop-down box to display a list of roles and select your roles

Click on the drop-down box in the right corner of the blank screen for a list of roles based on InfoAreas within BW as well as administrator and power-user roles. Assigning these roles in Web AD does not override individual security authorizations. However, it limits authorization. In other words, you can add as many roles as you want to this list, but if the users do not have these roles in their BW profile already, they do not have access. You can pick up to 15 roles per Web menu. In my example, I added two roles: Sales and Distribution and Financial Accounting (Figure 3). You also have the ability to create multiple Web menus for various user groups.

Click on the save icon to save your changes to the Web application. A dialog box appears (Figure 4). Save the template to your Favorites or to a place specifically for the IT staff. Give the Web application a Description and

Technical Name and save.

Figure 4 Save the roles to your favorites

Test Your Customized Web Menu

Test your Web menu to make sure it works and contains the right roles listed on the Web menu. To execute your

Web application, select the execute icon . You’ll see a dialog box asking you to provide a user name and password. Click on the OK button.

You should see a Web menu with the selection of roles that you chose to appear on your list (Figure 5). In this case,

I selected two roles: Sales and Distribution and Financial Accounting, as seen in Figure 3.

Figure 5 Web menu with links to various reporting options

In Figure 5, both roles have several folders with subfolders under them with indented arrows followed by Web reports as well as workbooks. These roles allow the user to view BEx reports in BEx Analyzer and view BEx workbooks, Web reports, transaction codes, and documentation in BEx Browser. These areas may correspond to your InfoAreas in

BEx Analyzer. At this point, a user can select which item to execute. The Nomination Activity Detail-Customized item is a Web report and the others are workbooks.

Note

Businesses access Web reporting in many forms: Web links via intranet pages, portals, broadcasts of links, HTML pages, or Excel attachments to user groups. Some departments use and access BEx Web reporting in different ways, depending on the department or job function.

Note

If you would like to learn more about BEx, SAP Education offers these classes in the US: BW305 SAP BW - Reporting & Analysis (for BW 3.5) and BW305 BI - Enterprise Reporting, Query & Analysis (for SAP NetWeaver 2004s). For more information, go to www.sap.com/useducation.

Give Your Web Menu to End Users

In Web AD, capture the URL that connects your Web menu and Web reporting. To do this, select Publish>Copy

URL to Clipboard to copy the URL in memory (Figure 6). Close Web AD and open an R/3 session.

Figure 6 In Web AD, copy the URL in memory

The SAP menu is located in the top left corner of your R/3 screen. Right-click on the favorites icon to reveal the Favorites folder and the SAP menu. Right-click on your Favorites folder to see a dialog box and select Add other

objects. In the screen that appears (Figure 7), choose Web address or file to copy your link to your Favorites folder.

Figure 7 Choose Web address or file

Click on the green check mark icon to execute. You’ll see the screen in Figure 8, where you name the Web menu item and paste the URL link. Click on the green check mark icon to add the link to your Favorites folder in the R/3 menu (Figure 9). To execute the BEx Web menu, double-click on the globe icon in Figure 9. BW Web reporting via R/3 performs the same way as it does in BW.

BW teams should promote the business benefits of software like BEx and offer training. One easy way to encourage your end users to use BEx is to implement the process I’ve outlined here.

Figure 8 Name the Web menu item and paste the URL link

Figure 9 Access BEx Web reporting via your Favorites menu in R/3

SAP NetWeaver 2004s What’s New in the BI Back End  

by Ned Falk, Senior Education Consultant, SAP America

Take a peek at the new features in SAP NetWeaver BI, which is part of SAP NetWeaver 2004s.

Categories: Analytics, BEx, Business Content, Data Management, ETL, Event and Process Chains, Security

Key Concept

SAP NetWeaver 2004s, a minor release of the SAP NetWeaver platform, became available in restricted release in October 2005. SAP now packages its Business Intelligence (BI) software as SAP NetWeaver BI. The latest release of BI is only available as part of SAP NetWeaver 2004s.

In SAP NetWeaver 2004s, BI transitions completely into the SAP NetWeaver landscape and is no longer its own release. The idea of BI encompasses the ability to analyze, plan, and disseminate data through various tools. In addition to improving the core data warehousing features, SAP has enhanced other BI features such as information broadcasting and analytic capabilities. Enterprise Data Warehousing (EDW) serves to consolidate, clean, and efficiently store data from varied sources.

Several new features and improvements in SAP NetWeaver BI help you tackle your back-end computing challenges. They include an enhanced Operational Data Store object (ODS, now called DataStore object), improvements to SAP NetWeaver BI InfoSets, and high performance analytics (HPA). This overview of SAP NetWeaver BI back-end changes covers what I consider the most useful new features, many of which are major improvements over the prior SAP BW Release 3.5.

Note

Refer to http://help.sap.com’s release notes for SAP NetWeaver 2004s for more information.

DataStore Objects

DataStore objects are an improved version of ODS. New types of DataStore objects and performance enhancements allow you to optimize them in various levels of your EDW. For example, if you want to transfer data to BW and don’t

need delta features, you would use a standard ODS in BW 3.5. The new write-optimized DataStore object, which I

will describe, is a more efficient alternative. Table 1 shows the three types of DataStore objects.

DataStore object type

Versions of data

BEx access

Usage Structure  

EDW layer

ODS layer

Delta determination

Fast access (no activation) Other

Active data

Change log

Activation queue Integration

Standard Active, modified, delta

X X X X     X X X Via data transfer process

Write- optimized

Active X X X   X Especially for large sets of data

X     Via data transfer process

Direct update

Active Active       X Also for use by the Analysis Processes Designer (APD)

X     Via Application Programming Interface (API) functions

Table 1 Summary of the differences among the three types of DataStore objects

Standard DataStore objects are a lot like the standard ODS, but offer better activation performance. SAP reduced the time necessary to activate data in ODS from SAP BW 3.0 to 3.5, and now this process is even faster in SAP NetWeaver 2004s.

In addition to the standard DataStore objects, SAP created a new write-optimized DataStore object. Write-optimized means that you can transform data more efficiently when loading massive numbers of records when delta features are not necessary.

For example, many data sources can provide an additive delta via an increasing transaction ID or timestamp without necessarily using the delta features of the standard ODS. The write-optimized DataStore object does not have a change log or activation queue, and you can load it via the new data transfer process, which I’ll discuss in the “Graphical Data Transfer Process” section.

The direct update DataStore object replaces the transactional ODS. This is mostly a name change, with nearly the same uses and limitations. For example, with the direct update DataStore object, like its predecessor the transactional ODS, you can not query with BEx tools directly — you must use a BI InfoSet.

SAP NetWeaver BI InfoSets

SAP NetWeaver BI offers improved InfoSets. The capability to join InfoCubes as part of InfoSets results in much more flexible objects. For example, you can easily create a report of slow or no sales customers via a left outer join between master data 0CUSTOMER and InfoCube 0SD_C01.

In addition, you can link an InfoCube to an InfoObject, and this InfoObject to another InfoObject, which gives you access to an attribute’s attribute, known as a transitive attribute. Finally, with improvements to temporal joins and the ability to link to an InfoCube, you could create a pseudo-historical truth report by linking the day of the sales transaction in the InfoCube and time-dependent master data attributes without including these in the star schema.

HPA

Of the many improvements in core technologies, the newest and most promising is HPA. HPA, new with SAP NetWeaver BI, combines hardware technology improvements and the existing SAP NetWeaver TREX search engine

features with new algorithms, resulting in incredibly fast queries (Figure 1).

Figure 1 TREX supports HPA in SAP NetWeaver BI

This feature improves query response times tenfold (though 100 or more times faster is possible depending on the hardware used, the query, and the number of records involved). The system accomplishes this without query changes or the costly administration of normal database aggregates and other design techniques.

Note

Although HPA seems like a panacea, it has some restrictions, such as specific hardware requirements, so don’t throw out your existing performance-tuning knowledge just yet.

Graphical Data Transfer Process

SAP NetWeaver BI provides better design tools for the data transfer process and updates the extract, transform, and

load (ETL) process to a graphical format (Figure 2). Other ETL vendors (e.g., Informatica, Ascential) provide graphical ETL tools. SAP now has a similar drag-and-drop GUI to create transformation logic inside SAP NetWeaver BI, including the data flow between the Persistent Staging Area (PSA) and data targets in SAP NetWeaver BI or from target to target. In addition, SAP NetWeaver BI offers improvements in error handling during the ETL process.

Figure 2 New design tools for the data transfer processclick here to view a larger version of this image

To support this graphical ETL, SAP uses new terms, so current terms such as InfoPackage and data transfer process

change slightly. For a list of the old and new SAP NetWeaver 2004s terms mentioned in this article, see Table 2.

New term Old term New term’s definition

Analysis authorization Reporting authorization

An improved type of reporting authorization that gives you control over authorization of navigation attributes

Data transfer process Data transfer process

An SAP NetWeaver BI object to aid with follow-on loads and transformations in SAP NetWeaver BI

DataStore object ODS object An improved version of the ODS object

Direct update DataStore object

Transactional ODS

A DataStore object that queries the write-optimized DataStore object with BEx tools

HPA N/a A feature that improves query performance by combining hardware technology improvements with the existing SAP NetWeaver TREX search engine features

InfoPackage InfoPackage An SAP NetWeaver BI object to facilitate the load from a source system to PSA only

Remodeling toolbox N/a Allows you to redesign SAP NetWeaver BI data targets

SAP NetWeaver Portal

SAP Enterprise Portal 6.0

Provides a roles-based GUI and single sign-on

VirtualProvider VirtualProvider RemoteCube

BW does not manage the transaction data for this type of InfoCube

Write-optimized DataStore object

N/a A DataStore object that allows you to transform large sets of data more efficiently

Table 2 New terms and definitions in SAP NetWeaver 2004s

Process Chains

Many clients now use the scheduling tool called process chains. SAP has enhanced it with added flexibility in SAP NetWeaver 2004s. One improvement lets you evaluate the output result of a system command by looking for specific words or phrases.

For example, when your logic processes the server’s response for a file read request, you could evaluate a response like “file not found” and then branch to a process link that would try to read the file again.

Other significant new features involve more control over the consumption of resources (dialog or batch processes) to ensure that you do not jam your system with a chain that has many subchains or parallel branches. Depending on the type of chain you have, the system lets you schedule the chain as a single dialog process and, for other situations, allows you to calculate the number of batch processes the chain consumes before executing it.

Another new process chain feature is the integration of process chains into Central Alert Framework (CAF). CAF is an SAP NetWeaver feature SAP BW 3.5 first used with Reporting Agent. It permits users to subscribe and unsubscribe to many alerts that you can receive via email, Short Message Service (a phone text message), or a Web link. In SAP BW 3.5, exceptions could use CAF, but now a process failure or success message can alert anyone through the generic CAF toolset.

Authorization and Auditing

Improvements supporting compliance and control are timely with the recent emphasis on the Sarbanes-Oxley Act. Improvements in this area in SAP NetWeaver 2004s include a new reporting authorization concept and change tracking.

The new authorization concept, now called analysis authorization, fixes some issues with the older method (transaction RSSM/reporting authorizations) and includes the following features:

Reporting authorization objects are not limited to 10 referenced objects

You have direct control over authorization for navigation attributes

Complex authorizations provide a union of allowed values

In connection with authorizations, remember that the ability to trace changes to these authorization objects is an auditable activity. SAP NetWeaver 2004s Business Content supports this via RemoteCubes (now called VirtualProviders) and BEx queries that provide reports tracking the authorization objects, number of changes, and who changed user authorizations.

Tip!

In an SAP NetWeaver BI environment, you should still limit the authorizations that drill down to the InfoObject-value level whenever possible. Too many checks at this level slow performance and restrict the information that you can access from the SAP BI system.

Near-Line Storage (NLS)

Archive support for SAP BW was created in SAP BW 3.0 — but with a significant hurdle. If you wanted to report on the archived data, you first needed to return the records to the database (via an enhancement to the data mart extractor). Although SAP still supports traditional archiving, NLS allows you to read NLS data via the query without reloading it to the database.

SAP NetWeaver BI Administrator Cockpit

Since the early days of SAP BW 1.2B, tools above and beyond the core Basis tools monitored and reported on statistics. SAP BW 2.0 improved these tools and provided a comprehensive Excel workbook with many embedded BEx queries reporting from the SAP statistics InfoCubes and MultiProviders. Although this is a powerful toolset, it lacks Web access.

The new SAP NetWeaver BI Administrator Cockpit provides the missing Web access to performance and status

information (Figure 3). The Administrator Cockpit uses SAP NetWeaver Portal (formerly SAP Enterprise Portal 6.0) and iViews derived primarily from existing SAP NetWeaver BI queries.

Figure 3 New Administrator Cockpitclick here to view a larger version of this image

In addition, the Administrator Cockpit can show the CAF alerts discussed in the “Process Chains” section. CAF can in turn link to CCMS issues, such as memory or disk space alerts, and process chains directly or via the CCMS transaction code. Thus, the Administrator Cockpit provides central Web-based access to everything affecting load, reporting, and system issues in an SAP NetWeaver BI environment.

Remodeling Toolbox

The remodeling toolbox is a new toolset to assist in the redesign of SAP NetWeaver BI data targets. In some cases (for example, deleting objects or when you do not need to go back to the source for new fields), you can use this tool to add, delete, or replace new key figures or characteristics in an InfoCube without having to reload all the data from the source again. For new fields, this capability assumes you can come up with the logic of how to derive the new characteristic or key figure.

Navigation/Layout/Organization

Improvements in the area of navigation/ layout/organization include changes to navigation and to the consistency in accessing and creating GUIs.

InfoCube design and GUI now have the same look and feel as DataStore objects. Gone are the days when the GUI for InfoCube design started with InfoObjects on the right side of the screen, and you had to move objects to the left into the InfoCube. Now the left-to-right GUI based on the ODS design is the standard.

The new RSA1 transaction offers better context menus and options; for example, separated tabs now exist for administration functions (e.g., manage, delete, process chains) as opposed to modeling (creating objects). This new organization of paths and menus combines into one-path functions that the same type of BI analyst commonly performs together. For instance, the organizational structure groups data loading tasks separately from data modeling tasks.

GUI to Create DataSources

A new consistent GUI to create DataSources is now available. In the BW 3.5 standard SAP source system, XML, Universal Data Connect (UDC), and Database Connect (DB Connect) data sources had a different look, feel, and

menu path. In SAP NetWeaver 2004s, SAP has standardized these wherever possible. Figure 4 shows the new look of DataSources.

Figure 4 Standardized DataSource creation interface

Business Content and Content Management

Improved Business Content and Content Management are features of the new system. Although the metadata repository browser has been a great tool for many years, access to basic information required you to export the HTML files or access the metadata browser via the back-end GUI. SAP NetWeaver 2004s provides a Web template

with access to the metadata repository with navigation from InfoAreas to InfoCubes and to metadata repository

information for the selected object (Figure 5).

Figure 5 Web template access to the metadata repositoryclick here to view a larger version of this image

In a related area, tools in SAP BW 3.5 were available to help you create custom Business Content. Large companies could sell or use this content internally. SAP NetWeaver BI for SAP NetWeaver 2004s provides new tools to help manage and ensure completeness (i.e., all interrelated objects are defined correctly) for all of this custom content.

SAP NetWeaver 2004s

What’s New in the BI Front End: Part 2  

by Ned Falk, Senior Education Consultant, SAP America

Find out about changes to BEx Suite tools in SAP NetWeaver 2004s. They include improvements to Web-based printing, document management, Information Broadcasting, BEx Analyzer, BEx Query Designer, Web Analyzer, and Web Application Designer.

Categories: BEx, Event and Process Chains, Reporting, Web Application Designer

Key Concept

BEx Web, a component of the BEx Suite, includes the new BEx Report Designer (discussed in part 1) as well as the updated BEx Web Analyzer and BEx Web Application Designer (Web AD). BEx Report Designer creates formatted SAP BI reports for presentations. BEx Web Analyzer allows you to analyze data via a URL or an iView in SAP NetWeaver Portal. With BEx Web AD, you can create Web sites with SAP BI content.

With SAP NetWeaver 2004s, several BEx Suite tools receive updates. On the Web side of SAP BI, the major changes include enhanced Web-based printing and a command generation tool to help you create sophisticated Web pages without writing code. For BEx Analyzer, the first major change in years offers better formatting and design capabilities. Finally, updates to document management and Information Broadcasting cross both the Excel- and Web-based areas of SAP BI.

Note

For more information about the new BEx Suite tools included in SAP NetWeaver 2004s, refer to the first part of this

series, “SAP NetWeaver 2004s: What’s New in the BI Front End: Part 1,” in the April 2006 issue of BW Expert.

Web-Based Printing

SAP NetWeaver 2004s integrates Adobe PDF formats as the primary way to support Web-based printing. This includes printing BEx Web templates and the Web-based reports created with BEx Report Designer (a new SAP NetWeaver 2004s report formatting tool that I discussed in part 1). Many users felt that limited printing features for the Web in previous versions of SAP BW restricted usability of the Web interface. Enhanced printing capability offered in Adobe PDF files allows users to easily print from the Web. Now users may take advantage of other aspects of the Web interface, such as a cockpit format and faster performance compared to BEx Analyzer. You only need a Web browser installed on the client side to use this feature.

Previously in SAP BW 3.x, you could manually embed the output of a BEx Web application in an Adobe PDF (using the Adobe toolset installed on your PC). Or, you could have used an unsupported, SAP-supplied printing method and class developed with ABAP object-oriented (OO) programming. This behind-the-scenes solution generated simple page formatting that you could print out via your Internet browser. With SAP NetWeaver 2004s, SAP integrates Adobe PDF and direct-to-printer output, thus enabling standard PDF formatting options including page sizes,

headers, and footers (Figure 1).

Figure 1 Create Adobe PDF output of BEx queries or query views directly from the BEx Web tool or indirectly via Information Broadcasting

Document Management

Documentation can make or break an SAP BI implementation. If you do not document the metadata with detailed records (such as how you calculate items and where you find InfoCube data), you risk alienating and confusing users over differences between online analytical processing (OLAP) and online transaction processing (OLTP) data. You also should use document management to replace email and phone conversations regarding problems and opportunities.

The major change in document management with SAP NetWeaver 2004s relates to how you can handle documents. In earlier versions, when you accessed the document interface you could view all types of documents, but you could create only text documents. In BW Release 3.5, you could not upload Word files or other complex document types. This limitation disappears with SAP NetWeaver 2004s. Now a new Web-based document browser allows you to display, edit, and create different types of documents. You can initiate the document management GUI from Web Application Designer (Web AD), Web Analyzer, or BEx Analyzer.

Other improvements with document management center on easier access of Knowledge Management (KM) services with documents. These new features include:

Access to and customizing of KM services, even if you store documents in your SAP BI server and not on a dedicated document server (Content Management [CM] standard repository). Your landscape does not need another server to access KM services.

Assignment of documents to hierarchy nodes. This allows analysts to document, for example, information about why they organized hierarchy branches a certain way.

Easier migration of documents residing in SAP BI to CM standard repository. Now you can use older BW 3.x documents with KM document features such as collaboration.

Although in BW Release 3.5 you could have master data, metadata, and InfoProvider documents, you may now

leverage KM services on these documents. Figure 2 shows how you can access KM features no matter where your documents physically reside. For example, say you have a sales document for a customer Computer 3000 and you store this document on the BI server. While previously you had to also store this document in a CM standard repository to access KM collaboration features, you now can access KM features from the BI server.

Figure 2 Access KM features from SAP BI server

Information Broadcasting: BEx Broadcaster

Information Broadcasting with BEx Broadcaster in BW Release 3.5 performed some of the same features as Reporting Agent (e.g., generating Web pages at a predetermined time). Now BEx Broadcaster handles all the

Reporting Agent tasks as well as some new ones (Figure 3). SAP does not plan to develop Reporting Agent further, although as is the case with all BW 3.x tools, it can run on SAP NetWeaver 2004s. New BEx

Broadcaster functions include printing directly to Adobe PDF and multi-channel broadcast to combine other distribution types and formats in one BEx Broadcaster setting. For example, this feature lets you broadcast print and email at the same time from one setting. Previously, one setting could only do one thing at a time.

Figure 3 BEx Broadcaster functions

Note

SAP includes the old BW 3.5 tools as part of SAP NetWeaver 2004s. The old tools are completely separate, allowing business areas to upgrade to new features in a step-by-step manner.

Another new feature is bursting, which gets its name from the old process involving huge paper-based reports that you manually had to separate (burst — e.g., by country), then mail to the physical address of the sales manager for the country. With bursting in BEx, you filter once for each sales manager and email a Web link or completed output

(Web or Excel workbook) to him or her (Figure 4). Each manager receives the appropriate material, but you do not need a formal authorization scheme as you did for BW 3.5.

Figure 4 Bursting with Information Broadcasting allows you to filter for sales manager by country, then send your report via email

Note

When you broadcast via the portal, you have KM features available even if you do not store the document in a dedicated KM content repository on a different machine. This means that you do not need a separate KM system.

BEx Analyzer

The improvements to this Excel-based interface focus on how you design workbooks, making the design similar to that of a BEx Web application. The features are best divided between design mode and analysis mode.

In design mode (Figure 5), you create a workbook with visual and navigation elements. Drag design elements including tables, buttons, exceptions, conditions, and drop-down boxes to the layout area, just as you do with Web AD. Then, assign data providers to feed query data to these design elements.

Figure 5 Excel-based design mode. Drag elements from the toolbar on the left to the Excel grid on the right.

Besides the general layout options afforded by the new design methods, you can automatically and uniquely assign Excel formulas to every data cell. You have dedicated formatting options for each cell that are similar to the options

included in the new BEx Report Designer. Figure 6 shows some formatting possibilities. With these capabilities you may not need to use third-party formatting tools.

Figure 6 Formatting possibilities in Excel with the new BEx Analyzer design methods

In analysis mode, you can change navigation with the new drag-and-drop method (e.g., swap columns or replace one characteristic with another). This combined with navigation buttons you can add in design mode means that you should not need Visual Basic/.NET code to analyze data.

Note

Refer to help.sap.com documentation for layout limitations involving two structures. Go to BI Suite: Business Explorer>Query Design: BEx Query Designer>Analysis & Reporting: BEx Analyzer>Design Mode>Working in Formula Mode.

BEx Query Designer

BEx Query Designer looks very different in SAP NetWeaver 2004s, offering easier-to-access settings (Figure 7). You

can reorganize sections, giving you a custom look and feel. The new Default Values section limits the initial data included in the report. Unlike a filter, you can navigate to other values if you need to after you execute the query.

Figure 7 The updated BEx Query Designer. Notice the new Default Values and Properties areas.

However, if you set restrictions in the Default Values section, the system only provides an initial (yet changeable) set of data. You could ask for more data via subsequent navigations, because the characteristics in the default section appear as free characteristics in the output to the user. For example, a default for country US allows an end user to ask for Germany (DE) during navigation, whereas a filter for US prevents the end user from selecting any other country except US. In prior releases this functionality was only possible through a variable setting that allowed subsequent navigation. BEx Query Designer has other features that improve usability, including wizards to create conditions and exceptions.

The Properties window is also new. When you click on objects in the other panes, the Properties frame changes and displays the options available to you for those objects. The center pane toggles between the Filter or Rows/Columns by clicking on the buttons at the bottom of the pane, highlighted in Figure 7. Characteristic

Restrictions in the Filter section work the same as they do in BW 3.x — they completely restrict the data available to the user.

Tip!

Although the latest release of BEx Query Designer is easier to use, I still do not recommend that end users develop queries. Instead, power users should handle the primary query design in the functional areas of the business. Web Analyzer and views should cover any ad hoc user needs not covered by queries created by power users.

Web Analyzer

Web Analyzer, a Web-based tool for analysts, was introduced in SAP BW 3.5. In SAP NetWeaver 2004s, Web Analyzer works with KM features to create and save complex analyses more easily using only a Web browser. Although the average user may use this tool as the primary way to obtain Ad Hoc Query analysis, analysts who work

primarily in the Web environment can find and execute queries not assigned to their roles. In addition, analysts without formal query design authority can create quick custom queries without needing to consult a power user.

Improvements involve drag-and-drop query design on the Web (though not as sophisticated as with BEx Query Designer), wizards for exceptions and conditions, and easier saving of query views for later use. Integration between SAP BI and SAP NetWeaver Portal allows you to save the results of Ad Hoc Query analysis in your personal portfolio.

Web AD

Although Web AD experienced no major changes to the look and feel, it is now easier to drill down on an area, then filter by a specific criterion. Your Web cockpits become more intuitive by integrating command buttons and tabs that allow you to navigate with a wizard, avoiding the need to add command syntax to get the report results you desire. For example, you could drill down on country and then filter on customer 1000 by using just the command buttons and tabs in the wizard.

In SAP NetWeaver 2004s, these commands are available to build from menus integrated in the design mode of Web AD. A wizard walks you through the functions you want the button to perform and then writes the code. Additions to Web AD include new Web items, more chart types, and drag-and-drop table item navigation (now called an analysis Web item).

Note

For more information about these new features, as well as hands-on experience, refer to the upcoming SAP NetWeaver 2004s delta classes offered by SAP. In the US and Canada, these courses include DBW70E “Extraction and Back End Delta,” DBW70P “SAP BI Planning Delta,” and DBW70R “Reporting and Front End Tools Delta.” Outside of the US and Canada, these courses include TZBI7E “SAP BI — Enterprise Data Warehousing (Delta SAP NetWeaver 2004),” TZBI7R “SAP BI — Enterprise Reporting, Query, and Analysis (Delta SAP NetWeaver 2004s),” and TZBI7P “SAP BI — Enterprise Planning.”

SAP NetWeaver 2004s What’s New in the BI Front End: Part 1  

by Ned Falk, Senior Education Consultant, SAP America

Learn about the new BEx Report Designer and BI Integrated Planning included in SAP NetWeaver 2004s and see how they fit into the SAP NetWeaver BI data output landscape.

Categories: Analytics, BEx, BI Integrated Planning, Reporting

Key Concept

The BEx Suite consists of reporting and analysis tools to help you create formatted reports (reports with a specific design) to distribute SAP BI data to the decision-makers in your company. You can use these reports both online and offline and even transfer them to PDA

SAP NetWeaver 2004s includes two new front-end tools for the BEx Suite, BEx Report Designer and BI Integrated Planning. BEx Report Designer allows you to create formatted reports (reports containing design and style elements)

that you can access via the Web. Examples of formatted reports include income statements for tax forms that contain specific fields in a particular layout.

The other new tool delivered in SAP NetWeaver 2004s, BI Integrated Planning, replaces BW-BPS. This changes the way you perform planning at your company, whether it’s sales planning, profit center planning, or another type of financial planning. You no longer need to have multiple Excel spreadsheets circulating through management levels. This tool leverages SAP BI InfoCubes to store plan data and SAP BI front-end tools to enter and present it.

Figure 1 provides an overview of the new and improved BEx tools SAP NetWeaver 2004s offers. Part 1 of this series contains information about the two new tools. In part 2, I will explain enhancements to existing BEx Suite tools in the SAP NetWeaver 2004s release.

Figure 1 Overview of BEx Suite update in SAP NetWeaver 2004s

Note

For information about the new SAP BI back-end features offered with SAP NetWeaver 2004s, refer to my article, “SAP NetWeaver 2004s: What’s New in the Back End,” in the January 2006 issue of BW Expert.

BEx Report Designer

An enhanced formatting tool, BEx Report Designer allows you to create reports with blank cells, characteristic value-based shading, and colored cells.

You can also incorporate titles, headers, footers, and other stylized output into your reports. This provides Web-based flexibility to meet the formatting needs of both internal (users within your company) and external (customers, industry groups, government agencies) report recipients.

Formatting options are the key BEx Report Designer features. Compared to other SAP data output software, you have less control over navigation features (although you can reduce the data set through filtering), but more control over the look and feel of a report. BEx Report Designer provides formatting options that are not possible with Web Designer or with Excel (BEx Analyzer). These options include headers, footers, and page breaks, as well as fonts and colors. You may also include text, charts, and pictures in your reports with BEx Report Designer.

Table 1 provides an overview of the various SAP software programs available for creating SAP BI reports. You can use this table as a guide when deciding which software to use for your reports. For example, if

you want to create a report in which users can drill down to various items, you might want to use BEx Analyzer. Conversely, if you want to generate a sharp-looking report with high-level data for a manager, you may want to use BEx Report Designer.

SAP software for SAP BI data output

GUI Analysis navigation capabilities

Information sources

Formatting capabilities

BEx Analyzer

No thin client; needs Excel XP

Extensive addition to Excel features

SAP BI sources (InfoProvider) and third-party providers directly)

Somewhat extensive; new features for BEx Analyzer allow for many more formatting features

Web Analyzer

Thin client (Web browser)

Many navigation options, customization possible, but better left to the Web designer

SAP BI sources Very limited; SAP controls data table format

BEx Report Designer

Thin client (Web browser)

Limited SAP BI sources Extensive; add colors, headers, and footer cells

Web Designer

Thin client (Web browser)

Extensive; new buttons make complex designs much easier

Mostly SAP BI sources (programming needed for others)

Very good layout options for Web items; detailed formatting for individual Web items

Visual Composer

Thin client (Web browser)

Medium; depends on underlying data source.

Through Java-based connectors access to almost all possible sources of data, including SAP BI

Good; a custom Web application design tool in which you can implement Web coding for total design control. Non-code-based solutions have limited formatting.

Table 1 SAP BI analysis tool comparison

BEx Report Designer is not an Excel-based tool, but rather a Web-based tool that uses Java Runtime. In BW 3.5 and below, you needed to know ABAP to change a table’s design. BEx Report Designer provides a non-code-based solution, to improve the look of an analysis. Again, this is for Web-based output, but in the next article, I will cover

improvements for Excel-based output as well. Figure 2 contains a sample report created with BEx Report Designer. You can add colors and titles, but the navigation options provided via the Filter link are limited.

Figure 2 Web-based BEx report output on the Webclick here to view a larger version of this image

Note

With Java Runtime, the new SAP NetWeaver 4.0s Web templates no longer support the ABAP table interface tool.

Although I will discuss the enhanced printing (BEx Information Broadcasting) features in part 2, you should know that SAP NetWeaver 2004s permits you to easily link BEx reports to the integrated Adobe PDF printing solution. Also, you

may execute reports overnight to distribute early the next day via email and SAP NetWeaver Portal (Figure 3).

Figure 3 BEx Report Designer input and output options

Complete integration exists between BEx reports and BEx Web Application Designer (Web AD). You may insert multiple BEx reports via the new report Web item. This allows for a complex cockpit of information in a BEx Web template with a highly formatted data table in the cockpit.

BI Integrated Planning

SAP NetWeaver 2004s also includes the new BI Integrated Planning, which allows you to forgo Excel-based financial and sales planning and move to cross-functional integrated planning on top of InfoCubes. Although SAP included Business Planning and Simulation (BW-BPS) for planning functions in the prior BW 3.5 release, there were issues of consistency with other SAP BI tools and ease of use. BI Integrated Planning has nearly the same functionality as the old BW-BPS, but consistency with standard BEx tools makes it a much better solution.

Note

BI Integrated Planning was one of the main benefits of moving planning out of Strategic Enterprise Management (SEM) and into SAP NetWeaver Enterprise Services Architecture (ESA). Now one management team can focus on developing both the planning and analysis tasks of SAP NetWeaver BI.

Note

For more information about how BW-BPS and BI Integrated Planning differ, read Karen Comer’s “What You Should Know About Planning With SAP NetWeaver BI” at https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2919.

Prior to the introduction of BI Integrated Planning, you needed to learn two different toolsets — one for planning and one for analysis — although many areas within the two toolsets performed similar functions. The new BI Integrated Planning tool provides one tool set for both planning (user/automated data input and manipulation) and analysis. Using one instead of two toolsets speeds up your implementations and requires less work in the long term.

In BI Integrated Planning, the concepts and data storage with transactional InfoCubes (now called real-time InfoProviders) remain the same as in BW-BPS. Also, the goal of both the BI Integrated Planning and BW-BPS tools is a targeted planning input screen for the user.

It is the method of achieving this goal that is new. The design environment (where you develop planning applications) has changed completely (Figure 4). For example, it is now Web-based and tightly integrated with BEx tools. With this

new design come new terms (Table 2).

Figure 4 SAP NetWeaver 2004s BI Integrated Planning compared to BW-BPS

New term

Old termNew term’s definition

Real-time InfoProvider

Transactional InfoCube

InfoCube designed for direct plan data loading

Filter Planning package The data a planner plans in one planning session

Input-enabled BEx Queries

Manual planning layout

The entry screen for planning

Aggregation level Planning level A high-level slice of an InfoCube’s data to support SAP-delivered planning tools

Table 2 New terms and definitions introduced with BI Integrated Planning in SAP NetWeaver 2004s

The development environment for planning is now all Web-based. Using a browser-based GUI, a planning modeler sets up the planning environment, but includes only the elements uniquely connected to planning, such as data selections (aggregation levels and filters) and planning functions and sequences. The BEx toolset in SAP NetWeaver 2004s now handles output options and data entry screens previously handled by BPS-specific functionality. These include BEx Query Designer, BEx Analyzer, and Web AD, which I will discuss in more detail in part 2 of this series.

While some terms have changed, most of the functionality and concepts are the same. Concepts of data slices, characteristic relationships, SAP-defined planning functions, user exits, and formula extensions (FOX) have the same meaning and purpose. Although the concept of locking remains the same from a business perspective, the technical implementation has changed with more display options and

features. The new design reuses the standard BEx toolset for manual planning input and uses process chains to schedule planning functions and planning sequences.

Note

You can use standard BEx variables in step 1. For example, if you use variables in the planning model design, you can limit the number of objects you need to make (as you do in query design). With a planning input query that automatically changes values based on who is planning, I can eliminate 100 hard-coded versions that are specific to one planner.

The three basic steps for implementing a planning project are the same.

Step 1. Model the planning environment. First, define the aggregation level (previous planning level) to connect to a real-time InfoProvider. Then, define data slices (a subset of an entire dataset) to lock out data from accidental changes. Next, define filters for specific characteristic value combinations for planners to limit the data involved in planning a task. Finally, when necessary, create planning functions to automate planning tasks.

Step 2. Create a user interface. In this step, you enter plan data and execute user-initiated planning functions. Build input-enabled queries off aggregation levels and use filters to limit the planned data. Make sure to use BEx variables where necessary. For example, the filter could depend on an authorization-filled variable. This would dynamically limit the data for each planner differently if necessary. Then build Excel workbooks and Web pages with these input-enabled queries. You can even incorporate buttons to execute planning functions (like macros) and planning sequences (multiple, linked planning functions).

Step 3. Automatically create and execute process chains containing planning functions and sequences. New SAP NetWeaver 2004s process types allow you to switch real-time InfoCubes from planning mode to loading mode. In some planning system designs, the system loads an InfoCube with data from source online transaction processing (OLTP) systems. Then the system switches the InfoCube to allow direct input of the plan data. Previously, you had to schedule the switching function and run it with ABAP tools. These steps are automated with the SAP BI process chain toolset. They also permit you to execute planning functions and sequences, another new feature.

Note

For more information about these new features, as well as hands-on experience, refer to the upcoming SAP NetWeaver 2004s delta classes SAP offers. These courses include DBW70E (“Extraction and Back End Delta”), DBW70P (“SAP BI Planning Delta”), and DBW70R (“Reporting and Front End Tools Delta”).

SAP NetWeaver BI 7.0 Discover New BEx Themes and Excel Formatting Options  

by Ned Falk, Senior Education Consultant, SAP America

Find out how to apply themes to your BEx Analyzer workbooks. In addition, see how you can use advanced Microsoft Excel options to further format your workbooks.

Categories: BEx, Reporting

Key Concept

The themes formatting option for BEx Analyzer is modeled after the themes feature in SAP NetWeaver Portal. Themes allow you to separate the color and font scheme from the design elements of your workbook, such as buttons and tables of data. This means that you can have a different color scheme for an individual while keeping the basics of the workbook design the same for everyone.

SAP NetWeaver BI 7.0 provides expanded options for formatting and reusing formatting in both the Web and Microsoft Excel (BEx Analyzer) worlds. In this second part of my three-part series, I address a new use for custom collections of styles called workbook themes. I also discuss Excel formatting, including the new formula mode. I did all my testing on release level 70015.

Note

In part one of this series I discussed styles in connection with default workbooks. In part 3 I will discuss the Web and its formatting options.

Themes

Just as styles are collections of formatting options, themes are collections of styles stored in a group, or theme name, on the SAP NetWeaver BI server. Normally administrators or experienced Excel people modify the styles, but instead of connecting the modified styles to a default workbook, you can create a theme for them and save them on the server.

Users allowed to save workbooks can select different themes to target different groups with differing color schemes. This control over styles does not affect the overall design because themes do not control the design elements, such as buttons or logos. These users can retrieve the styles and assign them to any workbook, thus overwriting the settings for any styles on the existing workbook. It doesn’t matter if the workbook started as a corporate default workbook or SAP’s delivered default.

The steps to create and use BEx themes are:

Step 1. Modify SAP-provided styles on a workbook

Step 2. Create a theme

Step 3. Load the styles from the workbook into the theme

Step 4. Apply the new theme to future workbooks

Step 1. Modify SAP-provided styles on a workbook. As I described in part 1 of this series, open the SAPBEXS.xla workbook and change your styles to identify good and bad data exceptions. When you click on a cell, the name of the

style appears (Figure 1). Select the cell you want to change, then go to Format>Styles to change the SAP-supplied style.

Figure 1 SAP’s style example workbook (SAPBEXS.xla)

Step 2. Create a theme. After a workbook is active in the system with the styles you want, it is time to create your theme. You do not have to use the SAPBEXS.xla workbook to generate a theme, but using this workbook allows you to see all the style choices in one place without a query containing exceptions and highlighting. From the BEx design

tool bar, click on the workbook settings icon and then click on the Themes tab (Figure 2).

Figure 2 Workbook settings in the Themes tab

Click on the New button and create a theme that uses the naming conventions of a letter in the beginning and all caps. In my example, I created the theme VI_THEME, which represents a theme for visually impaired users. Click on the OK button to save your theme.

Step 3. Load the styles from the workbook into the theme. In the Workbook Settings screen, highlight your new theme and click on the Apply button to load the styles from the current workbook to the theme (Figure 3). A pop-up

screen appears to let you know the loading was successful. Click on the Save button to save your theme to the SAP NetWeaver BI server so that other users can select and use it. Another pop-up screen appears to let you know that the system saved your themes successfully.

Figure 3 Apply your styles to the new theme

Step 4. Apply the new theme to future workbooks. In this step you update the styles for the future workbooks via a theme, but you do not affect their overall designs. Access the Theme tab for your new workbook as you did in step 2 (Figure 2) and select Reapply Theme Before Rendering. This overwrites all the styles on the existing workbook with the same names as those contained in the theme. For example, say the VI_THEME theme has the SAPBEXexcBad9 style surrounded by a border and the SAPBEXexcGood1 style surrounded with a dot pattern. The border setting quickly changes to reflect the styles in the VI_THEME settings. The Apply New Styles option adds the styles contained in the theme that are not already in the workbook and does not overwrite the ones that are already there.

Excel Formatting

Now let’s move on to more formatting options for BEx Analyzer. This section requires Excel knowledge rather than SAP skills. If you use Excel for formatting, the system does not tag the cells of the analysis item with an SAP- provided style (e.g., SAPBEXexcBad9). Instead you tag the cells with styles or format them using Excel features.

To format in Excel, click on the design mode icon from the BEx Analyzer tool bar (Figure 4). With your cursor in

the desired workbook sheet, click on the analysis mode icon to access the item’s properties.

Figure 4 Icons used with Excel formatting in BEx Analyzer

Go to the General tab shown in Figure 5 and uncheck Apply Formatting to disable SAP NetWeaver BI’s control over formatting via SAP-supplied styles. After you do this, the output of the analysis table is simple numbers on a normal Excel style of black on a white background. Now you can use Excel styles, or directly format cells, without SAP’s style overwriting them.

Figure 5 Analysis item properties

Other Excel Features for BEx Analyzer

You can use advanced Excel features, such as conditional formatting. You may also have specialized formatting needs that are not that widespread, and therefore do not require the complexities of a theme. To access the Excel advanced features, go to the Format menu in Excel. Use Microsoft’s Office Assistant (Help>Show the Office Assistant) to find out more about these features.

The only problem you may encounter occurs if you navigate the output using BEx features. The formatting comes exclusively from your workbook, so Excel does not know when you have exchanged a column or a row, and does not have the appropriate SAP styles controlling the formatting. Therefore, the format that you created manually with Excel features remains the same. For this reason, I think this kind of formatting override works best with fixed structures in the rows and columns of the query, or when navigation options are removed from the analysis item and workbook, making this kind of navigation impossible.

New BEx Analyzer Formula Mode

Although it is not a formatting feature, the new BEx Analyzer formula mode works well with the concept of Excel-based formatting. In SAP BW 3.x, and as a default in SAP NetWeaver BI 7.0, the analysis item returns data to Excel from the SAP NetWeaver Application Server (SAP NetWeaver AS) as an entire set. Each query or query view navigation checks with SAP NetWeaver AS and returns the appropriate grid of data.

You have another option in SAP NetWeaver BI. You can use the setting Use Formulas shown in Figure 5 or the corresponding context menu option Convert to Formula on the Excel output. These settings tell SAP NetWeaver BI to send each cell exactly the piece of data it wants. SAP NetWeaver BI then sends the data not as a grid in a collection, but as a cell-specific formula that asks SAP NetWeaver BI for information.

Figure 6 shows an example of the Use Formulas option. In this sheet, each cell has its own formula. The formula for cell F13, =BExGetData(“DP_1”,D$4,$C5), fetches the data from the data provider DP_1 (in this case, a normal SAP NetWeaver BI query). The formula then selects the cell containing Act 2001 (D4), the key figure (D$4), and the

Canadian dollar ($C5). The value shown in cell F13 always reflects the same information, no matter where on the workbook you place it.

Figure 6 The formula mode output. Cell F13 reflects the same data as D5 because they both point to the same underlying formula.

One advantage to the formula mode is that each cell has its own formula and stands alone, which means that you can format each cell and organize these cells anywhere in the workbook you desire. The formula for each cell fetches the appropriate data from the server, while your theme and styles control what the workbook looks like.

Note

For more information about this topic, consider attending SAP Education class BW306 : Enterprise Reporting, Query and Analysis (Part II) for SAP NetWeaver BI 7.0.

SAP NetWeaver BI 7.0 Unlock a World of Formatting with Themes in BEx Web  

by Ned Falk, Senior Education Consultant, SAP America

Find out the eight steps to design a query using BEx Web in SAP NetWeaver BI 7.0. Along with explaining how SAP NetWeaver Portal is now part of the process, these steps introduce new concepts, such as themes, portal desktops, and BEx Reports.

Categories: BEx, Reporting, SAP NetWeaver Portal

Key Concept

Cascading Style Sheets (CSS) is a standard internet technology that enables Web-based formatting. Used with HTML, CSS allows designers to have more control over the output of their reports when compared to the formatting options in BEx Web Analyzer, the Excel-based option for query design. You can use CSS to determine formatting options, such as color and object placement. Furthermore, you can use multiple links to separate CSS pages on a single HTML page, allowing you to have one style for print and one style for on-screen viewing. Although CSS is the underlying technology, SAP often incorporates it through tools found in SAP NetWeaver Portal, Web, and BEx Query Designer.

Previously in this series, I introduced you to new Excel-based formatting options for BEx. Now let me show you the new formatting options for Web-based BEx output in SAP NetWeaver BI. This type of output lets you view query results from any Web browser.

In SAP BW 3.5 and earlier, you controlled the formatting options by linking the BEx Web template directly to Cascading Style Sheets (CSS). In SAP NetWeaver BI 7.0, SAP NetWeaver Portal takes over the function of assigning the style sheets through portal themes, which ultimately drives the Web output format. This makes it easier for administrators to keep a consistent look and feel across the whole user experience, regardless of the Web template author.

However, to format the Web output, you need to use two Web technologies: HTML for content and CSS for formatting. Although CSS is the underlying technology for formatting, SAP NetWeaver Portal packages CSS under portal themes. This means that end users never work with CSS.

Note

For more information about formatting options available with BEx Web Analyzer in SAP NetWeaver BI 7.0, refer to my first two articles in this series: “Everything You Need to Know About Formatting Part I: BEx Analyzer and BEx Query Designer” (Volume 6, Number 2) and “SAP NetWeaver BI 7.0: Discover New BEx Themes and Excel Formatting Options” (Volume 6, Number 3). You can find these articles in the BW/BI Expert knowledgebase at www.bi-expertonline.com.

Themes change the output of the tagged object on the BEx Web template. This means that a BEx Web template on my portal might have pink subtotals and blue data rows, while on your portal the subtotals are green and the rows are purple. You can find the themes in the portal desktops, which include layout features as well as style options. SAP NetWeaver Portal (not CSS) rules define the logic of which theme is available and the default theme for each portal user.

Here are the eight steps you need to take to customize your Web-based BEx query results. Note that this article assumes working knowledge of Web Application Designer (Web AD). The first six steps explain how to set up the formatting for BEx Web. Steps 1 through 5 relate to BEx Web templates, while step 6 refers to the new BEx Report. The final two steps target how you can use the themes. These steps fall under the portal administrators’ domain, so I’ll just mention them briefly. If you are unfamiliar with CSS, refer to the sidebar “CSS Basics”.

Step 1. Modify the underlying style

Step 2. Change the settings for exceptions

Step 3. Change the output in the CSS Style tab

Step 4. Apply CSS syntax for advanced formatting

Step 5. Modify the style commands for specific BEx Report areas

Step 6. Select the portal theme

Additional steps for the portal administrators are:

Steps 7 and 8. Link the portal theme to a desktop/Assign the desktop to the user

Note

Style rules can be on the page, directly attached to the HTML code, or linked to the HTML code via a style sheet stored separately from the page. Given this, the steps in this article all change the style rules, just via different methods.

Step 1. Modify the Underlying Style

First you need to modify the style associated with specific cells or structure elements (e.g., rows or columns) using limited SAP NetWeaver BI query settings. This step involves setting the key figure properties to Highlighted Display

(Figure 1), which I explained in the first article of this series. The Highlighted Display setting changes the selector, and thus the default format that the portal theme applies to the HTML code. This alters the underlying CSS class assigned to this key figure. Subsequently, you can change the actual output format in the Web by adjusting the defaults for this style (via themes in step 6).

Figure 1 Change the query key figure properties to Highlighted Display

Step 2. Change the Settings for Exceptions

These settings alter the way the system displays the exceptions. SAP NetWeaver BI 7.0 offers many options for visualizing exceptions via the Web. In previous releases of SAP BW and in BEx Web Analyzer, you could highlight exceptions only with colors. In BEx Web Analyzer in SAP NetWeaver BI 7.0, you can use symbols instead, as Figure

2 shows. In this example, the up arrows indicate good exceptions (higher than the expected sales volume). The down arrows indicate bad exceptions (lower than the expected sales volume). The right arrows indicate marginal exceptions (sales that are close to what you expected but trending badly).

Figure 2 Exceptions indicated by arrows

SAP NetWeaver BI 7.0 provides two ways to change the exception output to symbols in BEx Web Analyzer. The first method involves the exception wizard, which you can use if you created the exception using the exception wizard. The second method involves changing the exception properties, which you should use in other cases when the Web template designer is the driving factor in deciding to use symbols.

For this first method, access the exception wizard in the BEx Web Analyzer Settings tab, located on the right side of the Web Analyzer. In step 4 of the wizard, click on the Add button for the exception Web item and select Symbol for

the visualization (Figure 3).

Figure 3 Exception wizard for the visualization of exceptions

The second option to configure symbols is using a setting on the Analysis Web item, which you use to build the Web template in Web AD. The item’s Data Provider must obtain data from a query with exceptions to use this method.

Figure 4 shows the Analysis Web item properties for ANALYSIS_ITEM_1. You can select symbols, colors, or other options during the design of the BEx Web template when using Analysis Web items.

Figure 4 Change the Analysis Web item to show exceptions as symbols

Step 3. Change the Output in the CSS Style Tab

CSS allows you to assign formatting style rules to the HTML template easily without needing to know all the syntax. To access these options, insert the HTML table into your layout view of the BEx Web template, right-click on the HTML item, and then click on the CSS Style tab (Figure 5). Then click on the style that you want to change

(backgroundColor in my example) and directly enter your revision (RED in my case).

Figure 5 CSS style commands

When you change styles in Figure 5, your SAP system generates the CSS code behind the scenes and adds the code to the Extensible Hypertext Markup Language (XHTML) code on Web AD. (Note that XHTML code is just HTML code plus some additional allowed tags.) Although you do not need to know CSS syntax to change the style rules, it’s easier if you know a little CSS syntax, which allows you to enter your style rules directly. I’ll discuss how to do this next.

Note

To find out more about the BEx Reports and Web AD, consider attending the SAP Education BW306 class “BI - Enterprise Reporting, Query and Analysis (Part II)” for SAP NetWeaver BI 7.0.

Step 4. Apply CSS Syntax for Advanced Formatting

In this step, you use style commands inside your BEx Web template to override the defaulted look and feel of the Web items or other HTML tags. The direct access to the code provides complete access to the vast formatting options in standard CSS. You can also add watermarks, make objects blink, or change more basic formatting features.

However, with a little knowledge of CSS syntax, you can apply the rules directly to the XHTML code in Web AD’s design screen (e.g., style = “BACKGROUND-COLOR: red”), as shown in Figure 6. To learn more about the CSS

syntax options, refer to http://w3schools.com/css/css_reference.asp.

Figure 6 The XHTML code including style commands

Step 5. Modify the Style Commands for Specific BEx Report Areas

In SAP BW 3.5, you had only one tool to customize Web pages with BW data — Web AD. SAP NetWeaver BI 7.0 offers the new BEx Report, which allows you to change the color, row size, column size, and cell placement, as well as to add additional body text, cell text, headers, and footers to specific areas of your report output. The system executes all these options via style rules behind the scenes.

Figure 7 shows the design screen for BEx Report. Access this screen by following menu path Start>Programs>

Business Explorer>BEx Report Designer. This GUI allows you to format columns, cells, background colors, and totals. You can also add other features to improve the look of the report.

Figure 7 BEx Report design GUI

Step 6. Select the Portal Theme

As I mentioned, portal themes use CSS as their underlying technology. Figure 8 shows a user employing

BI_THEME_A. By clicking on the Personalize link, you can select a theme from the list. This allows you to easily change the look and feel of your portal experience.

Figure 8 Select a theme

This user also has a default framework page that contains the layout for the iViews and high-level links. Both the theme and default framework page are linked in a portal desktop, which I’ll discuss in the next step.

Steps 7 and 8. Link the Portal Theme to a Desktop/Assign the Desktop to the User

You can review the concepts for modifying the look and feel of the portal and the SAP NetWeaver BI content in the document, “How to Create a New Portal Desktop,” which you can find on the SAP Developer Network (SDN) at www.sdn.sap.com. Enter the title in the Search box to download the document.

My focus is more specifically on how to change themes to affect the format of SAP NetWeaver BI objects. Figure 9 shows the theme editor and the Analysis Web item (e.g., tables). Portal administrators use this theme editor to change the underlying style sheet. The administrators normally start with an SAP-supplied theme, copy it, and then change the copy. In this example, I show how the portal administrator can change the color for a given exception, which in this case is a bad exception.

Figure 9 Change the color of a bad exception to dark blue (#F66767)

The next step is to find the object category for which you want to change the default. Select the object category from the list on the left side of the screen in Figure 9. In my example, I want to change the Tables section within the grouping Complex Elements. This table section refers to data tables, including the Web Analysis item.

Click on the Options link next to the value you want to change. In my case, I changed the Color of Bad Value

(Dark) to dark blue (#F66767). Figure 10 shows the updated theme.

Figure 10

The bad exception appears as dark blue

You have three options to connect the CSS rules to your HTML code. You can assign CSS style rules to each component of the HTML output directly or via a CSS styling rule connected to a selector that is defined on the page (as in my example). For either of these options, you can enter the code on the XHTML tab in Web AD.

However, the third option is best. For this you use a separate style sheet linked to your HTML code page with the following syntax:

These two lines of code link to your style sheet with all the rules. The HTML code then obtains the style rules (e.g.,

selectors and declarations) as listed, one after each other, on the YOUR STYLES SHEET.CSS style sheet. These control how the system displays each tag to the user.

Note

To learn more about the underlying technology of CSS, refer to www.w3.org/style/CSS/learning. You can also read chapter 2 of the book Cascading Style Sheets, Designing for the Web, by Håkon Wium Lie and Bert Bos (Third Edition, 2005, Addison Wesley Professional, ISBN 0-321-19312-1).

In some cases, another CSS feature called inheritance might be called into action. With inheritance, if you have a set of styles on a separate CSS sheet that makes H1 red, and your page has H1 as green, the system chooses the style closest to the actual HTML code, so the output is green. This is a nice feature built into the underlying technology of CSS. It allows query designers to overwrite corporate standard colors and formats if necessary.

CSS Basics

To better understand CSS, let’s look at an example. Figure 1 shows the HTML code and corresponding output. This is a simple page but it includes HTML tags and embedded CSS style rules. On this page the CSS syntax is the line. CSS uses terms such as selector (e.g., H1 and H2) and declaration, which its property (e.g., color) and value (e.g.,

blue) define.

Figure 1 HTML code with a style command

SAP NetWeaver BI 7.0 Design in No Time with New BEx Analyzer Control Objects  

by Anurag Barua, Manager, SAP Application Support, The Washington Post

Find out how to implement the new BEx Analyzer slice-and-dice features in SAP NetWeaver BI 7.0.

Categories: Analytics, BEx

Key Concept

BEx Analyzer in SAP NetWeaver BI 7.0 allows users to insert control objects, such as check boxes, buttons, and drop-down menus, with simple drag-and-drop functionality. The ability to use these control objects adds value to interactive end-user analysis, especially for ad-hoc querying.

BEx Analyzer looks significantly different in SAP NetWeaver BI 7.0 compared to its predecessor in SAP BW 3.5. For instance, this release offers control objects that you can drop into your Microsoft Excel worksheet to create and analyze queries. Let me show you how to add these controls. In the interests of space, I’ll look at two of them: the drop- down menu and the radio button group. Then I’ll show you an important Visual Basic setting that you need so you can ensure that the queries and filters run properly.

Note

Ned Falk’s article, “SAP NetWeaver 2004s: What’s New in the BI Front-End: Part II,” (Volume 4, Number 5) introduced you to the concept of adding design items and controls in BEx Analyzer. This article provides a deeper look at the updated design and analysis modes available with SAP NetWeaver BI 7.0.

When you open a query in BEx Analyzer, you are in analysis mode. Three buttons appear at the top: Chart, Filter, and Info. I prefer to use the Filter view because it’s easier to add control objects to the query from this view. Figure 1 displays the Filter view for an open accounts receivable (AR) amounts query, which shows data from InfoCube

0FIAR_C03. The various examples in this article use this AR query.

Figure 1 Query Filter view in BEx Analyzer

Click on the toggle design mode icon to switch from analysis mode to design mode to develop your query. In this screen you see a graphic that represents the analysis grid that displays your query results (Figure 2). On the left side of the screen I arranged two toolbars as one contiguous strip — one for BEx Analysis and one for BEx Design. To

add controls, use the BEx Design toolbar, which includes the control objects to analyze query results (Figure 3). These control objects give you more flexibility to analyze your data than the traditional drag-and-drop method in BEx Analyzer or the predetermined filter values in BEx Query Designer.

Figure 2 Filter and analysis grid in design mode

Figure 3 Available design controls

Add a Drop-Down Menu

You can use a drop-down menu to filter your query by the customer InfoObject (0CUSTOMER) values, which in turn allows you to filter your result set more quickly. In design mode, click on the desired location on your worksheet, and then click on the drop-down menu icon to place it in the worksheet. Next, click on the icon to access the properties box in which you set the properties for your drop-down menu. Figure 4 shows the properties box with three tabs:

General, Dimensions, and TargetDataProvider.

Figure 4 Set the drop-down menu properties in the General tab

On the General tab, keep the default DATA PROVIDER_1 for the Data Provider. The Range reflects the cell coordinates in which your drop-down menu resides. If you prefer a different cell or would like to change the dimensions, you can do it in the Range box. Keep the current range (column C, row 32). If you select the Display Label check box, the system displays the filtering characteristic when you run the query. Now, let's look at the

Dimensions tab (Figure 5).

Figure 5 Specify the filtering characteristics in the Dimensions tab

Next, you need to specify the filtering dimension (characteristic) for your query results. I selected Customer. You can also set the Text Type you want to see for the characteristic. If you are not sure, select the Default Text option because your master data may not have all the texts (short, middle, and long). If you select Short Text when the characteristic does not have it available, you won’t have any values to select in your drop-down menu.

For the Read Mode, you have three options: Posted values (Q), Dimension table (D), and Masterdata table (M). Although a discussion of the pros and cons of using each of these methods is beyond the scope of this article, I recommend that you use the D option because your primary purpose is filtering.

Finally, set the display type for your drop-down menu by selecting one of the four options in the Display box. Dimension values tend to make more sense when the system displays text (such as John’s Flower Shop) instead of a key (such as 100689750). If you want to display both, you can select either the Key and Text or Text and Key options. After you click on the OK button, your drop-down menu is ready for filtering.

Click on the toggle design mode icon again to switch to analysis mode. Your drop-down menu appears in column C,

row 32 and you are ready to filter your query results on the customer characteristic. Figure 6 displays the filtering results for a particular customer along with a free characteristic fiscal year/period added to the drill down. Note that the system carries out this filtering in real time — the system returns the filtered results immediately after you select a value from the drop-down menu. You can also manually enter the master data value in the drop-down field instead of selecting one from the list. The system then filters the data based on the value you entered.

Figure 6 Drop-down menu and filtered results in analysis mode

The results on the analysis grid, highlighted in Figure 6, change based on the value you select for the filter for the customer characteristic. To change the value, click on the drop-down menu for Customer and select the desired filtering. Note that after you select a particular value from the drop-down menu, the system does not display the filtered output in the analysis grid. You must click on a cell (any cell) in your worksheet to view the output.

Add a Radio Button Group

The process to add a radio button group is similar to adding a drop-down menu. Even though adding a radio button group is not really needed for the AR query, I will show you how to do it. You should only add a radio button group when you have a small list of values from which to choose. The entire list of characteristic values is displayed on the worksheet, so it may not be aesthetically appealing to add one if you have numerous values.

I am going to add a radio button group for filtering on fiscal year/period. Although this is not the most relevant reason for adding a radio button group, it serves the purpose of giving you an idea of what this type of filtering looks like. Keep in mind that with a radio button group, you can select only one value at a time. You should not use this control if you want to filter on multiple values simultaneously.

Click on the toggle design mode icon to switch back to design mode and drop the radio button group control from the toolbar to the design pane. When you click on the icon, it takes you to a similar Properties pop-up screen as the one for the drop-down menu in Figure 4. Select the properties as you did for the drop-down menu, except this time select the Fiscal Year/period dimension as the filtering characteristic on the Dimensions tab.

After you set all the properties, toggle to analysis mode to see the values listed on your worksheet — posted values if you selected Q, dimension values if you selected D, and master data values if you selected M for the Read Mode option in the property maintenance Dimensions tab. You are now ready to filter on the fiscal year/period

characteristic by selecting the appropriate radio button (Figure 7).

Figure 7 Radio button group for filtering

Your new radio button group filter acts in conjunction with your previously added drop-down menu filter. For example, if you select Jerry Seinfeld as your customer in your drop-down menu filter and Period 10 2005 in your radio button group filter for fiscal year/period, the system filters your query as follows: Display balances for customer Jerry Seinfeld for fiscal year/period 010.2005.

Visual Basic Macros Setting

Your filtering may not work if you don’t have a certain setting for Visual Basic macros. If you are relatively new to these controls, you may not realize why the data is not filtered in the way you expected. In fact, sometimes you may not even be able to add a control in the design mode. At other times, you are able to add a control and set its properties but when you switch to analysis mode, the filtering does not have any effect on the displayed results.

Regardless of where and when this happens, you might see a message at the bottom of the screen saying: There are messages. Double-click to display them. When you double-click, you see a pop-up window that reports Access to Visual Basic Project Failed. Double-click on this message to find out how to fix the error. The system walks you through the procedure to solve the problem, as shown in Figure 8. In this example, the solution is to select

the Trust access to Visual Basic Project check box in the security settings.

Figure 8 Visual Basic security setting for macro enabling

Note

For more information about BEx Analyzer in SAP NetWeaver BI 7.0, attend SAP Education class BW306: BI Enterprise Reporting, Query, and Analysis (Part 2).

Save Time and Resources by Managing Excel Workbook Growth

by Joerg Boeke, Director Business Intelligence, syskoplan AG, Germany

Learn how to clean up BW workbooks. You’ll speed up BEx Broadcaster, conserve resources on your BW server and email server infrastructure, and save time, disk space, and cost.

Categories: BEx, Performance

Key Concept

One major side effect of using workbooks in Excel is the history effect, or workbook growth. Excel creates history traces in its files even if you turn off the change management feature. As a result, your files keep growing when you save the Excel file either locally or on the BW server. The problem does not relate to SAP BW, so this applies to all of your Excel files.

A lot of companies use BW for Sales and Distribution (SD) reporting. Imagine a salesperson not connected to high-speed Internet or dial-in connection. When that person executes a workbook report, the BW server first transmits the workbook and secondly refreshes the data. So whenever he downloads a workbook, he has to wait for the data to refresh. Modifying workbooks creates historical data that consumes lots of system resources. I’ll explain how to get rid of that historical data to speed up your system.

First, I’ll show you an example of how the data accumulates. Then I’ll explain how to isolate huge workbooks that don’t contain a lot of data and how to reduce their size using a third-party tool of your choice. This should reduce the strain on your servers and make BEx Broadcaster run faster.

Workbook Growth Example

Create a new Excel workbook and insert a query. Start BEx Analyzer and select Open Query from the toolbar. No matter what query you use, try to use a query that delivers very few result lines. The historical workbook growth occurs with all queries because of the way Excel works. You therefore can apply my tips to all Excel workbooks.

Make sure your query only displays a few lines so that you can see the growth effect. In Figure 1, the first query creates 36 lines in Excel.

Figure 1 This query creates 36 lines in Excel

Next, save the workbook on your local drive, which has the same effect as saving to the BW server. Check the size

by displaying the file in your Windows browser in the detail view (Figure 2). As you can see, my actual test file size is 83 KB.

Figure 2 Display your test file’s size

Now, reopen your file. Create a view or navigate your query so that it displays up to 700 lines of records or even more

(Figure 3).

Figure 3 Reopen your file and include up to 700 lines

Save the file with the same file name. You expect a bigger file due to more data? You’re correct! As Figure 4 shows, you can see in my case the file went from 83 KB up to 242 KB.

Figure 4 The file grew from 83 KB to 242 KB

For the last step, go back to the original query definition that displays 36 records. Save the file again. Although you might expect the file size to be 83 KB, in my case the new file size of my workbook (containing the same data except

some more empty lines) grew from 83 KB to 105 KB (Figure 5). This growth is about 25 percent.

Figure 5 The file grew from 83 KB to 105 KB even though both files display 36 records

Consequences of Large Workbooks

Note

I suggest that you never save data in your own workbook. It enlarges the size of the workbook due to the stored amount of data. In addition, you transmit a file that might contain sensitive data that hackers can filter. Instead, you should refresh the workbook that accesses data stored in BW.

Large Excel files slow down the system by hindering the initial report distribution. Users who open workbooks on a network with a slow connection consume lots of server resources. In addition, BEx Broadcaster in BW 3.5 and higher can distribute workbooks by email to multiple recipients. Distributing many large workbooks negatively impacts the performance of the distribution. Earlier BW systems can perform similar distribution with the help of BEx Application Programming Interfaces (APIs) and Visual Basic for Applications (VBA). I described VBA in my March 2004 BW Expert article “The BEx User Exit: 22 Functions to Automate and Enhance Your BW Reports in Excel.”

If your system is slow, then you need to analyze its load. In some cases, your Microsoft Exchange server might be experiencing heavy traffic. In other cases, it might be your Lotus Notes server. No matter what email client you use, huge workbooks slow it down. Some companies distribute daily sales reports by email. Some of the reports have an actual size bigger than 5 MB. I bet your company has some workbooks with a file size higher than 3 MB.

In a later section, I will explain two ways to isolate large workbooks (manually and via a query). Then I'll show you how to eliminate the historical data to reduce their file size.

Another effect of large workbooks is their negative impact on your security. Imagine you are a power user or controller with a wide authorization to create and test queries. Whenever you execute queries and save those queries in workbooks, the workbooks contain the data you are allowed to access. The CEO sees everything, but SAP BW authorizations only allow other users to see restricted information based on each employee’s authorization.

However, before individual users refresh the workbook query, they see whatever a user with a high level of authorization such as the CEO has saved so far. Larger workbooks take longer to load. This causes potentially sensitive data to stay on your screen for longer periods of time. I have found security breaches in some systems in workbooks containing sensitive data.

To prevent this security problem, save the workbook without data. From the BEx Analyzer toolbar, select the tool

icon. Choose All queries in workbook>Delete results to remove data. After refreshing the workbook, the client PC only displays the authorization- dependent data.

Note

Not all huge workbooks are related to historic growth. If users run queries containing 60 KB worth of rows, there is no way to shrink the size because real data is causing the size. When dealing with files of this size, consider the security aspect I mentioned above.

Track Large Workbooks

The value of spotting huge workbooks and resizing them relates to the number and age of workbooks and the number of changes. If a company has 1,000 Excel workbooks and each has an overhead of data of 1 MB, this causes an extra load of 1 GB on your email distribution system and a countable delay time for users working with regular phone lines instead of high-speed networks.

I suggest that administrators on your BW team sort workbooks by size. They can contain file size with my suggestion to save the workbook without data.

I’ll share a little trick for users to find out the size. In BEx, select Open Workbook from the BEx toolbar and turn on the property window by selecting the icon in the upper right corner of the dialog (Figure 6). Then, check your actual

file size. In my example it’s 2,995,200 bytes or 2.9 MB.

Figure 6 View the file size of your Excel workbook

BW administrators can use a more convenient way to see what workbook might be over the limit. I recommend investigating workbooks bigger than 1 MB. Enter transaction SE16 and type in table name RSRWBINDEX. That table stores information about all workbooks on your BW server. Select version A (active version). Sort descending for field FILESIZE and see how your workbooks behave in terms of file size. Figure 7 displays the largest workbook in table

RSRWBINDEX. This table unveils the user in the field OWNER who created that workbook. You might inform that user that he should save the workbook without data, because he might not know this feature.

Figure 7 Sort workbooks by their file size

You might also be interested in the workbook name because some companies save workbooks using the naming convention with refreshed data or a similar name to provide a manual user refresh (i.e., for higher management). To look up workbooks by name, use the WORKBOOKID field and create a second mode in transaction SE16 (open another session and enter the transaction again) for table RSRWBINDEXT. This table stores the description of each

workbook (Figure 8). Type in WORKBOOKID and version A (active) to find the appropriate language-dependent

name by selecting your country-specific language like D for German or E for English.

Figure 8 Search for a workbook by name

I added a generic extractor (by view) using transaction RSO2 to those tables. In other words, I created a view and joined the field RWORKBOOKID of table RSRWBINDEX and RSRWBINDEXT to track their growth in BW administrative statistic reporting. I’ll explain how to do this next.

Retrieve Workbook Statistics Automatically

I’ll explain an alternative to the manual ways I’ve explained for looking up large workbooks. You can automate the process of looking up large workbooks by using a BW query. To add workbook size information to enhance statistical reporting in SAP BW, proceed as follows. In my example, I’ll use only the file size. If you choose, you can enhance your statistical content with any information from table RSRWBINDEX. I’ll explain how to populate the attribute to SAP’s InfoObject 0TCTWORKBK. Alternatively, you can create a DataStore object (formerly an operational data store [ODS] object) to store the information described next as transactional information. This allows you to create BW queries to track workbooks greater or less than a certain size.

First, create a DataSource using transaction RSO2 as shown in Figure 9. Next, maintain the parameters for this DataSource. In the Applic. Component (application component) field, enter tct to store the DataSource in technical

content (Figure 10).

Figure 9 Create a DataSource

Figure 10 Enter tct to store the DataSource in technical content

In the View/Table field, enter table name RSRWBINDEX. Click on the save icon to view the next maintenance screen (Figure 11). Next, select the desired attributes for your workbook as shown in Figure 11. I used WORKBOOKID and

FILESIZE as selection criteria and checked these items in the Selection column. Click on the save icon again.

Figure 11

Choose which fields to use as selection criteria

Now, replicate the DataSource in the BW source system. Choose your source system from the list, right-click, and select Replicate DataSources from the context menu.

Create a new InfoObject for the new attribute for InfoObject 0TCTWORKBK. Use Number as the Type/data type (Figure 12). This allows you to assign the value for Filesize next. To do this, add the new generated characteristic as

attribute to 0TCTWORKBK and activate the InfoObject.

Figure 12

Select Number as the Type/data type

The last step is to generate an InfoSource containing the new InfoObject as displayed in Figure 13. Assign the InfoSource to the DataSource and create an InfoPackage. In SAP NetWeaver 2004s, this step is no longer necessary.

Figure 13 Enhance the InfoSource

Now, define InfoObject 0TCTWORKBK as an InfoProvider (Figure 14) by selecting the InfoObject. Enter change

mode and in the Master Data InfoSource / Data Target / InfoProvider tab maintain the InfoArea (Figure 14) to insert the new InfoProvider.

Figure 14

Maintain the InfoObject to become an InfoProvider

Next, create an update rule for 0TCTWORKBK based on the InfoSource you just created (Figure 15) by right-clicking

on the newly created InfoProvider and selecting Create Update Rules. Then, create update rules according to Figure 15.

Figure 15

Update rules for InfoObject 0TCTWORKBK

Load the data with the help of the InfoPackage as described in the previous step and include the package in your process chain to automatically reload new information.

Now you can see the file size in BW’s master data for each individual workbook (Figure 16) either in master data maintenance and in case of enhancing the statistical content queries described before in BW reporting. You can use this information in queries to trace workbooks bigger than 1 MB. After you’ve isolated the large files, you can shrink them by following my instructions in the next section.

Figure 16 Display of master data maintenance of InfoObject 0TCTWORKBK

Shrink the File Size

After you isolate suspicious files (huge size, only a few rows), you can manually shrink the file size. You can find many tools for this purpose by searching the Internet for “shrink Excel file size” or equivalent text. You can find free

shareware tools for manual shrinkage of single files or third-party tools, but no standard SAP tool can control this problem. Download such a tool and run it against one of your workbooks in three steps.

Step 1. Load your workbook from the BW server and save it locally on your PC

Step 2. Run the tool and compare the file size

Step 3. After shrinking the workbook, open BEx Analyzer and the smaller workbook. Save it as the existing workbook’s file name.

I did this with one of my customers and reduced a workbook of 6 MB to 250 KB. This greatly improved the performance, network, and disk space.

Using a BEx API, you can automate such a shrink process, which I’ve explained in my March 2004 BW Expert article “The BEx User Exit: 22 Functions to Automate and Enhance Your BW Reports in Excel.”

Note

Check out the SAP class BW360, SAP BW Performance and Administration (for BW 3.5) or BW360, BI Performance and Administration (for SAP NetWeaver 2004s) for more ideas to improve reporting performance. This is an advanced BI class, so be sure to check the course prerequisites. For further details, visit www.sap.com/useducation

Set Up the BEx Map for Flawless Function in Five Easy Steps  

by Lori Vanourek, BI Specialist, BI Product Management, SAP Labs

Analyze geographic data with the BW Business Explorer Map functionaility.

Categories: Analytics, BEx

SAP BW has a great feature that allows you to analyze geographic data. For example, you can evaluate customer data starting at a regional view and then drill down to a state, county, or city view if you wish. The engine in BW that allows you to do this is the BEx Map within Business Explorer. It is part of the BEx Analyzer, and it aids users in the decision-making process by showing patterns and trends from a geographic perspective. Considering that 80 percent of all corporate and business data contains geographic components, this functionality can add significant value to the decision-making process.

The BEx Map requires geographic data to know what to plot. If this geographic data is not properly loaded, you will experience error messages when attaching maps to queries. To help you to avoid encountering error messages, I offer you the following steps1 that can be used as a checklist to ensure that your BEx Map is fully set up. I've also included a few tips that I've learned from working with the BEx Map that can save you from some common mistakes.

Step 1. Apply for the ESRI SoftwareAlthough the BEx Map is a standard BW component, you can't use it until you obtain the ArcView GIS software from ESRI. (ArcView 3.3 is used for versions up to BW 2.0B, and ArcView 8.2 is used with versions later than BW 3.0A.) Please see the Service Marketplace (http://service.sap.com/bw) folder Partner-OEM/Resell Partners-ESRI for more information.

ArcView is necessary for using the BEx Map. Your SAP BW installation packet should contain a voucher that you can redeem to get the software from ESRI. The installation packet also contains a CD developed by SAP and ESRI that contains a range of maps covering the world in various levels of detail. If these maps are not sufficient for your needs, you can apply directly to ESRI for additional detailed maps in ESRI shapefile format (http://gis.esri.com/intldist/contactint.cfm).

Step 2. Identify the InfoObjects (Characteristics) to Use for MappingYou will be loading the geographic data from ESRI into the BW system. It is important to identify which InfoObjects will be used in your queries so that the geo-specific data is attached to the correct InfoObjects (i.e., the same InfoObjects that are used in your InfoCubes). For example, if you want to query by city, and the InfoObject in your InfoCube for city is 0CITY, then make sure you load your geographic data for city into the InfoObject 0CITY.

Step 3. Determine Whether the InfoObjects Will Be Static or Dynamic A static geo-characteristic describes an area (polygon) for which the geographical coordinates do not often change. Countries or regions are examples of static geo-characteristics. A dynamic geo-characteristic describes a specific geographical location or point on a map for which the geographical information changes more often. Customers or plants are examples of dynamic geo-characteristics, because they are associated with a geographical point on a map as described by an address. This information is likely to change eventually.

It is important to identify the type of InfoObject so that the correct type of geo-specific data can be loaded (i.e., dynamic geo-characteristics will need specific latitude/longitude coordinates whereas static geo-characteristics would not). To tag static and dynamic InfoObjects, go to the InfoObject maintenance screen using transaction code RSD1.

Click on the Business Explorer tab (Figure 1).

Figure 1 Identify InfoObjects as static or dynamic at this screen

If the InfoObject is a static geo-characteristic, you must download the shapefiles from the ESRI CD to a hard-disk drive that your BW system can access. These “shapefiles” define the geometry and the attributes of the static geo-characteristics and will be loaded into the BW system in a later step of this process.

If your InfoObject is a dynamic geo-characteristic, then you will need to assign latitude and longitude coordinates to the master data values. This process is referred to as geocoding.2

Step 4. Maintain the SAPBWKEYYou must match your master data values to the values in the delivered shapefiles (which are stored in a .dbs format). The shapefiles you receive from ESRI do not take into account your company's master data coding scheme. For example, for some companies the customer ACME would have a key value of ACME, whereas other companies would have a key value of customer 98844. This matching process is called maintaining the SAPBWKEY.3 To

maintain the SAPBWKEY, you will use either ArcView GIS or other software that can edit dBase files (i.e., Microsoft Excel).

Step 5. Upload the Prepared Shapefiles to the BW SystemYou load these shapefiles from the same transaction that you used to mark the InfoObject as a geo-characteristic (RSD1) in step 3. Notice the button Upload shape files in Figure 1. When you press this button, BW prompts you to load three shapefiles for the InfoObject that is currently being edited, assuming that you have already made it a geo-characteristic. These files have the following extensions:

.dbs – dBase file that saves the attributes or values of the characteristic .shp – saves the current geometry of the characteristic

.shx – saves an index for the geometry

Tip! If you have loaded multiple versions of your shapefiles (i.e., you loaded the shapefiles before maintaining the SAPBWKEY, and then maintained the key and renamed and loaded the files), then be sure to delete the old files.

Now that the geo-specific data has been loaded, you are ready to create a Query and attach a map. In Figure 2, the static geo-characteristics are country and state (notice the distinct boundary lines). Color shading represents the total sales for each state (states in grey did not have any sales). Pink dots represent specific distributor locations; the geo-characteristic for distributor is dynamic as the distributor's location is subject to change.

Figure 2 Static and dynamic geo-characteristics

Tip! Make sure your query displays only one geo-characteristic in the row at a time. (This is a system requirement and will help you to avoid error messages.) It is possible to have multiple geo-characteristics in the query, but drill down so that only one is in the row at any given drill-down step. One way to do this is with the Save Filter function.

Street-Level Geocoding

For many applications, geocoding to zip code or other administrative boundary files may be all that's needed. Typically, X-Y coordinates obtained from this level of granularity are based on the center of the zip code or other boundary. This may be adequate for some marketing or advertising applications, but may not be granular enough for other applications such as routing. For these applications, street-level geocoding may be needed. Here, X-Y coordinates are derived from an interpolation along street segments with known address ranges. The geocoding process uses the street-level addresses in its algorithms, not just the zip or other boundary code.

When downloading master data from BW, you can select which attributes of 0Customer you want to download, usually the Postcode attribute. You can also download street addresses if they are available. However, you will also need street-level spatial data with address ranges for both the left and the right sides of the street for use as a reference layer for the geocoding process. This data is available from a number of sources including ESRI Inc., Geographic Data Technology (GDT), and Tele Atlas North America.1

Once you have your street reference layer, the procedure for street-level geocoding is similar to that for postal-code geocoding except that you have more preferences and properties to set. For example, you can set spelling sensitivity and address match scores, side-of-street offsets for locating points in ArcMap, and output fields from the geocoding process such as the standardized address, which can be propagated back into BW for other uses such as mailing campaigns. Follow the instructions in the ArcCatalog and ArcMap user guides for ArcView version 8.x.

An important consideration is what coverage is available for the area you are interested in. For example, street-level data for the U.S. and Western Europe is readily available and relatively inexpensive. Street-level data for other parts of the world might be patchy or nonexistant. Furthermore, the address format and address scheme vary significantly throughout the world, which can greatly alter the geocoding algorithms from country to country. If your organization operates in many countries, street-level geocoding can become complicated and expensive.

Fortunately, things have improved recently. The major data vendors have targeted the largest and most active markets worldwide, greatly expanding coverage. To lower costs they have begun to offer worldwide geocoding as Web services, eliminating the need for an organization to buy, integrate, and maintain multiple street data sets and geocodes. Check out ESRI's Geography Network http://www.geographynetwork.com/ for links to key sources of

street-level data and geocoding services.

-Steve Benner, ESRI

1 The Web addresses for these companies are, respectively, http://www.esri.com, http://www.geographic.com, and http://www.na.teleatlas.com.

Again, I suggest that you download the “BEx Map 2.0b (Including Geocoding)” whitepaper, as it contains more detail than I can show here. The process for attaching maps to queries is also detailed in the whitepaper. I will go into more depth on this topic in the next issue of BW Expert. I will also show you how to set up a Web template for the BEx Map, and I will explain the relationship between maps and tables.

Figure 2 Static and dynamic geo-characteristics

Tip! The system will only graph dimensional characteristics. Make the InfoObject that contains the geo-characteristic a main characteristic (not a navigational attribute).

1 These steps apply to all versions of SAP BW.

2 The ESRI software will help automate this process. The SAP whitepaper “BEx Map 2.0b (Including Geocoding)” explains how to do geocoding. You can access this document via www.service.sap.com/bw under the folder Documentation>Documentation Enhancements.

3 See the “BEx Map 2.0b (Including Geocoding)” whitepaper for instructions on maintaining the SAPBWKEY.

Simplify Reporting by Creating a Top N Analysis Report  

by Yu (James) Hong, Information Management Lead, Major Manufacturing Company, and Balaji Bitra, BW Lead, Major Manufacturing Company

See how to develop a BW Web report that shows the top N product analysis with the subtotal key figures of top N products and the subtotal of the remaining products in one report. Walk through an example of how to set up a top 20 products analysis based on the user selection of the subsidiary and time period.

Categories: ABAP, Analytics, BEx, Reporting

Key Concept

Top N product analysis allows a company to select a certain number of its products and analyze them both as a group and in comparison to the remaining products in its portfolio. Using this kind of analysis, a company can assess products in various ways based on different criteria, such as region.

A global company’s product portfolio produces complex reports that often require simplification to emphasize certain pieces of information. Managers usually want to see concise reports of important products that explain key elements of their product lines.

One way to produce such a report is to show how the top N products of a given portfolio perform relative to the remaining products in terms of sales or profit. The standard report only shows the top N products’ information. With access to the subtotal key figures of the top N products and the subtotal of the remaining products in one report, managers can allocate brand investments, research, and development to the right products. Moreover, some products could be very important in one region but not in the other.

Users can select the region and period for which they would like to perform the top N products analysis. You then have a report that includes the top N products, their subtotal, and the other products’ subtotal.

You can use a product variable with a user exit type to create such a report. We’ll develop a report that shows the top 20 products in a given company as compared to its other products, which is information a standard report doesn’t provide. We’ll also show you a previously undocumented way to code the ABAP user exit so that it calls another

query to populate the values at runtime. First, you need to create a report that lists the top 20 products and their key figures, which we’ll explain next. This process applies to SAP BW 3.x and later.

Top 20 Products with Key Figures Report

You have to create a BEx Query to show the top 20 products based on sales. Follow menu path Programs>SAP Front End>BEx Query Designer to define the query ZSR_MCS1_QW_ESS0011_GC_QTD (Figure 1). The first column shows the current quarter sales that you’ll use later in the query condition to define top N products. The query produces the top section of the final report, which we’ll show at the end of the article. In our example, &ZT_VR1&

&ZT_FYP1& / (GC/QTD) is a predefined restricted key figure that shows the current quarter sales.

Figure 1 Create the query with product in the rows

Drag the characteristic Product into the Rows section, and then drag the key figures under the Key Figure section

from the left into the Columns section. Next, drag Fiscal year/period dimension to the Free Characteristics area, as shown in Figure 1.

Note

To see how to create a condition, refer to the BEx Query Designer documentation at http://help.sap.com/saphelp_bw320/helpdata/en/f1/0a5a2ee09411d2acb90000e829fbfe/frameset.htm. Select Query Design: BEx Query Designer from the menu on the left side of the page.

Management Entity can represent a region, subsidiary, division, or whatever the user defines. Likewise, Fiscal Period is a year (as used in my example), a quarter, or a period of any length. By double-clicking on Management Entity and Fiscal Period, you can restrict them with user input variables so the user can select the management entity and time period when running the query. This allows the end user to run the report that gets the top 20 products for any combination of management entity and time period. Click on the define condition icon in Query Designer

(circled in Figure 1) to bring up the screen in Figure 2.

Figure 2 Create a condition on product to list top N products based on sales

In this screen, you can define a condition. Check the Product check box so that the system only evaluates the condition for products. Select the first key figure (&ZT_VR1& &ZT_FYP1& / (GC/QTD), in this example) from the drop-down list, and then select Top N as the operator. Enter 20 in the Values field. I’m using 20 in my example; this number simply represents N in a given scenario. You can also create a variable to let the user pick the value of N. By checking the Variables Entry check box in Figure 2, you can define a variable for top N instead of top 20. Now that you’ve created the top 20 products key figures report, we’ll show you how to create a report that shows subtotals.

Subtotal of Top 20 and the Remaining Products Report

The process to create this report involves four steps. First, you generate a query to show only the top N products. Then you create a user exit variable that calculates the top 20 products. From there, you populate the product variable in the user exit and use it to derive the subtotals for the top 20 and the remaining products.

Step 1. Create a query with the condition that you show only top N products. In the screen shown in Figure 3, create query ZSR_MCS1_QW_ESS0034. This query is similar to ZSR_MCS1_QW_ESS0011_GC_QTD (the query

from the previous section) and it uses the same Management Entity and Fiscal Period variables. You can follow the steps in the previous section to define the condition.

Figure 3 ZSR_MCS1_QW_ESS0034 calculates top 20 products

Step 2. Create a user exit variable under Product to calculate the top 20 products. Open Query Designer and expand the characteristic Product. Right-click on Characteristics to bring up the context menu and select New Variable. In the screen that appears, define a user exit variable (Figure 4). In this screen, you specify the fields as

your needs warrant. We filled the screen with the appropriate values and included the variable’s name (ZC_PRD28) and a description.

Figure 4 Create a user exit variable ZC_PRD28

Step 3. Call ZSR_MCS1_QW_ESS0034 in the BEx Variable ABAP user exit to populate the product variable. Refer to the BEx variable by user exit documentation at http://help.sap.com/saphelp_bw320/helpdata/en/f1/0a56f5e09411d2acb90000 e829fbfe/content.htm for further details about using user exits to populate product variables.

You need to use the ABAP user exit code that you can find in the Downloads section of BW/BI Expert’s Web site at www.bi-expertonline.com. The code has three major sections. The first section retrieves all variable values for management entity, year, and other values selected by users.

The second section calls the query, ZSR_MCS1_QW_ESS0034, defined in step 2 to retrieve the result set internal table. When the query runs, the system first stores the result in the result set internal table. The top 20 product codes are also stored in the result set table. By looping through the result set table, all the product code values pass to the function call in the user exit module.

The third section retrieves the list of product codes based on the result set table. The system then populates variable ZC_PRD28 based on the result set table.

Step 4. Use the user exit product variable ZC_PRD28 in ZSR_MCS1_QW_ ESS0026_GC_QTD to derive the subtotals for the Top 20 and the remaining products (Figure 5). The query contains the same column structures

as ZSR_MCS1_QW_ESS0011_GC_QTD. It uses another structure in the rows to show the subtotal of the top 20, the subtotal of the remaining products, and the grand total.

Figure 5 Query for the subtotal of top 20 and the subtotal of the remaining products

Select Top 20 Products under the row Structure. This brings up the screen shown in Figure 6. Then, drag Product from the left side to the right. Double-click on Product to specify the variable ZC_PRD28, which you use to restrict

the Top 20 Products.

Figure 6 Top 20 Products restricted by product variable ZC_PRD28

Next, double-click on All Products in Figure 5 to bring up the Edit Selection screen shown in Figure 7. You still need to drag Product from the left side to the right. However, notice the difference between Figures 6 and 7: the latter does not show a restriction under Product. In this situation, All Products shows the grand total for all the

products under the Management Entity and the time period that the user selects.

Figure 7 All Products has no restriction on product

Then create a formula in the Rows section called All Others (Figure 8). All Others is the difference between the

selection of All Products and the selection of Top 20 Products. It is the last step of the query creation and gives the user an idea of the total sales of the remaining products without showing the product details.

Figure 8 All Others equals All Products minus Top 20 Products

After creating this report, the final step is to publish ZSR_MCS1_QW_ESS0011_GC_QTD and ZSR_MCS1_QW_ESS0034 to the same Web template. Open BEx Web Application Designer and drag two table items from the left to the right layout screen. Then assign data provider ZSR_MCS1_QW_ESS0011_GC_QTD and ZSR_MCS1_QW_ESS0034 to the first and the second table, respectively. When you execute the report, the variable screen shown in Figure 9 appears. Enter the required data and click on the Execute button to view the report. In the

sample report in Figure 10, PRODUCT 1, PRODUCT 2, and PRODUCT 20 represent the individual product lines you would see — a real report would have 20 lines above the three summary lines.

Figure 9 The selection screen of the top N analysis report

Figure 10 Sample report with totals for Top 20 Products, All Others, and All Products

Note

For more information about Top N analysis, attend SAP Education course BW305: Business Information Warehouse: Reporting and Analysis (SAP BW 3.5) or BW305: BI Enterprise Reporting, Query, and Analysis: Part 1 (SAP NetWeaver BI).

Take the Challenge Out of BEx Report Formatting: It’s Easier than You Think  

by Stuart Chambers, BI Consultant, Innogence (June 2009)

Companies often want their reports to have a certain look and feel. Using an example of formatting your BEx reports so that negative numbers appear red, find out how you can easily modify your report parameters. You can use this three-step process for other reporting needs, such as changing the exception icon.

Categories: BEx, Web Application Designer

Key Concept

Analysis Web item parameter modification modules allow BEx Web Application Designer (BEx Web AD) developers increased control over Analysis Web item behavior. In SAP BW 3.x, this control was previously available through Web Design APIs. However, in SAP NetWeaver BW 7.0, SAP provides standard modification modules that you can insert in the XHTML of a BEx Web AD template, allowing rapid and intuitive manipulation of Analysis Web items.

Satisfying end-user formatting requirements in BEx Web Application Designer (BEx Web AD) can be a difficult task. Every business has different standards that it must adhere to, and each division often has specific needs and wants. It’s not uncommon to see an end user very unhappy with a BEx Web AD template — not because of the data quality, but because the template’s usual colors, column widths, and exception symbols are not present.

With Web Design API for tables no longer in use, SAP now provides parameter modification modules for Analysis Web items to enable the modification of the standard table structure and cells. You control these modules by adjusting the parameters within them. By following this basic methodology in the following three steps, you can successfully implement an Analysis Web item modification.

Step 1. Identify the module that satisfies your formatting requirements

Step 2. Define the module in the Analysis Web item modification parameter

Step 3. Adjust the module-specific parameters to control the Web Analysis item display

I use the example of setting up Analysis Web items to automatically change negative numbers to red, and show you how you can tailor the result to your specific requirements. My example applies to SAP NetWeaver BW 7.0 Support Package 7, Patch 1, Revision 473. The functionality may not be available with earlier versions. You can use standard SAP modules to modify the Analysis Web item display.

Note

The parameter modification modules are delivered as part of the Java stack, and their availability is based on which stack level you are on. The major limitation on the use of these modules is that the SAP Basis infrastructure in SAP NetWeaver 7.0 is not customizable. Therefore, users cannot develop their own modules, and Analysis Web item

modifications are limited to the options that SAP supplies.

Step 1. Identify the Module that Satisfies Your Formatting Requirements

Take this example scenario. You have completed the build of your BEx Web AD template, generated an iView of your template, and assigned it to a portal role. However, the end users have discovered a defect — they cannot see negative figures in red as they could in their old reports. In fact, they only want to see negative numbers in red for a particular key figure. Data quality, ability to slice and dice, and timely access to data aside, the user will not sign off on your template without this piece of comfort formatting delivered.

To have a satisfactory outcome for the example scenario, you need to implement the Negative Number module (com.sap.ip.bi.rig.NegativeNumber).

Step 2. Define the Module in the Analysis Web Item Modification Parameter

Implementing the Negative Number module in your BEx Web AD template to make all negative numbers red is a relatively simple process. It requires that you insert a small selection of predefined code in the BEx Web AD XHTML tab.

The code for each data provider is presented in Figure 1, which you can find by switching to the XHTML tab in BEx Web AD. Before you do this, there are two important concepts to remember. First, the module is data provider-specific, so you need to insert the code in Figure 2 in each Analysis Web item to which you want to apply it. Second, by default the module is inactive, so ensure that the Active parameter (on line 3 of Figure 2) is populated with X. To insert the parameter modification module, insert a new line after the <bi:DATA_PROVIDER_REF value="DP_1" />

tag and paste the code in Figure 2.

Note

Your BEx Web AD template may contain many Web Analysis items. By specifying the Web Analysis item to which you want to apply the parameter module (as shown in Figure 1), you can choose which data providers within the BEx Web AD template the parameters affect.

<bi:ANALYSIS_ITEM name="ANALYSIS_ITEM_1" designwidth="400" designheight="200" >

<bi:DATA_PROVIDER_REF value="DP_1" /></bi:ANALYSIS_ITEM>

Figure 1 Apply the Negative Number module to ANALYSIS_ITEM_1

<bi:MODIFICATION type="CHOICE" value="MOD_SINGLE_MODULE" > <bi:MOD_SINGLE_MODULE type="COMPOSITE" > <bi:ACTIVE value="X" /> <bi:MOD_SELECT type="CHOICE" value="MOD_GENERIC_MODULE" > <bi:MOD_GENERIC_MODULE type="COMPOSITE" > <bi:MOD_REFERENCE value="com.sap.ip.bi.rig.NegativeNumber" /> </bi:MOD_GENERIC_MODULE> </bi:MOD_SELECT> </bi:MOD_SINGLE_MODULE>

</bi:MODIFICATION>

Figure 2 Add this code after <bi:DATA_PROVIDER_REF value="DP_1" />

Click the correct and format icon on the BEx Web AD toolbar. BEx Web AD activates and formats the inserted code. Then click the save and execute icon on the BEx Web AD toolbar to see all the negative numbers in the

Analysis Web item specified, displayed in red (Figure 3).

Figure 3 The negative numbers appear in red

Step 3. Adjust the Module-Specific Parameters to Control the Web Analysis Item Display

However, in my example, the end user has specified that only the negative values in a particular key figure should be displayed in red. Through the use of parameterization, the Negative Number module allows you to specify columns to which the system should apply the formatting.

Figure 4 shows how you can introduce a modification parameter list and the modification parameter COLUMN. In this list you enter any additional parameter modifications that are available for the module. This is a basic example of how you define a particular column for red negative numbers. Once again, place this code in the XHTML tab for the applicable Analysis Web item as you did previously.

<bi:MODIFICATION type="CHOICE" value="MOD_SINGLE_MODULE" > <bi:MOD_SINGLE_MODULE type="COMPOSITE" > <bi:ACTIVE value="X" /> <bi:MOD_SELECT type="CHOICE" value="MOD_GENERIC_MODULE" > <bi:MOD_GENERIC_MODULE type="COMPOSITE" > <bi:MOD_REFERENCE value="com.sap.ip.bi.rig.NegativeNumber" /> <bi:MOD_PARAMETER_LIST type="ORDEREDLIST" > <bi:MOD_PARAMETER type="COMPOSITE" index="1" >

<bi:MOD_PARAM_NAME value="COLUMN" /> <bi:MOD_PARAM_VALUE type="CHOICE" value="BOOLEAN" > <bi:BOOLEAN value="X" /> </bi:MOD_PARAM_VALUE> <bi:MOD_PLACEHOLDER_LIST type="ORDEREDLIST" > <bi:MOD_PARAM_VALUE type="CHOICE" index="1" value="INTEGER"> <bi:INTEGER value="6" /> </bi:MOD_PARAM_VALUE> </bi:MOD_PLACEHOLDER_LIST> </bi:MOD_PARAMETER> </bi:MOD_PARAMETER_LIST> </bi:MOD_GENERIC_MODULE> </bi:MOD_SELECT> </bi:MOD_SINGLE_MODULE> </bi:MODIFICATION>

Figure 4 Apply this code to specify that only certain negative numbers should be red

In this case, I applied the formatting to the Units Sold Variance key figure (Figure 5). By changing the value in

<bi:INTEGER value="6" />, you can select any key figure in the report.

Figure 5 The Negative Numbers module applied only to the Units Sold Variance key figure

Limitation of Using the Negative Number Module

It is worthwhile to note a limitation of this parameter modification module that could affect its application. Because the selection of the column to which you apply negative number coloring is not dynamic, adding or removing characteristics and key figures affects the number of columns in the grid. Therefore, if you remove one characteristic in Figure 5, the system then applies the negative number formatting to the Units Value 2007 column.

The BEx User Exit

22 Functions to Automate and Enhance Your BW Reports in Excel  

by Joerg Boeke, Director, Business Intelligence, syskoplan AG Germany

The BEx user exit allows you to perform many valuable tasks and functions in Excel, which can be a great platform for displaying your SAP data when used to its full potential. The author provides 22 ways that the BEx user exit can optimize your Excel reports, with downloadable documents available at the BW Expert Web site.

Categories: BEx, Reporting

Did you know that every time you run an SAP BW report in Microsoft Excel that you are accessing an almost unknown SAP user exit? The BEx user exit has many functions associated with it that allow you to enhance or automate your reports. For example, did you ever think about having users see the actual data in their reports whenever they open a BW report without prior refresh of that particular query? Perhaps you have wanted to modify data in your reports in an automated way — for example, highlighting sections or using text-wrap functions for the first result row.

The BEx user exit provides you with obscure functions to accomplish these tasks and more. In fact, I have identified 22 functions that are not well known but quite useful. These functions, listed in Table 1, are part of the BEx API. They are not BW function modules, and are not accessible via transaction SE37. The functions discussed here are available only from the SAP BW GUI front-end installation and will only work in combination with Excel. You can download a complete overview and examples for using them from the Download Section of the BW Expert Web site at www.BWExpertOnline.com. I will show you how you might use these functions by walking you through one example. They work equally well with BW 2.x or BW 3.x.

1.

Function SAPBEXinitConnection(Optional newConnectionObj As Obj

Set up a connection to the BW server.

ect) As Boolean

2.Function SAPBEXgetConnection(Optional what As Integer) As Variant

Get the existing connection object if already connected to BW server by help of BEx.

3.Sub SAPBEXattachGIS(Optional refreshOnly As Boolean)

Attach GIS map (same as clicking on the BEx toolbar button).

4. Sub SAPBEXpauseOn()

Issue more than one API command (such as two individual filter values) without immediate refresh.

5. Sub SAPBEXpauseOff()All commands called after SAPBEXpauseOn are executed.

6.Function SAPBEXsetVariables(varValues As Range) As Integer

Set variable values for user to provide pop-up filter selections (filter dialogs are disabled if properly filled).

7.Function SAPBEXrefresh(allQueries As Boolean, Optional atCell As Range) As Integer

Refresh either all queries in workbook allQueries=FALSE or selected queries by identifying the query range.

8.Function SAPBEXsetDrillState(newState As Integer, Optional atCell As Range) As Integer

Set DrillState via coding to vertical (newState=1), horizontal (newState=2), or no DrillState (newState=0).

9.

Function SAPBEXgetDrillState(currentState As Integer, Optional atCell As Range) As Integer

Find out what DrillState is defined for a specific object.

10.Function SAPBEXsetFilterValue(intValue As String, Optional hierValue As String, Optional atCell As Range) As Integer

Set a filter value for a specific characterictic (e.g., 0CUSTOMER = 1002) to filter either on simple or hierarchy values.

11.

Function SAPBEXgetFilterValue_IntValue() As String: SAPBEXgetFilterValue_IntValue = g_SAPBEXgetFilterValue_IntValue: End Function

Set a filter value for a specific characterictic (e.g., 0CUSTOMER = 1002) to filter either on simple or hierarchy values.

12. Function SAPBEXgetFilterValue(intValue As String, hierValue As String, Optional atCell As Range) As Integer

Get a filter value for a specific characterictic (e.g., 0CUSTOMER) to use later

on either simple or hierarchy nodes.

13.

Function SAPBEXcopyFilterValue(fromCell As Range, Optional atCell As Range) As Integer

Copy a filter value for a specific characteristic.

14.Function SAPBEXfireCommand(fCode As String, Optional atCell As Range) As Integer

Issue commands such as remote-control context menu or toolbar (values can be found via a trace file).

15.Function SAPBEXcheckContext(fCode As String, Optional atCell As Range) As Integer

Check if an OLAP command such as SAPBEXfireCommand can be used on that particular cell.

16.

Function SAPBEXshowTextElements(Optional selectGroup As String, Optional atCell As Range) As Integer

Display text elements (filters, global values) via the toolbar.

17.

Function SAPBEXshowTextElements(Optional selectGroup As String, Optional atCell As Range) As Integer

Report: Report Interface; jump to a specified workbook or view.

18.

Function SAPBEXgetResultRangeByID(ByVal queryID As String, Optional ByVal charName As String) As Range

Find out where data from query is being displayed — for example, if you want to add data to last column.

19.Function SAPBEXsaveWorkbook(Optional wbName As String) As Integer

Save your workbook after refresh (no name needed) or save as new file.

20.Function SAPBEXreadWorkbook(wbID As String) As String

Open your workbook via Workbook ID (GUID).

21.Function SAPBEXgetWorkbookID(wbName As String) As String

Find workbook ID by opening the workbook using a "human-friendly" name. Return value is GUID.

22.Function SAPBEXembedQuery(genUID As String, Optional atActiveCell As Boolean) As String

Like the toolbar function; embed a new query (not workbook) to your active workbook.

Table 1 BEx API provides 22 functions to automate and enhance your reports

Using the BEx user exit requires basic skills for programming Visual BASIC for Applications (VBA), which is delivered with Excel. If you do not have these skills, you might find the extended examples at the BW Expert Web page helpful. Another option is to use the Excel macro recorder. After refreshing the query, start the Excel macro recorder, change your report to the desired display, and stop the recorder. You can insert the resulting code saved in the macro recorder directly into the BEx user exit, where it will be executed after each refresh. By using that exit, You can

change the format or display of data. As described in the next example, you can also control your BW reports remotely.

By using the functions listed in Table 1, I will show you how to interact with your reports. The functionality is the same using the context menu, but through the BEx user exit, you can predefine the behavior of your queries. For example, instead of filtering for a specific year using the navigation and filter area, you could create a button for the actual and previous year. By clicking on this button, the query filters just this setting. In the case of management reporting workbooks, this is a great option to provide simple navigation for your users.

Now I will show you the syntax for calling these SAP functions.

Consider the following simple task (just a warm-up). You want to format the first row of your result area with a defined height and with text-wrap to provide a better view. This format should be dynamic, meaning if you insert rows above,

the system should keep the format in the proper row (row 9) as Figure 1 shows.

Before

After

Figure 1 Note the formatting change in row 9 of the after image

Do you think this is a tough job? No, just display the Excel Visual Basic toolbar by selecting View> Toolbars> Visual Basic from the Excel menu. Select the editor icon, which is circled on the toolbar below:

When you insert BW queries into Excel workbooks, the system automatically inserts the BW Visual Basic Application (VBA) exit. You can find this exit, which is provided by the SAP module SAPBEX, in the VBA editor. The VBA code in Figure 2 is responsible for the dynamic format shown in Figure 1. You enter your code after the line:

Sub SAPBEXonRefresh(queryID As String, resultArea As Range)

Figure 2 The code in the box on the right is responsible for the dynamic format shown in Figure 1

SAP-BW provides the following information inside this exit; you may use it to add other functionality.

First queryID: This queryID can be found when you open your workbook. Right- click and select the Information tab under Properties. Then choose QueryID (local). You can use this ID (SAPBEXq0001) to run functions only on specific queries inside your workbook.

Second resultArea: This Excel range object can be used for purposes such as calculating the last row or first row using VBA functionality. In my example (Figure 3), I used the resultArea.Row function to find out what the first row of

my resultArea (data area) is in that report. The user exit signals function MyFunction_ReFormat, which sets the row height and text properties.

Sub SAPBEXonRefresh(queryID As String, resultArea As Range)If queryID= "SAPBEXq0001" then' dynamically reformat the first rowMyFunction_ReFormat resultArea.RowEnd IfEnd Sub

Function MyFunction_ReFormat(i As Integer)Dim j As Integer, k As Integer Rows(i).Select

With Selection .WrapText = True .Orientation = 0 .AddIndent = False .ShrinkToFit = False .ReadingOrder = xlContext .MergeCells = False .RowHeight = 64 End WithEnd Function

Figure 3 The resultArea.Row function determines the first row of the resultArea, and MyFunction_ReFormat sets row height and text properties

As I said, this is just a warm-up example for utilizing the user exit. In this user exit, you can integrate all your macros (the macro recorder of Microsoft Excel can do a lot of work for you) or your VBA coding.

Call SyntaxNow let me explain the syntax for calling the SAP functions with the help of one selected BEx API function, SAPBEXcopyFilterValue. Table 1 shows all of the other functions. I will also provide the VBA code for the automatic silent log-on to your BW server. With this function, you can log on to your BW server without user interaction (you must provide a user ID and password in the function) and use Excel to automatically load a desired workbook (SAPBEXreadWorkbook), refresh your workbook (SAPBEXrefresh) and store it back onto the BW server with actual data (SAPBEXsaveWorkbook). This functionality allows all of your users to see the actual data in reports without a prior refresh.

Imagine a workbook containing two different queries that both use 0CUSTOMER and 0MATERIAL as characteristics. I call the first Query-A (providing key figures for the actual month) and the second Query-B (providing historical data such as an actual year/previous year comparison). Wouldn’t it be great to synchronize any filter selection on Query-A with Query- B? A couple of my clients are using this functionality in SAP-BW Management Cockpit queries.

How can you achieve this using an SAP user exit and API functions? All you have to do is enter the VBA exit as

described previously and enter the code shown in Figure 4. It is important to reference the SAPBEX.xla (the Excel add-on file functionality for SAP BEx).

Sub SAPBEXonRefresh(queryID As String, resultArea As Range)' This is our sending Query-AIf queryID= "SAPBEXq0001" then' Send FilterValue for 0Material from Query-A to Query-B If Run("SAPBEX.xla! SAPBEXcopyFilterValue", Sheets("Query_A").Range("D6"), _

Sheets("Query_B").Range("D9")) = 0 Then Else MsgBox "Function failed" End IfEnd IfEnd Sub

Figure 4 VBA code to synchronize filter selection between two queries

Because you use the queryID, the function is called only when selecting filter values for material in Query-A. Whatever your navigational steps in Query-B might be, they do not affect Query-A.

It is easy to use the user exit to either format your query or call SAP functionality to improve your navigation or report functionality. Remember, the full functionality of this user exit is described in downloadable documents at the BW Expert Web site.

The BEx Web Analyzer Template: Your Access to BEx Web Reporting  

by Yasan Gooding, PhD, and Cory Fite, MCAD, MCP, of Valero Energy Corporation (November 2008)

Find out a shortcut to access the BEx Web Analyzer Web template without opening BEx Analyzer to execute it.

Categories: BEx, Reporting

Key Concept

BEx Web Analyzer, a new BEx Analyzer menu option in SAP NetWeaver BI, serves as an entry point to all InfoAreas containing various InfoCubes and queries that fall under specific cataloged business content. This pathway makes it easier from a Web environment to access InfoCubes and queries based on an individual's role authorization in SAP NetWeaver BI.

In an age of convenience, business users are apt to use easily accessible tools for analysis. BEx Web Analyzer in SAP NetWeaver BI 7.0 can be that tool for business users. It can serve as an entry point to all your reports in BEx Analyzer through a URL, providing the user flexibility to access reporting within and outside various technical environments. This shortcut exposes the user to the familiar categorized InfoAreas in which InfoCubes and queries pre- exist and where ad-hoc reporting on various InfoCubes can take place on the spot. Users of BEx Analyzer will discover that it is very similar to the steps of opening a query in BEx Analyzer.

To do this, you must first employ Web Application Designer (Web AD) in SAP NetWeaver BI 7.0. Web AD is important because the BEx Web Analyzer Web template exists in Web AD under the technical name 0ANALYSIS_PATTERN.

Before you obtain the URL through Web AD, you must alter the template so that it mimics the way the variable screen is displayed in BEx Analyzer. By default in BEx Web Analyzer, BEx Web queries are executed instantly, bypassing the variable screen for user input. This scenario often leads to the re-execution of the report for values desired of the business user. You need to change some of the configuration within the template itself so that the variable screen appears when a user selects a BEx Web Analyzer query with variable inputs.

First, you must execute Web AD to alter the behavior of the template. To do this, you or your IT personnel must have authorization or role privileges to make changes. To access the standardized BEx Web Analyzer template, click on the open icon located at the top left corner in Web AD.

This brings up a dialog box for opening a particular template. In our example, we want to locate the 0ANALYSIS_PATTERN template. Under the Search Method text description, enter 0ANALYSIS_PATTERN and select Search in Description and Search in Technical Name (Figure 1). Click on the Find button. In the results,

highlight the template you want and click on the Open button (Figure 2).

Figure 1 Click on the Find button to search for a given method

Figure 2 Highlight 0ANALYSIS_PATTERN

To keep this standard template version of 0ANALYSIS_PATTERN unscathed, copy it so that you can configure the BEx Web Analyzer template to meet the needs of general users. Copy the template by clicking on the Web Template menu item located at the top left corner of Web AD. Select the Save as… option and use your company's IT naming standards for description and technical naming. You should save the template to a specific role so that other IT personnel can access it if a production support issue presents itself.

Now you can make the changes necessary for this template to function properly. In Web AD, click on the Layout tab. In the Properties section, select the drop-down menu that displays all the Web items Figure 3. Select Web

Template so that two tabs appear: General and Web Template Parameters (Figure 4).

Figure 3 Select Web Template

Figure 4 General and Web Template Parameters tabs

To customize the template so that it displays the variable screen when the user wants to run a Web BEx Analyzer report, you must alter the properties in the Web Template Properties tab. The Behavior section contains an option labeled Display Variable Screen. Select this option so that a check mark appears in the check box and it says On

(Figure 5). Click on the save icon.

Figure 5 Activate the Display Variable Screen option

Capture the URL

Now that your template is more user friendly, you can capture the URL and place it anywhere for user convenience. Web AD has an option that obtains the URL and copies it to a clipboard. On the Web AD menu bar, select Web Template>Publish>Copy URL into Clipboard.This stores the URL link to your customized BEx Web Analyzer template. You can then paste the link in an Internet browser or post it to a portal page.

You can also use the URL to display your customized BEx 7.0 template inside your Business Server Page (BSP) application. To do this, implement IFrame functionality to display the inline frame by entering a simple HTML code inside the BSP application. You achieve this by creating a BSP application using Object Navigator or Web Interface Builder.

If you are going to make only one BSP page to display a customized template, then Object Navigator is a good option to develop a BSP application to reside on a BSP page. Otherwise, you can use Web Interfaces to build a Business Planning and Simulation (BPS) applications. You can use Web Interface Builder to create a BSP application to combine the customized template BSP page with BPS planning applications. It is useful to have both in the same application so business users can use the customized template to look up any existing query. They can also create a new query to gather data to enable and support their operational and strategic decision making process, and then use any BPS planning applications to enter data for their planning and forecasting activities.

Object Navigator

To implement the URL into the BSP application using Object Navigator, log in to SAP NetWeaver BI and execute transaction SE80. Then enter a new customized BSP application with a name that begins with Z to follow the SAP NetWeaver BI naming standard to create a new custom object. Next, click on the Layout tab and enter a simple HTML code to create IFrame functionality with the template URL as a source of the IFrame inside the layout (Figure

6).

(Enter or Paste the template URL here )” width=”900 px” height=”600 px”>

Figure 6 Enter the HTML code for the IFrame functionality

Activate the BSP application by clicking on the activate icon. Then test the application by clicking on the test icon

. This automatically launches a new window and displays the BSP application with your customized template URL embedded inside the IFrame.

Web Interface Builder

To use the Web Interface Builder, log in to SAP NetWeaver BI and execute transaction BPS_WB. Create the application by clicking on the New button and assigning the application a name that begins with Z to follow the SAP NetWeaver BI naming standard for a custom application.

Next, create a new subcomponent by right-clicking on the page and selecting Text, Image, HTML. Assign a name to the subcomponent and then click on Ok. Finally, click in the Text field to display text and select the Use F4 Help to Edit Text option (Figure 7). Enter the simple HTML code shown in Figure 6. To make sure the text subcomponent

displays as HTML, change the HTML option in Figure 7 to true.

Figure 7 Enter a component name, select text, and enable HTML

Execute the Web Interface application. Click on the generate icon to generate the application. Then click on the Display Preview button to launch the BSP application automatically.

Access the URL

You have now implemented a simple HTML code to create IFrame functionality to display our customized BEx 7.0 template inside the BSP application. You can also use the BSP application's URL for your portal environment or to open the BSP URL from your Internet Explorer Favorites folder.

If you paste the URL into an Internet Explorer window, you can log on using your SAP NetWeaver BI user ID and password. After you log in, you can access any BEx Analyzer report by clicking on the New Analysis button (Figure 8). A dialog box appears that allows the user to access BEx queries from the History, Favorites, Roles, and

InfoArea tabs (Figure 9).

Figure 8 Access BEx Analyzer reports with the New Analysis button

Figure 9 Select where you would like the user to access the query

Clicking on any of the items listed in any of the tabs executes the report. A variable screen appears if there are variable options in the BEx report. We copied the standard template and changed the properties so that the system prompts us for a variable entry as shown in Figure 10. Enter the desired values for your report and click on OK to execute. The BEx Web Analyzer report appears allowing users to navigate, filter, chart, and analyze their data easily

through a URL link (Figure 11).

Figure 10 Variable Entry screen

Figure 11 BEx Web Analyzer report

Add the URL to Portal Site

In certain situations you might want to integrate the URL in an SAP NetWeaver Portal to present the application to the business customers. First, you or your IT personnel must have access to Portal Content Studio, which is an environment for developing and managing portal contents. There are several ways to create an iView.

Note

If you or your IT personnel are new to portal development, you should consult with the SAP NetWeaver Portal administrator to determine the appropriate place to develop your portal contents under the Portal Content folder hierarchy.

Develop an iView in the Development Folder

One way would be to develop an iView under your development folder by right-clicking a folder to open a drop-down list of options and clicking on New>iView. A new iView page and tab appears on the right side of the page. Accept a default option to use the iView template and click on Next.

Then, you should be presented with an iView template selection page. If you created a BSP application with IFrame functionality, select the SAP BSP iView template and click on Next. Enter the appropriate required iView name and iView ID fields.

When completed, click on Next. Choose either Application or Alias for the BSP definition type. We recommend using Alias because it is simpler.

Next, you come to the BSP Parameters page. For the system setting, choose the SAP NetWeaver BI system. For the BSP alias, enter sap/bc/bsp/sap/(insert your BSP namespace here) . Finally, enter the BSP application name ending with .htm in the Start Page option and then click on Next. This takes you to the summary page, which is the

final process of creating an iView. Click on Finish to complete the process and you should now see your iView under your development folder.

Note

If you don't see any system that uses SAP NetWeaver BI, contact the SAP NetWeaver Portal administrator for assistance or have the administrator create a new SAP NetWeaver BI system in the back end of the SAP NetWeaver Portal landscape.

Use the Web AD URL

If you did not create a BSP application, use the Web AD URL instead. First, right click your folder to open a drop- down list of options so you can click on New>iView. A new iView page and tab should appear on the right-hand side of the page. Accept a default option to use the iView template and click on Next.

An iView template selection page appears. Select the BI 7.x Web Application iView template option and then click on Next. Enter the appropriate names for the required Name and ID fields and then click on Next. The BEx Web Application parameters page appears in which you select the SAP NetWeaver BI landscape system for the System

option.

Note

If you do not see an SAP NetWeaver BI 7.0 system under the System options, contact the portal administrator to add one for you.

For Query String, inspect the template URL and enter the URL path that begins with TEMPLATE=(NAME OF WEB AD). When completed, click on Next for the iView summary page, and then click on Finish to complete the iView creation process.

Publish the iView in Web AD

Another way to create an iView is to publish the iView in Web AD to your development folder in SAP NetWeaver Portal. In Web AD, go to menu option Web Template>Publish>To Portal. Click on the selection icon to the right of the Folder field. Find your development folder, click on Transfer, and then click on Execute. Close the confirmation window, and then go to Content Administration in SAP NetWeaver Portal and verify that the iView is visible under the development folder.

Create a Portal Page

After you have completed creating or publishing an iView to your development folder, you need to create a portal page. The portal page presents the iView to the business users.

Right-click your development folder and then click New>Page. Enter the appropriate Page Name and Page ID, and then click on Next. Accept the default Page Template selection for the page and click on Next . We recommend choosing the 1 Column (Full Width) layout to fully display the application in the portal.

When completed, click on Next and then Finish to complete the page creation process. Select the check box to edit the object if it is not already selected and click on Next. To add the iView to the page, right-click on the iView under your development folder and select Add iView to Page>Delta link from the context menu (Figure 12). Figure 13

shows the result of adding the iView delta link to the portal page. Click on Save when you are finished.

Figure 12 Add the iView delta link to the page

Figure 13

After you add the iView delta link

Organize the Portal Page

You can organize the portal page using a portal role. Right-click on your development folder and select New>Role from the context menu to create a new role if you do not have an existing role. Enter the appropriate Role Name and Role ID and then click on Next. Finally, review the role creation process summary and then click on Finish. Accept the default option to edit the role object and then click on Next. The Role Object editor for the role appears on the right side of the screen.

Right-click on the role and select New Folder from the context menu to create a new folder under the role to serve as first level navigation if you do not have one already. Edit the new folder properties and change the Entry Point option to Yes to enable the folder to act as an entry point on the first-level navigation.

Click on Save to save your work. Right-click on the portal page you just created and select Add Page to Role>Delta Link to add the page to the role. The page appears on the second-level navigation. You can also add a second new folder to serve as the second-level navigation and then add the page under this new folder. With the latter option, the page link appears in the navigation on the left.

Assign Users and Groups

Now you can assign users or groups, such as Active Directory groups, to the portal role under User Administration

in the portal's first-level navigation (Figure 14). This allows business users to see a page that contains the template. If you do not see User Administration, consult your SAP Portal Administrator to give you the User Administration role or have the administrator add users or groups for you.

Figure 14 Template displayed in SAP NetWeaver Portal

Understand What Role MDX Plays in Third-Party Reporting Tools

by Scott Lawrence, Director, Product Marketing, Cognos

Third-party reporting tools generally use Multidimensional Expression (MDX) to generate reports and query multidimensional data sources in BW. The author explains the features and functions of the technology, the differences between shallow and deep MDX, and how it affects your BW resources.

Categories: BEx, Reporting

Multidimensional Expression (MDX) is the industry standard language used to query multidimensional data sources and generate reports in BW. It is typically used by third-party reporting tools.

Those of you who are interested in a non-SAP reporting solution to augment Business Explorer (BEx) need to understand the impact of MDX. Each tool uses it differently, and MDX affects your BW resources.

Over the years, third-party reporting tools have employed different levels of MDX. The level of MDX usage can impact your system and the capabilities you can realistically expect from them. I will explain the implications of deep versus shallow MDX support. I will also detail how MDX can support a self-service, Web-based reporting environment (ad hoc, standard reports, complex reports, pixel-level formatting for reports, easy interface, etc.), and how it can affect a broad base of users with limited BW knowledge and little to no technical skills.

MDX is not user-friendly like other query languages such as SQL, and it is not a language that you are likely to use yourself. It is run in the background by various applications, however, including third-party BW reporting tools.

Created by Microsoft, the MDX syntax offers many benefits. Perhaps its most attractive feature is that MDX is very flexible so it can be used on a range of platforms.

For BW reporting, third-party reporting tools generate MDX, which supports up to 15 dimensions, and passes queries through a BAPI interface behind the scenes to BW for execution. BW then hands the results back to the reporting

tools (Figure 1). BEx uses its own API, which is distinct from the published BAPI for third-party tools, and relies on two dimensions for results.

Figure 1 The MDX syntax passes queries via a BAPI interface to BW for execution, and hands the results back to the reporting tools in the same fashion

Deep MDX

In the past, third-party reporting tools used MDX at a simple level. This often limited the BW feature set that these tools supported, leaving gaps in the functionality that had to be managed manually by the IT group or power users to maintain report accuracy and integrity.

With simple or “shallow” MDX, older third-party tools generated a very basic request to the BW system, and the query results were brought back for local processing. The approach is similar to writing an SQL query, “select * from table1” and all data elements (columns) and all transactions (rows) are returned from the source. It is up to the query tool, then, to do any additional activities locally such as filtering, calculating, etc.

Processing data locally required duplicating hardware and infrastructure to effectively mirror the BW system’s query processing capability. It also meant that when the data was downloaded, the link back to the BW server was broken and the ability to leverage special aggregations (or semi-aggregations) implemented on the server was lost.

Relying on a simple level of MDX hampered third-party reporting solutions and caused problems for end users. Shallow MDX flattened hierarchies and caused other headaches such as ignoring free characteristics and limiting data to only the main cross-tab portion of a query, which often produced results inconsistent with those generated by BEx.

A growing number of third-party reporting solutions avoid many of the problems associated with their predecessors by generating more complex MDX and featuring an SAP-certified BAPI interface. While some will undoubtedly stick with an ODBO interface and may explore XMLA, I expect to see more generations of third-party tools based on the SAP BAPI interface and implementing deeper MDX. (For more details on these three interfaces, see “SAP BW Open Access Interfaces and Certified Front-end Tools: What IT and Query Designers Need to Know,” BW Expert, April 2003.)

With complex, or “deep,” MDX, more is incorporated into the statement sent to the BW system, so the entire query is executed on the BW server including filters, calculations, groupings, and more. By generating deep MDX, newer generations of third-party reporting tools are able to use the BW system more efficiently by reducing result sets, using precalculated aggregations, and optimizing the OLAP processor.

Deep MDX helps ensure that all query processing runs on the BW server and uses more of BW’s native capabilities such as:

Employing variables regardless of their association with free characteristic values

Recognizing hierarchies and maintaining parent-child relationships

Accessing aggregates and semi-aggregates maintained on the server

Representing accurate data values regardless of formatting such as rounding

Interpreting and rendering BW visual cues for currency codes and invalid results from bad calculations

With the latest generation of third-party reporting tools, the BW architecture and capabilities are being used more effectively and IT teams no longer have to maintain and duplicate processing power. The BW server is more fully leveraged by deeper MDX to do all the query processing. The results are successfully passed back to the reporting tool for formatting as well as for any additional value-add features such as scheduling, report bursting, and distribution.

Automatic Exposure of All BW Variables

Deep MDX allows third-party reporting tools to use variables including those associated with free characteristics. Variables are part of the business rules applied to queries, characteristics, and hierarchies in the BEx Query Designer. They improve the relevance of data for users and reduce the number of records returned. This improves system efficiency, lowering the load placed on the BW server and infrastructure.

Older reporting solutions that relied on simple MDX could not effectively accommodate free characteristics. Any variables associated with free characteristics were ignored. IT teams or power users were routinely forced to create new queries if their reports were to be generated with an older reporting solution so as to duplicate all free characteristics.

Frequently third-party reports based on queries with free characteristics would not match the results of a BEx report. This further compounded the workload because, to prevent erroneous data from being disseminated, reports had to be intercepted and reviewed for errors by BW teams and power users.

With deeper MDX, reporting tools can recognize free characteristics and render any associated variables as user prompts. The properties of these variables are automatically exposed. Reporting tools from some vendors accept BW default variable properties, and they may allow customization to control how these variables are exposed.

Parent-Child Relationships — Hierarchy Awareness

Reporting tools that rely on simple MDX generation often flatten hierarchies, breaking parent-child relationships. As a result, when performing calculations on values that exist for those relationships, problems arise because some values are prone to duplication and any calculations based on these values are inaccurate.

For example, Figure 2 provides the results of a query researching sales quantities for products by their order method. Two levels from the product hierarchy are included — Product Line and Product Type. You can see the parent-child relationship exposed in the groupings: Camping Equipment is the parent and the children are Cooking Gear,

Tents, and Sleeping Bags. The Result entries are the sum of the children for each parent totaled for each group break point.

Figure 2 BEx query showing parent-child relationships and hierarchies

If a report is generated using simple MDX, the hierarchies could be flattened. Table 1 shows what the results might look like in such a situation. Note that the individual values for each of the Product Type entries are erroneously

combined with the totals for each Product Line. The end result doubles the actual total quantity sold for the products.

Order Method

Product LineProduct Type Quantity

Email      

  Camping Equipment   68,252

  Camping Equipment Cooking Gear 31,152

  Camping Equipment Tents 21,566

  Camping EquipmentSleeping Bags

15,534

  Mountaineering Equip   32,734

  Mountaineering Equip Rope 6,326

  Mountaineering Equip Safety 3,708

  Mountaineering Equip Climbing

    Equipment 22,700

      201,972

Fax    

  Camping Equipment   22,716

  Camping Equipment Cooking Gear 10,966

  Camping Equipment Tents 7,720

  Camping EquipmentSleeping Bags

4,030

  Mountaineering Equip   10,980

  Mountaineering Equip Rope 2,662

  Mountaineering Equip Safety 1,176

  Mountaineering Equip Climbing

    Equipment 7,142

      67,392

Table 1 Potential inaccuracy resulting from not maintain- ing parent-child relationships

Faced with this report, users must identify and choose the appropriate hierarchical levels and the corresponding values. If that task fell to a less-experienced end user, or if a more complicated report with more hierarchies was required, inaccurate results are likely. IT personnel or power users could intervene and use programming to hide or remove the duplicates. However, such a solution is manually intensive, not always accurate, and could be forgotten in the reporting process — not to mention costly to implement and maintain.

Deep MDX enables reporting tools to maintain hierarchy awareness and accurately reflect parent-child relationships. As a result, users can build accurate reports without manual intervention.

Visual Cue Support

Another problem with simple MDX is that it often fails to recognize BW indicators for visual cues. BW inserts special formatting and other visual cues in reports so users can recognize instances such as when multiple currencies are being displayed or if numbers have been rounded. Without these formats and indicators, it is easy for users to make mistakes such as totaling unlike currencies or units of measure, thinking the results are valid numbers, or mistakenly view rounded values as actual accurate numbers.

For example, Figure 3 represents revenue numbers reported with BEx that have been rounded up to the nearest $1,000. The visual cue is the indicator at the top of the Revenue column — *1,000 $. Without this cue indicating that

the values should be multiplied by $1,000, the values in Table 2 might be reported, which are obviously wrong. It would be up to the recipient of the report to determine what these numbers represent.

Figure 3 A BEx report showing Revenue rounded to the nearest thousand

Calendar year

BrandRevenue

1993 ACME DISHWASHERS 79.14

1993 ACME MICROWAVES 55.08

1993 ACME STOVES 123.28

1993 AUTOKITCHEN DISHWASHERS 36.66

Table 2 Without the proper formatting or visual cues, these values would be easily misinterpreted

Visual cues are critical for discerning among values when multiple currencies and multiple units of measure appear in a report. Default formatting in BEx uses symbols to differentiate between currencies and measurements to eliminate the possibility of confusion.

Currency and units of measure symbols present a problem for third-party reporting tools not using complex MDX. If such cues are not embedded in the same cell as the values or do not appear as part of the result set from the query, the potential for misinterpretation is high. Doing other calculations that cross multiple currencies or units of measure further compound the errors.

Deep MDX in the latest generations of reporting tools is able to recognize BW indicators for invalid numbers and automatically apply the default formatting. These tools also offer cell-level formatting to embed the symbols for currency or unit of measure in the appropriate field and accurately reflect the correct formats for different currencies.

Other Benefits of Deep MDX

Reporting tools that fully employ MDX can leverage BW global business rules, including multilingual metadata as well as currency conversion capabilities. All fields can have multilingual descriptions, titles, and content. MDX support

allows reporting solutions to recognize that there are multiple languages available from BW. At run time, the report can pick up user language preferences and the same report can be displayed using the different languages available changing the report or rebuilding the report multiple times.

In addition, deeper MDX is able to leverage aggregates and semi-aggregates in the BW system. Simple MDX often breaks the ability to use aggregates and may produce different results than what should have come from applying the BW aggregates.

Congnos ReportNet: Deep MDX Support

Cognos ReportNet generates complex MDX through a certified BAPI interface. I’ve highlighted how complex MDX and the SAP-certified BAPI interface support BW in some key areas so as to ensure the accuracy of query results and reduce the impact on your system.

Automatic Variable Exposure

The MDX in Cognos ReportNet recognizes all variables associated with BW queries, including free characteristics, regardless of whether the characteristic (or hierarchy) associated with the variables is included in the report.

At report execution time, the query is sent to BW, which provides values for the active variables. ReportNet automatically reflects the variables’ properties, including if they are mandatory or optional; single-select, multi-select, or interval; etc. My firm’s reporting tool also supports administrator-defined augmentation to the way variables are exposed to the user, including things like prompt type to represent the variable and inserting a default value.

In Figure 1, the query includes a mandatory, multi-select characteristic variable and filters the results based on Order Method. The selections are passed via MDX back to BW to complete the query, ensuring all mandatory variables are addressed. Because MDX exposes all the variables associated with a query, all variable types — an

optional, multi-select, characteristic variable, for example — can be applied to a presentation hierarchy (Figure 2).

Figure 1 Mandatory, multi-select prompt driven by a char- acteristic variable from SAP BW on Order Method using Cognos ReportNet

Figure 2 Optional, multi-select hierarchy prompt driven by a hierarchical node variable in SAP BW focused on Sales Region

Cognos ReportNet generates the MDX to leverage BW’s currency-conversion business rules and applies exchange rates to various local currencies so they can be displayed as a single, selected currency. This approach can be applied to sales numbers, expenses, and more.

Hierarchy Awareness

Cognos ReportNet understands and maintains relationships within BW hierarchies. Reports ensure calculations across multiple levels of the same hierarchy are accurate. The tabular results of a query crossing Product Line and

Product Type in the Product hierarchy is presented in Figure 3. While these results are the same as those found in a BEx report, it is only a part of a more complex report.

Figure 3 Tabular results of a query crossing Product Line and Product Type in the Product hierarchy

Rounding and Visual Cues

The MDX generated by Cognos ReportNet identifies when BW has applied special formatting. When rounding, for example, the actual number is displayed in the report. Currency and unit of measure are rendered so that symbols are automatically inserted in the same cell as the values. An asterisk also is inserted in the cell of a value if it is an invalid number.

Currency symbols and formatting are automatically passed from BW directly into Cognos ReportNet reports. They remain in the same field as the values to ensure that there is no confusion if multiple currencies are displayed.

Multilingual Reports

As Cognos ReportNet submits the MDX to BW, it indicates the user’s geographic location by sensing the browser settings or ReportNet preferences. The resulting report, which is run by different users from different geographies, displays the information in the appropriate local language. ReportNet also applies formatting for currencies and dates to reflect local conventions such as presenting the date order in the U.S. as month, day, year versus day,

month, year for Europe and other regions (Figure 4).

Figure 4 User locale or preferences determine the language displayed at run time such as the English and a German version of the same report

Use Excel Workbooks for Attractive, Easily Maintained Reporting Front Ends  

by Simon Ferres, BW Team, Barclays Capital

Sometimes, the standard BW options for supplying your business with reporting tools just aren't enough. Additional reporting power is available from Excel worksheets, which when used in conjunction with BW queries result in graphically impressive reporting front ends that are simple to maintain.

Categories: BEx, Reporting

Key Concept

Solutions workbooks are Excel spreadsheets linked to BEx Analyzer queries via Visual Basic that are used for a

front end. Via BEx Analyzer, solution workbooks provide for reporting that combines data from multiple ad hoc queries from the same (or different) InfoProviders in a solution that end users can maintain themselves. They also can be employed for ad hoc reporting that combines BW data sources with offline or other non-BW sources of data, which don’t adhere to the master data and metadata stored in BW.

BW offers a substantial array of features in its so-called “presentation layer” so you can create versatile, intelligent, and graphically impressive Web and Business Explorer (BEx) front-end tools. Sometimes, however, your reports need more than what the BEx Analyzer alone can provide. A simple remedy to the dilemma is solution workbooks, which combine BEx queries with Microsoft Excel worksheets for business intelligence reporting.

The solution workbook uses BEx Analyzer queries linked via Visual Basic functions to an Excel worksheet used as a front sheet. Its simple design and construction enable the BW developer and more technically able end users to link multiple BEx queries and other sources of data within Excel for BW reporting.

I will help you decide whether BW solution workbooks are right for you and your end users. Then, I’ll walk you through the development process for solution workbooks. In a future issue of BW Expert, I’ll show you how to maintain your solution workbooks after you’ve set them up for your business reporting.

Note that while developing solution workbooks is not complicated, it requires basic knowledge of Visual Basic. In addition, you need to know basic Excel functionality such as using logic to add formulas to a workbook.

Are They Right for You?

Solution workbooks are a great way of generating reports that don’t adhere to the master data and metadata stored in BW. They also provide for reporting via the BEx Analzyer that combines data from multiple ad hoc queries from the same (or different) InfoProviders in a solution that end users can maintain themselves. Other examples of when BW solution workbooks fit the bill are when your ad hoc reporting requires combining BW reporting with off line or other non-BW data sources, or you need more advanced report formatting via Excel.

Consider who will be using the reports. The beauty of adding front ends to your BEx queries using this simple approach is that modifying workbooks is relatively easy. It’s also a process that your more savvy users can undertake with sufficient training.

Typically, solution workbooks are built and used by authors and analysts. This group performs more advanced analysis work using BEx as well as ad hoc explorations and report development. Initially, your development team will be responsible for gathering the data, ensuring that it is translated properly, and building the solution workbook. With training, however, you can pass this development back to the authors and analysts.

Other Reporting Options

I can’t detail the pros and cons of all the various reporting options in this article, but let’s look at some of the more popular ones relative to solution workbooks.

Introduced with the BW 3.1 Content Release, the Analysis Process Designer (APD) allows users to merge data sets and store the merged data in an ODS for subsequent reporting on an InfoSet. However, my experience tells me that these reports, if they don’t follow the BW structures, can change frequently. No such overhead is required in this scenario with the Excel solution, and users can maintain it.

BW 3.5 offers a new precalculated workbook option that should cut down on the overhead and improve performance, but that functionality will only be available in the most recent release of BW — not a solution if you’re not ready to upgrade.

Crystal Reports offers BW users a robust optional reporting tool and shares some of the features of solution workbooks, but this technology requires upfront configuration not needed for solution workbooks. While it offers similar query merging capabilities, it costs extra after your first 10 reports. In addition, Crystal Reports follows the

structures held in BW and does not support spot picking specific nodes from a hierarchy, selecting across levels, etc., which you can do with solution workbooks.

Web reports are faster than the Excel-based solution I’m proposing and do not require client- installed software like solution workbooks. However, they often are not as straightforward as solution workbooks. Also, Web-based reports do not offer self-sustainable solutions for users because they require a developer’s input. Web reports also struggle in much the same manner as Crystal Reports to produce reports that do not conform to BW structures.

Required Planning

Once you’ve decided that solutions workbooks are right for you, a certain amount of planning is essential regardless of the flexibility they provide. A clearly defined set of reporting requirements is important, but not necessary. However, failure to spend sufficient time analyzing your business needs can lead to inefficiencies in the workbook design and result in increased maintenance overhead. You run the risk of system performance degradation due to excessive BEx query runtimes as well as failing to create the desired self-sufficient user-supportable model.

I suggest that you create a matrix that details all your requirements, report by report. Some areas of consideration that should be in your matrix are:

Reporting fields

Hierarchy view vs. structure attributes

Time dimensions

Other non-BW sources of data

Look and feel of report format

Next, determine the sources of data you’ll require, including which InfoCube and query are needed. This allows you to spot any overlap and gain efficiencies by identifying where the solution workbook presentation pages share data that can be derived from shared queries — eliminating duplication.

Note

If your business structures are such that they ensure both the key and text are displayed against each record, it may seem that using them as a front-sheet reference is not good practice. Displaying both, however, makes locating the correct key much easier, so you should consider this approach.

InfoProvider Selection

In most cases, you’re not required to select an InfoProvider as a data source for your solution workbooks. If faced with a number of InfoProviders as potential data sources, however, you will have to choose. You would be wise to ask a few standard questions before making your pick.

Look at the volume of data stored in an InfoProvider before you select it and ask if the data is available from one with fewer records. If you are tapping only 5 percent of the data stored in an InfoProvider, you may want to choose a smaller one.

You also need to determine that the data is refreshed frequently enough to satisfy the demands of the reporting. In addition, check to see if any feedback or negotiations are required from other business units and make sure the requirements of your service level agreements (SLAs) are met. SLAs may be in place that determine the number of data refreshes performed during a day, week, month, and modifying the frequency or timing of these refreshes may affect established SLAs.

Also, remember to check that your report performance is optimized. If the report is based on a summarized view of the InfoProvider data, for example, make sure the InfoProvider has aggregates that will be hit by the report. See if other performance-improving features are available such as aggregates on hierarchies, which I’ll detail further next.

Best Queries

Poor query management can substantially hamper the performance of your BW system, and solution workbooks offer you a way to improve this. Managing BEx queries from within solution workbooks puts control of the query engine room in your hands. Adding, removing, and creating views are all actions that the user can take within the solution workbook to create the necessary data source.

Using queries that include unnecessary hierarchies, key figures, etc. can result in solution workbooks that take longer than necessary to refresh. Worse still, this situation can lead to a number of users running poorly designed workbooks in parallel, which can degrade performance. Adding more solution workbooks exacerbates the condition. The unnecessary use of a hierarchy within a solution workbook in isolation may not have much impact on system performance. A suite of solution workbooks, however, all running with the same problem hierarchies may throttle down performance.

The best queries are simply constructed but flexible enough to get the job done. There is no hard and fast rule for query selection, but I can offer a couple tips. Take out any unnecessary key regardless of whether it is displayed because each will be calculated at runtime. When the list of items is relatively small, avoid using exclusions and make “includes” rather than “excludes.” Also, avoid using hierarchies where possible. Hierarchy queries are slower to refresh than queries containing the hierarchy as attributes.

When determining which queries to use, it is important to consider who is responsible for managing the queries. This includes both the ongoing maintenance and any further development. Queries can be used throughout the business by any number of teams, so it is important to identify up front where conflicting requests might affect the query used in the solution workbook. I’ll discuss this in more detail later.

Preparing the Code

As I noted earlier, my approach to building a solution workbook requires a working knowledge of the standard Excel functions in Table 1. You also need to use the additional non-standard function (MATCHMULTILINE), which is

available at the Download Section of the BW Expert Web site (www.BWExpertOnline.com).

Standard function

Performs

CONCATENATE Joins several text strings into one string

IF Checks whether a condition is met,and returns one value if TRUE, and another value if FALSE

INDEX Returns a value or reference of the cell at the intersection of a particular row and column,in a given range

INDIRECT Returns the reference specified by a text string

ISNA Checks whether a value is #N/A,and returns TRUE or FALSE

MATCH Returns the relative position of an item in an array that matches a specified value in a specified order

ROUND Rounds a number to a specified number of digits

Table 1 Standard Excel functions used in solution workbooks

MATCHMULTILINE returns the absolute column reference matched for two ranges within a workbook. This typically means matching column headers in the front sheet to the column headers in the query range.

Creating Your Solution Workbook

First, copy and paste the MATCHMULTILINE code at the BW Expert Web site into the SAPBEX module using the Visual Basic editor (Figure 1). Next, using the BEx Analyzer, insert the BEx queries you selected as your data

sources. Leave the first column free and place one query per worksheet into cell B1, which is the cell in the first row of the second column. Then refresh, filter, and drill down or across to create the necessary view for the workbook’s front sheet to source its data.

Figure 1 Add the custom MATCHMULTILINE code to the SAPBEX moduleclick here to view a larger version of this image

Tip!

If you need to remove a query from a workbook during the build phase or at any point when the workbook is live, make sure to use the Remove Query option in the BW toolbar. Simply deleting the worksheet does not remove the query from the workbook!

With both the code and BEx queries in your solution workbook, you can build the frontend. Use the INDEX function to find the intersection of a column and row reference from a data range. The data cell can move both longitudinally and laterally as a result of the query refresh, and locating the intersecting column and row reference with the INDEX function overcomes this problem. The column reference is the key figures or characteristics you drilled across in the

BEx query; and the row reference is the characteristic (Figure 2).

Figure 2 BEx query drill-down reference pointsclick here to view a larger version of this image

Use the CONCATENATE function, which joins several text strings into one string, to bring together each of the keys on the adjacent row from the query result range so the front sheet can derive the row reference. Add two ranges to your BEx query worksheet. The first contains the reference column added in the previous step, which is displayed as DATANAME in Figure 3. The second range represents the entire query result range. The workbook front-sheet code uses this range to locate the intersection of the row reference range DATANAME and the column reference found via

the function MATCHMULTILINE. For this example, I’ve called it DATA (Figure 4).

Figure 3 Range DATANAMEclick here to view a larger version of this image

Figure 4 Range DATA click here to view a larger version of this image

Insert Formulas

The front sheet contains three formulas to reference the rows and columns of the query and uses these intersections to bring back the data from the ranges I mentioned earlier. The row reference formula copies the key based on the concatenation of the query drill-down keys to the first column of the front sheet and provides the row reference. The second formula determines the column reference using the MATCHMULTILINE function to match the column in the query with the header in the front sheet. The third formula indexes the row and column references and searches the range DATA to locate the cell containing the relevant data.

Let’s look a little more closely at each of these three formulas and see how they are used in an example solution workbook that spot picks and reports specific levels or areas within a business structure. This process calls for locating a key based on the concatenation of the drill-down keys from the query and copying it to the first column of the front sheet. The first formula locates the row reference, which is added to discover the row reference/number. The logic for this formula is:

=IF(ISNA(MATCH(A10,INDIRECT($B10&”Name”),0)),0,(MATCH(A10,INDIRECT ($B10&”Name”),0))).

In this example, cell A10 is the concatenated key taken from the BEx query and cell B10 is the range. DATA becomes DATANAME via formula. The second formula is:

=MATCHMULTILINE(Queryworksheet!30:32,’FrontSheet’!J1:J3).

It finds the column reference using the MATCHMULTILINE function and identifies the column in the query that the header in the front sheet matches.

The last formula, which uses the indexing function, is:

=ROUND(INDEX(INDIRECT($B16),$C16,J$5),J$7)/J$6*J$8

It indexes the results of the other two formulas and searches the range DATA to locate the cell containing your data.

Having connected the front sheet to the BEx query via the steps outlined above, you can now bring the front end of the solution workbook to life. It may contain one or more BEx queries brought together in the presentation front end

(Figure 5), or you may want to add links to other non-BW data sources, insert graphs, text fields, etc.

Figure 5 A formatted front end with two BEx queries as the data sourceclick here to view a larger version of this image

Use the Report-Report Interface to Enhance Filtering in Your Reports  

by Iliya Ruvinsky, BW Consultant, NESS, A.T.

The report-report interface supports drill-through functionality to jump from one report to another. The author explains how more robust filtering can be added via the interface as users drill through two reports.

Categories: BEx, Performance, Reporting

Glossary

The report-report interface lets you link together reports that contain a limited number of characteristics so that you can report on a number of different combinations of data online. This helps you to avoid the problem of having particularly large reports with volumes of data that they cannot be constructed online and have to be planned as a background job.

Recently, a client came to me looking for a way to monitor complaint messages after they were opened. The client added a twist by requesting the ability to identify additional complaints received after the initial problem was corrected via drill-through functionality. This required a little ingenuity.

The solution I came up with offers end users a great tool that provides enhanced filtering. I built two reports — a sender and a receiver. The reports have the ability to interact with each other so users can drill into a report and learn if other complaints are registered after a problem is resolved. Using my approach, end users are able to apply characteristic values that differ from the characteristic values that were just filtered. To do this, BEx technology and the Web Application Designer (Web AD) need to work in concert via the report-report interface.

The sender report I created passes filter parameters to the receiver according to the appropriate navigation results. For example, if during navigation the sender report is filtered by the parameters Cal. Year/Month = 04.2003 and Attendee = 00029032, then these parameters are delivered as filtered to the receiver report when an end user drills through the sender. My client wanted the Cal. Year/Month parameter delivered in such a way that the receiver would apply the filter itself to all values less then or equal to 04.2003 (e.g., Cal. Year/Month <= 04.2003) instead of just being filtered by 04.2003 (e.g., Cal. Year/Month = 04.2003).

First, I’ll show you the problem I faced in the BEx environment, when I’ll expand the focus to the Web AD implementation.

The BEx Solution

Before I detail the solution, you’ll need some background information. My client had BW 3.0B with Patch 11 implemented, but my approach can be used with all BW 3.x systems. I used InfoCube 0PE_C02 (Professional Training Provider) and both the sender and receiver reports in this example have identical structures to demonstrate the drill-through parameters in each.

First, create a receiver report and insert the Date characteristic in either the Free Characteristic, Filter, Rows, or Columns of the BEx Query Designer. I used characteristic 0CALMONTH in this case.

Next, I created the variable ZRECEIVE to restrict the Date characteristic by setting the Processing by field to User

Entry / Default Value. The variable properties are presented in Figure 1.

Figure 1 Set the Processing by field to User Entry / Default Value when you create your custom variable (ZRECEIVE)

Restrict the Date characteristic in step 1 with the variable established in step 2. The Selection field must be set to Value Range but the selection restriction can vary. Depending on your needs, restriction options can include Between, Greater than or equal to, Less than or equal to, Greater than, or Less than. I used the Less than or equal to option to receive filter parameter Cal. Year/Month = 04.2003 and filtered it such that Cal. Year/Month <= 04.2003.

Now, create the sender report with the same Date characteristic used for the receiver report. Define it as the report sending parameters and the receiver as the one receiving them via transaction RSBBS. Run the sender report and

filter it by a single date value (0CALMONTH = 04.2003) while navigating (Figure 2).

Figure 2 Run the sender report and filter it while navigating

Drill through the sender to jump to the receiver report. Because the variable is inserted into the Free Characteristics area in the BEx Query Designer, you cannot see how the 0CALMONTH characteristic is filtered after bringing up the

results. To show the filter, follow the menu path Layout>Display text elements>Filters in the BEx toolbar. Figure 3

shows that the receiver report is filtered on a Date characteristic and the filter definition is 0CALMONTH <= 04.2003.

Figure 3 The receiver report is filtered on a Date characteristic

Note that if you drill through the receiver report without first filtering on a Date characteristic in the sender report, the receiver will prompt you to enter a date. This is because the report did not receive a Date parameter from the sender report and its variable is defined as Mandatory and Ready for Input, so it must receive a Date parameter. You will get the same prompt if you run the receiver report alone.

The Web AD Solution

Instead of launching sender and receiver queries in a Web browser from within BEx environment, I created two Web reports — one for the sender and one for the receiver — in the Web AD that are independent of the BEx reports. In addition to enhanced query performance, this approach allows for a better front-end architecture and easier access to the reports repository.

Open the Web AD and create the report SENDER_WEB. Select the BEx sender report as DATAPROVIDER and create the RECEIVER_WEB report based on the corresponding BEx report.

In the BW environment, execute RSBBS and access the Maintain Sender/Receiver Assignment screen. The BEx sender report is listed in the Query tab along with the BEx receiver report, which was previously defined. It is located in the Receiver section of the screen.

Press Shift+F4 for the Report Assignment prompt and select the BW Web Application option under the Report

Type tab. In the Report section, locate the RECEIVER_WEB report (Figure 4), and press F8 to transfer your selection.

Figure 4 Locate the RECEIVER_WEB report and transfer selection

Now you are able to drill through from your SENDER_WEB report to the two queries in Figure 5. The difference

between the two is that RECEIVER_WEB report is custom designed to meet the customer’s needs.

Figure 5 You can add more Web AD elements to enhance your reports

You can add more Web AD elements and enhance the RECEIVER_WEB report. For example, you could add a filter element like I did to the report template to display how the report is filtered. Various other options are also available via the Web AD including changing the visual appearance of the report. The BEx receiver report is available in the

Goto option of the SENDER_WEB report and can be displayed through a Web browser. This is the default option and based on a standard SAP template that cannot be changed or edited.

Use Virtual Time Hierarchies for Flexible Reporting with Time Characteristics  

by Lorne Kellaway, Senior Business Systems Analyst, Alcatel-Lucent Canada Inc.

Activating virtual time hierarchies provides a flexible and convenient option for reporting on time characteristics. Not only is it simple to implement, it can immediately increase the functionality available to query designers and users. It can deliver reports with summary time groupings on existing time characteristics (based on 0DATE, 0CALMONTH, 0CALMONTH2, and 0FISCPER) with no changes required to the data targets.

Categories: BEx, Data Modeling, Reporting

Key Concept

Virtual time hierarchies allow users to report time-related characteristics in various hierarchical layouts without creating custom hierarchies or including such functionality in the design of data targets.

Have you ever been required to provide a summarized monthly report based on an InfoProvider that contains only a date field as a time characteristic? How about providing the same data by year (fiscal or calendar) or even in weekly buckets? What do you do with InfoProviders with multiple date fields? Should you include month and year data for every date field in a data model just in case there is a need to report on those dates in an aggregated manner?

For example, assume you have a requirement to determine the monthly usage for the BW system, but the BW

Statistics InfoCube (0BWTC_C10) contains only a calendar day (0CALDAY) time characteristic. How can you complete this request in a timely manner and also be able to re-use it as needed?

Note

The virtual time hierarchy functionality is also available in SAP NetWeaver 2004s where the standard content version of fiscal year/period (0FISCPER) also has hierarchies available. The standard content version of 0CALMONTH no longer supports hierarchies in SAP NetWeaver 2004s. However, if the InfoObject is modified to allow hierarchies (using transaction code RSD1), you can retain the virtual time functionality. Similarly, in prior versions, you can enable hierarchies in 0FISCPER to allow virtual time hierarchies on that characteristic as well.

While several options exist, from incorporating additional characteristics in the InfoCube to executing macros on the results, the use of virtual time hierarchies allows you to quickly and easily address this requirement. Once implemented, the hierarchies are available for use on any InfoProvider containing the relevant time characteristics, thus immediately expanding time-based reporting opportunities.

Since BW 3.0, virtual time hierarchies have enabled users to display certain date fields as a fiscal- or calendar-based hierarchy, such as year, month, and quarter. For example, you could use 0DATE, or any characteristic created as a reference to this InfoObject (such as 0CALDAY) to display data in various time groupings. This option is also available for certain other time characteristics or any time characteristic created as a reference to these particular

InfoObjects. Table 1 summarizes the characteristics available as virtual time hierarchies.

Virtual time characteristic

Base InfoObject

Hierarchy levels (*)

Date 0DATE By year, quarter, month, week, weekday, fiscal year, fiscal year/period, posting period, half year splits

Calendar year/month 0CALMONTH By calendar year, quarter, half year split

Calendar month 0CALMONTH2 By quarter, half year split

Fiscal year/period 0FISCPER By fiscal year

* Requires certain InfoObjects (0HALFYEAR1, 0CALQUARTER) to be activated. Also, the content version of the active InfoObject may affect what you can see in the hierarchy (e.g., key vs. name).

Table 1 The characteristics available for virtual time hierarchies and the various hierarchy levels available for each

If an InfoCube holds several date-related characteristics (i.e., created with 0DATE as a reference object), you can, using virtual time hierarchies, report any or all of these time-based InfoObjects on a calendar or fiscal month grouping. You can do this with no design impact and at the full discretion of the BEx Query creator or user (when changing the local definition of the query). Of course, other options may be available to facilitate such reporting, including custom time hierarchies or additional characteristics in the data target. However, these options could increase both design effort and confusion to the end user.

You cannot create additional virtual time hierarchies, but are limited to those delivered (several are automatically derived for each fiscal year variant on the BW system). The delivered hierarchies cover many scenarios and should be suitable for most time reporting requirements.

Configuring Virtual Time Hierarchies

You activate virtual time hierarchies via the configuration menu (Figure 1) or transaction code

RSRHIERARCHYVIRT.

Figure 1 Configuration path for virtual time hierarchies

Use the two tabs on the screen (General Settings and Virtual Time Hierarchies) to activate hierarchies for specific time characteristics (0DATE, 0CALMONTH, 0CALMONTH2, and 0FISCPER).

The General Settings tab has three input sections (Figure 2). Of these, only Time Interval is directly related to virtual time hierarchies, but an overview of each follows:

Time Interval: The Time Interval setting is an integral component of the virtual time hierarchy’s process and controls the entries made in the hierarchy SID table (K table) of the underlying InfoObject. Refer to Figure 3 for the contents of the K table for 0DATE as seen in the 0CALDAY InfoObject (which references 0DATE). The table entries do not hold the time interval values until initially accessed via a query. The system adds the entries to the table on a hierarchy-by-hierarchy basis. As the time interval shifts, the K table entries reflect the new range for each hierarchy. Records are not removed unless you deactivate a time hierarchy. Time Interval controls the size of the virtual time hierarchies available within the query. Try to strike a balance between having a range large enough to meet reporting requirements but not too large to be unwieldy. Ensure sufficient periods are populated for any fiscal year variant to be used as a hierarchy since this can cause errors on query execution. The fiscal periods should include one year prior to the interval.

Factory Calendar: The factory calendar is used for certain OLAP functions, such as the exception aggregation AV2 (average weighted with the number of working days according to the factory calendar). These functions would use the factory calendar specified here.

Master Data Texts for Time Characteristics: This option controls the display of the fiscal year/period

(0FISCPER) text to use either the true fiscal year or the calendar year. This setting is relevant only if you have fiscal years that are offset from the calendar year. For example, if you have a

fiscal year that is offset from the calendar year (i.e., calendar year 2005 is actually fiscal year 2006), you see different text for the fiscal periods in query results depending on the setting you make here.

Figure 2 General Settings tab for virtual time hierarchies

Figure 3 K table for 0DATE as seen in 0CALDAY (which uses reference characteristic 0DATE)

The Virtual Time Hierarchies tab (Figure 4) contains the available characteristics in the left panel (based on

0DATE, 0CALMONTH, 0CALMONTH2, and 0FISCPER). When you select a characteristic in the left panel, the panel on the right displays the different hierarchies for that object.

Figure 4 Virtual Time Hierarchies tab displays hierarchies for selected objects

Note

The SAP class BW330, BI Modeling and Implementation (for SAP NetWeaver 2004s) or BW330, SAP BW Modeling (for BW 3.5), provides further information about data modeling. This is an advanced BI class, so be sure to check the course prerequisites. For further details, visit www.sap.com/useducation.

In Figure 4, Date is selected, presenting the hierarchies available to the 0DATE characteristic in the right-hand window. To activate a hierarchy for an InfoObject, either double-click on a hierarchy in the right panel or drag and drop it to the lower portion of the screen. Once you activate it, you can rename the hierarchy to better reflect its

purpose by typing in the appropriate short, medium, and long descriptions (Figure 5). You can also specify the default starting level of a hierarchy in the lower portion of the screen. The starting level can also be set in the query definitions.

Figure 5 Activated time hierarchies for 0DATE with modified descriptions

Once activated, the hierarchies are available for use in queries. As noted earlier, these hierarchies are pre-delivered and dependent on the activation of underlying InfoObjects (e.g., 0HALFYEAR) as well as the activated version of the time characteristic InfoObjects. There is no way to create or modify the available hierarchies. Activating them makes them immediately available for reporting activities. No explicit option is available in transaction RSRHIERARCHYVIRT to transport the activated hierarchies. If activation directly in a production system is an issue, you need to investigate manual transports.

Using Virtual Time Hierarchies

Once you activate them, you can use the hierarchies on any characteristic based on the hierarchical time InfoObjects (e.g., any characteristic referencing 0DATE, 0CALMONTH, 0CALMONTH2, and 0FISCPER).

Recall the requirement at the start of this document to determine the monthly usage of the BW system from the BW statistics InfoCube (0BWTC_C10), which contains only the 0CALDAY time characteristic. Figure 6 shows the active

hierarchies available to use for the calendar day (0CALDAY) InfoObject (based on 0DATE) when a designer restricts on that characteristic while creating a query.

Figure 6 Activated time hierarchies for 0CALDAY (based on 0DATE) as available within a query

Note

Some of the hierarchies (especially for year values) are redundant and not all should necessarily be activated. A suggested approach is to activate a set of hierarchies and then review them in a query using a hierarchy and node variable to better determine those that are useful.

As the system initially accesses hierarchies from a query, either on execution or by displaying as values of a hierarchy variable, the associated hierarchy SID (K) table is populated to reflect the time interval set in transaction

RSRHIERARCHYVIRT if entries do not already exist in that range. You can apply a virtual time hierarchy to the

0CALDAY object in the BEx Query definition (Figure 7).

Figure 7 BEx Query definition to use year/month hierarchy and a node variable applied to 0CALDAY

When the query is executed, the user will be prompted to enter a time period (based on a hierarchy node variable). The results include a year and month grouping of system activity with the ability to drill down to days if desired

(Figure 8). This addresses the requirement for monthly distribution of activity, and as with any query, you can make further layout changes to provide desired results. You could have months across the top and users in rows to present monthly distribution by user.

Figure 8 Query results for monthly system usage using a time hierarchy applied to 0CALDAY

As seen in Figure 9, the context menu (right-click on a characteristic cell) for these hierarchies is also unique since it provides more detail than the generic node level expansion usually available for hierarchies. As with any hierarchy, you can create variables to prompt the user to select not only a hierarchy node, but to specify the hierarchy to be used, which further enhances the flexibility of these hierarchies. Therefore, a user can have a single query that can present a calendar or fiscal view of the data depending on the hierarchy selected at execution.

Figure 9 Context menu in query result for time hierarchy on 0CALDAY

To minimize the number of variables, create them for the reference characteristic (e.g., Date) vs. the object in the InfoCube (e.g., Calendar Day). This is an option when creating the variable in the General Information window in the SAP BW Variables Wizard (Figure 10). With this approach, you can re-use the same variables to select a time hierarchy or node for many characteristics, not just those for which they are specifically created. In the example in

Figure 10, this variable is available to be used for other characteristics based on 0DATE, not just 0CALDAY.

Figure 10

Create the variable on Date vs. Calendar Day

Considerations

As with most configurations, you should review SAP Notes for the most current changes. For example, SAP Note 930521 may be a relevant note resolving a problem in which the time frame available for the query restriction does not reflect what is set on the General Settings tab (Figure 2).

It is also critical to ensure that periods exist for all relevant fiscal variants, not only for the range set in the General Settings tab, but also for a year prior to the range. If the prior year does not exist for a fiscal variant, you will encounter errors in either BEx Query Designer or during query execution when using a hierarchy relevant to that fiscal variant.

If a user is not prompted for variable input of the virtual time hierarchy nodes, the hierarchy is display only and acts as a dynamic filter. The filter limits the output to the data that exists for the time interval specified on the General Settings tab. The user receives a warning message to that effect at the time the display hierarchy is included in the results. This message re-appears during any navigation unless warnings from the server have been suppressed. You can suppress such warnings in BEx Analyzer via Setting>Suppress warnings from server. However, other warnings could be useful (e.g., missing exchange rates), so you need to take care when suppressing warnings. While it does have some limitations, the virtual time hierarchy functionality can provide a useful solution to date characteristic reporting requirements with minimal, if any, development required.

Web Application DesignerCreate Multiple Reports from One Report with a Drop-Down Box Function  

by Yasan Gooding, Ph.D.

Often, there is a need to recreate the same queries and Web reports to change a small feature such as a different unit of measure. The author shows you how to avoid this by creating one flexible report, containing many similar reports in one report, with the drop-down box functionality of Web Application Designer (3.0 or higher).

Categories: BEx, Reporting, Web Application Designer

You have seen it before; you have heard it before. A business user has requested that you recreate an existing report in BW for the Web using key figures that are different from the existing report in other uniform measurements like dollars, pounds, or kilograms. Chances are likely that other combinations of key figures in different units of measure will eventually lead to the creation of a new query with the same basic characteristic and filter requirements, but with different combinations of key figures in other series of measurements.

Before you resign yourself to creating multiple queries and Web reports, consider the alternative that Web Application Designer (Web AD) 3.0 or higher offers. A customized drop-down box function used with your BEx Analyzer query gives you the flexibility to create several reports in one report, showing each group of key figures by category in a drop- down box in your Web application.

Even though the Web AD has its own standard drop-down box Web feature, it is used mainly for filtering characteristic values and individual key figures. It does not display a series or combination of key figures together. When the item is launched to the Web, you see individual values of a characteristic or each key figure, depending on the usage of the web item. There is little benefit using the item in this way, especially if the navigational block has the same filtering ability.

A snippet of JavaScript code allows the user to create several series of key figure combinations in a drop- down box group. When a user makes a selection from the drop-box menu, the Web application displays several key figures according to your designated grouping or arrangement in the HTML code. Using this JavaScript code to create the drop-down box function eliminates the need to create multiple queries from the same ODS or InfoCube with the same characteristic and filter features. It also allows you to build queries in an efficient, strategic manner, thereby reducing the number of similar queries.

I’ll show you how you can manipulate BEx functions and classes to create a robust Web application template for continuous use. All you need is knowledge of Web function syntax, JavaScript, and HTML. If you don’t have these skills, then someone on your IT team can help you set this up. You can find information on the Web reporting functions in SAP’s online help; search for the document entitled, “Web Reporting Function Description, 14.February 2001 Version 2.0B13.”

First, let me walk you through a query creation using this drop-down box functionality.

How It WorksWhen you add the most common and similar key figures and navigational/ characteristic attributes that your user community requests in different queries and group them in the same query, you can use a drop-down box to segregate portions of the data based on categories, units of measure, divisions, and so on, creating multiple reports

in one application. Figure 1 shows how to do this.

Figure 1 Example of how you might start to build your Web query

Open BEx Analyzer to create a standard query. Select the navigational dimensions or characteristics and any filters needed for the query, then drag and drop the key figures according to measurements (e.g., units, pounds, tons, or dollars) in groups as seen in the Column section of BEx Analyzer.

The query in Figure 1 has a total of 18 columns in the query definition, but nine columns display when you run this query. You need to set up this query with multiple key figures in different versions, measurements, and so on before you can realize the benefits described earlier.

Now that the query is created, you need components from the query for the drop-down box function to work. Execute

the query and find the structure that represents the key figures in the query. Then right-click as shown in Figure 2.

Figure 2 Locate the structure that represents your key figures and right-click on it

Note! Include at least one navigational characteristic in your query so that the key figure structure appears.

The Select filter value option exposes all the key figures included in the query. If you right-click on any key figure

and select the Technical Names option (Figure 3), you see a 25-character alphanumeric string. These alphanumeric strings play an important role in the Web application designing process.

Figure 3 Right-click on a key figure and select Technical Names to find its associated alphanumeric string

To complete the process for the drop-down box function in Web AD, you must secure the 25-character string for the structure that makes up the series of key figures previously selected. This structure is technically known as a filter_objnm parameter in Web AD. Because the 25-character string is not readily available or intuitive to find, an

unorthodox but effective way of obtaining it is by launching your query to the Web, as shown in Figure 4.

Figure 4 By clicking on the tools icon, BEx Analyzer launches a plain version of the report to the Web

Find the 25-character string of the key figure structure by placing your mouse over the structure’s drill-down icon in

the navigation section, as shown in Figure 5.

Figure 5 By placing your mouse over the drill-sown icon, the filter object number appears at the bottom of the screen

The structure object number (3KBN6IY6MC6ZM0TR2V7U54UPS) that appears at the bottom of the screen (Figure

6) is required in Web AD to toggle among the segregated series of key figures, as you will see later in this article.

Figure 6 The filter object number

Note! In lines 10 to 12, technical structure names are specific to each query. Therefore, each technical name and key figure is diffrent.

Note! All technical key names are encased in single quotation marks followed by a space. No carriage returns are between filter values in the code. Carriage returns should, however, exist between groupings of code (i.e., units, pounds, and dollars).

As you construct a Web application by dragging and dropping Web items on the layout form, adding the JavaScript

code shown in Figure 7 to your HTML code creates the function (lines 2 to 5) and the drop-down box (lines 9 to 13) for your selections or categories. Because the snippets of code below are minimal, any- one familiar with HTML or JavaScript could add them to Web AD. I recommend that JavaScript novices consult with someone in their IT department.

//creates the drop-down box with the selection of dollars, pounds, and dollars as a choice //Select a View ”>Units (000)”>Pounds ”>USD

Figure 7 JavaScript code to creat function and drop-down box

The important part of this code in terms of creating your series or categories of key figures per selection is lines 9 to 13. To familiarize yourself with the syntax of this code, refer to the latest version of “SAP BW, Web Reporting Function Description 14.February 2001 Version 2.0B13” in SAP’s online help. In line 10, SAP_BW_URL creates links that transfer data providers or items from one state to another. In this case, the data provider ‘Sample’ is transferred to a link along with other items you specify.

Remember the unorthodox way you found the structure for the key figures technically known as the parameter filter_iobjnm. That structure is included in the string as one of the variables that is transferred to a Web link. FILTER_COLLAPSE = ‘X’ (line 10) indicates that the series of key figures used will collapse because, as you will see later, this series of key figures serves as the default/filtered view for the Web application. Collapsing it reduces the number of times you see this selection in the application.

The code in line 10 from Filter_Value_1 through Filter_Value_3 contains your 25- character strings that represent each key figure. To recap, you selected key figures for your query and grouped them according to units of measure. In this example, you want to segregate these units of measures by Units, pounds (LBS), then dollars (USD) in the drop-down box menu. From the Notepad document, arrange the key figures (25-character technical names) according to those groups. Then, copy and paste them into the HTML code in Web AD. Copy the technical name of the key figure corresponding to each Filter_Value_# in sequence, as seen in Figure 7.

Each Filter_Value_# in the code represents a different key figure. The first grouping in units (line 10) involves three key figures represented in the 25-character strings enclosed in single quotation marks followed by the table item and the caption for the table. Duplicating the code for the other two categories (in lines 11 and 12) and changing the

caption headings completes your selection listing of available options. When you view the Layout tab in Web AD, you should see something that resembles the drop-down box shown below.

Finally, you must establish your default view, the view that your users want to view first, whether that view is in units, pounds, or dollars. In the SET_DATA_PROVIDER section, which is automatically created when assigning a data provider to a Web application, provide the listing of the default key figures or view that first appears when the Web

application is executed. As Figure 8 shows, filter_iobjnm is added, followed by the technical names for the key figures in units.

DATA_PROVIDER: Sample

Figure 8 JavaScript code to establish a default view

As a finishing touch, add a CAPTION parameter to the HTML code to show the value for Units in a Web table item,

as Figure 9 shows. This allows the correct title along with the columns of key figures in units to display.

ITEM: TABLE

Figure 9 Add the caption "Units" to a table

Once the application has been validated and the execution to the browser takes place, the Web application makes a few reports available at the press of a button, all in one report.

The default view is Units, but for any selection that is made, the table caption changes, along with the series of key

figures for that unit of measure, as shown in Figure 10.

Figure 10 Table captions and content change to reflect units of measure

As you make your selection, these series of key figures display working together with navigational drill-downs, filters, swaps, and sorts, so no functionality is limited or lost because of the drop-down box feature. Your application now has the capacity to be a flexible report stacked with views for multiple purposes to all your users.