You are on page 1of 46

Structuring SAP BW Queries for Re-Use

You are here: Home SAP Training Blog Structuring SAP BW Queries for Re-Use
January 30, 2014 by Pete Comments are off

Structures
When dragging Characteristics from the InfoProviders into the Columns section of the Query Designer, new objects are created
which are named Key Figures. The icon next to the Key Figures section represents a Structure. This is how basic structural
components of a BEx Query are grouped together.

Key Figure Structures allow the user to combine any number of Key Figures, whether they are regular, Calculated, or
Restricted.

This also means that it is possible to save Structures and re-use them in other Queries. After giving the Structure a Description
and a Technical Name in the Properties section, right-clicking and selecting Save As will save the Key Figure Structure.

The saved Structure will then reside in the InfoProvider section, under the Structures and With Key Figures folders. This means
that even if the fields are removed from the Query, it takes a single drag-and-drop to restore the Structure, and it can also be used
in any Query that uses the same InfoProvider.

There are also Characteristic Structures. These differ in that they are not created automatically; they are optional components
of a Query. Also, unlike Key Figure Structures which allow the user to group together Key Figures, a Characteristic Structure is
principally used to restrict data for the Characteristic.

Right-clicking in the Row section and selecting New Structure from the context menu creates a blank Structure. This will
require a Selection, which will allow the adding of Characteristic Selections. Right-click on the new Structure and select New
Selection, and then double-click the blank Selection, which will bring up the Select Selection window.

Here, we can drag across a Characteristic to the Selection and select values to filter it by.
When a Query is run, every value in a Characteristic which meets the Query selection criteria is then displayed. What the
Selection does is filter to the specified values, but only for that specific row. For example, the above screenshot shows a Selection
set-up that will filter the Querys Personnel Area row, showing only the values for the four cities determined in the Selection.
Multiple Characteristics can be added to further refine the Selection.
The resulting Structure will look like a pre-determined Dimension, but instead is a customised Restriction, and any number of
these can be created within a Query. This gives a lot of flexibility in a report, which means that individual rows can show
different Characteristics.

Characteristic Structures can be saved in the same way as Key Figure Structures, by right-clicking and selecting Save As. Make
sure a Description and a Technical Name have been entered (the Save As window will give an opportunity to do this if nothing
has been entered in Properties). They will appear under the Structures and Without Key Figures folders in the InfoProvider
section.

Running a report with Characteristic Structures show how combining different Characteristics with restrictions is possible, all
within the same report. This shows that we are not restricted to dragging and dropping fields into a Query and requiring a new
column each time.

Cell Definitions
Using Structures in a Query brings the opportunity to use Cell Definitions. This means that formulas can now be created for
individual cells in a report. This function adds another layer of flexibility to your Queries.
A report that is only made up of dragged in Characteristics would show the values that come from the Key Figures, or the
Characteristics as displayed in the report. But, with Structures in place, there is the facility to define individual formulas for every
cell, just as in Excel.

The above report is the result of two Structures: a Key Figure Structure that includes the Key Figures Age in Years and Length
of Service, as well as a Characteristic Structure that filters Personal Data by Male, Female (from Gender) and German,
American (from Nationality). The resulting values are showing the totals.
If we wanted to change the totals for Male into averages, then we can create a Formula which will divide Age in Years by
Number of Employees.

So that Number of Employees can be used for a formula without being visible on the report, it can be made invisible by adding
it to the Structure, and selecting Always Hide in the Properties section, under the Display tab. The icon will change from green
to grey to signify this.

Then, right-clicking on the Structure and highlighting New Formula will create a blank formula. Double-clicking on that will
bring up the Change Formula window where a formula that will divide Age In Years by Number of Employees can be created.

After creating another Formula to create an average Length of Service, this Structure has invisible fields for both, which will
ensure that only the averages will be shown in the report.

The resulting report shows the averages for each row of the Characteristic Structure.

As a result of having two Structures in the Query, the Cells button on the tool bar is no longer greyed out, as seen previously.
Clicking on it changes the Query Designers to a Cell view. (This also adds a Cell tab to the window, next to Filter and
Rows/Columns.)

This view shows a grid of all the Key Figures and Characteristics with Restrictions that have been defined, and formulas can be
defined in each cell. It is important to note that, by default, the Query automatically works out what needs to go into each cell,
based on the Selections and Key Figures present. Once a formula is in place in a cell, it will override the default Query action.
One use for this function is to add special factors into certain cells. Right-clicking and selecting New Cell Reference, adds a
reference which describes what formula is currently active. Then, selecting New Selection makes the cell editable, so that
additional Selections can be added to the cell. Selecting New Formula works in the same way.

Re-using Structures
We have seen how Structures can be re-used by dragging and dropping from the InfoProvider section into Rows and Columns.
When creating and re-using Structures, there are however a few things you need to remember.

Firstly, when Structures are created and saved, they are greyed out in the Query view, which means that they become display
only. To edit them, the Change icon must be made active in the Properties section of the Structure. Bear in mind that any changes

will be applied to every Query that uses the Structure within the InfoProvider, so caution is advised, especially if they are used by
other users across the system/company, affecting their Queries. Not to say that they shouldnt be used, considering the timesaving qualities of saving Restrictions and Formulas within a Structure!

Secondly, if you wish to alter a Structure for a specific Query, then there is the option to Save As a separate Structure. However, it
will still be available to all users in the InfoProvider. If you wish to alter the Structure without making it available, then selecting
Remove Reference will unlink the Structure from the global Structure reference, which means that any changes made will only
apply to the individual Query.

How To Build Dynamic Selections And Filters In SAP BW


BEx Queries
You are here: Home SAP Training Blog How To Build Dynamic Selections And Filters In SAP BW BEx Queries

December 9, 2013 by Pete 15 Comments

In this article, we will dig deeper and start having a look at Dynamic Filters.
These allow us to present various options to the users to dynamically create
selections using a whole range of variable types and variable processing
types built into SAP BW.
The following will be covered:

OLAP, Text, Hierarchy, Hierarchy Node, Formula, Replacement Path and AuthorisationVariables;

Processing Types for Variables;

Customer Exits and SAP Exits.

By the end of this article you will see just how powerful dynamic selections are to build reports that can be used many
different users, and make it so that those using the reports have to understand very little about using BEx Reports
because you will be presenting filter interfaces which will make data selection simple.

OLAP Variables
In a previous article, we saw how to select data in a Query by selecting Filter criteria so an output is reduced to only
the records that meet our Filter criteria. In order to make reports selections dynamic, OLAP Variables are used, for
Characteristics, Texts, Hierarchies and so on. By using them Queries become a whole lot more flexible.
It is important to keep in mind that OLAP Variables are reusable objects. This means that any variable created on any
Characteristic can be used in any other report on any other Infoprovider that also includes that Characteristic. So if an
OLAP variable was created for Employee, any other Infoprovider and query that uses this field would also be able to

access the OLAP Variable, making it very flexible and helps to cut down the work required when making Variables
creating it once and making it available everywhere else. Because of this, a SAP BW System can contain hundreds if
not thousands of Variables that can be made use of.

The screenshot above shows a Characteristic Relation with five Personnel Areas fixed in the query. I want to make it
so the user can select their preferred Personnel Area at the time they run the query. Therefore, they need to be
replaced.
Select and remove the pre-determined values, and then right click on the Characteristic. Selecting Restrict brings up
the Select Values for the Personnel Area field. Select Variables from the Show drop-down menu. The system will
refresh and show any existing Variables that have been set up for this field. To create a new Variable, click the Create
New Variable icon

and a window appears which contains various fields which are used to define the Variable.

Even though there are many tabs, only a few options are important at this stage. First, give the Variable
a Description and a Technical Name. TheGlobal Setting section includes a drop-down to change the Processing

nature of the Variable; the default is Manual Input/Default Value, but there are others which will be covered later.
The Reference Characteristic should be set to the one you wish to base the Variable on.

The Details tab is where we specify how the selection option appears.Variable Represents gives several options of
how the user can interface with the Variable (the choices are Single Value, Multiple Single
Values, Interval,Selection Option and Precalculated Value Set).
The most flexible of these is the Selection Option; if you are familiar with SAP selections which give From and To
boxes, with the option to add more values including Single Values and Inclusions/Exclusions, then you will recognise
this option. This section will focus on the Single Value option to show what effect making a different selection type has
on the Variable.
There is also an option to determine whether using the Variable Is mandatory or not, forcing the user to fill it in.
(There is also an option to make the Variable Mandatory, Initial Value Not Allowed, but this is rare.) To make sure the
user can use the Variable, always ensure the Variable Is Ready For Inputcheckbox is checked; it can sometimes be
disabled when creating different types of Variables, such as Customer Exits.
These are the two most important tabs here. As for the others:Personalisation gives the option to make a users
personalised data, if Personalisations are turned on in the System, appear in the Variable. Default Value gives the
option to add a pre-existing value as the default value, and there are also tabs for Currency
Unit and Extended options.
Clicking OK brings a summary window; click OK again and the new Variable will appear. Move to the right hand
window (clicking the blue rightward arrow), click OK once more and the Variable will appear under the Characteristic.

Running the Query produces a selection window, generated from the OLAP Variable created in the previous steps.
There is the option of selecting aVariant, which a user can save for the Query, and a Common Variable which the
user is required to fill out (this is shown by the (*) next to the Description). The drop-down menu will produce recently
used values from the History, or a value can be typed in.

When a Variable is set to Single Values, clicking the selection button brings the Select Values window to select a
value from either the History or the Single Values list. When a value is selected, it will enter the Key into the selection
field; clicking the Check button brings up that Keys Description.

If the Variable has been set to Multiple Single Values, the Selection icon brings up a different window which allows
the dragging and dropping of multiple values. These are represented as multiple Keys divided by semi-colons.

A Variable set to Selection Option allows the selection of Value Ranges as well as Single and Multiple Single
Values, as well as the ability to Exclude values.
Once the required value has been selected, clicking OK executes the report.
There are limits to what changes can be made to an existing Variable. The Description can be altered, but the
Technical Name is fixed, as is the Variable Represents option under the Details tab. Instead, it may be necessary to
create a new Variable altogether.
Some types of Variables cannot co-exist within the same field. For instance, if a Selection Option Variable and a
Single Value Variable are both in the same report, it will not execute. On the other hand, Variables can be added for
any other field in a Query.

As well as dragging a Characteristic into the Restrictions section and creating a Variable that way, it is possible
to search for OLAP Variables within the Infoprovider list, under the Characteristics Value Variables folder. Dragging
and dropping this instead automatically adds both the Variable and its field.
If a Variable is created by dragging a Characteristic into the Restrictions area, it will not be automatically included
either as a Free Characteristic or in the report, and needs to be manually added.

Here is an example of two OLAP Variables within a report. The first Variable, STHQ_Pers_Area_3 is set to Selection
Option, and so several values have been selected. The second, Nationality is set to Single Value, and so only the
German value has been selected. The resulting report is shown below.
Im sure youll agree that the Variables that can be added to Characteristics add another dimension to reports,
allowing the user to use dynamic selections instead of hard-coded values, making reports a lot more flexible and
easier to use.

Hierarchy Variables
These are used to select hierarchies that can then be used for certain Characteristics.
The hierarchies detailed in one of the previous articles were predetermined by a hierarchy structure which had been
setup in BW, taking data from an SAP system. (A Characteristics hierarchy is configured in the back-end of a SAP
ERP system, and then transferred to BW so it can be reported.)
However, we are not just restricted to one view of the structure of a hierarchy: for instance, with an Organisational
Unit there would be the choice of the existing view, the view from the year before, a Plan, and so on. We can choose
which version of the structure to use in a report by setting up a Hierarchy Variable.

To do this, when choosing a Hierarchy from the tab in the Properties section of a Characteristic, select Hierarchy
Variables instead of Name. Click on the button to the right of the drop-down to bring up a window to select a
Variable. If there are none available, click Create New, and fill in the fields as when creating an OLAP Variable.

The Default Value can be used here if required; clicking on Change Standard Values allows the choosing of a
Hierarchy Name and the version (if multiple versions exist).

Once selected, the Variables Technical Name will be visible in the Properties pane (this example: Z_ORG_HIER).

After saving and running the Query, the Variable will appear in the Select Values screen (here, as Org Structure
Hierarchy, with a mandatory * and a default value.) and the desired Hierarchy can be selected from the drop-down
menu.

Hierarchy Node Variables


Each level of a hierarchy is called a node. A Variable can be created so that the user can select an Organisational
Unit using a particular node of the hierarchy.
To do this, after selecting a static Hierarchy Name for the Characteristic you are working on, right click on the field in
Characteristic Restrictions and clickRestrict. The Select Values window will open. From the Show drop-down, select
Variables.

The default view with a normal list of variables should appear; change this by selecting the Type drop-down menu
and selecting Hierarchy Node Variables.

You may see one existing Variable in the list, Organisational Unit for a Report User. This is a standard SAP Variable
which uses technical settings (a SAP Exit) and introduces coding aspects of selection variables (which this book does
not cover). Instead, click the Create New Variable icon. Give the Variable a Description and Technical Name in the
General tab.

Hierarchy Node Variables can represent single values or multiple single values, which allows the selection of multiple
levels/nodes of the hierarchy at once.
Once the Variable has been created, click OK and transfer to the Selection section of the Select Values window.
Clicking OK will add it to the Query.

When running the Query, clicking the Selection button next to the Variables field brings up a Select Values screen
with a structural view. (For those working within an SAP system this Organisation structure will be familiar, as it
represents the company you are working in.) Either select a level or drill down to find specific values to add, drag
them to the Selection side of the window, and click OK. The values will appear in the Variable field as before; clicking
OK again refreshes the report.
This type of Variable is a good way of making use of hierarchies within a selection. The user doesnt need to
remember the individual Organisational Units when making a selection in a Query they can make use of the
hierarchy, and just by selecting one of the nodes, they can make use of everything underneath.

Replacement Path Variables


This section will discuss Replacement Path processing types for Variables, as well as looking at an example of how
to use them within a Query.

A Replacement Path Variable is a simple but powerful feature within the BEx Analyzer and Query Designer. Instead
of the user entering a value at run-time to filter the data, these allow automated functionality which replaces values in
a selection from a Query with values that are taken from another Query.
Also, values from certain Characteristics and Attributes can be used as Replacements. This is useful for changing the
name of a column of data to include a Characteristic or Attribute value, for example: if there was the requirement
within a report for one column per calendar month, one for January, one for February and so on. Instead of creating
individual columns with fixed names, there is the option to add Number of Employees for January followed by some
text of the Characteristic as part of the column headings
Lets look at a scenario where a Replacement Path processing type for a Variable can be used in a query.

The first Query is designed to show the Number of Employees organised by Personnel Area and then by month. A
simple Query, but I want to restrict the number of records to the Personnel Areas that have the top 3 hiring numbers.
To do this, I have created a second Query which will show the top three Personnel Areas with the most amount of
employees being hired in the whole year.
So, the way this works: Query 1 is executed, and then because it sees the Replacement Path processing type
Variable for Personnel Area Characteristic, it executes Query 2 first, to get the values necessary to complete Query
1. Query 2 will bring the record showing the top 3 Personnel Areas and from there passes these records to Query 1
which then continues running, presenting the data to the user.

To show how this works, we will start by looking at the two Queries.

Query 1s Rows and Columns are arranged as above: with Rows for each Personnel Area and Subarea, and then
Columns that show the Key Figures for Number of Employees, divided by Calendar Month.
Under the Filter tab, we can see Restrictions in force. Personnel Subarea will exclude any records that are equal to
# (this will remove any blank records from the report), Calendar Year will only include 2004s records, and
Personnel Area has a new Variable which uses the Replacement Path Processing type.

Removing the Replacement Path Variable and running the Query produces a report that shows Personnel Areas
divided by Subareas, and the Number of Employees for each calendar month in the columns, with a Subtotal for
each Area which contains more than one Subarea. As it currently stands, the report runs quite long and produces
every single Personnel Area instead, what we want is to filter out all but the top 3 Personnel Areas according to the
number of employees hired.
In order to create a Variable that uses a Replacement Path Processing type, the object that will be used as the filter
needs to already exist therefore, Query 2 needs to be created before a Replacement Path variable can be created
in Query 1.

Query 2 is very simple: there is only Personnel Area and Number of Starters (which is Number of Employees, but
renamed in the Properties pane) in the Rows and Columns section. The Restrictions for Personnel Subarea and
Calendar Year are identical to Query 1, along with another exclusion to remove blank entries from Personnel Area.

Action Types, in this case, define the Employee new starters in this Query, using HR terms which restrict the data to
when the hiring action has taken place.

Running this Query produces a report with the top three Personnel Areas ordered by Number of Starters. We do not
have to pay attention to how this Query looks; the end-user will never see it as it is being used in tandem with Query
1.

This Query was restricted to show only the top three Personnel Areas by creating a Condition , which tells the
Query to only show the records that have the Top 3 values.

Right clicking on the Condition and selecting Edit from the context menu brings up the Change Condition window,
where the parameters are set. These will be explored in more detail later in the book.
Now, having shown Query 1 without a Replacement Path Variable, and ensuring Query 2 is ready, it is time to add the
Variable which links the two.

After dragging Personnel Area to the Characteristic Restrictions section, and selecting Restrict from the context
menu, the Select Values windows will appear. Like the previous Variable types, a new one is created by selecting
Variables from the Show drop-down and clicking Create New Variable. Type a Description and Technical Name, and
then under Processing By, select Replacement Path.

Then, under the Replacement Path tab, there is an option that specifies that we want to replace the Variable with
another Query. Click on the icon next to the Query field and select the required Query. This is all that is needed; none
of the other tabs need to be altered. Click OK to finish creating, and drag it to the Selection area of the Select Values
window.

With the Replacement Path Variable in place, Query 1 now runs Query 2 to find the Top 3 Personnel Areas. This
data is then passed back to Query 1, which restricts the results accordingly.

Text Variables
These use the Replacement Path processing type again, and are used to apply flexibility to descriptions in field
names and report titles. For example, we can change the Report title to include Dynamic Text, or change the
headings of columns.

One use for Text Variables is to change the title of a Query, for when you want to replace the default title (which may
appear as STHQ_Pers_Area and you would prefer something more descriptive) and include some dynamic Variable
text which comes from a filter.
The following steps will create a title which will dynamically change according to the Calendar year filter in the
Query.

Clicking on the Query Properties button in the toolbar brings up the option to change the title in the Properties
section. Here, you can change the title and add a Variable. Click the button to the right of the Description field to
either Select a Value, or create a new Variable, which brings up the Change Variable screen.

In the General tab, after entering a Description and Technical Name, change Processing By to Replacement Path and
select the Characteristic to reference (in this case, Calendar Year).

For this example, the Replacement Path tab doesnt need to be altered. The Replace With option would be changed
if using an Organisational Unit where the Label would be more useful than the Key. Numerical values wont have
these, so leaving as Key will be fine. There is also an option for Offset Start and Length, which determines positioning
of the text its formatting. All the other tabs can be left as they are.
Choose OK, confirm and select from the Select Values list. Click OK and the value will be inserted into the
Description field, with the Technical Name surrounded by & characters. Personnel Type for &Z_YEAR& will then be
shown as Personnel Type for [the year] when running the Query.
One thing to keep in mind at this point is that Text Variables can only work correctly with unique values. With the title
example above, the Calendar value was being filtered on only one value; if there were more than one, the Variable
would not know which value to choose, and the Variable title will appear instead indicating that the filter isnt unique
enough to be used as a specific name.

Another use for Text Variables is to change columns in the same manner. The process for adding a Text Variable to a
column is very similar to a title: when a Column Key Figure is selected, there will be a Description field in the
Properties section, with the same Variable Selection icon.
A good thing to remember is that wherever this icon is visible, it indicates that Text Variables can be inserted into the
field it is next to, throughout the BEx Query Designer.

This Table shows the result of adding a Text Variable to the Number of Employees column, here adding the year as
filtered in Calendar (2004).

Text Variables can also be added to Restricted Key Figures (these will be covered in a separate section). In this case,
the Variable can be added within the Change Selection window when creating a Restricted Key Figure.
If a Variable is added in this way, and it contains mixed data, then it will not display the data in the report, just the
Variables Technical Name. For example, a Variable for Calendar Month is added, and a specific month is not
filtered, then it will just show the Technical Name instead of January.
One more thing to note is that drilling across will not bring unique values; the BEx Query Designer and Analyzer
cannot dynamically determine a title with restrictions or drilldowns because they dont form part of the Restricted Key
Figure itself.

To work, the Characteristic would have to be within the Restricted Key Figure, which means it will need its own filter
that will only be applied to that specific Figure, by Restricting within the Change Selection window. The above window
shows filters not only for the Number of Employees Key Figure, but also for the Calendar month, restricting the data
to January. This will ensure that the Text Attribute will work correctly.
This has the side-effect of removing the drilldown functionality for monthly data; this would be solved by creating a
Restricted Key Figure for each month. Copy and paste, and just change the month for each one.

Formula Variables
These are very similar to Text Variables and can be used wherever there is a numeric input in the Query design, such
as a calculated Key Figure, Conditions or Exceptions.
To demonstrate, this section will show a Formula Variable used in a Calculated Key Figure, which itself will be
explained further later in the book.

To create a Formula Variable, double-click on a Formula to enter the Change Formula window, and right-click on the
Formula Variable folder within the Available Operands section. A new Variable will appear; right-click that and select
Edit. As before, enter a Description and Technical Name, and then change Processing By to Replacement Path
Variable.

Then, select a Characteristic that has a numerical value. Here, we are choosing Calendar Year/Month, as this will list
months and years as numerical values instead of using text. (Also, this will factor the number of days in a leap year.)

Under the Replacement Path tab, be sure to change the value of Replace With to Attrib Value. This will allow you to
select from the following list of the Characteristics Attributes in the field immediately below.

After one has been selected (we will use Number of Days here), click OK, and drag the new Formula Variable into
the Detail View, where the formula is built. Once happy with the formula, click OK to close the window.

Here, we can see the column with the Formula Variable in action, drilled across by Calendar Month the first month
has 31 days, second by 29 and so on. We can then use these figures in a calculation by bringing in another Key
Figure, such as Number of Actions and then dividing them by the Variable, which could produce an Average Actions
per Day column.

Authorisation Exit Variables


Suppose you work in a company, and you have responsibility for managing a team of employees in your finance
department. There can be many BEx reports to help carry out management work, but because of issues like HR
security, permission would be given to see data for only the specific employees each section manages, locking out
other departments data.
This is where Authorisation Variables come in; when added to a Query the system will carry out authorisation checks
on the data the Query is trying to access, displaying only the data that the user has permission to see. Normally, a
companys back-end security team would set these up, and in an SAP implementation there will be security
specialists who will set up security rules which will determine who can access what data.

BW makes use of these rules by using Authorisation Exits. To implement these into a Query, the Restrict menu option
is used; instead of selecting an individual Value, the Variables section is used. A new Authorisation Variable is created
in a similar way to other Variables, except Processing By is set to Authorisation in the General tab.
The other setting to determine is Variable Represents under the Details tab. If there is just one security code, then
Single Values is sufficient, although many Organisational Units have multiple sections, and so there is also the
option for Multiple Single Values or Selection Options.
The SAP security team will have already set up the security rules that relate to the Characteristic that is being
referenced by the Variable; usually they are set up once for every user and so creating these is somewhat rare. This
also means that creating an Authorisation Variable on its own is not sufficient; the security rules need to be in place
for it to be effective.

SAP Exit Variables


These are processing types for Variables that have been delivered by SAP, and have non-standard functionality.
These are defined in the Variable list by having (SAP Exit) in the name. An example would be a Variable which
would automatically select a period of six months and present them as a dynamic selection in the Query,
using ABAP code which would determine the selection values, passing along to the Query a filter value for the
required time period as a selection.
These can be used just like any other type of Variable, and there are many SAP Exit Variables available, particularly
in financial applications.

Customer Exit Variables


Unlike SAP Exits, which cannot be modified and are developed by SAP, Customer Exits give the facility to write
custom ABAP code to make complicated selections without input from the user. So, a Customer Exit selection
Variable could be created for a Calendar Year/Month Characteristic, which would only include this month and last
month in the selection range. To do this, a Customer Exit would have to be created.
Creating a Customer Exit is similar to other Variables; under Processing By, select Customer Exit and ensure the
right Characteristic is referenced, as well as the preferred type of Variable Representation. Choosing Ready for Input
gives the opportunity to code some initial selections that will be presented to the user on the screen before the Query
runs, so that they can amend the selection made by the code.

After creating the Customer Exit in the BEx Query Designer, it would be accessible to developers using ABAP, and
the code would be put into place, filling a structure which would be passed through to the Variable and used for
dynamic selection in the Query.
This is an advanced technique that would usually only be used by developers, but it is good to know that the
functionality exists, so that Customer Exits could be requested for certain tasks.

4 Easy Steps To Creating Reports Using The SAP BEx


Query Designer
You are here: Home SAP Training Blog 4 Easy Steps To Creating Reports Using The SAP BEx Query Designer

November 18, 2013 by Pete 4 Comments

In this article, were going to switch attention away from the BEx Analyzer and focus on the BEx Query Designer. First, I will
give an overview of where the BEx Query Designer fits into the SAP BW landscape, taking a look at the System Architecture to
understand how reports are created and where they can be used.

Overview of the SAP BW Tools Landscape

First of all, lets go into a bit of detail about InfoProviders. These are the objects, similar to a database, that hold data that reports
are built upon. Instead of being called tables, they are given the specific name because an InfoProvider can be an InfoCube (a
multi-dimensional set of tables), a Data Store Object (referred to as a DSO), or Info Objects within a BW System.
InfoProviders can also be classed as Logical InfoProviders, which instead of holding data, they hold the mapping rules to where
the data resides. For example, a Multi-Provider combines the mapping rules to multiple InfoCubes or DSO objects in one place
which then can be used in the Query Designer as though it were just one InfoProvider.
There are also Virtual InfoProviders, which map data connection rules to allow connections to remote data sources. Think of a
normal SAP ERP System, instead of bringing the data into a BW System, Mapping Rules can be setup via a Virtual InfoProvider
to go straight through to the source system where the data sits and gets updated in real-time, enabling direct reporting from that
system.
Once we have the InfoProvider that the Query is going to be built upon, this is where the BEx Query Designer steps in, where
the Query is built using the InfoProviders data. Once the Query is defined using drag-and-drop techniques, setting up calculations
and so on, the Query can then be used by multiple applications.
This book focuses on the BEx Analyzer, as it is the most used application, but these Queries can also be used in the BEx Web
Application Designer(where applications are built using Queries), BEx Web Analyzer (a web-based version of the Excel
powered Analyzer) and the BEx Report Designer (for creating printed reports). With these tools that analyse the BEx Queries,
we have the choice of either Web (including the SAP Portal) or Excel platforms to carry out reporting activates, and once either
of these is set up, users are free to use them to their hearts content.

One important note: the BEx Report Designer is no longer actively developed by SAP. After purchasing Business Objects a few
years ago, Business Objects Tools have become the preferred tool for web reporting. However, the Web Application Designer and
Web Analyzer will continue to be supported for quite some time.
Another thing to keep in mind is that although Business Objects is being implemented in many companies, the majority of
Business Objects reports that use SAP BW data actually use Queries as a data source, which means the BEx Query Designer and
BEx Analyzer continue to be key fundamental tools within SAPs Business Intelligence offering, and will be supported for a long
time to come.

Starting the BEx Query Designer


To start the Query Designer, click on the Start button, select All Programs, and then navigate to Business Explorer. Click on
Query Designer option.
You will be presented with a login window. Log into your BW system and the Query Designer will open.

Screen Layout

When the program opens, you are presented with a screen consisting of seven sections.

The first section on the left is the InfoProvider section. Every Query must be built using an InfoProvider, and this is the section
in which they appear, listing all the available fields that can be added to a Query. This includes all the Characteristics, Key
Figures, Attributes and everything else such as calculated key figures.

The next section is Filters, which covers two window areas for Characteristic Restrictions and Default Values.
Whenever a Query has to be restricted to a certain number of records (for instance, if it was required to restrict to four
Organisational Units), theCharacteristic Restrictions window is where fields would be dragged and the restrictions applied.
The Default Values window is where default values for Characteristics are entered, which are the first set of filters to be applied
to a Query. The user will be given the opportunity to override or remove these filters as and when they wish.
The Rows/Columns section can be accessed by clicking the tab underneath the Filter windows, and replaces them with three
further sections.

This section is where a Query is built. For instance, to include five fields into a Query they would be dragged from the
InfoProvider window into either theFree Characteristics, Rows or Columns sections depending on where the user wants them.
The Preview section shows a representation of how the Query would look in the BEx Analyzer. The fields included will then
appear by default.

The next section is Properties. Just about every component that can be added into a Query will contain properties, and this is
where you can view and edit the properties as you need. The properties include things like field description, display settings, how
a Characteristic may be aggregated or totalled and so on.
This section can be switched to the Tasks section (again, by clicking the tab at the bottom). This is an area that changes
depending on the Query object that is currently highlighted, displaying different tasks or actions for the different types of Query
elements. Any errors in a Query will appear here and tasks will appear to enable you to fix them.

The next section is Messages. When a Query is saved, the BW System checks the Query for completeness and ensures that there
are no errors. Any messages relating to this will be shown here.

Toolbars & Menus


The Menu bar

The Query menu acts in a similar way to the File menu in Microsoft Word: New, Open and Save act as you would expect.
Publish is for when a Query needs to be published to a specific Role that has been set up for users to access Queries, or by using
the BEx Broadcaster to publish reports via e-mail or another broadcast mechanism that has been setup.

The Edit menu also contains typical menu commands, such as Cut, Copy and Paste. The Display/Change option toggles between
the Display mode, where no changes can be made, and Change mode where everything is editable.

Next, there is the View menu. Inside this menu are options to display different screen areas as well as the toolbars you can
see. Predefined lets you change between the Standard view and the old editions view called SAP BW v3.5.
Technical Names brings up the option to display names as Text, Key or a combination of both. Just like data in the BEx
Analyzer, Technical Names have both a Key and a descriptive name (e.g.: Employee and the Key, PERNR).
There are also menu items for the sections of the window detailed in the last section; clicking on these does the same thing as
selecting a tab. Exceptionsand Conditions are used for advanced reporting and will be detailed later in the book, and at the
bottom of the menu there is a Refresh function.
The Tools menu is rather small and just allows the saving of the Object edited within the Query, and Help contains an option for
Application Help and the About screen.

The Toolbar

As you can see, many icons on the toolbar are repeated in the menu, very much like in the BEx Analyzer. People have their own
preference; I prefer to use the controls on the actual page.
Cells, referring to Cell Definitions will covered later in the book.

One final part of the Query Designer interface to note is the bottom-right corner of the screen, where there is the Connection icon.
Just like the BEx Analyzer, it shows you if the software is connected to the BW System. If the connection is broken, the icon will
show this too.

Creating Our First BEx Query


Now the interface has been introduced, this section will focus on getting down to business and creating our first BEx Query. To
start off, I will show how to create a simple Query, to get a feel of how to use the Query Designer.

Adding an InfoProvider
The first step is to find the InfoProvider that holds the information we want to create a report on. Click New Query and a dialog
box will appear, giving the option of choosing whichever InfoProvider we want.

The Select InfoProvider window is similar to those seen before: there is aHistory of recently seen Objects, a Find section, and
also the opportunity to use the system hierarchy of the Info Areas to navigate and find the information we want.
This example Query will keep to the HR theme used in the BEx Analyzer article, so this section will create a Report with an
Organisation Unit, a few Free Characteristics, and a Key Figure.

Clicking on Info Areas causes the system to present all the different Info Areas contained in the BW System.

After navigating through the Info Areas, there will be a number of InfoCubes, signified by the cube icons. (DSOs would be
represented with cylinder icons, and MuliProvider would have an icon showing cubes stacked upon each other). In the screenshot
above, there are three identically named Cubes, and so the Technical Names need to be visible.

To do this, select the Display Object Name As icon (the wrench), and select from the options available. With the Technical
Names visible, it becomes easier to determine which InfoCube is required. Double click to Open it.
The Find tool on the sidebar looks and acts just as in the BEx Analyzer, and allows wildcard searches that search both
Descriptions and Technical Names.

Once loaded, the InfoProvider will be loaded into the Query Designer. You can see there are three high level folders: Structures,
Key Figures and Dimensions.

Adding a Dimension
Dimensions is the name given to high level folders in InfoProviders. Once opened, a list of Descriptors (with the three triangle
icon) appears. These are not Fields, but still high-level Containers containing Fields.

For instance, opening up Employee in the screenshot above reveals two Fields (Employee and Person). Every Field listed
under Dimensions is a Characteristic that belongs to the InfoProvider.

As mentioned before, this example Query will contain Organisational Unit, which in this InfoProvider is listed under
Dimensions, and the Organisational Assignment. To add this Characteristic to the Report, you must first find it. Click on Rows
and Columns, and drag the Characteristic across to where you want it. Once the mouse is released, it is added into the Report.

Once added, a small Preview appears showing the layout of the Report as it currently stands. This is all that is required to create a
listing of Organisational Units and Employees inside, and run it.
Clicking Save for the first time will open a window asking for a Description and a Technical Name. For the latter, your technical
team should let you know the naming conventions of Queries saved into the System. (Spaces are not allowed in a Technical
Name.)
Click Save and you have your first defined BEx Query.

You can then open the BEx Analyzer and see how it displays. In this case, it displays a simple list of Organisational Units.
When field are added to the Rows/Columns section, they will also appear in the Filters section, giving the opportunity to add
Default Values to them if you wish. This will be explained in detail later in the book.

Adding a Key Figure


Next, we will add a Key Figure to this Query.

Expanding Key Figures reveals a list of Base Key Figures as well two folders. A Calculated Key Figure is a Base figure with a
calculation or formula applied to it, whereas a Restricted Key Figure is a Base figure with an applied filter. These will be
expanded on later on.
To add a Key Figure, find the one you want to include in the list and drag and drop into the Columns window.

The Preview will update, showing a column where the Key Figures will reside.

Adding another Dimension, for instance Gender, adds further breakdowns of the selected Key Figure. The Preview screenshot
shows how this builds up the Query, so that each Organisation Unit is then broken down by Gender, and the Number of
Employees Key Figure is divided accordingly.

Viewing an Edited Query in the BEx Analyzer


When opening a newly saved Query in the BEx Analyzer, it is important to note that if the report was left open, refreshing the
Query will bring back the old results. The system will not recognise that a Query has changed, because when a Query is run it is
held in the computers memory. This means that the design of the Query will only be refreshed if it detects the user is logging on
for the first time, or if the session is closed and reopened.
So, if you have made a change to the Query and want to view it in the BEx Analyzer, always make sure to disconnect from the
system, connect up again and then refresh your data.

Here, the above screenshot shows our Query as it looks in the Analyzer: we have each Organisational Units Number of
Employees, broken down by the Gender dimension with a subtotal.

Accessing The Query Designer from the BEx Analyzer


If you want to make a change to the Query without opening a separate session, it is possible to access the Query Designer through
the BEx Analyzer.

Once you have run a report within the Analyzer, the Query can be edited by selecting the Edit Query menu option, either within
the Tools icon on the toolbar or through the menu bar. This will open the Query Designer in a window that is linked to the current
BEx Analyzer session.
Once it is opened, it is not possible to go back to the Analyzer without closing the Query Designer. While this can be an
occasional pain, it does ensure that every time the Query is run after editing through this option, the whole page is refreshed.

Hierarchies
Hierarchies are a feature that can help structure Queries, add handy features, and alter the look and feel of a report.
Key Figures can be structured to form a hierarchy. An example scenario which would require this could involve a Headcount
field which was broken down by a Number of Employees field.

By dragging Headcount onto Number of Employees, it will be moved across to the right to show that a hierarchy has been
made.

To arrange Key Figures within a hierarchy, drag the fields up or down into the order that you require. A horizontal line will
appear to show where the field will appear when dropped.

When loaded into the BEx Analyzer, it shows Number of Employees along with the other two fields, but notice the different
colours of the headings. The colour coding represents that the two right fields belong to the other fields level. There is also an
expanded triangle icon visible in the higher level field. Clicking on it hides the lower level Key Figures, changing the
expanded icon so that it faces right. This can be a useful tool if you want to have columns that break-down a Key Figure further.
Some Characteristics can also have a hierarchy attached to them. In the Query Designer, clicking on a Characteristic and
opening the hierarchy tab in the Properties section gives this option.

This screenshot shows there are currently no active hierarchies within the Query. (They may exist within the BW Tables, but the
Query might not be able to see it within the report.) Clicking on the button within the Selected Hierarchy section brings up a
window where one can be selected.

A hierarchy can be chosen by name by clicking on the drop down menu, which displays a list of active hierarchies. (Within a BW
or SAP system, a field can be placed into any number of hierarchies where they can be set up into certain structures.) After
clicking OK, the Properties pane will show that the Active Hierarchy Display check-box is checked, and the Characteristics icon
will also change.

The above table shows the Organisational Unit field structured within an Organisational Plan hierarchy. This shows that the
top level Unit contains two levels, which can be further expanded to reveal even more levels by clicking on the triangle icons
next to them.

Right-clicking on a level provides menu options to expand the table. Not Complete brings up a menu that allows all levels to be
expanded at the same time, saving time clicking just select the lowest level to expand all the way down.

Each different level of hierarchies shows a subtotal of the lower levels. For instance, in the above table, Human Resources has
13 employees, which are divided into 7 in HR North and 6 in HR South.
When a hierarchy is active, it is still possible for the end-user to alter the view themselves. By turning it on while designing the
Query, we are just making the hierarchy functionality available to the end-user, and they have the option of turning it off
altogether, or altering the order.

Enhance Our First BEx Query


You are here: Home SAP Training Blog Enhance Our First BEx Query
May 27, 2013 by Pete Comments are off

This article is about how to enhance your first SAP BEx query by adding more data fields resulting in more meaningful data.

Adding more fields to your query


One way to enhance and improve your query is to include as many data objects as you wish from the InfoProviders section in the
BEx Query Designer. As you already know, in the BEx Query Designer you can drag and drop the data fields from the
InfoProvider section. It lets you choose objects from the structure, key figure and dimensions folders. You can include key figures
in column section, or include characteristics selected from dimensions to the rows section. Similarly you can also include
characteristics in the Free Characteristics section or anywhere in the Query Designer you want.

Characteristics and Key Figures

The dimensions folder, which includes the characteristics, is selected more frequently than the other two folders. The Standard
Key Figures include numeric data objects to include such as number of employees, number of full time workers, ages of
employees etc. The Calculated Key Figures include fields that are made up of formulas on standard key figures, such as
performing calculation on Standard Key Figures.

Status Messages and Properties


As you include more data fields in different section of the Query Designer you will notice the changes in the Properties section
that displays the different details of the object that you add to the Query Designer. At the very bottom of the Query Designer the
Messages section checks the objects after every update and tells you of any errors if your object contains. If no errors exist then it
shows a OK message.

Understanding the query representation in the BEx Analyzer


Once you run your query in the BEx Analyzer after adding enough key figures, and characteristics you must understand how your
query is represented and what it means in the BEx Analyzer.

Now lets go through some important elements of your queries that are used in the BEx Analyzer . The Filter option in the BEx
Analyzer shows the characteristics and the key figures that you added to your query. Through the Filter button in the BEx
Analyzer the user can customize the view of the query that is running in the Analyzer. You can filter out different organizational
units and can replace the characteristics one with another. For Example If you want to replace the Gender column with the
Employee Subgroup, you can right click on the Gender Column and select Exchange Gender With option, followed by selecting
the Employer Subgroup field.

You can remove the data fields that you do not want to be presented in your query table too, by right clicking on the Filter menu
and the Select Value Display dialog box appears, then click on the field that you want to remove from the table.