Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP HANA is a registered trademark of Oracle Corporation. UNIX, x / Open, OSF / 1, and Motif are trademarks or registered trademarks of the Open Group.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP HANA is a registered trademark of Oracle Corporation. UNIX, x / Open, OSF / 1, and Motif are trademarks or registered trademarks of the Open Group.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP HANA is a registered trademark of Oracle Corporation. UNIX, x / Open, OSF / 1, and Motif are trademarks or registered trademarks of the Open Group.
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.
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