performance architecturefora custom abap applicationon hana · documents 8,5 mio. document...

Performance Architecture for a Custom ABAP application on HANA

Agenda

2 Dr. Burghard von Karger, Salt Solutions AG

1 Showcase: Condition Management at Ottogroup

2 Software Architecture

3 Migration to HANA

Effect on Performance

Changes to Architecture

Agenda




3 Migration to HANA



KKM ( = Enterprise Condition Management)


KKM

Contracts

InvoiceDeductions

Reporting

OrdersInvoices

Business objectives• Contract management• Settlement of conditions• Supplier Notifications• Incidence Management

Technical Responsibilities• Data Storage and interfaces

company systems• Movement Data: Invoices, Orders• Master Data: Articles, Suppliers,

Conditions

Customers of KKM

5

Technical Key Figures

6

Interfaces

60+

Suppliers

8.600

Contracts

25.000

Articles

20 Mio.Documents

8,5 Mio.

DocumentPositions

110 Mio

Settlement Results

455 Mio.

Reporting Facts

1 Mrd.Database

2,6 TB

KKM Users

160+

Man years

>40

Interfaces

60+

OKM (Operative Condition Management)

7

OKMSupplierSupplierImport

ArticleImport

OrderImport

InvoiceImport

Suppliers

Articles

Orders

Invoices

SettlementSettlement

Contracts SupplierNotifications

Settlement Results

Reporting Data

Mail

FI Export

SKM ExportSKM Export

SAP ERP

Companies

ContractManagement

(FI-KM)

Supplier

Companies

SKM

Agenda


1 Invoice Verification and Optimization at Ottogroup


3 Migration to HANA



2.1 Persistence Layer

9

• All Business Data are modelled in the OOP Paradigm

• The persistence layer performs theobject-relational-mapping betweendatabase rows objects

Dr. Burghard von Karger, Salt Solutions AG

Responsibilities of the Persistence Layer

10

• Maps objects to table entries

• Decouples business logic from database

• Enforces Integrity Constraints

• Caching

• Data Change management

• Data versioning


Persistence: Technical Realization

Dr. Burghard von Karger, Salt Solutions AG11

IO-Class:• Manages loaded rows and status

Factory:• CRUD-Operations• OR-Mapping & Caching• Persistence of changes• Can be mocked by an in-memory-

version

Business Object:• OO-encapsulation of a database row

Database Persistence LayerIn-Memory-Persistence Layer

In-Memory-Persistence for Unit-Tests

12

InvoiceOrder Contract Condition

DatabaseInterne

TabellenInterne TabellenInternal

Tables

...


In-Memory-Persistence Layer

In-Memory-Persistence

13

InvoiceOrder Contract Condition

Interne TabellenInterne

TabellenInternal Tables

...

Benefits

• Reproducible

• No side effects

• High Performance


Service Layer


Service-Class• Contains process-independent business logic• Re-usable across processes• Example: Incident Generation

Service-Factory:• creates services• Amenable to mocking

Background Processing Framework


Job:• Selects data to be processed and creates work items• Creates and starts process instance for each work item• Controls parallel execution of work itemsProcess:• Processes one work item and updates its state in the work item table

Processing Pipelines

16

If processing can be split into stages, the stages can bepipelined

IDoc Stage 1 Stage 2Import Aggregate Business

ObjectEnrich

IncidentCockpit


Agenda




3 Migration to HANA



Migration to HANA: Technical Architecture


Legacy Architecture

§ Database (Oracle) and Netweaver on same server

Target Architecture

§ Database (HANA) and Netweaver on separate servers

Benefits:

§ Easier Maintenance

§ No performance side effects on each other

§ Backup/Recovery-Strategy

System Komponente Version

Applikation Server (Productive)

CPU 16 Cores

Memory 64 GB

SAP HANA Server (Productive)

CPU 72 Cores

Memory 3000 GB

Application Server:Netweaver AS ABAP

SAP HANA

Network

Migration to HANA: Legacy Architecture


Otto Systems

Finance

Movement andMaster Data

Settlement Profits

Migration to HANA: Target Architecture


Otto Systems

Finance

Movement andMaster Data

Settlement Profits

SAP HANA

Benefits• No more data duplication (ETL); OKM and SKM use the same data• Better Performance thanks to “In-Memory” Technology

Agenda




3 Migration to HANA



Migration of Business Processing


SKMOKM

Oracle DB

Netweaver AS ABAP

Teradata

SAP BO

SKM Logic

SKMOKMNetweaver AS ABAP

Teradata

SAP BO

SKM Logic

SAP HANA

Business Logic

Database tables

− The first migration step simply replaces the Oracle DB with a HANA DB.

Memory Usage

23

Kennzahlen


Custom Code

Classes CustomTables

Indexes Data

Performance – Individual Record Processing

24

Without specific optimizations HANA Performance may be worse

Process Step Optimized for HANA Time HANA Time Oracle Speed up

Data import no 8,64 sec 5,00 sec -73 %Data import yes 3,02 sec 5,00 sec 40 %Document Creation no 1,25 sec 1,50 sec 17 %Document Creation yes 1,10 sec 1,50 sec 27 %Immediate Settlement no 8,16 sec 8,04 sec -1 %Immediate Settlement yes 6,32 sec 8,04 sec 21 %


Performance – Data Retrieval Processes

25

The performance gain in user-driven processes such as the display of the profit overview is significant.Further gains via code pushdown seem possible.

LIFNR BUKRS Year #positions Time HANA Time Oracle Speed up

0020038817 0101 2010 136.567 51 sec 244 sec 478 %0010035978 0602 2015 484.747 131 sec 494 sec 377 %0010034177 0101 2015 441.842 413 sec 1086 sec 263 %0050014135 0581 2015 280.839 465 sec 1860 sec 400 %0010020070 0581 2015 204.487 382 sec 718 sec 188 %0010025085 0101 2015 1.876 7 sec 23 sec 328 %


Performance – Background Processing

26

Large gains for KKM‘s most critical task (end-of-period settlement runs)

ZLKZ BUKRS Jahr Anzahl Positionen Dauer HANA Dauer Oracle Speed up

0050014618 0581 2015 164.521 8.289 sec 219.691 sec 2.650 %0010020070 0581 2015 204.487 7.380 sec 144.420 sec 1.956 %0010105600 0581 2015 169.989 11.959 sec 125.875 sec 1.052 %0050014849 0581 2015 186.651 7.325 sec 108.753 sec 1.485 %0050000362 0602 2015 122.902 3.549 sec 102.421 sec 2.070 %0010634800 0581 2015 143.938 2.987 sec 94.668 sec 3.169 %0010195600 0321 2015 13.952 1.165 sec 41.012 sec 3.520 %


Migration of Reporting


− This was the original design

− Reporting was supposed to run in real time on transaction data produced by OKM

− We found that HANA performance is NOT sufficient for aggregating business data which is distributed across manytables in third normal form

SKMOKMNetweaver AS ABAP

Teradata

SAP BO

SKM Logic

SAP HANA

OKM SKM

SAP HANA

Netweaver AS ABAP

SKM Logic

SAP BO

Business Logic

Database Tables

Agenda




3 Migration to HANA



Architecture for Business Processing and Reporting on a single HANA instance


KKM

Importstage

Operative tables

Import

Settlement

Journals(Movement data,

supplier data)

Transformation(ETL with AMDP)

Source systems(e.g. F20)

HANA-Views

Master data

SAP BO /SAP AFO

SKM architecture

SKM User

Lessons learnt


• HANA performance is NOT sufficient for aggregating business data which is distributed across many tables in thirdnormal form

• Changing the relational model was not an option, because that would destroy the object-oriented architecture

• Code Pushdown to HANA seems also very hard to do without sacrificing the architecture.

Solution: create separate data structures for HANA (Journal)

- Persistence layer notifies Journal each time business data is changed

- Background process replicates changes to Journal

- HANA views operate on Journal.

Pros:

• Hana views are based on denormalized dataà good performance

• No impact on business processes

Cons:

• Requires extra memory for the journal

Contact


Marcus BehlingOtto Group ITProduct Manager KKM SAP Custom Solutions • PC-IT-AS-CS

Otto (GmbH & Co KG) Werner-Otto-Straße 1-7 • 22179 Hamburg

Phone +49 40 6461 [email protected]

https://www.xing.com/profile/Marcus_Behlinghttps://de.linkedin.com/in/marcus-behling-96764a60

Dr. habil. Burghard von KargerSenior-IT Berater

Salt Solutions AGCharlottenstraße 34, 01099 Dresden

Phone +49 174 [email protected]

mailto:[email protected]

https://www.xing.com/profile/Marcus_Behling

https://de.linkedin.com/in/marcus-behling-96764a60

mailto:[email protected]