SAP HANA 2.0 Tutorial: SAP HANA Introduction

Introduction to Database:

The main purpose of database is to store data and this data can be used for later purpose (analysis). Any big Enterprise we consider, they always store their business data into database. So that they use this data for analyzing their business.

Any database like (Oracle, Ms Access, SQL Server, Sybase ……) always store data in form of a structure called “TABLE”.

Table: Table is set of ROWS and COLUMNS

Each Row in a table is referred as Record

Primary Key:

It is a column in a database table which can maintain uniqueness for all the records in the table. It can be used to uniquely identify each and every record in the table

In above example: In the Customer Table the “Customer Number” is the Primary Key.

Every table must have a Primary Key (In Exceptional Cases we can have a table without a primary)

We have 2 types of columns in a table.

1) Key Column

2) Non - Key Column

Key Column:- Column which is a part of Primary Key.

Non - Key Column:- Column which is not a part of Primary Key.

All Non - Key Columns act as Attributes or Properties for Key Column.

Applications & Types:

Any application will have 4 aspects:

PL + database + OS + Concept

Programming Language is used to design the frontend (i.e, Interface screens &Application logic)
Database is used to design the backend to store data
Operating system to run the application
Concept is the reason for what the application is designed for

We have 2 types of applications:

OLTP
OLAP

OLTP [Online Transaction Process]:

OLTP applications are mainly to record all the transactions of the business

OLAP [Online Analytical Processing]:

OLAP application takes in all the transaction data from different OLTP applications and provides the reports for analysis.

Differences are there between OLTP and OLAP.

OLTP OLAP

1) Two dimensional model 1) Multi dimensional model

2) Day-to-Day Transactions 2) Historical data tractions also

3) Application oriented 3) Subject oriented

4) Users -> Thousands 4) Users - > Hundreds

5) DB size -> 100MB – 1GB 5) DB size -> 100GB-1TB

6) Redundancy 6) No Redundancy

7) No security 7) Security

Database design in OLAP:

In OLAP applications we store data in MDM [Multi Dimensional Format] by using the following models:

Start Schema or Traditional Star schema
Extended Start schema or BW Star schema or BI star schema
Snow Flake
Hybrid

Star Schema:

Star schema is an MDM ( Multi Dimensional Model ) which contains Fact table / Transaction data Table at the center, surrounded by Dimension tables / Master Data Tables existing within the Cube.
These Dimension Tables / Master Data Tables are linked to the Fact table / Transaction data table with Primary Key – Foreign Key Relationship.

Hierarchies:

When do we go for hierarchies.

When the Characteristics are related as 1:M and in the Reporting if we need to display the values by using hierarchies (Tree like display)

Hierarchy Structure

Software Engineering process:

Whenever we develop a software we follow the SDLC cycle . SDLC contains 5 steps:

Requirement Gathering
Design
Develop
Testing
Deploy
Maintenance & Support

1. Requirement Gathering:

At this phase we gather the requirements from the end users and understand the business process.

2. Design:

As we know every application will have the Front End (Interface Screens) & Back end (Database). As part of this phase we will have to design the Front end screens and Design the Database (Database design is referred in the Next Section)

3. Develop

At this phase by using some Programming Language & some database we develop the software.

4. Testing

At this phase we test the software, weather the software is working as per the user requirements or not.

5. Deploy

Once the Software is tested perfectly we deploy the software at the client location. So that the business can start using the software.

6. Maintenance & Support:

Once the software is deployed, we will have to provide the Maintenance & Support for any issues what the client/ Business faces.

Quick Overview of SAP BW, BW4HANA and SAP HANA

SAP BW

Multi Dimensional Models are implemented by creating Infocubes and DSO’s. System will generate tables whenever we create Cubes or DSO’s. (Dim and Fact tables)

Data Modeling ( Designing of Cubes and DSO’s & Others )
ETL - Extraction Transforming and Loading
Reporting (Bex reporting Tool – Default reporting tool for SAP BW)

SAP BW4HANA

SAP Made Mandatory to Create most of Data Targets/Objects in SAP BW/HANA Eclipse Based Modeling only.
Modeling Tab is removed from T.code -RSA1 Administration Workbench, (i.e all the Objects under modeling Tab is mandatory to create in Eclipse Based Modeling only)
DSO's Cubes, PSA is replace with ADSO ( Advanced DSO)
Multiprovider & Infoset is replace with Composite Provider , Composite Provider Can retrieve the data from Both SAP BW Data Targets & SAP HANA Views as well for Reporting.
Virtual Provider is replaced with Open DSO View.
Info Object Remains same, but need to Created only in BW Eclipse Based Modeling.
Field base Reporting is also possible.
Bex Reporting also can be done In SAP BW/HANA Eclipse Based Modeling
Transformations , DTP..So on made Mandatory to create in Eclipse Based BW Modeling.
Automatic Generation of View in SAP HANA is possible when we enable Check Box in ADSO, Open DSO Views, Composite Provider, Master Data Object.
As a Best Practice LSA++ Architecture is followed in SAP BW4HANA.
New Enhance Datasources are available as part of S/4 HANA.
New Business content Objects are also available.
SAP BW4HANA Embedded BW System is available for New customer, Existing Customer's can Upgrade & Migrate to SAP BW4HANA.

SAP HANA Database

Data Modeling in SAP HANA
Data Provisioning or Data Replication(ETL tools - SLT, DODS, SLT & DXC )
Implementation Of Data Models ( Creation of Views )
Reporting (SAP BO Reporting, Tableau, Quickview, Cognos, Lumira…)
Here Data Models (Multi Dimensional) are implemented by Creating Information Views.
Views created based on tables, These tables are Created manually or replicate from sources)

SAP HANA Overview

HANA Stand's as– High Performance Analytics Appliance

SAP HANA was implement in Nov 2011 and its adding with many Support Packs, Current Support Pack: SAP HANA 2.0 SP02.

SAP HANA is an in-memory database:

It is a combination of hardware and software made to process massive real time data using In-Memory computing.
It combines row-based, column-based database technology.
Data now resides in main-memory (RAM) and no longer on a hard disk.
It’s best suited for performing real-time analytics, and developing and deploying real-time applications.

An in-memory database means all the data is stored in the memory (RAM). This is no time wasted in loading the data from hard-disk to RAM or while processing keeping some data in RAM and temporary some data on disk. Everything is in-memory all the time, which gives the CPUs quick access to data for processing.

The speed advantages offered by this RAM storage system are further accelerated by the use of multi-core CPUs, and multiple CPUs per board, and multiple boards per server appliance.

Complex calculations on data are not carried out in the application layer, but are moved to the database.

Evolution of SAP HANA

In 1980's we have simple, General Purpose Database Server

Around year 2000 we have Separate Application Server tier, Processing the data from the DB, was introduced. also the Web Popularized this Architecture.

OLTP - Online Transactional Process (Only Current Data, and cannot handle more complex logics). OLTP is Mainly Uses to Insert, Update & Delete Records Faster.

OLAP - Online Analytical Process (Can handle Current and Historical Data ).The OLAP System is able to handle Complex reports, Forecasting , Analysis reports so on.. because its store huge Volume of data.

Bigger and bigger datasets forced the introduction of separate, specialized “ Data warehouses”, used for analytic processing (OLAP)

Evolution of SAP HANA

In OLAP Due to huge volume, generating reports would take long time, (Data retrieves from Hard Disk),
SAP tried with many theqnue’s to improve OLAP System Performance, like Performance Tuning, BIA as add on. So on. Still the OLAP System performance is low becase if huge volume of data in current era, and most type of analysis need to be done like text data read ( PDF files, Blogs, Face Book Data So on ..)

Advances of SAP HANA ( In Details discussed in Next Pages)

In SAP HANA Platform data is retrieved directly from RAM.
In HANA by using parallel processing and running reports by ram, Performance will be very high.
SQL Console in SAP HANA
Hardware Innovation

Major Advantages in SAP HANA

Reading data from RAM
SQL Console
Column storage in SAP HANA

Types of Tables

Row Store Table
Column Store Table
TABLE Type

4. Hardware Innovations

1. In Memory Data Base (IMDB)

By using In Memory Data Base, data is retrieved directly from RAM. (a Copy of Data will be stored in Hard disk, for any unexpected server shutdown.)

When we look into Traditional Model, the Entire data will be stored in Hard-disk. But in SAP HANA data is stored in RAM, the retrieval time from Ram will be faster than getting data from Disk, and further data is processed to Ram and display the output. So when we process through Ram the performance will be faster compared to traditional Model.

2. SQL Console

Introduction of SQL Script in HANA

The SAP HANA database has its own lanuguage called SQLScript.
QLScript is a collection of extensions to Structured Query Language (SQL).
In SAP HANA, the Logic will intensive pushdown to database.

Why SQLScript?

The main intension of SQLScript is to execute the data intensive calculations inside the SAP HANA database.

There are few reasons for best performance:

Here Moving calculations to the SAP HANA database layer eliminates the need of transfer huge amounts of data from the database Layer to the Application Layer.
All the Calculations need to be executed in the in SAP HANA database layer to get the maximum benefit'slike faster column operations, parallel execution of Query when we multihost Architecture.

If rows store processing on application level it will not benefited from the features above.

SQL Console

C. Overview of Row Data Storage and Column Data Storage

Relational databases typically use row-based data storage. However Column-based storage is more suitable for many business applications. SAP HANA supports both row-based and column-based storage, and is particularly optimized for column-based storage.

As shown in the figure below, a database table is conceptually a two-dimensional structure composed of cells arranged in rows and columns.

Because computer memory is structured linearly, there are two options for the sequences of cell values stored in contiguous memory locations:

Row Storage – It stores table records in a sequence of rows.
Column Storage – It stores table records in a sequence of columns i.e. the entries of a column is stored in contiguous memory locations.

How to Deside weather to go with be row store & Column Store. In SAP HANA Almost 98 % of the Tables will be used as Column Store becasue of its advantages.

Use of Row Store: If Inserts are more in number and Reading the Data volume is verly Less, then we go for Row.Also when we want to read all the Columns of a Table then we prefer to go with Row store. More Datil have provided below.

If Query Write , Read oprarions are more We go Column Store

Which type of tables should be preferred – Row-based or Column-based?

In case of analytic applications where aggregations are used and fast search and processing is required row-based storage are not good. In row based tables all data in a row has to be read even though the requirement may be to access data from a few columns. Hence these queries on huge amounts of data take a lot of time.

In columnar tables, this information is stored physically next to each other, significantly increasing the speed of certain data queries.

The following example shows the different usage of column and row storage, and positions them relative to row and column queries. Column storage is most useful for OLAP queries (queries using any SQL aggregate functions) because these queries get just a few attributes from every data entry. But for traditional OLTP queries (queries not using any SQL aggregate functions), it is more advantageous to store all attributes side-by-side in row tables. HANA combines the benefits of both row- and column-storage tables.

Conclusion:

To enable fast on-the-fly aggregations, ad-hoc reporting, and to benefit from compression mechanisms it is recommended that transaction data is stored in a column-based table.
The SAP HANA data-base allows joining row-based tables with column-based tables. However, it is more efficient to join tables that are located in the same row or column store. For example, master data that is frequently joined with transaction data should also be stored in column-based tables.

Advantages of column-based tables:

Faster Data Access: Only affected columns have to be read during the selection process of a query. Any of the columns can serve as an index.

Better Compression: Columnar data storage allows highly efficient compression because the majority of the columns contain only few distinct values (compared to number of rows).

Better parallel Processing: In a column store, data is already vertically partitioned. This means that operations on different columns can easily be processed in parallel. If multiple columns need to be searched or aggregated, each of these operations can be assigned to a different processor or core.

Traditional databases store data simply in rows. The HANA in-memory database stores data in both rows and columns. It is this combination of both storage approaches that produces the speed, flexibility and performance of the HANA database.

Advantages and disadvantages of row-based tables:

Advantages for Row Based

The application needs to only process a single record at one time (many selects and/or updates of single records).
The application typically needs to access a complete record (or row).
Neither aggregations nor fast searching are required.
The table has a small number of rows (e. g. configuration tables, system tables).

Row based tables have Dis-advantages.

In case of analytic applications where aggregation are used and fast search and processing is required. In row based tables all data in a row has to be read even though the requirement may be to access data from a few columns.

Row Store

One of the relational engines to store data in row format.
Pure in-memory store (Future versions will also have an option of disk based store)
In memory object store (in future) for live cache functionality
Transactions Version Memory is the heart of row store.Row store architecture

Write operation mainly go into "Transactional Version Memory"
INSERT also writes to persisted segment
Moves visible version from memory to persisted segment
Clears outdated record versions from Transactional Version memory
Row Store tables have a primary index
Row ID maps to primary key
Secondary indexes can be created
Row ID contains the segment and the page for the record
Indexes in row store only exist in memory
Index definition stored with table meta

Column Store

Improves read functionality significantly, also improves write functionality
Highly compressed data
No real files, virtual files
Optimizer and Executer – Handles queries and execution plan
Delta data for fast write
Asynchronous delta merge
Consistent view Manager
Main store compressed and read optimized – Data is read from Main Store
Delta Store – Write optimized – for write operations.
Asynchronous merge move the data from delta store to main store
Compression by create dictionary and applying further compression methods
Even during the merge operation, the columnar table will still be available for read and write operations. To fulfil this, a second delta and main storage are used internally
Merge operation can also be triggered manually with an SQL command

Persistence Layer

Peristence Layer is needed as Main memory is volatile
Provides Backup and Restore functionality
One Persistency Layer takes care of both row and column stores
Regular Save Points
Logs capturing DB transactions since last save point
Actions during system restart
Last savepoint must be restored plus undo logs must be read and uncommitted atransactions saved with last save point and apply redo logs
Complete content of row store is loaded into memory during start procees
Flags can be set for column store to specify which tables are loaded during system restart

4. SAP HANA Hardware

SAP HANA is a combination of hardware and software made to process massive real time data using In-Memory computing. To leverage the full power of the SAP HANA platform, you need the right hardware infrastructure.

Hardware Innovations

The SAP HANA can only be installed and configured by certified hardware partners.

SAP HANA Hardware Partners:

Currently SAP HANA Hardware partners are:

SAP HANA Combinations

HANA + BO

HANA + BW/BI

HANA + BODS

HANA + ABAP

HANA + HTML, Java Script , RDL (Extended Application Services )

HANA + Administration Any DBA, ETL, SAP Basis so on

SAP HANA Architecture:

Layer 1 : SAP & Non SAP Source Systems

Layer 2 : Various Replication Techonologies Used to Replicate Data to SAP HANA

A. SAP SLT (SAP Landscape Transformation)

The SAP Landscape Transformation (LT) Replication Server is the SAP technology that allows us to load and replicate data in real-time from SAP source systems and non-SAP source systems to an SAP HANA environment.

The SAP LT Replication Server uses a trigger-based replication approach to pass data from the source system to the target system.

Extraction data from SAP and Non SAP systems to HANA Database. (Its Real-time data Replication, 0 Downtime required.)

Advantage of SLT replication?

SAP LT uses trigger based approach. Trigger-based approach has no measureable performance impact in source system.
It provides transformation and filtering capability.
It allows real-time (and scheduled) data replication, replicating only relevant data into HANA from SAP and non-SAP source systems.
It is fully integrated with HANA Studio.
Replication from multiple source systems to one HANA system is allowed, also from one source system to multiple HANA systems.

Continuous Delta Replication after Initial Load

After the initial load process has completed, the SLT system continues to monitor the transaction tables in the ERP system, and replicates data changes in the source system to the SAP HANA system in near real time.

B. BODS Extraction (Business Objects Data-services)

BODS provide a blend of data integration with batch processing Extract Transform Load (ETL) and real time bi-directional data flow across multiple applications.

BODS can extract data from any SAP and Non SAP Systems to HANA DB.

SAP Data Services gives a single enterprise level solution for data integration, transformation, data quality, data profiling and text data processing which allows us to:

Build a trusted data warehouse platform using data integration, data transform and data profiling
Provides single graphical user interface application for developers to build everything in the system.
Web based tools for managing application including the reporting on system runtime statistics, metadata, user maintenance.
Enables organizations to maximize operational efficiency with single solution for data warehousing for improving data quality and integrating data from heterogeneous systems.

C. DXC (Direct Extract Connection)

No Additional license required for Using DXC, Here we do Cost Saving, No Server Maintained (DXC is Already in-built in source systems ). So Huge cost saving is achieved by Using DXC. ( For Using SLT or BODS we require Separate Server & resources as well)

For DXC we require source as Embedded ECC and target as HANA System.

DXC Connection – HTTP (XS engine comes into picture)

BODS & DXC can have both delta enabled.

Based on the required of the Client we can use DXC or SLT.

D. SAP HANA Log-Based Replication

Transaction Log Based Data Replication Using Sybase Replication.

This replication method is only recommended for customers that have been invited to use this
technology during the RTC of the SAP HANA 1.0 product delivery. If you are not part of this RTC group, SAP recommends using Trigger-Based Data Replication Using SAP Landscape Transformation (SLT) Replicator because of the rich feature set this replication technology offers.

E. HANA Smart Data Access

HANA Smart Data Access is a feature that provides the possibility to virtually access data from various remote sources without the need for previous movement or replication of data to SAP HANA. Virtual tables’ data types are mapped to SAP HANA data types and they are handled as SAP HANA local tables. After the connection to a remote source has been established, SQL queries can be run against virtual tables and can be combined with other existing physical SAP HANA tables or other SDA sources. One of the use cases for SAP HANA Smart Data Access is archiving cold data in an alternate source and keeping active hot and warm data in SAP HANA.

SAP HANA Smart Data Integration and Smart Data Quality features together provide an integrated ETL mechanism and therefore replace the need for a separate ETL tool. They were launched for the first time in Service Pack 09 and further enhanced in following releases.

SAP HANA Smart Data Integration capabilities are used for analytics, data migration and batch or real-time integration from multiple sources. Real-time replication is also available and supported by a built-in RSS adapter. Smart Data Integration transformations include basic and advanced SQL-oriented transformations, transformations that handle the data movement lifecycle and transformations for code execution.

Advanced Smart Data Quality transformations support data quality functionalities like parsing, standardizing and enriching the information on dimensional attributes as well as global address cleansing, and geocode enrichment for countries worldwide.

Flowgraph is a development object used for creating data flows with Smart Data Integration and Smart Data Quality transformations. Modeling of flowgraph starts with its creation and concludes with activation and execution of generated task or stored procedure.

In the example, I will show how to establish a remote connection to an SQL Server database, create a virtual table, create a flowgraph, transform and join data from virtual tables and store it into a SAP HANA table.

Layer 3 : Calculation & Planning Engine (More info Available in Details Architecture)

A. Calculation and Planning Engine.

Whenever we run Query, it translates to SQL and pushes to HANA DB and fetches the data.

B. Row and Colum Store

Table data can be store in form of Row or Colum based store. When we run query it hit’s both Row and Column level store.

Layer 4 :

SAP HANA Modeling: Here we are going to create All views ( Attribute Views, Analytical Views, Calculation, Analytical Privileges, procedures, .....So on)

SAP HANA Information Modeling which also known as SAP HANA Data Modeling is the heart of HANA application development.
You can create modeling views on top of database tables and implement business logic to create a meaningful report.

Before Creating views , We need Create Packages, Under Packages we create Views..

Package: Packages are just like Folders; these are Group of related information objects/Modeling objects.

Layer 5 :

User can go for any of the Reporting Flavor On top of SAP HANA Database. No reporting Flavor is free of Cost, On Top of SAP HANA the Client need to Purchase the reporting Flavor Separately such as, SAP BO Reporting Tool, Congas, Quick view , Tableau so on..

SAP BO Reporting Overview

SAP HANA Use Case Scenarios

SAP BW ON HANA Flow

Data Replication Techniques

SAP LT Replication Server (SLT)
SAP Data Services (DS)
SAP Direct Extractor Connection (DXC)

Detail Overview of all replications is explained Below

Overview

1.SLT Replication – (SAP LANDSCAPE TRANSFORMATION)

SAP LT Replication Server (SLT) is used for real-time data replication from SAP and non-SAP sources (SAP supported data bases only)

Mainly recommended for real time data replication business scenario

2. SAP Data Services (BODS- Business Objects Data Services )

SAP Data Services (DS) is positioned for batch load-based data replication from non-SAP sources and SAP sources (with complex ETL requirements)

-> Mainly recommended for batch type data replication business scenarios

3. SAP HANA Direct Extractor Connection (DXC)

DXC is available as a simple option in batch mode for data replication from existing SAP Data Source extractors (ERP) into SAP HANA.

-> Mainly recommended for batch type data replication for stand alone HANA business scenarios, Other Data Provisioning Options Sybase Event Stream Processor (ESP) * : will be available for replicating real time event streams from Sybase ESP (CEP) into SAP HANA

1. SAP SLT Replication – (SAP LANDSCAPE TRANSFORMATION)

The SAP LT Replication Server uses a trigger-based replication approach to pass data from the source system to the target system.

SLT – System Landscape Transformation

ECC Source System

Write Module : Writes data through DB connection to SAP HANA system♣

Read Module : Read Module with get entire data for first time and from next time delta.

Logging Table : Maintains the change log entries.

DB Trigger : DB Trigger used to trigger the data.

Note: No Data will be stored in SLT System. (Data Stores in SAP HANA DB)

Advantage of SLT replication?

SAP LT uses trigger based approach. Trigger-based approach has no measureable performance impact in source system.
It provides transformation and filtering capability.
It allows real-time (and scheduled) data replication, replicating only relevant data into HANA from SAP and non-SAP source systems.
It is fully integrated with HANA Studio.
Replication from multiple source systems to one HANA system is allowed, also from one source system to multiple HANA systems.

Continuous Delta Replication after Initial Load

SAP HANA Editions

There are 3 types of Editions in SAP HANA
1. SAP HANA Platform Edition
2. SAP HANA Enterprise Edition and
3. SAP HANA Extended Enterprise Edition

After SAP HANA 1.0 SP 05 Version , SAP have provided only 2 editions Only
1. SAP HANA Platform Edition
2. SAP HANA Enterprise Edition (BODS - SLT– SDA)

SAP BO Reporting Overview
Here We have Various Reporting tools in SAP HANA. Client Can Go ahead with any of the Reporting tools such as SAP BO, Tableau, Quick , Cognos so ..on..

SAP BO Reporting Tool Overview

SAP HANA Studio Overview

On the Left Hand Side we can see Catalog & Content

Under-->Catelog

-->Schemas
---Schema..1
---Schema..2
---Schema..3
---Schema......n

Types of Schemas

There are 3 types of schemas.

User Defined Schema

System Defined Schema

SLT Derived Schema

1. User Defined Schema:

These are created by users, Basically DBA or System HANA Administrator

2.System Defined Schema:

These schemas are delivered with the SAP HANA database and contains HANA system information. There are system schemas like _SYS_BIC, _SYS_BI, _SYS_REPO, _SYS_STATISTICS etc.

System Generated Schemas

_SYS_BIC: This schema contains all the columns views of activated objects. When the user activates the Attribute View/Analytic View/Calculation View/Analytic Privilege /Procedure, the respective run-time objects are created under _SYS_BIC/ Column Views.

_SYS_REPO: Whatever the objects are there in the system is available in repository. This schema contains the list of Activated objects, Inactive Objects, Package details and Runtime Objects information etc.

Also _SYS_REPO user must have SELECT privilege with grant option on the data schama.

_SYS_BI: This schema stores all the metadata of created column Views. It contains the tables for created Variables, Time Data (Fiscal, Gregorian), Schema Mapping and Content Mapping tables.

_SYS_STATISTICS:

This schema contains all the system configurations and parameters.

_SYS_XS:

This schema is used for SAP HANA Extended Application Services.

3. SLT ( System Landscape transformation )Derived Schema:

When SLT is configured, it creates schema in HANA system. All the tables replicated into HANA system are contained in this schema

Under System

-->Content (Under Content we Create Packages & Views )

Package: Packages are just like Folders; these are Group of related information objects/Modeling objects.

Packages are of Two Types

1. Structural Package

Here we can create only sub-packages (No Views Can be created)

2. Non-Structural Package

We can create any object. (Views can be created)

Example 1:

Under

SALES.(Structural Package)

-->Sales (Non-Structural Package)

· Attribute views

· Analytic views

· Calculation views

-->Delivery (Non-Structural Package)

· Attribute views

· Analytic views

· Calculation views

-->Billing (Non-Structural Package)

· Attribute views

· Analytic views

· Calculation views

Provisioning : This is used for getting Virtual Tables using SDA(Smart Data Access from Various Source Systems .

Security - To Create Roles & Assign Roles to Users

SQL Editor: Here all Access/Prvilages are provided from SQL editor only.

Quick Launch Tab

Delivery Unit :

A single Unit which can be mapped to multiple packages and can be exported as single entity. So that all the packages assigned to Delivery Unit can be treated as single unit.

Generate Time Dimension: For Time Dimension we need to manually Generate eithet Fiscal Year or Calender Year. All time dimension’s will store in Schema as _SYS_BI. ( Models _SYS_BIC ). All time dimensions can be stored based on their grangularity (Ex. From Year, Month, date ,…).

Configure Import Manager: Here BODS Connection Setting can be done

Data Provisioning: We can Replicate Tables in SAP HANA Studio under "Data Provisioning"

This will launch Data Provisioning UI in HANA studio and by default you will see three ABAP data dictionary related tables (DD*) in replication status.

Select the Source System & Target Schema

Now press the "Replicate" button and we will select a sample table(TBTCO , AGR*) to replicate.

Import & Export : (Transportation) : We can Upload Flat files to the Tables in SAP HANA. Also we can export as Xml File .throgh delivery unit. Also we can import tables from DODS ( BODS Connected to Import Servers).

Mass Copy ( HANA Live )A Buch of Business Content Objects can be activated and used in a Go.

Migrate : This option is available to transulate multiple languages supported by HANA

Validate: A Bunch of Objects can be Validated in Single Go...

Activate: A Bunch of Objects can be Activated in Single Go...

Redeploy: Redeploy will be used when ever we upgrade the system. Basically we take backup of Schemas/objects when we do upgrade and redeploy into HANA Studio.

Auto Documentation: Every Model we create it will be auto documented as PDF format , so we can use for reference or Documentation .

Swithch Honourship: Whenever SAP team wants to login to HANA system we use this option.

Schema Mapping: Moving objects from one system to other system (not SQL , procedures, Calc View)

In SAP HANA Studio --> Double Click on System

Monitor

we can watch all servers running and health of the system.

How to add new HANA system in HANA studio?

In order to connect to a SAP HANA system we need to know the Server Host ID and the Instance Number. Also we need a Username & Password combination to connect to the instance.
The left side Navigator space shows all the HANA system added to the SAP HANA Studio.

Steps to add new HANA system:

1. Right click in the Navigator space and click on Add System

2. Enter HANA system details, i.e. the Hostname & Instance Number and click Next.

3. Enter the database username & password to connect to the SAP HANA database. Click on Next and then Finish.

4. The SAP HANA system now appears in the Navigator.

1. What is the difference between catalog and content?

In HANA Studio every HANA system has two main sub-nodes, Catalog and Content.
Catalog: The Catalog represents SAP HANA’s data dictionary, i. e. all data structures, tables, and data which can be used.

All the physical tables and views can be found under the Catalog node.

Content: The Content represents the design-time repository which holds all information of data models created with the Modeler.

Physically these models are stored in database tables which are also visible under Catalog. The Models are organized in Packages. The Contents node just provides a different view on the same physical data.

The created Column Views are always located in schema _SYS_BIC, their metadata in schema _SYS_BI.

2. Does 32 bit version of HANA client work with SAP HANA repository and SAP HANA Development perspective?

There is no 32 bit version of the repository client.
If you want to make use of the repository integration features, for example, in the Project Explorer view in the SAP HANA Development perspective, you must install the 64 bit version of the repository client.

3. How can we set path to the repository client in HANA Studio?

1. In SAP HANA studio, choose Window –> Preferences –> SAP HANA Development –> Repository Access

2. Choose Browse and enter the path to the SAP HANA client executable, regi.exe. For example, C:Program Filessaphdbclientregi.exe

3. Choose Apply to enable the new setting.

4. Choose OK to save the settings.

4. How to start HANA Studio in Linux?

To start the SAP HANA studio, perform the following steps:

1. Open a shell and go to the installation directory, such as /usr/sap/hdbstudio

2. Execute the following command “./hdbstudio”. The SAP HANA studio starts.

3. To set the path to the repository client

4. In SAP HANA studio, choose Window Preferences SAP HANA Development Repository Access

5. Choose Browse… to enter the path to the SAP HANA client executable, regi. For example, /usr/sap/hdbclient

6.Choose Apply to enable the new setting.

7.Choose OK to save the settings.

SAP HANA – Overview of Modeler Perspective

In SAP HANA studio, the SAP HANA Modeler perspective helps you create various types of information views, which defines your analytic model.

This above image shows the pictorial representation of Modeler perspective along with the views.

SAP HANA Systems view: A view of database or modeler objects, which you create from the Modelerperspective.

Quick View : A collection of shortcuts to execute common modeling tasks. If you close the Quick Viewpane, you can reopen it by selecting

Help

Quick View

Properties pane: A view that displays all object properties.

Job Log view: A view that displays information related to requests entered for a job such as, validation, activation, and so on.

Where-Used view: A view that lists all objects where a selected object is used.

5. History View: This view shows us the different types of jobs we have executed and its detailed view over a period of time.

6. Progress View: This view has the list of jobs that we are currently running on SAP HANA system. This view only shows active objects and jobs can also be cancelled from this view.

7. Quick View: This is very important view for modeler, because of the reason that we can perform a lot of activities that are very important for modeling from here. To know more about how to perform each activity that we have under Quick View screen, please go through the below articles.

How to open a View?

If we feel like some of the views are missing in any perspective or need additional views we can get then by going into ‘Main Menu’ → ‘Window’ → ‘Show View’ → ‘Other’.

This will give us the screen with list of different views categorized into folders available in HANA Studio. We can choose the view we would like have in the Studio and click ‘ok’ to see that in Studio.

How to minimize a view?

Sometimes when we are building complex models in SAP HANA or writing big SQL statements we might feel uncomfortable with all these views residing all around.

We can minimize a view and also restore it whenever we need using the ‘minimize’ and ‘restore’ buttons available.

Note: Minimizing the ‘systems view’ and ‘Where-Used List view’ places extra icons on left side top of the HANA studio and for other views it is going to be on right side top.

We don’t have minimize option for ‘Quick View’. This can be closed and reopened from ‘Main Menu’ → ‘Help’ → ‘Quick View’.

Properties/Job Log/History/Progress View:

Systems View & Where-Used List:

Various Perspectives' in SAP HANA

How to switch between perspectives: We can quickly switch between multiple perspectives using the option we have on top of the SAP HANA Studio as shown below.

Note: The perspective we are currently using will be highlighted on top as shown above in the above image.

With this we have seen details about how the modeler perspective looks in SAP HANA studio and the different types of views it has.

Thank you for reading and hope this information is helpful. Please do share with your friends if you feel the information is useful.

Happy Learning.

SAP HANA studio is an eclipse based environment designed to provide platform for Development, Data Provisioning, Modeling and Administration on SAP HANA.

One of the main feature we have in SAP HANA studio is perspective. SAP HANA Studio provides different types of perspectives which are specifically designed to perform certain tasks on SAP HANA Database.

We can see the list of perspectives available in SAP HANA Studio by going to ‘Main Menu’ → ‘Window’ → ‘Open Perspective’ → ‘Other’ as shown.

This gives us the below screen with list of perspectives available in SAP HANA Studio as shown in below image.

Some of the important perspectives that are frequently used are

1. ABAP:

This perspective is used to build, debug and execute the ABAP programs like how we do in any SAP ECC system.

Using this perspective one can switch between SAP GUI screen and eclipse screen any time and the SAP screen here provides all the functionalities that we get when we login into SAP system directly.

This perspective doesn’t come as a default perspective along with SAP HANA studio.

Please go through ‘ABAP Modeling tools installation’ article on how to install this perspective in SAP HANA Studio.

2. BW Modeling:

This perspective is used to build the BW modeling objects and maintain the BW system from HANA studio rather than logging into BW system separately.

This actually provides single point solution for BW modeling and administration.

Some of the modeling objects that we can create using BW modeling tools in HANA Studio are Advanced DSO, Composite Provider and Open ODS View.

This perspective also doesn’t come as a default perspective along with SAP HANA studio, please go through ‘BW Modeling tools installation’ article on how to install this perspective in SAP HANA Studio.

3. Debug:

This perspectives helps us in debugging the codes we write while building web applications using developments perspective.

Example: To view source code, monitor or modify variables, and set break points.

4. SAP HANA Development:

This perspective is used to perform all the tasks related to application development on SAP HANA XS

For example: to manage application-development projects, display content of application packages, and browse SAP HANA repository.

You can also define your data-persistence model here by using design-time artifacts to define tables, views, sequences, and schemas.

Note: This is the most frequently used perspective by developers in SAP HANA.

5. SAP HANA Modeler:

This perspective is used to build analytic models like attribute view, analytic view, and calculation view and so on.

Using this we can also maintain the database objects like tables, views, sequences, indexes and so on and administering the real-time replication using SLT.

Note: This is the most frequently used perspective by modelers in SAP HANA.

6. SAP HANA Administration Console:

This perspective provides different elements to administer the SAP HANA database from the threads that are running on server to the system level configuration.

Please go through the ‘Introduction to SAP HANA Administration’ to know how this perspective is helpful to monitor SAP HANA database.

Note: This is the most frequently used perspective by administrators in SAP HANA.

7. SAP HANA PlanViz:

This perspective is used to do performance analysis on the modeling objects we create by executing visualize plan.

This perspective will be called by default when we execute ‘Visualize Plan’ from SQL console on any HANA model or SQL statement.

Note: This perspective is frequently used by modelers in SAP HANA.

8. Team Synchronizing:

This perspective is used to synchronize the development artifacts we have created in local file system to SAP HANA repository.

Note: This perspective is frequently used developers in SAP HANA.

How to Add SAP BW4HANA System in SAP BW Eclipsed based Modeling

Once we login to SAP HANA studio ..

Under SAP HANA Studio First login to Modeler From there Go to --> Windows-->Perspective-->Open Perspective-->Others

Click BW Perspective

( or ) Click On

The below Screen will appear. Click On Open Project & Click on BW Project

Select BW4HANA System and Click on NEXT

Provide the SAP GUI Properties as Required

Click on Next ( the above are SAP BW4HANA Login Details )

Provide SAP BW4HANA System ID & Password.

One We Login we Can Create New Info Area, Under Info Area we Can Create Info Object, Data Targets, Queries,..So On........

********************* End *******************

Browsecourses

SAP HANA Introduction

Advantages of column-based tables:

Quick Launch Tab

Various Perspectives' in SAP HANA

SAP HANA 2.0 Online Training Reach Us @ sapbwbi4hana@gmail.com