SAP Smart Data Integration (SDI) and difference vs Smart Data Access (SDA)

HANA as data management platform needs to connect to other data sources to get a data. There are many integration patterns to follow to enable the connection. There is an ETL processing, real time replication, data integration etc. Each of them has its own advantages as well as disadvantages. With the introduction of SAP HANA Smart Data Integration (SDI) the SAP is pursuing to get the best of some of them.

SAP Smart data integration (SDI) is an extension of SAP HANA Smart Data Access (SDA). The SDA leverages the concept of virtual tables (data federation type of thing). That means a data replication is eliminated by providing a virtual layer that abstracts the underlying data sources. Metadata of tables of the source system are imported as virtual tables into the HANA. On top of the SDA the SDI brings broader set of preinstalled adapters from Data Provisioning Agent (DP Agent) component. The adapters in case of the SDI are no longer part of HANA DB. They run as separate processes in DP Agent component.

The SDI is part of the Enterprise Information Management (EIM) solution of SAP. Its purpose is to connect data sources to the HANA, provision data from them and load the data from them to HANA.

As the SDI brings more functions into the EIM process, some customers are opting for this option. Therefore e.g. in SAP BW area they are migrating the SDA based data sources to the SDI one.

 

SDA is available since SAP HANA 1.0 SPS06

SDI is available since SAP HANA 1.0 SPS09

More information:

SDA

SDI online docu

2400022 - FAQ: SAP HANA Smart Data Integration (SDI)

2180119 - FAQ: SAP HANA Smart Data Access

2600176 – SAP HANA Smart Data Access Supported Remote Sources

SAP HANA license types

There are several license types available for the SAP HANA database. Below is a brief overview of the most common ones:

 

SAP HANA Runtime License: This license allows users to run the SAP HANA database in a production environment. It is available for both on premise and cloud deployments and is typically based on the amount of memory utilized by the database. The runtime license is most likely more purchased database license type. This is also the more restrictive license since customers can only leverage it for SAP applications and the underlying SAP and non-SAP data can only be loaded, exported, and managed via SAP technologies.

 

SAP HANA Full Use License: This license provides full access to all of the SAP HANA features, including data integration, advanced analytics, and development tools. It is typically purchased as an add-on to the SAP HANA Runtime License. The full use license type is less restrictive one. It is because there are less restrictions of SAP HANA Runtime. Organizations can use HANA full use for any combination of SAP, non-SAP, custom, or third-party applications. In addition, no limitations exist on the loading and exporting of SAP and non-SAP data directly in and out of SAP HANA.

 

SAP HANA Platform Edition: This license includes both the SAP HANA Runtime and Full Use licenses, as well as additional tools for data modeling and administration. It is designed for organizations that require a comprehensive data management solution.

 

SAP HANA Enterprise Cloud License: This license provides access to the SAP HANA database via a cloud-based subscription model. It includes both the SAP HANA Runtime and Full Use licenses, as well as cloud-specific features such as automated backups and disaster recovery.

 

SAP HANA Edge Edition: This license is designed for small to medium-sized businesses and includes a subset of the SAP HANA Platform Edition features. It is typically based on the number of users or CPU cores utilized by the database.

 

SAP HANA Express Edition: This license is a free, streamlined version of the SAP HANA database that is intended for non-production use. It includes a limited set of features and is typically used for development, testing, and training purposes. It is a free up to 32GB of use with the ability to purchase more, making it suitable for individuals.

 

The licensing terms and conditions for SAP HANA may vary depending on the specific product and deployment model. SAP clients need to always check with their SAP account manager about appropriate license type for their needs.

 

 

More information:

What type of SAP HANA (License) do you need ?

3247198 - SAP HANA License

SAP HANA Smart Data Access (SDA)

Within an advent of SAP HANA there was a new technology introduced to enable bringing data from external sources to the SAP HANA. It is called SAP HANA Smart Data Access (SDA). The data stored in the external databases appear if they were local tables in SAP HANA. There is no need to transfer the data physically from those external sources to the HANA in order to use them.

It uses a concept of virtual tables which point (via mapping) to remote tables in different data sources. In the HANA an SQL statements can be executed to process those data. The HANA query processor process these SQL statements and execute part of them against target database returning results to the HANA.

There is a number of the external databases that are supported. Depending on their hardware platform it varies from: SAP’s DB portfolio (HANA DB, IQ, Adaptive Server Enterprise (ASE), Event Stream Processor, HANA Smart Data Streaming, MaxDB), MS SQL Server, Oracle, Apache Hadoop, Apache Spark, IBM Netezza, IBM DB, Teradata, etc. The SDA was introduced in version of SAP HANA 1.0 SPS06 (in 2013).

 

More information:

1868209 - SAP HANA Smart Data Access 1.0 Master Release Note

2352696 - SAP HANA Smart Data Access 2.0 Master Release Note

Online docu SAP HANA Smart Data Access

SAP HANA Extended Application Services (SAP HANA XS) flavors

HANA has built-in an application server for native development in the SAP HANA environment. There are actually two flavors application servers. I depict here the two and mention some differences. 

HANA native application development resides on the XS server (or also called as XS Engine or just XS). The XS is a small footprint application server including: web server and basis for an application development environment.  The XS is installed on the same hardware as SAP HANA. It does extend the SAP HANA database. It makes a platform out of it.

XSC - SAP HANA XS classic, lightweight application server includes web based HTTP and OData services. It can consume HANA database artifacts (e.g. calculation views) and it has built in support for the SAP Fiori UI. Also supports transactional services based on core data services (CDS). It uses database permissions, there are DB users in HANA itself. It was introduced in SAP HANA SPS 05 (around year 2012). 

Programming model: OData REST services is generated from any existing SAP HANA Table or View. All metadata and source codes (XS server-side JavaScript (XSJS)) for XS Classic app are stored in the SAP HANA repository.

XSA - SAP HANA XS Advanced is a new application server for native development in the SAP HANA environment. It supersedes SAP HANA XS. It is decoupled from HANA, are not necessary users in HANA DB. XSA started to be delivered SAP HANA SPS 11 (around year 2015).

Programming model: UI rendering and other front end processing is normally done in web browser using HTML5 and client-side JavaScript. Application logic, business logic, calculations, and data processing talks place in HANA DB by using SQL, SQLScript procedures, Calculation Engine (CE) functions. Means data processing is performed in database - close to the data. Three runtimes currently supported: 

XSJS - same as in XSC

Node.js – to support asynchronous web programming model, to leverage node.js’s ecosystem as there are many open source nodejs modules

Java – as there is a huge number of popular Java frameworks out there

More information:

A New Development Platform for Native SAP HANA Applications

SAP HANA SPS 11 new developer features xs advanced

How to find out SAP HANA version in various tools

More information about SAP HANA versions revisions can be found in this blog.

1. from SAP GUI:

1.1 Via menu System -> Status 

 

1.2 By running FM DB_DBRELINFO 

 

  

2. In SAP HANA Studio:

2.1 Right click on HANA system in Systems perspective and choose menu item Properties.

2.2 While in the Systems perspective select Configuration and Monitoring -> Open Administration. Version the information can be found under Overview tab.

3. From SQL console (console can be opened from System perspective by right clink on the particular system and choosing menu item “Open SQL Console”):

By entering following SQL statement:        select * from "SYS"."M_DATABASE";

4. Using command line (for command ninjas):

By executing a command:    HDB version

Useful links:

HANA versions / revisions

Documentation M_DATABASE System

 

HANA 2

On last year Barcelona’s TechEd (Nov. 8–10 2016) a new generation of SAP HANA was introduced – the HANA 2. It is basically a new generation offering functions in areas of DB management, data management, analytical intelligence, and application development. In details they cover following:

DB management – A new active/active read-enabled option allows reading data stored in secondary systems. Before that such a data needed to be replicated first before using it.

Data management – a web based tool called SAP Enterprise Architecture Designer allows to visualize impact of new technologies to current landscapes. E.g. enhancement of tiered storage impacting distributed storage of data by priority.

Analytical intelligence – new algorithms of areas like classification, association, time series and regression were added into predictive library to support job of e.g. data scientists in terms use cases of machine learning.

Application development – in this area functions for application servers, development tools, and development languages were added. New file processor interface allows to extraction of metadata from documents.

Micro services – usage of cloud based micro services can enhance applications with analytical insight using APIs and any language or development platform.

More information:

SAP HANA Platform (Core) 2.0

SAP HANA2 announcement

SAP HANA2 announcement 2

Feature Scope Description for SAP HANA 20 SPS 00

BW: Conversion of DB tables to from Row Store to Column Store

Within a move of SAP NetWeaver based system from any DB to HANA DB there are many steps involved. Also a step of converting tables from row to column based is one of them.

Running the system on HANA DB you can have the table regardless of it store type (either row store or column store). Then depending on type of the system (OLTP or OLAP) majority of tables are set to one of the store types. E.g. in case of OLAP system (e.g. SAP BW) most of the tables are type of column store tables because it delivers a better performance in case of data warehouse data processing (running queries, transforming the data, etc). Also it delivers better compression rate in case of OLAP. On other side in the systems like OLTP it requires balanced approach whereas for some table a row store might be better and for others column store concept.

During HANA migration (or even before that to minimize downtime) an ABAP report called RSDU_MOVE_TO_COLUMN is used convert the tables based on row store to column store. However the program can be run even after the migration to find out what are tables that have potential to be converted to column store. The report has several modes of runtime. In the “Check only” mode a list of biggest row store tables is provided.

Also to see to what store type a particular table is set; see table DD09L (DD: Technical settings of tables) and its field (ROWORCOLST - For distinction between Row or Column Store) in particular.

More information:

ABAP on HANA: How to check what tables are type of columnar?

2044047 - Pre-BW7.4 SP08 RowStore-to-ColumnStore conversion

Can DTP be pushed to HANA DB for execution?

Usually one of very first things that are checked once the BW system is migrated to HANA database is to find out what are data loads that can be pushed to HANA easily without any modification. To do this check SAP offers within the set of tools for migration to BW on HANA tool called SAP BW Transformation Finder (ABAP report ZBW_TRANSFORM_FINDER).

The tool is quite a complex and it offers to identify redundant data layers like "1:1" or "N:1" transformations. Through this tool the transformations that can be pushed to the DB can be found. Although a list of the TRFN is definitely useful I was wondering whether there is a way to identify a list of the DTP for the same – push to the HANA DB. As I blogged in my older post Pushing DTP execution to HANA DB there is a button available in the DTP maintenance screen that allow to find it out. To check this for many DTPs at one shot I developed short program. The program can be found in my github - DTP_TO_BE_PUSHED2HANA.

My tool similarly to SAP one utilizes a call of method CLARIFY_REALIZATION of class CL_RSTRAN_DB_STAT. If DTP particular DTP is compatible with SAP HANA Execution then it is listed out in tool’s output screen. Hope someone will find the tool useful.

More information:

github - DTP_TO_BE_PUSHED2HANA.

1908367 - SAP BW Transformation Finder

Scalability – scale out/in vs up/down

One of important aspects of computer system is scalability. It is a capability of the system to handle expanding amount of tasks that need to be completed by the system. Prerequisite is that the system must function in same way after scaling as it was before the scaling. The system in this terms can be computer, network etc. Scalability is sometimes referred as extensibility.

There are two basic approaches to scaling of the computer systems. It is horizontal and vertical scaling.

In first case – horizontal scaling it means to add or remove a computing unit (node) to/from the system. This is so called quantitative change. As example a new computer can be added into distributed system. The horizontal scaling is also called as scale out/in.

The latter case – vertical scaling it means to change a property of the existing system by adding or removing resources to/from the computing unit (the node) of the system. This is so called qualitative change. As example it can be about adding more CPUs or memory to existing node. The vertical scaling is also called as scale up/down.

Difference between the two can be noted on following example. There can be a system of having an 8TB of memory in total in one node – a scale up approach. While as scale out example there can be 8 nodes having 1TB of memory each.

In terms of scaling of SAP HANA both approaches can be used as the HANA is designed for scale up and as well for scale out since the beginning.

BoH: Obsolete processes in process chains

While running SAP BW on HANA database there are couple of processes within process chains that were used before and are not needed anymore. Reason is that HANA has some of these functions already build on DB level and BW doesn’t need to be worry about them. A list of these obsolete processes is here:

Index related:

Build Index

Delete Index

Aggregate or BWA related:

Initial Filling of New Aggregates

Adjust Time-Dependent Aggregates

Rolling Up Filled Aggregates/BWA Indexes

DB statistics related:

Construct Database Statistics

Other:

Update Explorer Properties of BW Objects

So what actually the SAP BW system does when it runs into the process that is obsolete for HANA? There is simple check if the HANA is the DB of particular system. The check itself is very similar to the checks that I introduced in my other blog: How to check whether your ABAP NetWeaver is HANA DB based? It is just a check of attribute n_is_hdb_system which is initialized in constructor of class CL_RS_UTILITIES (cl_rs_utilities=>n_is_hdb_system = rs_c_true). While the check return value true then messages like below are displayed:

·         Variant &1 skipped (not required for SAP HANA database)

·         Deleting the index is not necessary/useful for HANA DB systems

·         Building an index is not necessary/useful for HANA DB systems

·         No roll-up required for HANA DB systems

Then finally what we see in process chain monitor is nice log like following:

Useful links:

Online docu

HANA versions / revisions

 Last update:           22.2.2022

In this post I will try to summarize all versions of HANA that are (or were) available per Support Package Stack (SPS) and covering revisions ranges. SPSs and revisions are fixes (corrections) shipped by SAP for the HANA product. SPSs are numbered incrementally starting from 000. They are normally released twice a year.

Meaning of version code:

Version: major_version.minor_SPS.patch/revision.build

A.BC.DEF.GH.IJKLMNOPRS

ABC - indicates major HANA version 1 or 2 currently

DEF - indicates minor HANA version - so called SPS level

GHI - JKL - indicates patch/revision

MNOPRS - indicates build

Examples:

1.00.122.12.1502962396    HANA 1 SPS 12

1.00.100-1.00.109             HANA 1 SPS 10 (every revision between 100 and 109 is SPS10)

 

HANA2 - SAP HANA PLATFORM EDITION 2.0

SAP HANA SPS       Release Date          Note             Revisions Range

SPS 06(12/2021)     03.12.2021             2945239       060 - 061

SPS 05(06/2020)     26.06.2020             2932865       040 - 048

SPS 04(04/2019)      05.04.2019             2656575       010 - 041

SPS 03(04/2018)     06.04.2018             2551355       010 - 033

SPS 02 (07/2017)     26.7.2017               2460914       020 - 024

SPS 01 (04/2017)     12.04.2017             2404375       010 - 012

SPS 00 (11/2016)     30.11.2016             2380257       000 - 002

 

HANA1

SAP HANA SPS       Release Date          Note             Revisions Range

SPS 12 (05/2016)     12.05.2016             2298750       120 – 122

SPS 11 (11/2015)     24.11.2015             2227464       110 – 111

SPS 10 (06/2015)     01.06.2015             2165826       100 - 109

SPS 09 (11/2014)     28.11.2014             2075266       90 - 97

SPS 08 (05/2014)     28.05.2014             2004651       80 - 85

SPS 07 (12/2013)     03.12.2013             1921675       70 - 74

SPS 06 (06/2013)     28.06.2013             1848976       60 - 69

SPS 05 (11/2012)     29.11.2012             1771591       50 - 58

SPS 04 (05/2012)     10.05.2012             1703675       40 - 48

SPS 03 (11/2011)     15.11.2011             1642937       30 - 37

SPS 02 (07/2011)     27.06.2011             1600147       20 - 29

SPS 01 (12/2010)      27.06.2011             N/A               10 – N/A

Initial Shipment Stack         N/A               N/A               N/A

 

 

There are different Revision Types for SAP HANA. The “Revision” refers to packages containing fixes for the SAP HANA core components (like SAP HANA Database, Studio, Clients, AFLs, LCapps, SDA, HWCC tool, etc). Here are different Revision Types:

1. Release to customer (RTC) Revision – new features and fixes, for early adapters and Non-production systems, released every 6 months

2. Standard Revision – incremental fixes, based on latest SPS feature set, for early adapters and Non-production systems, released on demand

3. Datacenter Service Point (DSP) Revision – incremental fixes, based on latest SPS feature set, released every 6 months after having run in SAP production system for 2+ weeks

4. Maintenance Revision – incremental critical fixes only, production systems (targeting planned and unplanned maintenance), released on demand provisioned for previous SPS between RTC and DSP only as of SPS10: provided after DSP for the current SPS

 

There is another term used within release management of SAP HANA. A ”weekstone”. The HANA weekstone is a build generated from source code every week. It is not released for customers and serves only for SAP internal purposes. Tests of the HANA like regressions and other tests related to quality happen on the weekstones. Once the particular weekstone passes all the tests it becomes Revision which is afterwards released to our customers/partners.

 

Useful information:

2115815 - FAQ: SAP HANA Database Patches and Upgrades

2021789 - SAP HANA Revision and Maintenance Strategy

2378962 - SAP HANA 2 Revision and Maintenance Strategy

1999997 - FAQ: SAP HANA Memory

SAP HANA Revision Strategy

How to check whether HANA or BWA are available?

Some time back I wrote two posts regarding how to find whether SAP NetWeaver system is HANA DB based and how to find BWA version. Here I’m going bit further on same topic and I introduce another small ABAP code snippet. 
This time it is about how to check on both whether the HANA and/or BWA are available in the system.

REPORT ZMM_HANA_BWA_CHECK.

* via class's attr - this is preferable way
IF cl_rs_utilities=>n_is_hdb_system = rs_c_false.
  WRITE: / 'no hana'.
ELSE.
  WRITE: / 'hana in place'.
ENDIF.

* via class's method
IF cl_rs_utilities=>is_hdb_system( ) = rs_c_false.
  WRITE: / 'no HANA'.
ELSE.
  WRITE: / 'HANA in place'.
ENDIF.

* via class's method
IF cl_rsddtrex_core=>get_trex_rfc_dest( ) IS INITIAL.
  WRITE: / 'no BWA'.
ELSE.
  WRITE: / 'BWA in place'.
ENDIF.

Source code available at: github.com/softy12/ZMM_HANA_BWA_CHECK  

Related posts:

How to check whether your ABAP NetWeaver is HANA DB based?

How to find BWA version?

Learn your BW in hard way

What is SAP S/4HANA

Today SAP announced during event hold at New York Stock Exchange (NYSE) venue a successor of their ERP flag ship product. I followed the event online and within this blog post I want to grab interesting facts about it. It is SAP Business Suite 4 SAP HANA or shortly as SAP S/4HANA or referred as SAP S4HANA. S stands for “simple”, 4 stands for 4^th generation and HANA stands for in-memory platform that can run entire company – a quote from Bill McDermott.

R/2 (1979) -> R/3 (1992) -> ERP (2004) -> S/4HANA (2015)

(Both pictures taken from twitter feeds)

Most interesting part of the event was conducted by Hasso Plattner. He explained like he was lecturing 10 years ago students at University of Potsdam about enterprise software (EnSw). As there was not much development in the EnSw area he wanted to create something new. Together with students they started by sketching of how new future EnSW should look like. They captured few rules like almost zero response time, simple DB model, less effort dedicated to maintenance of such a system, web/mobile like UI/UX etc. The research led to creation of new DB – in-memory, columnar store oriented and capable of processing both type applications (transactional and analytic) database. After two years of such a university research Hasso approached SAP and ask to develop such a DB. SAP started with some components like TREX (search engine), P*TIME (in-memory OLTP database), maxDB (in-memory liveCache engine). HANA was introduced to market first as database (approx. Nov 2010) later as whole platform (2011). Later SAP solutions like BW (BoH) and ERP started to be supported on HANA as on DB and even later SAP started to optimize these for HANA (SuiteOnHANA). Last year a first new part of ERP got optimized for HANA it was SFIN (Smart Financials), later renamed Simple Finance. In that one the FI module’s database module was rewritten just with few tables, removing all aggregates and indices. Today SAP Business Suite 4 SAP HANA was introduced where more ERP applications (old terminology would be SAP modules) were rewritten in order to be optimized for HANA. Here are its main features.

·        Reduced DB footprint – 1/10 because of simplified data model

·        3-7 higher throughput

·        Up to 1800x faster analytics

·        4x less processing steps

·        No locking, no updates, parallelism for throughput

·        Multitenancy

·        Unlimited workload capacity

·      Capable of running all kinds of the systems (ERP, BW, CRM, SCM, PLM) in one system – will be available as phased availability

·        Fiori UI – responsive for any device

·        Capable of processing all type of data: text, social, geographic, graph processing

·         Deployments possible as (public/managed) cloud, on-premise

·        Guided configuration – reinvented implementation guide (IMG)

·        No anyDB approach any more, it only runs on HANA DB

In short: S/4HANA is Business Suite designed to run on HANA with Fiori UI with focus on simplicity.

There are many questions opened on how the new S/4HANA will affect current SAP customers running e.g. ERP. It is for sure that SAP will support their software running on any DB from long term perspective. On other hand it is obvious that new features and innovations of their solutions will be delivered only for solutions running on HANA.

More information:

discover S4HANA