SAP Documentation

SAP HANA Appliance Software

Applicable Releases:
SAP HANA Appliance Software SPS 03/04







Version 1.1
March 2012

SAP HANA Content/Software Lifecycle Management


Copyright 2012 SAP AG. 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 AG. The
information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors
contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered
trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p,
System p5, System x, System z, System z10, System z9, z10, z9, iSeries,
pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390,
OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power
Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER,
OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,
HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex,
MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and
Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other
countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either
trademarks or registered trademarks of Adobe Systems Incorporated in
the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open
Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame,
and MultiWin are trademarks or registered trademarks of Citrix Systems,
Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks
of W3C, World Wide Web Consortium, Massachusetts Institute of
Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used
under license for technology invented and implemented by Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP
BusinessObjects Explorer, StreamWork, and other SAP products and
services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and other
countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other
Business Objects products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of Business
Objects Software Ltd. Business Objects is an SAP company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere,
and other Sybase products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of Sybase, Inc.
Sybase is an SAP company.

All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this
document may be reproduced, copied, or transmitted in any form or for
any purpose without the express prior written permission of SAP AG.
This document is a preliminary version and not subject to your license
agreement or any other agreement with SAP. This document contains
only intended strategies, developments, and functionalities of the SAP
product and is not intended to be binding upon SAP to any particular
course of business, product strategy, and/or development. Please note
that this document is subject to change and may be changed by SAP at
any time without notice.
SAP assumes no responsibility for errors or omissions in this document.
SAP does not warrant the accuracy or completeness of the information,
text, graphics, links, or other items contained within this material. This
document is provided without a warranty of any kind, either express or
implied, including but not limited to the implied warranties of
merchantability, fitness for a particular purpose, or non-infringement.
SAP shall have no liability for damages of any kind including without
limitation direct, special, indirect, or consequential damages that may
result from the use of these materials. This limitation shall not apply in
cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not
affected. SAP has no control over the information that you may access
through the use of hot links contained in these materials and does not
endorse your use of third-party Web pages nor provide any warranty
whatsoever relating to third-party Web pages.
SAP How-to Guides are intended to simplify the product
implementation. While specific product features and procedures typically
are explained in a practical business context, it is not implied that those
features and procedures are the only approach in solving a specific
business problem using SAP NetWeaver. Should you wish to receive
additional information, clarification or support, please refer to SAP
Consulting.
Any software coding and/or code lines / strings (Code) included in this
documentation are only examples and are not intended to be used in a
productive system environment. The Code is only intended better explain
and visualize the syntax and phrasing rules of certain coding. SAP does
not warrant the correctness and completeness of the Code given herein,
and SAP shall not be liable for errors or damages caused by the usage of
the Code, except if such damages were caused by SAP intentionally or
grossly negligent.
Disclaimer
Some components of this product are based on Java. Any code change
in these components may cause unpredictable and severe malfunctions
and is therefore expressively prohibited, as is any decompilation of these
components.
Any Java Source Code delivered with this product is only to be used by
SAPs Support Services and may not be modified or altered in any way.


Document History
Document Version Description
0.9a First draft
0.9b Template Change
0.9c Template Change & Change Tracking Activated
1.0 Released Internal Version
1.1 REGI Improvements from SPS4 Drop 8





Typographic Conventions
Type Style Description
Example Text Words or characters quoted
from the screen. These
include field names, screen
titles, pushbuttons labels,
menu names, menu paths,
and menu options.
Cross-references to other
documentation
Example text Emphasized words or
phrases in body text, graphic
titles, and table titles
Example text File and directory names and
their paths, messages,
names of variables and
parameters, source text, and
names of installation,
upgrade and database tools.
Example text User entry texts. These are
words or characters that you
enter in the system exactly
as they appear in the
documentation.
<Example
text>
Variable user entry. Angle
brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.
EXAMPLE TEXT Keys on the keyboard, for
example, F2 or ENTER.
Icons
Icon Description

Caution

Note or Important

Example

Recommendation or Tip






Table of Contents
1. Introduction ...........................................................................................................................1
2. Delivery Units .........................................................................................................................1
2.1 Naming Convention ......................................................................................................... 2
2.2 Vendor Maintenance ........................................................................................................ 2
2.3 Creating a Delivery Unit ................................................................................................... 4
2.3.1 Creating a Delivery Unit without Studio Support ............................................ 5
2.3.2 Creating a Delivery Unit with Studio Support .................................................. 7
2.4 Creating a Delivery Unit Dependency ............................................................................ 9
3. Packages ............................................................................................................................. 12
3.1 Naming Conventions for Packages ...............................................................................12
3.2 Types of Packages ..........................................................................................................13
3.2.1 Structural Packages ..........................................................................................13
3.2.2 Default Packages ...............................................................................................13
3.2.3 Package Transportability ..................................................................................13
3.2.4 Packages for Generated Content .................................................................... 14
3.2.5 User-private Packages ..................................................................................... 14
3.2.6 Governing the Package Structure ................................................................... 14
3.3 Creating a Package ........................................................................................................ 14
3.3.1 Package Hierarchy and Structure Packages .................................................. 17
3.4 Repository Authorizations............................................................................................. 19
3.4.1 Package Authorizations / Object Authorizations .......................................... 19
3.4.2 General Repository Authorizations ..................................................................21
3.4.3 Granting Repository Authorizations to Users with SQL ................................21
3.5 Managing a Package in Team Provider ........................................................................ 22
3.5.1 Creating an Eclipse Project .............................................................................. 23
3.5.2 Sharing the Project ........................................................................................... 25
3.5.3 Adding Packages to the Project Explorer ....................................................... 28
3.5.4 Creating a Package using Team Provider ...................................................... 29
3.6 Managing a Package using REGI................................................................................... 32
3.6.1 Creating a Workspace/Project via REGI......................................................... 32
3.6.2 Adding Packages to the REGI Workspace ...................................................... 34
3.6.3 Creating a Package via REGI ............................................................................ 35
4. Object Management ........................................................................................................... 37
4.1 Object Management in Team Provider ........................................................................ 38
4.1.1 Object Creation Using Team Provider ............................................................ 40
4.1.2 Object Activation Using Team Provider .......................................................... 43
4.1.3 Checkout Using Team Provider ....................................................................... 43
4.1.4 Conflict Resolution in Team Provider ............................................................. 44
4.2 Object Management using REGI ................................................................................... 48
4.2.1 Command Reference for REGI ........................................................................ 49
4.2.2 Object Creation Using REGI ..............................................................................51


4.2.3 Object Activation Using REGI........................................................................... 52
4.2.4 Checkout Using REGI ........................................................................................ 53
4.2.5 Conflict Resolution Using REGI ....................................................................... 54
5. Export / Import ................................................................................................................... 55
5.1 Change Tracking and Patching ..................................................................................... 56
5.1.1 Export ................................................................................................................. 56
5.1.2 Import ................................................................................................................. 61
5.2 Troubleshooting Export/Import ................................................................................... 65
5.2.1 Traces ................................................................................................................. 65
6. Translation .......................................................................................................................... 69
6.1 Repository Translation Tool (RTT) ............................................................................... 70


HANA 1.5 Partitioning (Internal)
March 2012 1
1. Introduction

The SAP HANA repository provides features for management of various kinds of SAP HANA
objects, including a namespace concept, transport (export from one HANA system, import into
another), software component delivery, translatable texts, object versioning, and more. This guide
provides an overview of the key concepts related to the aforementioned lifecycle management
aspects, and takes a how-to approach with examples to illustrate the proper usage of repository
features.
A key concept for SAP HANA lifecycle management is the package. Every repository object must
be created within a package, and therefore belongs to that package. A package can contain an
arbitrary number of objects of arbitrary types. A key purpose of the package is to establish a
namespace. In the repository, an object is uniquely identified by the combination of its package
name, object name and object type. That means that multiple objects of the same type may have
the same object name if they belong to different packages.
Another key concept for SAP HANA lifecycle management is the delivery unit. A delivery unit is a
logical grouping of packages. It defines a set of packages that are transported or shipped together.
A delivery unit roughly corresponds to the concept of a software component, or in a customers
system, a project (or major unit of a project).The export functionality allows you to export complete
delivery units, including all packages and objects contained therein. In addition, dependencies can
be defined between delivery units. This allows checking whether all references between objects
from different delivery units are permitted through corresponding dependencies between delivery
units.
A package can be assigned to a delivery unit (by filling the respective attribute fields, delivery_unit
and du_vendor, in the package header). Note that the assignment of packages to delivery units is
independent of the package hierarchy. Each and every package must be assigned individually to a
delivery unit. Parent and child packages can belong to different delivery units.

Figure 1 - A Delivery Unit comprises all packages that are assigned to the Delivery Unit and all
objects in these packages

2. Delivery Units

Delivery Units are the vehicles to deliver software from SAP (or partner) to customers, and also to
transport repository content between SAP HANA systems. A delivery unit is identified by two key
fields: vendor and name. While a vendor might offer multiple versions of a delivery unit in parallel,
only one version of a delivery unit can be installed in a HANA System at a time. The well-established
LCM of SAP treats delivery units and their versions as software components and software
component versions. Software components and software component versions are usually shipped
as part of a surrounding product / product version.

HANA 1.5 Partitioning (Internal)
March 2012 2
2.1 Naming Convention
The name of a Delivery Unit must consist only of capital letters, digits and underscore
It must not start with an underscore
2.2 Vendor Maintenance
Delivery units are identified by a vendor and a name. Vendor is used for a company producing
software, but also for a customer implementing SAP HANA, vendor is a generic term here. Before
maintaining your own delivery units, the vendor property of the current system should be set in the
indexserver.ini file, as value of the property content_vendor in the section [repository]. New
delivery units that you create will then belong to this vendor.
To avoid naming conflicts, it is highly recommended to use reserved DNS names. SAP content
development systems e.g. should use the vendor sap.com. Customers and partners should use
their own domain names, e.g. smithwidgets.com.

In order to maintain the vendor setting, switch to the Administrative perspective in the SAP
HANA Studio.

From the Configuration tab, you can choose the configuration file you wish to edit. In order
to configure the Vendor, you should edit the indexserver.ini file.
HANA 1.5 Partitioning (Internal)
March 2012 3
In the [repository] section, you will find the content_vendor property.

Maintain your new value and then save. If you are a customer or partner, enter your own
domain name here, e.g. smithwidgets.com. For internal development teams at SAP, use
sap.com.

HANA 1.5 Partitioning (Internal)
March 2012 4
The new value will now be reflected in the Configuration.

2.3 Creating a Delivery Unit

Once the vendor has been established, the next step is to create a delivery unit.
HANA 1.5 Partitioning (Internal)
March 2012 5
2.3.1 Creating a Delivery Unit without Studio Support
Until very recent versions of SAP HANA Studio, there was no specialized tool to create or
maintain Delivery Units. Therefore we will directly create entries in the underlying database
table which holds all Delivery Units. The table can be found in the schema _SYS_REPO and
is named DELIVERY_UNITS.


Here we use a SQL INSERT statement in the SAP HANA Studio SQL Editor to create a new
delivery unit:

insert into _SYS_REPO.DELIVERY_UNITS values ('SAPDEMO1', 'SAP',
'1.0', 'sap.com', '', '');


HANA 1.5 Partitioning (Internal)
March 2012 6
You can check the current list of delivery units, which should include your newly created
delivery unit, by using the Open Data Preview option on the table.


HANA 1.5 Partitioning (Internal)
March 2012 7
If you were to accidentally create a delivery unit which already exists in your system, you
will receive a validation error:
However, be aware that a validation for valid vendor does not exist; making it possible, for
example, to create a delivery unit for an invalid vendor by accident. Make sure you are
assigning the delivery unit to a valid vendor.


2.3.2 Creating a Delivery Unit with Studio Support
If you are on a newer version of SAP HANA, you can instead accomplish this same task of creating
delivery unit from the Quick Launch tool of the Modeler Perspective.
HANA 1.5 Partitioning (Internal)
March 2012 8
Choose Delivery Units from within the Setup group of the Quick Launch menu.

From this dialog, you can create or delete delivery units as well as assign existing packages
to your delivery units. Packages will be covered in the next section of this document.

HANA 1.5 Partitioning (Internal)
March 2012 9
When creating a delivery unit via this tool, the vendor is automatically set from the
configured entry from the indexserver.ini file and cannot be overridden.

2.4 Creating a Delivery Unit Dependency
SAP HANA also supports the maintenance of dependencies between delivery units. A transport of a
delivery unit will also transport the definition of these dependencies.
HANA 1.5 Partitioning (Internal)
March 2012 10
There is no specialized tool to create or maintain Delivery Unit dependencies. Therefore we
will directly create entries in the underlying database table which holds all Delivery Unit
dependencies. The table can be found in _SYS_REPO and is named
LEGAL_DEL_UNIT_DEPENDENCIES.

We will then write a small INSERT SQL Statement in the SAP HANA Studio SQL Editor to
create a new Delivery Unit dependency:

INSERT INTO _SYS_REPO.LEGAL_DEL_UNIT_DEPENDENCIES
VALUES ('SAPDEMO1', 'SAPDEMO2', 'sap.com', 'sap.com');


HANA 1.5 Partitioning (Internal)
March 2012 11
You can check the current list of Delivery Unit dependencies, which should include your
newly created dependency, by using the Data Preview option on the table.


If you were to accidentally create a Delivery Unit dependency which already exists in your system,
you will receive a validation error:
However, other validations do not exist, making it possible, for example, to create a dependency to
HANA 1.5 Partitioning (Internal)
March 2012 12
a delivery unit which doesnt even exist. Make sure you are assigning to a valid vendor.


3. Packages
Package is a key concept for SAP HANA lifecycle management in working with the repository. Every
repository object is assigned to a package. The main purpose of the package is to establish a
namespace. In the repository an object is uniquely identified by the combination of its package
name, object name and object type. That means that multiple objects of the same type may have
the same object name if they belong to different packages. A package typically consists of
numerous repository objects. A package hierarchy can be created, establishing parent-child type
relationships between packages. Packages are assigned to delivery units. Note that the assignment
of packages to delivery units is independent of the package hierarchy. Each and every package
must be assigned individually to a specific delivery unit. However, parent and child packages can
belong to different delivery units.

3.1 Naming Conventions for Packages
Package names are strictly limited to lower- and uppercase-letters, digits, "-" (hyphen), and
"." (dot)
Packages must not start or end with a dot or a hyphen
Two or more consecutive dots are not allowed

Packages that use a dot in their name are considered to form a logical hierarchy in the following
way:
"a.b" is considered a sub-package of "a"
"a.b.c" is considered a sub-package of "a.b"

The repository supports this hierarchical convention in the following manner:
When a package "a.b.c" is created, missing parent packages "a.b" and "a" are automatically
created
Packages can only be deleted if they do not contain objects nor have any sub-package
There is a method that delivers for a given package all direct sub-packages
Authorizations are inherited along the package hierarchy chain: if a user has a permission
on a package, then they have the same permission on all sub-packages of the package, or
more if additional permissions are granted there directly

HANA 1.5 Partitioning (Internal)
March 2012 13
3.2 Types of Packages
There are a few different package types which represent special use cases or special rules which
are applied to the package.

3.2.1 Structural Packages

By setting the property is_structural to Yes (which is 1 in the database field), this specifies that the
package cannot contain objects, but rather sub-packages only.


3.2.2 Default Packages

The repository provides some built-in packages; their purposes are described in the following
sections. The following packages are delivered by default with the repository:

sap (structural=true, src-system='sap')
system-local (structural=true, src-system=<local system id>)
system-local.generated (structural=true, src-system=<local system id>)
system-local.private (structural=true, src-system=<local system id>)

3.2.3 Package Transportability

The package system-local and all of its sub-packages are considered non-transportable, all other
packages are transportable. This is similar to the concept of the $tmp development class in SAP
NetWeaver ABAP.


HANA 1.5 Partitioning (Internal)
March 2012 14
3.2.4 Packages for Generated Content

All sub-packages of the delivered package system-local.generated should be used for generated
content (i.e. content that is not created by manual user interaction).

3.2.5 User-private Packages

The packagesystem-local.private can have subpackages that belong to individual users, which are
named after these users - and are exclusively reserved for these users.
Example: package system-local.private.Fritzle belongs to user Fritzle and is reserved for user
Fritzle.
User-private packages are future functionality, and are not completely implemented in SAP
HANA as of the publication of this document.

3.2.6 Governing the Package Structure

All content delivered by SAP should be in some sub-package of "sap". Partners and customers
should choose their own root package, they should NOT create packages or objects under the sap
root folder. There are no system mechanisms for enforcing this. Both for internal development and
for customer/partners, a governance process is needed to make sure that two teams/projects
dont attempt to create the same package names off of the root package in two different
development systems.

3.3 Creating a Package
From the SAP HANA Studio, the process of creating a new package or structuring a package
hierarchy is relative straightforward, as the functionality is built into the navigator of the Modeler
perspective.
.
HANA 1.5 Partitioning (Internal)
March 2012 15
Begin by right mouse clicking on the Content folder of your HANA System in the Navigator
window of the Modeler Perspective. Then choose New -> Package

The Delivery Unit field will offer the possible options which we created in the previous
section of this document. The Original Language setting will be important later if you intend
to perform language translation.

HANA 1.5 Partitioning (Internal)
March 2012 16
You can create sub-packages by repeating the above process, but starting from the parent
package.

You can also create multiple packages within a hierarchy from one dialog by simply utilizing
the previously described naming convention, which indicates a parent-child relationship.
For example:

HANA 1.5 Partitioning (Internal)
March 2012 17


3.3.1 Package Hierarchy and Structure Packages
The previous steps were focused on the process and not the actual package hierarchy. Packages
should be structured under a single root package representing the vendor. In the case of the
example, this would be the default sap package. The package for this example project is then
named demo-main and it has two sub packages to isolate the data model from the business logic.
Although there are no package interfaces to enforce visibility of objects across packages, this
separation of logical layers of development is still a recommended best practice.

In this example, demo-main is now the root of the delivery unit, and therefore we should convert it
into a structure package. Remember that a structure package is a package which does not contain
objects, but rather sub-packages only.
HANA 1.5 Partitioning (Internal)
March 2012 18
You can choose to Edit the demo-main package from the Navigator of the Modeler
perspective.

From the Edit Package Details dialog, there is the additional option to set this package to be
structural.

HANA 1.5 Partitioning (Internal)
March 2012 19
Notice that the icon for the demo-main package in the navigator window has changed to
signify that it is now a structural package.



3.4 Repository Authorizations
Authorizations are available in the Repository, which allow you to secure operations such as
reading and editing objects. Most of the repository authorizations work on the granularity of
packages, taking into account the package hierarchy.

3.4.1 Package Authorizations / Object Authorizations

When a user attempts to access an object in a package, first there is a check to see if the user has
the necessary privilege for the package for which they want to perform an operation; for example to
read or write to an object in that package. If the user is not authorized for the specific package,
then the authorization check is repeated on its parent package and then recursively up the package
hierarchy to the root level of the repository. If the user does not have the necessary privilege on
any of these packages, they will receive an authorization error. In other words, authorizations that
are assigned on a package are automatically and implicitly also assigned to all sub-packages.
Within the authorizations context, there is a distinction between native packages and imported
packages. Native packages are packages that were created in the current system and are thus
expected be edited in the current system. Packages that were imported from another system
generally should not be edited, except by updates via new imports, or manually in very rare
exceptional cases (e.g. emergency repairs).
Package authorizations can be set for a specific user or for a role. This is accessible from the
Modeler perspective, expand Catalog -> Authorization -> Roles or Users, and make a selection.
Next, choose the Package Privileges tab. For example:

HANA 1.5 Partitioning (Internal)
March 2012 20


Here you can select the appropriate privileges for packages, which will apply to all objects within
that package (and by default, to all sub-packages and objects contained therein unless overridden).
Developers typically should be granted these privileges in development systems, for packages for
which they have responsibility:
REPO.READ: read access to packages and design-time objects (native and imported
objects)
REPO.EDIT_NATIVE_OBJECTS: allows changes to design-time objects in packages
originating in the system in which the user is working (changing an object takes place in an
inactive version, which must be subsequently activated)
REPO.ACTIVATE_NATIVE_OBJECTS: activate / reactivate design-time objects in packages
originating in the system in which the user is working
REPO.MAINTAIN_NATIVE_PACKAGES: update or delete native packages, or create sub-
packages of packages originating in the system in which the user is working
Only in very rare cases the following privileges should be granted and used (e.g. repairs)!
REPO.EDIT_IMPORTED_OBJECTS: allows changes to design-time objects in imported
packages (changing an object takes place in an inactive version, which must be
subsequently activated)
REPO.ACTIVATE_IMPORTED_OBJECTS: activate / reactivate design-time objects in
imported packages
REPO.MAINTAIN_IMPORTED_PACKAGES: update or delete imported packages, or create
sub-packages of imported packages
HANA 1.5 Partitioning (Internal)
March 2012 21
Normally, any changes to objects in packages should be performed in their original development
system and transported into subsequent systems. Editing objects in test or production systems
violates normal change control procedures, and should only be done in exceptional cases (e.g.
emergency repair).

3.4.2 General Repository Authorizations
In addition to the authorizations on specific packages and objects in those packages, there are
some general privileges available which enable access to basic Repository operations. You can find
them in the Modeler perspective, expand Catalog -> Authorization -> Roles or Users, and make a
selection. Next, choose the System Privilege tab. Next, choose Select System Privilege, for
example:

REPO.EXPORT: allows the ability to export delivery units
REPO.IMPORT: allows the ability to import transport archives
REPO.MAINTAIN_DELIVERY_UNITS: allows the ability maintain own ones own
delivery units (in which case, the DU-vendor must equal the system-vendor)
REPO.WORK_IN_FOREIGN_WORKSPACE: allows the ability to move objects from a
foreign inactive workspace to your own workspace

3.4.3 Granting Repository Authorizations to Users with SQL

You can also grant/revoke repository privileges directly with SQL. All users who want to access the
repository from Eclipse or other clients need the EXECUTE permission for the database procedure
through which the REST API is tunneled:
GRANT EXECUTE on SYS.REPOSITORY_REST to SYSTEM23 [with GRANT OPTION];

HANA 1.5 Partitioning (Internal)
March 2012 22
3.4.3.1 Example: Granting Repository Super-User privileges via SQL:
With the following sequence of GRANT statements you make the example user KENT a super-user
for the repository - a user who is allowed to do everything (and who may also empower other
users):
GRANT REPO.READ on ".REPO_PACKAGE_ROOT" to KENT [with GRANT OPTION];
GRANT REPO.EDIT_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.ACTIVATE_NATIVE_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.MAINTAIN_NATIVE_PACKAGES on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.ACTIVATE_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.MAINTAIN_IMPORTED_PACKAGES on ".REPO_PACKAGE_ROOT" to KENT
[with GRANT OPTION];
GRANT REPO.EXPORT to KENT [with ADMIN OPTION];
GRANT REPO.IMPORT to KENT [with ADMIN OPTION];
GRANT REPO.MAINTAIN_DELIVERY_UNITS to KENT [with ADMIN OPTION];
GRANT REPO.WORK_IN_FOREIGN_WORKSPACE to KENT [with ADMIN OPTION];

3.5 Managing a Package in Team Provider
So far we have been working exclusively with the Navigator window of the Modeler perspective in
the SAP HANA Studio. This view displays our package hierarchy in full, but currently is limited to
only Modeler specific objects within the package (i.e. views and procedures). In SPS4, the
Navigator will be extended to display all repository objects. However in SAP HANA we can have a
variety of other types of objects stored in the Repository. For example a developer may also need
to manage user interface layer files or server side logic.
There is an additional tool called Team Provider which is part of the SAP HANA Developer
Workbench and installs as part of the SAP HANA Studio. This tool allows developers to manage
Packages from the Content Repository and utilize common source code control mechanisms on
this content.
The Team Provider integrates in SAP HANA Studio into the Project Explorer Window. It displays
only the sub-set of the packages in the Repository which the developer has added for local
HANA 1.5 Partitioning (Internal)
March 2012 23
management. Notice in the following figure how our new demo-main packages are present in the
Navigator view but not the Project Explorer:

3.5.1 Creating an Eclipse Project
Before you can begin to manage an SAP HANA Repository via the Team Provider/Project Explorer,
you must first create an Eclipse project. This project will represent a collection of packages from
the SAP HANA system which you want to work on for a single purpose. It will link to your
connection and authentication details which you have already maintained in the SAP HANA Studio.
You can have multiple projects connected to a single HANA instance.
From the Project Explorer, Choose New->Project.

HANA 1.5 Partitioning (Internal)
March 2012 24
Create a General Project:

HANA 1.5 Partitioning (Internal)
March 2012 25
Name your project. Note: this is also creating a workspace folder structure on your client
machine file system in order to store files during check-out and editing.

We now have a new, local project. It is not yet connected to our SAP HANA system or its
Repository.


3.5.2 Sharing the Project
Next we will connect this project to our SAP HANA System and its Repository. We perform this task
by sharing the project.
HANA 1.5 Partitioning (Internal)
March 2012 26
Right mouse click on the newly created project in the Project Explorer and choose Team ->
Share Project:

Choose the type of repository plug-in you want to use for the shared project. The SAP
HANA Studio has a standard plug-in called SAP HANA Repository.

HANA 1.5 Partitioning (Internal)
March 2012 27
Choose the appropriate SAP HANA System/User from the next dialog and then press the
Finish button:

The project is now linked to this SAP HANA System. We can see that this is a linked
package because the icon next to the project name has changed and we have a variety of
additional context menu choices under the Team option:

HANA 1.5 Partitioning (Internal)
March 2012 28
3.5.3 Adding Packages to the Project Explorer
From the Project Explorer window, right mouse click on your SAP HANA System and choose Team
-> Add Packages (Note: Regardless of the phrase Add Packages, you are not actually creating
packages via this tool.):

The resulting dialog will display all packages in your system. For example, we can highlight all the
sap.demo related packages and add them together:

HANA 1.5 Partitioning (Internal)
March 2012 29
The packages we selected in the previous step are now tracked packages. In addition to being
added to the Project Explorer, matching folders have been created in the workspace of the local
files system on the client machine.

We will discuss source management (check-in/check-out/merging) of individual artifacts in the
next section of this document.
3.5.4 Creating a Package using Team Provider
So far all the work we have shown with the Team Provider involved only extending access to already
existing packages which had been created via the HANA Studio Modeler. However, packages (and
as we will see later, many objects) can also be created from the Team Provider.
To create a project within the Team Provider; from the Project Explorer window, choose a
package within your project and right mouse click. Then choose New -> Folder.

HANA 1.5 Partitioning (Internal)
March 2012 30
A dialog then allows you to further refine the name of the new folder and its location.

If you look at the content view in the Navigator, you can see that a corresponding package
for this new folder now exists. And based upon the icon, we also know that it is already a
tracked package because it was created as a child of a tracked package.

HANA 1.5 Partitioning (Internal)
March 2012 31
Next, edit this package from the Navigator window in order to set package-specific
properties such as the Delivery Unit and the Person Responsible.

As already mentioned, our new package was automatically a tracked package (meaning
content is automatically committed to the repository when saved) because it was created
as a child of a tracked package. If we create a new folder which doesnt have a tracked
parent, we can see the visual difference in the icon used in the Project Explorer.

If you then need to make any new package a tracked package, you can do so via Team-
>Track Package. When you track a package, all content will automatically be checked out
from the server and any change to the file on the client will automatically be checked into
HANA 1.5 Partitioning (Internal)
March 2012 32
the server.

Likewise, if you wish to stop the tracking of a package, you can choose Team->Untrack
Package.
3.6 Managing a Package using REGI
The Team Provider, with its graphical integration into the SAP HANA Studio, is a relatively new tool
and may not be available in your system. Therefore there is a command line utility named REGI (for
"(Re)pository (Gi)t"), which predates the introduction of the Team Provider. In this next section of
this document, we will look at how you could perform the same operations from the previous
section using this command line utility.

3.6.1 Creating a Workspace/Project via REGI

REGI is used to load and activate Repository objects. Those objects include both DB objects (table,
sequence) and application resources (XSJS, HTML, etc.). Before we can begin utilizing REGI, we
first need to setup a workspace on our local file system. This is the same as the project workspace
which was created for us in the previous section by the Team Provider when we performed the
share project function.

Create a folder structure where your workspace will reside (i.e. C:\workspaces\HDB00)
HANA 1.5 Partitioning (Internal)
March 2012 33
Create a folder for your workspace (i.e. defaultws) , under the folder structure so it would
look like:

At the command line, from the workspace location (i.e. C:\workspaces\HDB00\defaultws>
) type:
regi create workspace --user=<DbUserName> --password=<DbPassword>
--host=<hostname>:3<sysInstanceNum>15

For example if you want to connect to a Repository running on an SAP HANA system with
Instance Number 00 on your local workstation via the user system, you would type
following:
C:\workspaces\HDB00\defaultws> regi create workspace --user=SYSTEM
--password=<DbPassword> --host=localhost:30015

A success message should appear, for example:
Created the workspace "defaultWS" in the Folder:
"C:\workspaces\HDB00\defaultWS".

At any point you can check your workspace status by:
c:> regi status --workspace=defaultWS

Alternatively, you can run the REGI status command from the workspace folder without
specifying the workspace argument:
C:\workspaces\HDB00\defaultWS> regi status

You should get an output similar to the following:

HANA 1.5 Partitioning (Internal)
March 2012 34
We now have a workspace that is identical to the managed project from the Team Provider
approach.

3.6.2 Adding Packages to the REGI Workspace
Now that we have a workspace, we need to get access to the packages which already exist in the
Repository on the SAP HANA Server. For this we will use REGI to sync these packages to the file
system workspace as folders and track them.
The command to track existing packages is as follows:
regi track <Package Name>

For example, to checkout everything within the sap.demo-main package you could issue
the following command:

You then need to issue the checkout command to sync the content from the server to the
client for all tracked packages.
regi checkout
You can see that we now have matching folders (including corresponding content) between
the server side HANA Repository and the local file system workspace:


HANA 1.5 Partitioning (Internal)
March 2012 35
3.6.3 Creating a Package via REGI
REGIs checkout functionality provides the ability to bring a copy of the current state of packages
and their corresponding content objects to your local workspace on your clients file system. From
there, you can then perform a variety of edits on this content changing, creating or even deleting
content. Once changes are completed, you then commit the content back into the repository and
activate it. We will discuss this topic further in the next section on Source Management, but for
now we can also use these techniques to create a new package from the workspace.

Similar to the previous example, when working with the Team Provider, we begin by
creating a folder to represent our package.


From the command line, you can use REGI to commit this new package back to the
Repository, for example:
C:\workspaces\HDB10\defaultWS\sap\demo-main>regi commit

HANA 1.5 Partitioning (Internal)
March 2012 36
Just like when we create the folder via Team Manager, we can immediately see the new,
corresponding package in the Repository from the SAP HANA Studio.

Next step is to edit this package from the Navigator window in order to set package-specific
properties such as the Delivery Unit and the Person Responsible.

Note that the Team Provider is fully compatible with REGI. Even though this package was
created via REGI, it still shows up in the Team Provider Project Explorer view as well (after
HANA 1.5 Partitioning (Internal)
March 2012 37
refreshing the Project Explorer via F5 or Refresh from the context menu). As long as objects
checked in from the Team Provider and REGI do not create overlapping conflicts, the two
tools can be used in combination by different individuals on the same development project.



4. Object Management
So far we have limited our scope to the higher level, grouping concepts in the Repository the
delivery unit and package. Now lets look at the tools which help to manage all the objects which
can be stored within a package.

The most basic form of object management involves the object types which can be created from
the Content view of the Navigator within the SAP HANA Studio. Attribute views, analytic views,
calculation views, analytic privileges, and procedures are all created as children within a package
and then immediately managed as objects belonging to that package.

HANA 1.5 Partitioning (Internal)
March 2012 38

For example, if we create a new attribute view the object management is directly integrated into the
SAP HANA Studio tools. The new view appears nested within the package of the Repository as
shown in the Navigator window. It automatically becomes part of the delivery unit to which this
package is assigned. Likewise activation within the modeler causes the repository to automatically
store a new version of this object. Also the version history can be displayed within this tooling.
These same capabilities are available for all the object types which are directly supported by the
SAP HANA Studio attribute views, analytic views, calculation views, analytic privileges, and
procedures.


4.1 Object Management in Team Provider
Although the Navigator view of the SAP HANA studio supports full editing of a limited number of
object types; the Repository itself can store and manage a much larger number of objects types.
For example, our demo project also contains some scripts for schema and table creation as well as
HANA 1.5 Partitioning (Internal)
March 2012 39
some HTML files for a user interface. These files do show up in the Navigator view of the Repository
but open in display-only mode or with a very limited editor when selected in detail.


However, with the SAP HANA Developer Workbench add-on for the SAP HANA Studio, all additional
Repository objects do show up in the Project Explorer window of the Team Provider tool. These
files can then be edited with any local editor on the client machine or any of the editing tools which
are part of your Eclipse installation. For example, our UI file opens in an Eclipse HTML editor when
accessed via the Project Explorer view of the Team Provider.


HANA 1.5 Partitioning (Internal)
March 2012 40
4.1.1 Object Creation Using Team Provider
In addition to viewing these objects within their respective packages, the Team Viewer add-on also
allows us to perform object management. We already have our project connection to the
Repository and our tracked packages from the previous sections of this document; now lets
explore the steps required for individual object management.

First we need to create a new object. This can be done from the team provider via the New -
> File context menu.


HANA 1.5 Partitioning (Internal)
March 2012 41
This process will merely create a file in the local file system of your project workspace.

Notice the icon has changed to indicate that this file is different on the client than it is on the
server. This file can be edited with any tool on the developer workstation including
additional Eclipse based tools which might be installed into the SAP HANA Studio.


As soon as you save the changes within an Eclipse-based tool the object is sent to the
server and stored with an inactive state in the Repository. There is also the option to trigger
HANA 1.5 Partitioning (Internal)
March 2012 42
the commit manually from the Team Provider of the SAP HANA Workbench plug-in (Team-
>Commit from the package). This option is really the exception, however, and is only
necessary when there is a problem marker (generally caused by a save when in offline
mode).

When logged on as user, SYSTEM, you can see the content of inactive objects within the
schema _SYS_REPO, table INACTIVE_OBJECT.


HANA 1.5 Partitioning (Internal)
March 2012 43
4.1.2 Object Activation Using Team Provider
Inactive objects cant be utilized (but they can be further developed). They must be
activated and therefore pass several activation checks before they are available for use.
This allows you to have a stable active version of an object while you develop a new inactive
version. To activate any object within the Team Provider, use the Team->Activate menu
option.

When activating a package, all objects contained therein (including the objects in sub-
packages) will be activated. Currently, there is no separate option in UI for individual object
activation. Activation is only done at the package level when you select the "Activate"
option from the context menu. Also it is important to note that at the time of creation of
this document no dialog to display activation errors within the Team Provider. Detail errors
during activation can only be seen from the Navigator activation or via the REGI command
line tool.

4.1.3 Checkout Using Team Provider
The process we have used so far has been the simplest approach, where one developer
creates, edits and then commits a single object. A more realistic scenario is that multiple
developers are working on the same objects within one project. To support multiple
HANA 1.5 Partitioning (Internal)
March 2012 44
developers working in teams, we have the ability to checkout objects from the content
repository. This is accomplished by simply refreshing the package via content menu or F5.
The refresh will trigger a checkout of the current state.

Similarly to the commit action, there is a menu option to force the checkout via Team-
>Checkout from the context menu. This option can be used in exceptional cases when
there were issues with the refresh activity.

Likewise, every time your eclipse workspace is refreshed, the Team Provider automatically
populates it with the latest changes from the repository on the SAP HANA server. You do
not need to manually load the remote changes into your workspace.

The file system of the developer who performed the checkout now has the latest versions of
the objects copied down from the SAP HANA server.

4.1.4 Conflict Resolution in Team Provider
Inevitably, objects in a distributed development approach can become out of sync between
the developers local file system and the Repository. There are several tools in the Team
Provider which can help to resolve these differences. For version management, there is
HANA 1.5 Partitioning (Internal)
March 2012 45
local history which can be accessed from the context menu:Team->Show Local History.

This local history can be used to show the full state of an object at different points of time
relative to its life span on the developers local machine.

HANA 1.5 Partitioning (Internal)
March 2012 46
You can also choose to restore an object from a version in history via the context menu:
Replace With -> Local History

HANA 1.5 Partitioning (Internal)
March 2012 47
Comparison between versions is available via: Compare With -> Local History


If someone else modified a file and activated the change while you also had a version of the
file checked out, it might produce a conflict with your local work. When you refresh your
workspace or save a file, you will be notified of such conflicts. There is no locking on objects
while editing. Tow version of an object can be edited simultaneously and whichever one is
activated first prevails. For the second one, a merge with the active version would be
required.
Steps for solving merge conflicts:
o Open the merge tool: Right-click the file with conflicts -> Team -> Merge Tool
o A side by side comparison will be shown. Merge your changes with the conflicting
changes: this requires making a manual adjustment to your version.
o Save the resolved file. The tool will then ask you if the file should be marked as
resolved.
HANA 1.5 Partitioning (Internal)
March 2012 48


As described in the previous sections, many actions are performed automatically in the
background as you work in the Team Provider. In case such an action does not succeed,
e.g. a change could not be committed to the repository or a package could not be checked
out, problem indicators will be added to the package in question. This will not be
uncommon if you are working offline. Simply retrying once the connection to the HANA
database is restored will solve the issue. This action can either be triggered via the context
menu on the respective packages, or via the quick fix context menu entry in the problems
view.
In the version of the tools at the time of publication it is possible to delete directories, but
the corresponding packages in the repository are not automatically deleted.
Adding a package that contains an empty file causes an error that the package could not be
added; however it actually is added and the file can be used as expected.
4.2 Object Management using REGI
Although the Navigator view of the SAP HANA studio supports full editing of a limited number of
object types; the Repository itself can store and manage a much larger number of objects types.
For example, our demo project also contains some scripts for schema and table creation as well as
some HTML files for a user interface. These files do show up in the Navigator view of the Repository
but open in display-only mode or with a very limited editor when selected in detail.


Although Team Provider provides Eclipse integration for managing repository objects, there is also
a command line tool called REGI (for "REpository GIt") which can be used along with Team
Provider, or in cases where you dont have access to the Team Provider tool, or it for cases where
its current capabilities do not address your specific scenario.
In Section 3.6, we have already covered how REGI can be used to connect to the Repository and
perform high level operations like the creation of a package. Remember in this earlier section,
REGI effectively made a local copy of the Repository package structure as folders in the developers
HANA 1.5 Partitioning (Internal)
March 2012 49
local file computer. The illustration below displays an example of files created locally by REGI. Next
we will see how you can use REGI to work with individual objects from the Repository.



4.2.1 Command Reference for REGI
Before we begin discussing specific operations in REGI, here is a brief description and
documentation of the main activities which can be triggered via REGI. They can all be used from the
command line in the form:
regi <action> <what> <workspace> <package> [options]
You can also get help on specific commands with:
Regi help <action>
4.2.1.1 regi_root
The command regi_root sets an environment variable which designates a particular local client
computer directory folder as the parent folder for the REGI workspace. This folder is the root of all
the workspace folders that the user creates. If you do not bind REGI_ROOT to a value, then REGI will
transverse the directory hierarchy upwards, starting from the current working directory, until it
finds a REGI workspace. (a directory which contains a ._SYS_REGISettings folder). This folders
name is then assumed to be the workspace name. If REGI does not find such a folder, it reports an
error.
REGI regi_root C:\workspaces\HDB10\defaultWS
4.2.1.2 workspace
REGI workspaces can be created and deleted using the workspace command. The workspace has a
name and an owner. By default the owner is the OS user. When the workspace is created a certain
subfolder structure beneath $REGI_ROOT is created. If $REGI_ROOT evaluates to the empty string,
then the current work directory is used as the workspace folder. REGI will create its metadata folder
named ._SYS_REGI_settings here.
regi create workspace --user=<DbUserName> --password=<DbPassword> --
owner=<DbOwnerName> --host=<hostname>:3<sysInstanceNum>15

HANA 1.5 Partitioning (Internal)
March 2012 50

4.2.1.3 checkout
Using the checkout command, copies of Repository objects and packages are sent to the local
client computer and then represented by files and folders. The dot in the package names specifies
the hierarchy delimiter. For example the package sap.com.tms is represented as the folder:
<$REGI_ROOT>\<workSpace>\src\sap\com\tms.
Objects in the package which are checked out are represented by files in that folder. During
checkout a workspace specific project file is maintained. This project file keeps the file name of
each object and its SHA1 Hash value. This project file has the name <workspaceName>.hrw and is
located in the folder <$REGI_ROOT>\ <workSpace>\settings. Repository specific meta data of
each object is maintained in the subfolder <$REGI_ROOT>\<workSpace>\settings\SYS. For
example content with the following name:
<$REGI_ROOT>\<workSpace>\src(\[<packageName])+\<objName>.<typeExtension> has
a corresponding meta data file:
<$REGI_ROOT>\<workSpace>\._SYS_REGI_settings\SYS\(\[<packageName])+\<objNam
e>.<typeExtension>.rgmf . This file contains the version and the version_id of the Repository
object.
Whenever a package or an object of a package is checked out, this package becomes one of the
tracked packages of the workspace. If REGI commit is called, then all tracked packages are also
checked out.

4.2.1.4 status
Using the REGI command status, you can view a list of those files you created, changed and
deleted. In other words you can see all the "uncommitted changes". If you perform a checkout
again, uncommitted changes are not overwritten but the repository version of the object is then
written to the folder
<$REGI_ROOT>\<workSpace>\src(\[<packageName])+\<objName>.<typeExtension>.
However with optional parameter force of the checkout command, the uncommitted changes are
overwritten.

4.2.1.5 commit
You can commit the uncommitted changes of a workspace via the REGI action commit. Local files
are written as inactive to the content repository and the workspace file is updated with the new
information (hashes, deletions and creations). REGI commit effects all tracked packages.

4.2.1.6 activate
With the activate command, you can activate the inactive objects: REGI activate
inactiveObjects.
4.2.1.7 revert
With the revert command, you can discard your changes and go back to the active state of the
objects, using: REGI revert inactiveObjects.

HANA 1.5 Partitioning (Internal)
March 2012 51
4.2.1.8 rebase
Activation could fail due to conflicts between local copies of objects and the server copies. This
happens when an object with a newer version id than the one the user checked out has already
been activated on the server. This situation generally occurs when you have multiple developers
editing and activating the same repository object in overlapping time intervals.
In this case, you have two options. You can revert inactive objects, which means to discard your
work, or you can rebase your inactive objects. Rebase allows you to manually merge conflicting
objects. To rebase, you first must ensure that there are no uncommitted changes. Rebase will copy
all local changes to the corresponding diff folder, revert the inactive objects and check them out.
This operation can be performed using REGI rebase package. The next step is to utilize your
favorite diff tool to merge the diff version with the src version on the local file system (an example of
this merge operation is shown later in section 4.2.5 Conflict Resolution Using REGI).

4.2.2 Object Creation Using REGI
We already have our project connection to the Repository and our tracked packages from the
previous sections of this document; now lets explore the steps required for individual object
management.

First we need to create a new object. Because this is only a simple file on the front-end
client computer, it doesnt yet have any connection to the Repository. You can create a file
from the file system or use any 3
rd
party tool you wish to create and then edit the file.


This file can be edited by any tools on the developer workstation including additional Eclipse
based tools which might be installed into the SAP HANA Studio. However unlike with the
Team Provider, when you save the changes within an Eclipse based tool no automatic
commit is sent to the server.
In order to trigger the commit manually from REGI use:
REGI commit
The object is then sent to the server and stored within the inactive state in the Repository.
HANA 1.5 Partitioning (Internal)
March 2012 52


As user SYSTEM, you can see the content of inactive objects within the schema
_SYS_REPO table INACTIVE_OBJECT.


4.2.3 Object Activation Using REGI
Inactive objects cant be utilized in an application. They must be activated and therefore
pass several activation checks before they are available for use. This allows you to have a
stable active, executable version of an object while you develop a new inactive version. To
HANA 1.5 Partitioning (Internal)
March 2012 53
activate all object with REGI use the command:
REGI activate


4.2.4 Checkout Using REGI
The process we have used so far reflects the most straight forward example, where one
developer creates, edits and then commits a single object. A more realistic scenario is that
multiple developers work on the same objects within one project. To support multiple
developers working in teams, we have the ability to checkout objects from the repository,
so that individual developers can work independently on objects. To accomplish this, utilize
the command:
REGI checkout


HANA 1.5 Partitioning (Internal)
March 2012 54
Notice that in this example the new file, New_Other_Devs_Stuff.txt, has been copied
from the Repository to the local computers directory. We now have an accurate
representation of the content as it exists on the SAP HANA server at this point in time.
Likewise, you can choose to refresh an entire workspace with the command:
REGI checkout workspace
This would be a common operation at the beginning of new version of a project.


4.2.5 Conflict Resolution Using REGI
When you have a distributed development approach, objects can become out of sync between the
copies on the developers local computer and the Repository. In this case, you have two options.
You can revert inactive objects or you can rebase the inactive objects. To rebase, first you must
ensure that there are no uncommitted changes. Then rebase will copy all local changes to the
corresponding diff folder, revert the inactive objects and check them out. You can perform a rebase
with the command:
REGI rebase


There are two ways to resolve a conflict:
1. Using a mergetool
2. Selecting the versions

4.2.5.1 Using a mergetool

The default way is to call a mergetool. The mergetool to be used must be configured through the
environment variable REGI_MERGETOOL3. After the environment variable has been set, calling:
regi mergetool

HANA 1.5 Partitioning (Internal)
March 2012 55

This will call the configured mergetool for all conflicts to be resolved in your tracked
packages, and after the mergetool has been closed (and the file has been changed), regi will
ask the developer interactively whether the merge has been successful:
The file has been updated. Resolve the file? (Y/n)

Pressing "y" or "Y" or RETURN will resolve the file as follows (press CTRL-C to stop the
resolve process):
o Unmark the file as conflicted in the workspace file.
o Remove the current active version of the object from the "diff" directory.
o Remove the current base version of the object from the "base" directory.

If the file has not been changed by the mergetool, regi will ask:
The file has not been updated. Resolve the file anyway? (y/N)

Pressing "y" or "Y" will resolve the file, pressing RETURN or anything else will not resolve
the file.

4.2.5.2 Selecting the versions

Calling:
regi resolve --with=local
This will resolve all the conflicts and simply delete the current active version from the "diff"
directory and the base version from the "base" directory. The "winners" will be the local workspace
versions of the objects. You can use "--with=remote" to let the remote version "win", and "--
with=base" for the base version.

5. Export / Import
Export and import are critical concepts for software lifecycle management. They provide the core
functionality for the concept of transport the technique utilized to promote objects from
development environments to test and production systems (or final assembly systems before
shipping to customers). Now that we have covered the basics of content organization and change
recording, we can discuss the mechanics of export and import.
HANA 1.5 Partitioning (Internal)
March 2012 56
5.1 Change Tracking and Patching
5.1.1 Export

To begin an export, use the Quick Launch tool within the SAP HANA Studio. Choose
Export... from the Content section of the Quick Launch.

For most use cases, you should export the delivery unit. If a project is structured correctly
with all necessary packages assigned to the delivery unit, exporting the delivery unit will
HANA 1.5 Partitioning (Internal)
March 2012 57
help to ensure a consistent export with all dependent objects.

In the next dialog, you can begin by choosing the delivery unit you wish to export. All
packages assigned to this delivery unit will be displayed below the delivery unit selection.

HANA 1.5 Partitioning (Internal)
March 2012 58
In the middle of the dialog, there is the option to Filter By Time. If you do not choose to use
this filter option, then a complete export of the current active version of all objects within
the selected delivery unit will result. This action would correspond to a major release or a
project milestone.
However, by choosing to utilize the Filter By Time option, you can create an export which
only contains the objects which have been change within a current time frame. Using this
option will allow you to create patches which include the active versions of only the object
changes, additions, or deletions within the specified timeframe. This would normally be a
much smaller set of objects than a full export of the entire delivery unit.

A careful approach is needed with the Filter By Time option to avoid serious object
consistency problems! A general best practice recommendation is to periodically schedule full
exports, and have a few exports using Filter By Time in between. When using Filter By Time, it is
recommended to use a From date that corresponds to the date of the last Full export. Actually,
its best to use a date and time that is slightly before the date and time of the last Full export; this
will ensure that no object changes are missed, and therefore a consistent export will be performed.

Additionally, if you choose a date that corresponds to the last Full export (or slightly before, as
recommended) each patch export will be prepared in a manner where any patch can be applied
without first applying every predecessor patch sequentially first. In other words each patch would
be a cumulative one, encompassing all necessary changes included in the previous patches. Please
note that the current version of the tools do not provide support for automatically tracking date and
time of the last full export! Therefore, some external tool (which could even be as simple as a
spreadsheet) should be used to track the dates and times of the full and Filter By Time exports.

The final option in the export dialog is to choose the download location of the export
operation. You can choose to download the file to the SAP HANA Server or to your client
HANA 1.5 Partitioning (Internal)
March 2012 59
machine.

5.1.1.1 Server Side Export
If you encounter any problems with the Export functionality via the SAP HANA Studio, there is an
alternative to perform the import on the server side via a Python script.
Next, you will utilize one of several python scripts located in the directory:
/usr/sap/<SID>/HDB<sysnum>/exe/python_support
Script repo_exportDeliveryUnit.py will create a full export while
repo_exportDeliveryUnitPatch will allow a Filter by Time type export.
You can check the options using the syntax:
/usr/sap/<SID>/HDB<sysnum>/exe/python_support/repo_exportDeliveryUnit
.py --help
Perform the export of the delivery unit. In our example, the command was as follows
(provide password for user SYSTEM):
/usr/sap/<SID>/HDB<sysnum>/exe/python_support/repo_exportDeliveryUnit
.py --connUser=SYSTEM --connPW=<password>
/usr/sap/<SID>/HDB<sysnum>/backup/
You should see a resulting message like ======> export was successful

5.1.1.2 File format for transports of delivery units
The archive format is a zipped hierarchical archive containing:
HANA 1.5 Partitioning (Internal)
March 2012 60
An archive-header
Lists of selected packages and objects
The transportable information per transported package and object.

For instance, if we were to look at the content of an uncompressed archive for our sample
SAPDEMO1 delivery unit, it would look like this:

The naming scheme for the archive files is as follows:
REPO_<Date as YYYYMMDD-hhmmssmmm>-<SID>-<tenant>-<delivery_unit>.tgz
For example:
HANA 1.5 Partitioning (Internal)
March 2012 61
REPO_20110120-132158432-AK7--MY_DELIVERYUNIT_01.tgz

5.1.2 Import

To begin an import, use the Quick Launch tool within the SAP HANA Studio. Choose
Import... from the Content section of the Quick Launch.

HANA 1.5 Partitioning (Internal)
March 2012 62
From the first screen of the Import dialog, choose Delivery Unit from within the HANA
content folder.

In the second screen of the Import dialog, begin by selecting the file location either from
your client machine or from a directory on the SAP HANA server. The file will be read
immediately and an object import simulation for all items in the import archive will be
HANA 1.5 Partitioning (Internal)
March 2012 63
displayed.


5.1.2.1 Limitations
Currently (as of SP3), the activation must not be performed implicitly by the import, because some
necessary logic is implemented in the client layer. Therefore, a manual activation via the SAP HANA
Studio of new content after import is necessary.
Packages that were removed from a delivery unit after having been transported already are not
deleted in target systems. The import deletes all objects in these packages in the target system, but
leaves the packages themselves unchanged.
HANA 1.5 Partitioning (Internal)
March 2012 64
5.1.2.2 Server Side Import
If you encounter any problems with the Import functionality via the SAP HANA Studio, there is an
alternative to perform the import on the server side via a Python script.
Copy the Delivery Unit archive to directory /usr/sap/<sid>/HDB<inst#>/backup/ For
example:

Next, you will utilize the python script repo_importFile.py located in the directory
/usr/sap/<SID>/HDB<sysnum>/exe/python_support
You can check the options using the syntax:
/usr/sap/<SID>/HDB<sysnum>/exe/python_support/repo_importFile.py --
help

Perform the import of the delivery unit. In our example, the command was as follows
(provide password for user SYSTEM):
/usr/sap/<SID>/HDB<sysnum>/exe/python_support/repo_importFile.py --
autoActivate=1 --activationMode=2 --connUser=SYSTEM --
connPW=<password> /usr/sap/<SID>/HDB<sysnum>/backup/REPO_20120105-
170711046-REV23--HANA_DXC.tgz
HANA 1.5 Partitioning (Internal)
March 2012 65
You should see a resulting message like ======> import was successful, for
example:

5.2 Troubleshooting Export/Import

If issues occur while importing or exporting delivery units, tracing features exist to aid in the
troubleshooting process. Simply turn on a trace, retry your import or export, then turn off the
trace, and inspect the resulting trace file. If you report the issue, you will likely be asked to send a
trace file, so you can save time by providing it when you report the issue.
5.2.1 Traces
Trace components
REPO_REST: set the trace level to INFO for tracing REST requests and responses
REPOSITORY: set the trace level to INFO or DEBUG for tracing the repository core component
How to change the Repository Trace Levels
In the Navigator of HANA Studio's Administration Perspective, right-click on the system
node, choose Administration and select the tab Diagnosis Files. Then click the Trace
HANA 1.5 Partitioning (Internal)
March 2012 66
Configuration tab (at the very right), for example:

Choose the End-To-End Traces:

HANA 1.5 Partitioning (Internal)
March 2012 67
Select Show All Components in the Configure Trace dialog

HANA 1.5 Partitioning (Internal)
March 2012 68
Now, type "repo" into the filter text field, for example:

Click into the column Trace Level in the line of the component "REPOSITORY" (or
"REPO_REST") in the section of the relevant process (typically the INDEXSERVER section)
HANA 1.5 Partitioning (Internal)
March 2012 69
choose "info" or "debug", for example:

With the trace enabled, debug information will be written to the respective trace file, which
is typically located at /usr/sap/$SID/HDB$INSTANCENO/$HOSTNAME/trace, for
example e.g.
/usr/sap/OPT/HDB01/lu123456/trace/indexserver_lu123456.30103.000.trc.

6. Translation
The Repository includes features for translating metadata texts. In order to prepare for translation,
some meta-data which will be used by the translation system must first be maintained in the
package. This meta-data maintenance is available from the Edit Package Details dialog.
HANA 1.5 Partitioning (Internal)
March 2012 70

The Terminology Domain and Text Collection are required fields, but are only utilized by SAP
internal translation systems. Customers and partners can also maintain option Hints and Text
Status values for the package, which are essentially notes for use by someone later performing the
actual language translation.
The ability to maintain these additional translation fields within the package dialog is a very recent
addition to the SAP HANA Studio. For older release levels of the SAP HANA Studio, these entries
can be made directly into that database in schema _SYS_REPO table PACKAGE_CATALOG.

6.1 Repository Translation Tool (RTT)
The Repository Translation Tool (RTT) is a Java-based command line tool which connects SAP
HANA with the SAP translation system for SAP internal usage, or exports language files in a
standard format for customer or partner usage. RTT implements this process in four steps:

Export: Exports the texts in the original language (written by the developer) from the SAP
HANA Repository text tables to the file system.
Upload (SAP Internal Only): Uploads the texts from the file system to the SAP translation
system. After this step, the translators can translate the texts from the original language
into the required target languages.
Download (SAP Internal Only): Downloads the translated texts from the SAPtranslation to
the file system.
Import: Imports the translated texts from the file system to the SAP HANA Repository text
tables.
The RTT tool also contains special commands which allow you to collapse multiple operation steps
together into one:
Export+Upload (SAP Internal Only): Exports the texts in the original language (written by
the developer) from the SAP HANA repository text tables and uploads them to the SAP
HANA 1.5 Partitioning (Internal)
March 2012 71
translation system. After this step, the translators can translate the texts from the original
language into the required target languages.
Download+Import (SAP Internal Only): Downloads the translated texts from the SAP R/3
translation system and imports them to the SAP HANA Repository text tables.

Here are some example usages of RTT:

Export the texts from those packages matching "pack*" from the database and upload the
texts into the translation system, using the default configuration file ("rtt.properties"):
rtt -e -p pack*

Download the translated texts from those packages matching "pack*" from the translation
system and import the texts into the database, using the default configuration file
("rtt.properties"):
rtt -i -p pack*

Export the texts from the database into the directory "exports":
rtt --export -p pack* -x exports

Upload the texts in the directory "exports" to the translation system:
rtt --upload -p pack* -x exports


Download the translated texts into the directory "imports":
rtt --download -p pack* -x imports

Import the translated texts from the directory "imports":
rtt --import -p pack* -x imports

Export and upload the texts from those packages contained in delivery unit "vendor1.du1":
rtt -e -du vendor1.du1

Export and upload the texts from those packages matching "pack*" or contained in delivery
unit "vendor1.du1":
rtt -e -p pack* -du vendor1.du1

Download and import the texts translated into locales "de_DE" or "fr_FR":
rtt -i -p pack* -l de_DE -l fr_FR


www.sap.com/contactsap