0701 - Administration - Software Lifecycle Management Overview.pdf

8/11/2019 0701 - Administration - Software Lifecycle Management Overview.pdf

1/78

SAPDocumentation

SAP HANA Appliance Software

Applicable Releases:

SAP HANA Appliance Software SPS 03/04

Version 1.1

March 2012

SAP HANA Content/Software Lifecycle Management


2/78

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 andInformix 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 forany 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. Thisdocument 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 i s only to be used by

SAPs Support Services and may not be modified or altered in any way.


3/78

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


4/78

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. Theseinclude 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 andtheir 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.

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, F2or ENTER.

Icons

Icon Description

Caution

Note or Important

Example

Recommendation or Tip


5/78

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


6/78

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


7/78

HANA 1.5 Partitioning (Internal)

March 2012 1

1. Introduction

The SAP HANA repository provides features for management of various kinds of SAP HANAobjects, 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 adelivery 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.


8/78


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 MaintenanceDelivery 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.inifile, 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 SAPHANA Studio.

From the Configuration tab, you can choose the configuration file you wish to edit. In orderto configure the Vendor, you should edit the indexserver.ini file.


9/78


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 owndomain name here, e.g. smithwidgets.com.For internal development teams at SAP, usesap.com.


10/78


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.


11/78


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 andis named DELIVERY_UNITS.

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

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


12/78


March 2012 6

You can check the current list of delivery units, which should include your newly createddelivery unit, by using the Open Data Preview option on the table.


13/78


March 2012 7

If you were to accidentally create a delivery unit which already exists in your system, youwill receive a validation error:

However, be aware that a validation for valid vendor does not exist; making it possible, forexample, 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 SupportIf you are on a newer version of SAP HANA, you can instead accomplish this same task of creatingdelivery unit from the Quick Launch tool of the Modeler Perspective.


14/78


March 2012 8

Choose Delivery Unitsfrom within the Setupgroup of the Quick Launch menu.

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


15/78


March 2012 9

When creating a delivery unit via this tool, the vendor is automatically set from theconfigured entry from the indexserver.ini file and cannot be overridden.

2.4 Creating a Delivery Unit DependencySAP HANA also supports the maintenance of dependencies between delivery units. A transport of adelivery unit will also transport the definition of these dependencies.


16/78


March 2012 10

There is no specialized tool to create or maintain Delivery Unit dependencies. Therefore wewill directly create entries in the underlying database table which holds all Delivery Unitdependencies. The table can be found in _SYS_REPO and is namedLEGAL_DEL_UNIT_DEPENDENCIES.

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

INSERTINTO _SYS_REPO.LEGAL_DEL_UNIT_DEPENDENCIESVALUES('SAPDEMO1', 'SAPDEMO2', 'sap.com', 'sap.com');


17/78


March 2012 11

You can check the current list of Delivery Unit dependencies, which should include yournewly 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


18/78


March 2012 12

a delivery unit which doesnt even exist. Make sure you are assigning to a valid vendor.

3. PackagesPackage is a key concept for SAP HANA lifecycle management in working with the repository. Everyrepository object is assigned to a package. The main purpose of the package is to establish anamespace. In the repository an object is uniquely identified by the combination of its packagename, object name and object type. That means that multiple objects of the same type may havethe same object name if they belong to different packages. A package typically consists ofnumerous repository objects. A package hierarchy can be created, establishing parent-child typerelationships between packages. Packages are assigned to delivery units. Note that the assignmentof packages to delivery units is independent of the package hierarchy. Each and every packagemust 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 followingway:

"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, ormore if additional permissions are granted there directly


19/78


March 2012 13

3.2 Types of PackagesThere 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=) system-local.generated (structural=true, src-system=) system-local.private (structural=true, src-system=)

3.2.3 Package Transportability

The package system-localand all of its sub-packages are considered non-transportable, all other

packages are transportable. This is similar to the concept of the $tmpdevelopment class in SAP

NetWeaver ABAP.


20/78


March 2012 14

3.2.4 Packages for Generated Content

All sub-packages of the delivered package system-local.generatedshould 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.privatecan 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.Fritzlebelongs to user Fritzleand 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 PackageFrom 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.

.


21/78


March 2012 15

Begin by right mouse clicking on the Content folder of your HANA System in the Navigatorwindow of the Modeler Perspective. Then choose New -> Package

The Delivery Unitfield will offer the possible options which we created in the previoussection of this document. The Original Languagesetting will be important later if you intendto perform language translation.


22/78


March 2012 16

You can create sub-packages by repeating the above process, but starting from the parentpackage.

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


23/78


March 2012 17

3.3.1 Package Hierarchy and Structure PackagesThe 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 theexample, 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-mainis 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 containobjects, but rather sub-packages only.


24/78


March 2012 18

You can choose to Edit the demo-main package from the Navigator of the Modelerperspective.

From the Edit Package Detailsdialog, there is the additional option to set this package to bestructural.


25/78


March 2012 19

Notice that the icon for the demo-main package in the navigator window has changed tosignify that it is now a structural package.

3.4Repository AuthorizationsAuthorizations 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-> Rolesor Users, and make a selection.

Next, choose the Package Privilegestab. For example:


26/78


March 2012 20

Here you can select the appropriate privileges for packages, which will apply to all objects withinthat 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


27/78


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-> Rolesor Users, and make a

selection. Next, choose the System Privilegetab. 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];


28/78


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


GRANT REPO.MAINTAIN_NATIVE_PACKAGES on ".REPO_PACKAGE_ROOT" to KENT


GRANT REPO.EDIT_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT


GRANT REPO.ACTIVATE_IMPORTED_OBJECTS on ".REPO_PACKAGE_ROOT" to KENT


GRANT REPO.MAINTAIN_IMPORTED_PACKAGES on ".REPO_PACKAGE_ROOT" to KENT


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 inthe 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 Providerwhich 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


29/78


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 ProjectBefore 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.


30/78


March 2012 24

Create a General Project:


31/78


March 2012 25

Name your project. Note: this is also creating a workspace folder structure on your clientmachine 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 itsRepository.

3.5.2 Sharing the ProjectNext we will connect this project to our SAP HANA System and its Repository. We perform this task

by sharing the project.


32/78


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 SAPHANA Studio has a standard plug-in called SAP HANA Repository.


33/78


March 2012 27

Choose the appropriate SAP HANA System/User from the next dialog and then press theFinishbutton:

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


34/78


March 2012 28

3.5.3 Adding Packages to the Project ExplorerFrom 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.demorelated packages and add them together:


35/78


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 ProviderSo 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.


36/78


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.


37/78


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


38/78


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 REGIThe 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.1Creating 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)


39/78


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= --password=

--host=:315

For example if you want to connect to a Repository running on an SAP HANA system withInstance Number 00 on your local workstation via the user system, you would type

following:C:\workspaces\HDB00\defaultws> regi create workspace --user=SYSTEM

--password= --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:
http://trexweb.wdf.sap.corp:1080/wiki/images/2/2d/Workspaces.pnghttp://trexweb.wdf.sap.corp:1080/wiki/images/2/2d/Workspaces.pnghttp://trexweb.wdf.sap.corp:1080/wiki/images/2/2d/Workspaces.pnghttp://trexweb.wdf.sap.corp:1080/wiki/images/2/2d/Workspaces.png


40/78


March 2012 34

We now have a workspace that is identical to the managed project from the Team Provider

approach.

3.6.2Adding Packages to the REGI WorkspaceNow 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

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:


41/78


March 2012 35

3.6.3Creating a Package via REGIREGIs 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 deletingcontent. 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


42/78


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


43/78


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 ManagementSo 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.


44/78


45/78


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 whichare 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.


46/78


March 2012 40

4.1.1Object Creation Using Team ProviderIn 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 letsexplore 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 -

> Filecontext menu.


47/78


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 theserver and stored with an inactive state in the Repository. There is also the option to trigger


48/78


March 2012 42

the commit manually from the Team Provider of the SAP HANA Workbench plug-in (Team-

>Commitfrom 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.


49/78


March 2012 43

4.1.2Object 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 inactiveversion. To activate any object within the Team Provider, use the Team->Activatemenu

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.3Checkout 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 multipledevelopers are working on the same objects within one project. To support multiple


50/78


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-

>Checkoutfrom 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.4Conflict Resolution in Team Provider

Inevitably, objects in a distributed development approach can become out of sync betweenthe 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


51/78


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.


52/78


March 2012 46

You can also choose to restore an object from a version in history via the context menu:

Replace With -> Local History


53/78


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.


54/78


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.2Object Management using REGIAlthough 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 Section3.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


55/78


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.1Command Reference for REGIBefore 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 [options]

You can also get help on specific commands with:

Regi help

4.2.1.1 regi_root

The command regi_rootsets 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 anerror.

REGI regi_root C:\workspaces\HDB10\defaultWS

4.2.1.2 workspace

REGI workspaces can be created and deleted using the workspacecommand. 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= --password= --

owner= --host=:315


56/78


March 2012 50

4.2.1.3 checkout

Using the checkoutcommand, copies of Repository objects and packages are sent to the localclient computer and then represented by files and folders. The dot in the package names specifies

the hierarchy delimiter. For example the package sap.com.tmsis represented as the folder:

\\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 .hrwand is

located in the folder \ \settings. Repository specific meta data of

each object is maintained in the subfolder \\settings\SYS . For

example content with the following name:\\src(\[


57/78


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 developersediting 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 section4.2.5 Conflict Resolution Using REGI).

4.2.2Object Creation Using REGIWe 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 3rdparty 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.


58/78


March 2012 52

As user SYSTEM, you can see the content of inactive objects within the schema

_SYS_REPO table INACTIVE_OBJECT.

4.2.3Object Activation Using REGI Inactive objects cant beutilized in an application. They must be activated and therefore

pass several activation checks before they are available for use. This allows you to have astable active, executable version of an object while you develop a new inactive version. To


59/78


March 2012 53

activate all object with REGI use the command:REGI activate

4.2.4Checkout 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


60/78


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.5Conflict Resolution Using REGIWhen 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 rebasewith 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


61/78


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 / ImportExport 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.


62/78


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


63/78


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.


64/78


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 releaseor a

project milestone. However, by choosing to utilize the Filter By Timeoption, 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 Timein 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; thiswill 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 Timeexports.

The final option in the export dialog is to choose the download location of the exportoperation. You can choose to download the file to the SAP HANA Server or to your client


65/78


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//HDB/exe/python_support

Script repo_exportDeliveryUnit.py will create a full export while

repo_exportDeliveryUnitPatch will allow a Filter by Timetype export.

You can check the options using the syntax:/usr/sap//HDB/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//HDB/exe/python_support/repo_exportDeliveryUnit

.py --connUser=SYSTEM --connPW=

/usr/sap//HDB/backup/

You should see a resulting message like ======> export was successful

5.1.1.2 File format for transports of delivery unitsThe archive format is a zipped hierarchical archive containing:


66/78


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_---.tgzFor example:
http://trexweb.wdf.sap.corp:1080/wiki/images/1/11/RepoArchiveFormat.PNGhttp://trexweb.wdf.sap.corp:1080/wiki/images/1/11/RepoArchiveFormat.PNGhttp://trexweb.wdf.sap.corp:1080/wiki/images/1/11/RepoArchiveFormat.PNGhttp://trexweb.wdf.sap.corp:1080/wiki/images/1/11/RepoArchiveFormat.PNG


67/78


March 2012 61

REPO_20110120-132158432-AK7--MY_DELIVERYUNIT_01.tgz

5.1.2Import

To begin an import, use the Quick Launch tool within the SAP HANA Studio. Choose

Import...from the Content section of the Quick Launch.


68/78


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 fromyour 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


69/78


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.


70/78


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//HDB/backup/ Forexample:

Next, you will utilize the python script repo_importFile.py located in the directory

/usr/sap//HDB/exe/python_support

You can check the options using the syntax:

/usr/sap//HDB/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//HDB/exe/python_support/repo_importFile.py --

autoActivate=1 --activationMode=2 --connUser=SYSTEM --

connPW= /usr/sap//HDB/backup/REPO_20120105-

170711046-REV23--HANA_DXC.tgz


71/78


March 2012 65

You should see a resulting message like ======> import was successful, for

example:

5.2Troubleshooting 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.1Traces

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 Administrationand select the tab Diagnosis Files. Then click the Trace


72/78


March 2012 66

Configuration tab (at the very right), for example:

Choose the End-To-End Traces:


73/78


March 2012 67

Select Show All Componentsin the Configure Trace dialog


74/78


75/78


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. TranslationThe 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.


76/78


March 2012 70

The Terminology Domainand Text Collectionare 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 recentaddition 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.1Repository 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 SAPHANA 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 bythe developer) from the SAP HANA repository text tables and uploads them to the SAP


77/78


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


78/78

www.sap.com/contactsap
http://www.sap.com/contactsaphttp://www.sap.com/contactsap

0701 - Administration - Software Lifecycle Management Overview.pdf

Documents

Transcript of 0701 - Administration - Software Lifecycle Management Overview.pdf