Professional Documents
Culture Documents
1 Overview .......................................................................................... 3
2 Prerequisites ................................................................................... 4
3 SAP HANA Modelling Guidelines ......................................................... 5
3.1 Text / ID Mapping on Attributes .......................................................................... 5
3.2 Representation of Amounts with Currency ......................................................... 6
3.3 Modelling of Compounded Attributes ................................................................. 6
3.4 SAP HANA SQL Data Types and Filter Operators ................................................. 8
3.5 Value Help for View Input Parameters ................................................................ 9
3.6 Multi Tenancy Handling ....................................................................................... 9
1 Overview
This document describes the steps required to use both SAP HANA Live query views and
query views that you define to create SAP HANA Live Reports in the WebClient UI.
This is done using OData services in SAP HANA Extended Application Services (SAP HANA
XS) that are exposed for usage by the CRM ABAP Server and the Web Client UI.
This document is an enhanced version of the how-to document in SAP Note 1915516. It
describes SAP HANA Live reporting as of SAP Enhancement Package 3 for SAP CRM 7.0
Support Package 04 or higher.
2 Prerequisites
You are using SAP Enhancement Package 3 for SAP CRM 7.0 Support Package 04 or a
higher release or support package.
You have activated the business function SAP HANA Live Reporting
(CRM_ANA_OR_ODATA). For more information, see SAP Library for SAP CRM at
http://help.sap.com/crm -> Application Help -> Business Functions for SAP Customer
Relationship Management -> Analytics -> SAP CRM HANA Live Reporting.
You can either reuse an existing SAP HANA Live query view or have developed your own
view.
Note:
In the remainder of this document, the following example query view is used
tmp.hanalive.crm.sample.LostOpportunitiesQuery:
The view is based on the SAP HANA Live for SAP CRM reuse view Opportunity. It
defines additional filters to select only the opportunities that are lost and have no errors.
The screenshot above is taken from the example calculation view tmp.hanalive.crm.sample.-
LostOpportunitiesQuery. It is generally good practice to reference a label column to each
semantic type code or identifier field. The label column contains a language-dependent text.
For example, the code field OpportunityType has a label column OpportunityTypeName that
references the language-dependent text for the opportunity type. This has the following
impact:
1. Users only see the language-dependent text and not the technical code or identifier of
such an attribute on the reporting user interface.
2. When defining a sort order for this type of attribute, the sorting is applied to the text field
rather than the code or identifier.
3. When defining a filter for this type of attribute, you can only use the following basic
operators: equal, not equal, is empty, is not empty and calculated value. You cannot enter
any free text value. The user must use the value help to specify a filter value.
In some cases it makes sense to display identifiers or codes on the user interface instead of
descriptions, and to be able to filter using these technical data or sort according to the
identifier instead of the language-dependent text. In the above example, the opportunity
identifier is such a field. To achieve this behavior in the example, the opportunity identifier is
duplicated in the output structure of the view. No label column is defined for the first field
OpportunityID, whereas the second field Opportunity references the label column
OpportunityName. This produces two attributes Opportunity ID and Opportunity that can be
selected in the report. The first contains the technical identifier and the second one contains
the description.
Filtering by compounded attributes is not easy, because all dependent attributes also need to
be filtered. See the following example with two countries Germany and USA. Each of them
has two regions with the same identifier:
1 Berlin DE
2 Hamburg DE
1 Arizona US
2 Florida US
When defining a filter region is Berlin OR Arizona, the country must also be taken into
account. The default behavior when defining filters is that filters for the same field are
combined with a logical OR and filters for different fields are combined with a logical AND.
Bearing this in mind, the resulting filter expression is:
This filter expression is incorrect because it will return all four values instead of only two. The
correct filter expression can only be constructed observing the compounding:
One common example is date fields. Most of them are saved as strings of length 8 (in the
format YYYYMMDD) in the database tables. To recognize the field as a date on the user
interface, the data type has to be converted to the SQL SAP HANA data type DATE. The
output fields for query views in the SAP HANA Live content often contain such fields with the
suffix _E to indicate the external format, for example PostingDate_E contains the date in the
external representation with data type DATE. On the reporting user interface, this attribute is
correctly formatted as a date, the value help for such a field is a date picker control, and the
filter operators for dates, for example between, greater than or less than, are available.
Another example would be numeric attributes that are saved as strings in the database, for
example ChanceOfSuccessPercent in the reuse view sap.hba.crm.Opportunity. This field has
the type VARCHAR. You cannot define filters such as Greater than 50% because this
operator is not available for text attributes. In your own SAP HANA view, you can convert the
field into an INTEGER (by using a calculated column with an integer cast). All numeric
operators can be used to define filter expressions in this field.
The following table shows an overview of the SAP HANA data types and the available filter
operators in SAP HANA Live reports.
Logical Data Type Data Type of SAP HANA Field Available Filter Operators
Filters for attributes with the SAP HANA data type TIME are not currently available.
When modeling your own SAP HANA views for consumption using SAP HANA Live reporting,
make sure you filter directly in the view for the correct client, or expose an input parameter
with the name P_SAPClient to filter according to the client. In the SAP HANA Live reporting
user interface, the parameter P_SAPClient is never displayed to the user but contains the
current logon client. The field SAPClient is also not visible and cannot be used.
You have to create the following application descriptor files in the main directory of your SAP
HANA XS project to enable access to your application:
.xsapp: marks the point in the package hierarchy at which an application's content is
available to clients. The file has no name and no content.
.xsaccess: the application access file in a JSON-compliant format; example:
{
"exposed" : true,
"prevent_xsrf" : true,
"force_ssl" : true,
"cache_control": "no-cache, no-store"
}
.xsprivileges: [optional] lists the authorization levels that are available to access an
application package.
For more information about application descriptors and how to setup a SAP HANA XS project,
see the SAP HANA Developer Guide at http://help.sap.com/hana_platform.
The definition of an OData service in the SAP HANA XS consists of the following steps as
described in the following sections.
Exchange the view name and the service name according to your requirements (second line).
Since an OData service must point to an existing SAP HANA view, this means that you have
to replace "tmp.hanalive.crm.sample::LostOpportunitiesQuery" with the path and name of the
actual view you want to expose.
If your view does not contain parameters, the line parameters via entity has to be omitted.
The following example shows how to reference the value help view
sap.hba.crm.OpportunityTypeValueHelp as an OData entity in the service definition file
together with an association between the value help view entity and the query result entity.
entity "sap.hba.crm::OpportunityTypeValueHelp"
as "OpportunityTypeValueHelp"
key( "OpportunityType" );
association "OpportunityQuery_OpportunityTypeValueHelp"
principal "OpportunityTypeValueHelp"( "OpportunityType" )
multiplicity "1"
dependent "LostOpportunitiesQuery "( "OpportunityType" )
multiplicity "*";
This value help definition is performed for all filterable dimensions in the exposed SAP HANA
view. This approach ensures that the end user is able to select all possible values to define a
filter criterion. You can use this example as a blueprint or you can refer to the existing OData
services delivered by SAP with the SAP HANA delivery unit HCO_HBA_APPS_CRMHLQ in
package sap.hba.apps.crmhlq.odata.
If this enhancement to the OData service is not performed, the end user would also see a
value help on the user interface. However, in this case, the suggested values come from the
query result directly instead of a separate entity. This means that only the values that are part
of the query result can be selected for filtering. It also has a negative impact on the
performance of the value help.
https://<server>:<port>/tmp/hanalive/crm/sample/LostOpportunitiesQuery.xsodata/$metadata
Note:
The port number for HTTPS is usually 43xx; for HTTP it is usually 80xx. (xx = Instance
number of SAP HANA installation, for example 00 or 02). Ensure that the path points to your
OData service definition file.
The result shows the metadata document for your OData service. In addition to the standard
OData V2 annotations, the metadata contains SAP-specific information in the context of
analytical services such as sap:aggregation-role and sap:semantics.
For a detailed description of the SAP-specific enhancements for OData version 2.0, see the
SAP community network article: http://scn.sap.com/docs/DOC-44986.
Create a new entry to define a new SAP HANA Live Query. The following screenshot
contains the information required for the example:
Currently, the Customizing settings for navigation cannot be changed by the customer. A
fixed number of fields are available for navigation. To reuse these Customizing settings for
your own SAP HANA calculation view, you must observe the naming convention for your field.
For example, to enable navigation to the details of an employee responsible in your reporting
result, you must name your SAP HANA field ResponsibleEmployee.
For a list of all available fields for navigation, check the content of the SAP CRM database
table CRMC_ANA_OD_NAV. The field ELEMENT_NAME in the table contains the SAP
HANA field names that can be used for navigation.
The report creation application reuses most parts of the report execution user interface. The
main difference is the ability to save the report and to perform additional tasks, such as
sharing the report or assigning it to specific business roles. However, the main use cases,
such as adding or removing attributes and measures, defining filters or changing the layout
and the chart type to the report are identical in both scenarios (report creation and execution).
1. Choose Create SAP HANA Live Report from the shortcut menu
2. On the dialog box, enter the report name, description and SAP HANA Live Query that you
have specified in Customizing
3. Choose Ok
After confirming the basic data dialog box, the reporting user interface is launched. A
corresponding filter row is displayed on the initial screen for all input parameters for the
associated SAP HANA view:
The input parameter P_SAPClient is hidden from the user interface and the system ensures
that the correct value is transferred to the OData service from the logon data. The input
parameter P_DisplayCurrency is shown on the UI in the section Query Parameters.
After confirming the parameter definition dialog box, you see an empty report that can be
defined step by step (for example add attributes and measures, define additional filters and
select the layout and chart type for the report). Once you have defined the report, choose
Save or Save and Back.
Choose Manage Reports and search for the new SAP HANA Live Report you have created.
Common examples of such dynamic filters are current year or last four quarters. You can
reuse or create your own value expressions to define these types of dynamic filters.
To create your own expression, you must create an ABAP class with a static method that
returns a string value that represents the evaluated filter value.
In Customizing for Customer Relationship Management under CRM Analytics -> SAP HANA
Live Reporting -> Define Value Expressions, you can create your own expression with a
name, description, category and a reference to your ABAP class and method name.
On the reporting user interface, you can select the operator calculated value to assign an
expression in a filter or parameter dialog. The value help shows you all defined expressions
with the category that matches the filter field. For example, a filter field with the date data type
only allows expressions with the category Date. The screenshot below shows the process of
defining a filter for the attribute Posting Date using an expression. The value help for
expressions is shown in the screenshot.