Best Practices for Modeling, Changing, and
Transporting SAP HANA Delivery Units
www.sap.com
Table of Contents
MOTIVATION .....................................................................................................................................................3
ARCHITECTURAL BACKGROUND INFORMATION .......................................................................................3
SAP HANA Repository ...................................................................................................................................... 3
An Example: ........................................................................................................................................................ 4
Activation Modes ................................................................................................................................................. 5
Activation Differences between the SAP HANA Repository and the new SAP HANA Deployment Infrastructure
(HDI) .................................................................................................................................................................... 5
Best Practices for Development Setup ........................................................................................................... 7
Recommendations for the setup of development teams ..................................................................................... 7
Examples for possible team setups ..................................................................................................................... 8
Best Practices for HANA Deployment Units (DU) Setup ................................................................................... 10
Example for a possible model refactoring ......................................................................................................... 11
Best Practices for HANA Transport and Change Management .................................................................. 12
Activation modes for transported content .......................................................................................................... 12
SAP HANA Repository Privileges ...................................................................................................................... 12
Additional Information: ....................................................................................................................................... 12
Best Practices for HANA Data Modelling ...................................................................................................... 13
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form
or for any purpose without the express permission of SAP SE or an SAP
affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products
marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in
the express warranty statements accompanying such products and services,
if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop or release any functionality mentioned therein. This document,
or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform
directions and functionality are all subject to change and may be changed by
SAP SE or its affiliated companies at any time for any reason without notice.
The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking
statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which
speak only as of their dates, and they should not be relied upon in making
purchasing decisions.
SAP HANA MODELLING BEST PRACTISES
MOTIVATION
SAP HANA Modelling is gaining increasing popularity and importance for our customers as they start to
discover the variety of SAP HANA features and possibilities. After all SAP HANA is much more than a simple
in-memory-database. Customers are starting to use features like modelling of calculation views natively in
SAP HANA, leveraging text-analysis capabilities or getting first hands-on experience with the geo-special
engine. The true potential of SAP HANA can be discovered best when customers start working with SAP
HANA in a native way using HANA Repository and the SAP HANA Extended Application Services (XS)
platform.
The motivation for this document is to provide some recommendations and best practices to avoid known
soft spots and to provide background information and a deeper insight on the SAP HANA system behavior.
The recommendations made in this document are valid for all SAP HANA 1.0 Support Package Stacks (SPSs)
that have been published since the introduction of SAP HANA XS.
ARCHITECTURAL BACKGROUND INFORMATION
SAP HANA Repository
The SAP HANA Repository is SAP HANA’s built-in, out-of-the-box, source code repository. Every entity which
you define in SAP HANA is stored in the SAP HANA Repository. The SAP HANA Repository does not
distinguish between storing SAP HANA native artifacts (e.g. tables, views, procedures) and storing other
artifacts (e.g. xsjs coding, xsodata services, html and java script files).
Besides storing the source code, the SAP HANA Repository controls the activation process that generates
native SAP HANA artifacts in the SAP HANA Catalog. The SAP HANA Catalog contains the metadata and the
physical SAP HANA entities, the tables with the data, the view definitions and the procedures. The
interaction between the SAP HANA Repository and the SAP HANA Catalogue is a complex process which
requires a closer look. This interaction process is also very different from what customers know in an SAP
NetWeaver environment.
While SAP NetWeaver from the very beginning had been designed as a platform to run on top of all
databases supported by SAP, the SAP HANA Repository was designed for the SAP HANA database. This has
implications for the process of activating entities in SAP HANA Repository and its influence on the SAP HANA
Catalogue.
First of all, all objects need to be validated for correctness during the activation process. This validation takes
place on the catalog level (by the SAP HANA database) as well as on the SAP HANA Repository level.
Depending on the type of object being activated the SAP HANA Repository checks all objects that are
depending directly or indirectly ("principle of upwards validation") on the activated object in order to
determine if any object dependencies break during the activation. On the catalogue level, incoming
dependencies are also checked, for example interfaces of used objects like tables, views, etc. This can lead to
a cascade of checks that increases significantly with the "network" of dependent objects and can lead also to
a situation in which objects are checked more than once. The goal and benefit of this behavior is the “selfhealing” aspect of the Repository in the sense that it ensures the achievement of a consistent and valid state
for all software artefacts in the HANA Repository after activation.
The downside of these validation cycles are activation times which are potentially long.
3
SAP HANA MODELLING BEST PRACTISES
An Example:
Due to the change of A the entity C2 becomes invalid in the SAP HANA Catalog (see Picture 1), but the
repository has so far no knowledge of it. In SAP HANA Repository C2 is still active. This is an inconsistency
which needs to be solved.
[Picture 1] Example of SAP HANA Repository – SAP HANA Catalog interaction during the activation process: Step1 &
Step2
To solve the inconsistencies between the HANA Repository and the HANA Catalogue the HANA Repository
triggers the DROP-CREATE-sequence for each entity in the entity net (Picture 2 and Picture 3):
 (Step 3) DROP B – (STEP 4) CREATE B
 (Step 5) DROP C1 – (STEP 6) CREATE C1
 (Step 7) DROP C2 – (STEP 8) CREATE C2
[Picture 2] Example of SAP HANA Repository – SAP HANA Catalog interaction during the activation process: Step3 &
Step4.
4
SAP HANA MODELLING BEST PRACTISES
[Picture 3] Example of SAP HANA Repository – SAP HANA Catalog interaction during the activation process: Step5 –
Step8.
After step 8 the consistency between the HANA Repository and the HANA Catalogue is re-established.
Activation Modes
Based on this general activation logic there are several different activation modes: 1-phase, 2-phase, import
mode (mode 4).
The 1-phase approach performs activation and re-evaluation in a single transaction.
The 2-phase mode first tries to activate an "activation set" and then to perform a commit. The re-evaluation
and potential re-creation of dependent artefacts is then performed in a second step along with the second
commit.
The import mode first marks all objects as “active” and then sorts them according to type before performing
the commit.
For more information about the activation modes, see the next sections of this document.
Differences of the activation process between the SAP HANA Repository and the new SAP HANA
Deployment Infrastructure (HDI)
With SAP HANA SPS11 SAP introduced new concepts for the repository and for the deployment and
activation of SAP HANA entities. This happens alongside with the development of the SAP HANA XS
Advanced platform. With SAP HANA XS Advanced Git becomes the default repository for source code
management. If the customer system landscape includes a central Git repository it can be attached to the
SAP HANA XS Advanced platform. Alternatively a Git repository is also offered as part of the SAP HANA
delivery.
5
SAP HANA MODELLING BEST PRACTISES
The activation behavior of the SAP HANA Deployment Infrastructure (HDI) makes use of the so-called "VModel" for view activation, if possible, where the complete view stack built on top of the object to be
activated is first dropped and then reconstructed from the bottom up. This saves checks and re-checks at the
catalog level and therefore should considerably reduce activation times.
6
SAP HANA MODELLING BEST PRACTISES
Best Practices for Development Setup
The following sections of this document give dedicated recommendations for the setup of the development
teams and development landscapes, for the definition of development units (DUs) and the transport and
change management. Finally, it contains some best practices for data modelling in SAP HANA to support
developers, data modelers and system administrators.
Recommendations for the setup of development teams
All developers of a given team should work with the same SAP HANA Repository. You may want to consider
using the multi-database-container feature (MDC) with tenant databases to allow for multiple teams
working in the same SAP HANA system while using separate Repositories. The optimal development setup is
given when each team develops in one dedicated SAP HANA tenant using the tenant’s SAP HANA Repository.
In MDC setups share test and replicated data via dedicated tenant databases and access them via crossdatabase synonyms from the development tenant database.
Constraints:
The cross-database access is read-only i.e. there is no write access possible to a foreign tenant database.
Synonyms work only with SQL Script, SQL Views, .hdbview, CDS views with the same schema name.
Calculation views can access objects from different schemas and tenant databases by means of an authoring
schema which is maintained along with calculation view definitions. There are some restrictions which are
documented in the MDC Guide
http://help.sap.com/hana/SAP_HANA_Multitenant_Database_Containers_en.pdf, Chapter 2.4 and in two
SAP notes:
-
2196359 - Limitations for cross-database access in an SAP HANA MDC environment
2248345 - HANA SPS 11 MDC - Limitations for cross-database access
The following special recommendations apply for attribute and analytical views:
 Attribute views and analytical views do not work with cross-tenant access.
 Migrate attribute and analytical views to calculation views using the “migrate” link in SAP HANA Studio
“Quick view”.
Define transport routes to all development tenants for reuse DUs. Setup a consolidation database (single or
tenant) where all relevant DUs are deployed into.
Make sure that you assign one DU to one team.
7
SAP HANA MODELLING BEST PRACTISES
Examples for possible team setups
Team-setup possibility 1:
Each team works in one tenant DB (T1 ... Tn) on dedicated disjunctive delivery units (Picture 4):
1. The team semantically PUSHES its own changes from T-development tenant to consolidation tenant:
a. Transport DU from T-development tenant to Cons tenant
b. Check issues in Cons tenant
c. Fix issues in T-development tenant
d. Transport anew the DU from T-development tenant to Cons tenant
2. The team semantically PULLS DUs of other teams from the consolidation tenant on as needed basis
SAP Tool Support
HALM
Implementation: transports
always triggered from the
target system
CTS+
Implementation: transports
always triggered from the
source system
Step 1
supported
supported
Step 2
supported
supported
[Picture 4]: Two phase push and pull of DUs.
8
SAP HANA MODELLING BEST PRACTISES
Team-Setup Possibility 2:
Each Team works in one Tenant DB (T1 ... Tn) on dedicated disjunctive delivery units:
1. The team semantically PUSHES its own changes from T-development tenant after testing the
downstream chain of tenants
a. Transport DU from T-development tenant to next downstream tenant
b. Check issues in next tenant
c. If an issue occurs fixes should always be done in the source system of the DU and transported to
downstream tenants to avoid conflicts.
2. No back transport necessary.
T3
DU3
T2
DU2
T1
DU1
DU2
2
1
DU1
DU1
T2
DU4
DU1
9
SAP HANA MODELLING BEST PRACTISES
SAP Tool Support
HALM
CTS+
Implementation: transports
always triggered from the
target system
Implementation: transports
always triggered from the
source system
Step 1
supported
supported
Step 2
supported
supported
[Picture 5] Downstream push of changes.
Best Practices for HANA Deployment Units (DU) Setup
The activation of imported DUs may become a time-consuming task and it is important to know the
implications that the DU activation process can have on a SAP HANA system.
SAP HANA schemas are primarily of importance to ensure the separation of content and for database
security. They have some impact on the performance when activating .hdbrole artifacts (schema privileges
vs. single object privileges for many objects).
It is also important to understand that during the activation of a DU all affected objects are blocked till the
end of the activation process. As a consequence no debugging and no view content usage is possible. On the
other hand debugging activities which are performed at the same time as an activation operation block the
activation of the corresponding or dependent objects. During the running activation process the system
generates temporary locks on the affected objects, this makes reporting on affected views sometimes
impossible.
Consequently, DUs should be defined according to business topics which need to be transported and
activated together. Separate DUs should be defined for re-use layers. It is recommended to have one team
developing on one DU. Model activation of the imported DU can lead to long running activation times when
the model has too many object dependencies.
If the model contains Scripted Calculation Views it is recommended to update the SAP HANA system to the
latest maintenance revision of the current SAP HANA 1.0 Support Package Stack (SPS) to take advantage of
performance improvements of the activation process.
In many cases the view models are made unnecessarily large leading to disproportionately high activation
times and numbers of activations. If you face activation times longer than acceptable, consider refactoring
the models in the source system to different and smaller packages. But note that introducing a high number
of (small) DUs may increase the overall activation time if those DUs are imported in a suboptimal order - e.g.
activating one DU with 100 objects may finish faster than activating 10 DUs with 10 objects if those 10 DUs
depend on each other.
The performance of the activation process mainly depends on the number of objects which are invalidated
during the import. Therefore, you should avoid unnecessary dependencies between objects.
10
SAP HANA MODELLING BEST PRACTISES
Example for a possible model refactoring
Analytical views (AVs) are not directly used by front-end tools are collected in package P_CORE1, Calculation
views (CVs) which are accessed by front-end tools are in package P_EXT. In the source system P_CORE1 can
be refactored (moved) to package P_CORE2 and transported. As the package P_CORE1 is not touched in the
target system reporting is still possible. Afterwards P_CORE2 and P_EXT can be transported to the target
system. Such a refactoring reduces the reporting downtime to the activation time of DU CORE2 objects
which is typically much faster.
[Picture 6] Model refactoring
11
SAP HANA MODELLING BEST PRACTISES
Best Practices for HANA Transport and Change Management
Start transports with bottom level DUs which have as little dependencies as possible.
Activation modes for transported content
There are three defined modes to trigger the activation of the transported content:
1. One-phase activation
2. Two-phase activation
3. Import mode.
In the event of transport errors during one-phase activation, the state is the same as prior to the transport.
This mode should be used for transports into productive systems.
The two-phase activation mode:
1. If the import / activation fails then the state is the same as before (like one-phase activation)
2. If the import / activation succeeds, but the revalidation fails then the DU objects are imported and
activated; but the revalidated dependent objects might be invalid.
The usage of the two-phase activation mode makes sense for transports in the development landscape to
ensure that development activities can continue despite of inconsistencies in the SAP HANA content.
The usage of the import mode might make sense in dedicated scenarios, but the activation state in the SAP
HANA system can become unclear.
SAP HANA Repository Privileges
For SAP HANA Repository the following package privileges are defined:
 REPO.EDIT_NATIVE_OBJETCS
 REPO.ACTIVATE_NATIVE_OBJETCS
 REPO.EDIT_IMPORTED_OBJECTS
 REPO.ACTIVATE_IMPORTED_OBJECTS
In the transport target system the objects are understood as imported objects which means developers or
those responsible for the transport do not have “edit” or “activate” privileges.
Note that the activate privilege enables you to check the objects.
To summarize: a separate check for imported objects is necessary if you want to execute syntax checks in
the transport target system to identify root causes.
Additional Information:
The Change Recording blog:
http://scn.sap.com/community/it-management/alm/software-logistics/blog/2015/05/19/understanding-ofnative-transport-of-changes-in-halm
The SAP HANA Application LM Guide:
http://help.sap.com/hana/SAP_HANA_Application_Lifecycle_Management_en.pdf
12
SAP HANA MODELLING BEST PRACTISES
Best Practices for HANA Data Modelling
When modelling data in SAP HANA it is important to know that some modelling options are no longer
recommended and should not be used for new development:
1. Scripted Calculation Views (CalcViews) should not be used. Use of CalcViews with table functions
instead.
 Usage of Scripted Calculation Views is not recommended because they do not fully support a
rollback during activation. SAP decided to not support Scripted Calculation Views in the SAP
HANA Deployment Infrastructure (HDI).
 Constraint: CalcViews with table functions cannot run in invoker mode.
2. Do not use implementation objects of CalcViews such as procedures of scripted CalcViews. Use the
CalcViews itself.
3. Switch off the creation of hierarchy views to speed up the activation time of CalcViews:
 Leave the data category in CalcView properties blank. This prevents the generation of
hierarchy views.
 Applies only if the CalcView is not consumed by any BI tool which accesses the view via
_SYS_BI.BIMC*
4. Avoid any combination of dependent Repository and catalog objects:
 Create Repository object A
 Via catalog generate object B which uses A
 Create Repository object C which uses B
 In such setups the user who owns the object B needs grant-option-privileges for object A
which is not possible.
5. When using virtual tables bear in mind that during the deployment and activation process the HANA
system can trigger the logon to the remote system.
 Make sure that the logon data to the remote system is valid
 Make sure that the defined timeouts in the remote system are long enough to enable the
import and activation process to complete.
Sometimes customers have concerns about the need for various tools for modelling. For example, the
modelling of new BW on HANA models is done in Eclipse old models are still in the traditional SAP GUI
whereas SAP HANA models are moved to the SAP HANA Web-Based Development Workbench.
SAP’s strategy on modelling tools focusses on Web-based tools. New development is done for SAP HANA
Web IDE which was recently delivered for SAP HANA SPS11 with continuous work in coming SPSs to close all
feature gaps.
13