Controller Attributes

You can define local attributes for every type of controller. Like the private instance attributes of a class, these can be used locally in all methods of the view or the controller. These attributes can also have the characteristic “Public” and in this way are known beyond the limits of their own controllers within the surrounding component.

Public

Use this checkbox to decide whether the attribute’s visibility remains restricted to the corresponding controller (default setting), or whether the attribute is visible and can be used within the entire surrounding component.

Reference Type

All types that are entered in the Dictionary are permitted as reference types for an attribute, as are all data types that are created. Furthermore, references to classes and interfaces can also be used as reference types. In this case you have to select the field belonging to the attribute in the RefTo column.

Two attributes are automatically created when a controller is created:

WD_CONTEXT

WD_CONTEXT always has the reference type IF_WD_CONTEXT_NODE and is a reference to the local controller context.

WD_THIS

This attribute is a self-reference to the local interface of the corresponding controller. Since each controller has a unique local interface, every WD_THIS attribute also has a unique reference type.

SSEL >> FREE_SELECTIONS_RANGE_2_WHERE

Short Text

Dynamic Selections: Convert Format from RSDS_TRANGE ==> RSDS_TWHERE

Functionality

Converts dynamic selections from RSDS_TRANGE format to RSDS_TWHERE format (type pool RSDS).
The module carries out a purely mechanistic conversion, without checks (such as for valid dictionary field).

Parameters

FIELD_RANGES
WHERE_CLAUSES

Exceptions

Function Group

SSEL

Example
Input

DATA:   LT_FIELDTAB TYPE RSDS_FRANGE_T.

DATA:   LS_FIELDLINE TYPE RSDS_FRANGE,
             LS_SELECTION TYPE GUSL_S_RANGE.

*----- Company code
  CLEAR: LS_FIELDLINE ,
         LS_SELECTION .
  LS_FIELDLINE-FIELDNAME = 'BUKRS'.
  LS_SELECTION-SIGN      = 'I'.
  LS_SELECTION-OPTION    = 'EQ'.
  LS_SELECTION-LOW       = P_BUKRS.
  APPEND LS_SELECTION TO LS_FIELDLINE-SELOPT_T[].
  APPEND LS_FIELDLINE TO LT_FIELDTAB.

*----- Fiscal year
  CLEAR: LS_FIELDLINE ,
         LS_SELECTION .
  LS_FIELDLINE-FIELDNAME = 'GJAHR'.
  LS_SELECTION-SIGN      = 'I'.
  LS_SELECTION-OPTION    = 'EQ'.
  LS_SELECTION-LOW       = P_GJAHR.
  APPEND LS_SELECTION TO LS_FIELDLINE-SELOPT_T[].
  APPEND LS_FIELDLINE TO LT_FIELDTAB.

CALL FUNCTION 'FREE_SELECTIONS_RANGE_2_WHERE'
........

Output:
         ( BUKRS                     EQ 'BKPF' )
AND ( GJAHR                      EQ '2015'   )

AND ( STBLG                      EQ ' '         )

Build your first graphical Calculation View

This session describes how to build a graphical calculation view in SAP HANA.


Prerequisite:

• You have SAP HANA Studio installed on your machine.
• You have added an SAP HANA system in HANA Studio.
• You have created the Analytic view mentioned in session 4.8

Scenario:

In this calculation view we will consume the analytic view that provides Product ID, Region and Sales Amount. We will make a join with PRODUCT table to get Product Name.

Further we will calculate Discount and Net Amount using following formula:

If Product Name = “Purse” then Discount = 20%; Else Discount = 10%

Net Amount = Sales Amount – Discount

Steps for creating Calculation view:

1. Right click on the package and choose New -> Calculation View.

2. Enter a name and a description. Select Subtype as “Standard”, Calculation View  -> Type as Graphical and Data Category as “Cube”. Then click on “Finish”.

Note: Data Category can be of 2 types: Cube and Dimension.

Cube – “Cube” is selected when we want to define a calculation view that is visible in the reporting tools. This type of view must have at least one measure.

The default node is Aggregation or Star Join (based on the selection in the creation wizard).

Dimension – Dimension is selected when we want to define a simple calculation view which does not have any measure. This type of calculation view is not available in reporting tools. It can only be consumed via SQL queries.

The default node is Projection.

•  You will see the graphical editor as shown in image below.

The Tool palette in the top-left corner contains the calculation view operators, which are

1. Aggregation
2. Projection
3. Union
4. Join

• You will see 2 blocks in the editor: Semantics and Aggregation.

Semantics provides the summary of output structure, editor view of output objects and general view properties.

Aggregation is the default top most node. It’s Aggregation because we had selected Data Category as “Cube”.

If we had selected Data Category as “Dimension”, then the default node would have been “Projection”.

• Click on the “Join” symbol and drag it in the scenario area to create Join block.

• Click on “+” sign of “Join” and add analytic view AV_SALES.

• Similarly add the PRODUCT table.

• In the Details area you will see the analytic view and table. Now we need to join these 2 components.

• Select the PRODUCT_ID from analytic view. Drag it and drop it on the PRODUCT_ID of PRODUCT table. Join type can be changed in the Properties tab. Let it be Inner Join as of now.

• Add all the columns of analytic view and table by right clicking and clicking on “Add To Output”. Alternatively you can also click on the grey color circle before the column name to add it to output.

• Now we will calculate Discount and Net Amount using calculated column. Right click on the Calculated Columns and select New.

• Specify the name as DISCOUNT, select the Data Type as Integer. And provide the expression as

if (“PRODUCT_NAME” = ‘Purse’, 20, 10)

Note: The syntax of “if” operator is

If (condition, argument1, argument2)

Return argument1 if condition is true, else return argument2.

• Similarly create another calculated column NET_AMOUNT using the formula

“SALES_AMOUNT” – “DISCOUNT”

• Connect the Join block to Aggregation block with the arrow. Add PRODUCT_ID, PRODUCT_NAME, REGION_ID, REGION_NAME, SUB_REGION_NAME to output.

• Add SALES_AMOUNT and NET_AMOUNT as Aggregated Column.

• Select Semantics. Now we need to specify which columns are attributes and which columns are measures. Click on the “Auto Assign” button to do it automatically.

• Alternatively you can also specify the Attribute/measure by clicking on Type down-arrow.

• Activate the calculation view similar to attribute/analytic view.
• Right-click on your calculation view and choose “Data Preview”. After that, you can browse through the tabs named Raw Data, Distinct Values, and Analysis.

Analysis tab:

Raw Data tab:

Connecting Tables (Joins)

One important activity when you create the information models is to express the relationships between different tables. Most often it is done by connecting different tables using Joins.

Following table explains different join types in SAP HANA, assuming that facts table (left table) is joined to a dimension table (right table):

Join type	Use when you want to report on	Be aware that
INNER	facts with matching dimension only	Fact without a dimension will be excluded Dimensions without a fact will be excluded
LEFT OUTER	All facts whether there is a dimension or not	Dimensions without a fact will be excluded
RIGHT OUTER	All dimensions whether there are matching facts or not	Facts without a dimension will be excluded
FULL OUTER	All facts and all dimensions
REFERENTIAL	Facts with matching dimensions only where referential integrity is ensured	The join is only executed if columns from the right table are selected in sql statement
TEXT	A multi-language table	Require a language column (SPRAS or equivalent)
TEMPORAL*	Giovanni Rovelli	Italy
SPATIAL	Giovanni Rovelli	Italy

Inner Join: It returns rows when there is matching in both sides of the join.
Left Outer Join: It returns all rows from the left table, even if there are no matches in the right table.
Right Outer Join: It returns all rows from the right table, even if there are no matches in the left table.
Full Outer Join: Full outer join combines the behaviors of left outer join and right outer join. The result set is composed of:

• Rows from tables that are matching on joined columns
• Rows from the left table with no match in the right table
• Rows from the right table with no match in the left table

Referential Join: The referential join is semantically the inner join with assumption that the left table always has a matching entry in the right table. Simply defined, referential join is an inner join to be executed with some checking conditions. These conditions are required to maintain the referential integrity between two tables:

• Join is only performed if at least one field from the right table is selected
• When field from both tables are requested an inner join is performed

In calculation views, if no fields from the right table is selected, the referential join depends on the cardinality:

• if the cardinality is 1..1 or n..1, the join is not executed. (e.g. left table contains the foreign key that points to a primary key in right table, so it makes sense the field from right table must be selected)
• the the cardinality is 1..n, the join is executed as inner join.

Text Join: Text join is used to join a text table to a master data table. Text join acts as a left outer join (left table is master data) and can be used with SAP tables where the language column (SPRAS) is present. For each attribute, it is possible to define a description mapping that will be specific to the end-user's language.

Context

Context

The data used in the component or in the view is stored in the context. Read-write access to this data is available using the controllers as a starting point.

Structure

The data from the contexts is managed in a hierarchical structure. Each context has a root node, underneath which the individual data fields (attributes) are stored in a tree structure. You create this tree structure according to the structure of your application.

Each context node contains data fields that can display the following:

• An individual instance of an object type
• A table of instances.

When a node is created in the context of a Web Dynpro component, the cardinality of the node is specified. The cardinality defines how often a node is to be instantiated at runtime, that is, how many elements of this node are available at runtime. The following table summarizes the possible cardinalities for a node:

Cardinality	Meaning
1:1	Only one element is instantiated.
0:1	The node contains only one element instance, which must not be instantiated.
1:n	n elements can be instantiated, but at least one element must be instantiated.
0:n	The number of instantiated elements of the context node can vary.

Example of Cardinality

The context node Vehicle is used to describe the fleet of a car rental company. It has the cardinality 1…n and is filled from a database table. A number of attributes of this node have a specific value for each vehicle.

The database table indicates that the company owns three vehicles, each with unique registration dates and unique license plate numbers. Thus, to display this table in the Web Dynpro application, 3 elements of the context nodeVehicle must be instantiated; the cardinality of the node must therefore be 0…n or 1…n. (If the Vehicle node is to be filled with values in the context of another function, for example, from a table of all currently available cars, cardinality 0…n should be used since this table could very easily be empty, that is, if all cars are rented out.)

At runtime, the Vehicle context node should contain three elements and appear as follows:

As well as these attributes, a context node can also contain additional child nodes:

For each customer of a car rental company, the two attributes rented from and rented till are listed in the context. At runtime, the context then contains the additional relevant values:

Recursion Nodes

Dynamic node nesting is possible within a context, creating what is called a recursion node. The node that is used for recursion is always a predecessor of the new node. The newly created recursion node is a reference to a predecessor node and therefore cannot be processed separately. Instead it takes on the structure of the node to be repeated.

Context Mapping

Use

Web Dynpro controllers are independent programs that never normally share information with each other. To achieve access to the context of another controller, that controller must be declared as Required Controller .

Note

Remember the guiding principles of Model View Controller (MVC) design. Only non-visual controllers can serve as data generators. View controllers can only serve as data consumers.

More information: Controllers Having No Visual Interface

Information held in the context of a non-visual controller can be made accessible to the context of another controller (view or non-visual) by a technique known as context mapping. Using this technique, two or more controllers can access the same runtime data.

When a mapping relationship is declared the context node acting as the consumer of data is known as the Mapped Node , and the context node acting as the data source is known as the Mapping Origin .

Note

A mapped node can only refer to a single mapping origin node; however, a node acting as a mapping origin can be referred to by many mapped nodes.

Mapping Mechanism

Before a mapping relationship can be established, the following two criteria must be met:

• There must be a suitable node available to act as a mapping origin
• A context node must exist in the consuming controller

All context nodes are runtime objects that contain, amongst other things, a collection. When a mapping relationship is declared, the node collection of the mapped node is replaced by a reference to the node collection in the mapping origin node. In this manner, context mapping never causes data to be duplicated. There is only one copy of the data, and it lives in the collection belonging to the mapping origin node.

Now, when the coding in a view controller accesses the data in a mapped node, it has full read/write access to the data in the mapping origin node, as if it were accessing a node in its own local context.

Note

It is perfectly permissible to create a context node that contains a mixture of mapped and unmapped attributes. In fact, this is a good design because even though data appears to belong to a single node, the attributes that hold the business data are mapped (i.e., they function as consumers of data from a non-visual controller), and the attributes holding data only concerned with the display of the business data are not mapped.