Ramblings over Rank Node, ABAP vs HANA SQL Data types and Activation error for DSO with only Key Fields

Rank Node : We have new node type introduced in calculation views, Rank Node. This serves the same purpose of Exceptions from Bex. Instead of swamping  user with lot of data, we could restrict to display only TOP N values. The value of N could be fixed or based on a input parameter. In addition to Calculated, Restricted Attributes/ Measures , Rank node will further enhance OLAP toolkit of HANA Appliance.

 Temporal Join :

 ABAP vs HANA Native Data Types :  Every table in SAP will have two definitions. ABAP run time object and Database Object. From SE11, we can navigate to both and you can spot differences between them. reason being, ABAP Language  comes with some native data types. Examples being DATS, TIMS, CUKY, UNIT, CURR etc. These data types will mapped onto underlying Database native data types. Hence we have two representations of same object. Database interface helps us in converting Open SQL queries into underlying Database SQL.

Lets shift our focus to Importing BW models into HANA Studio. While we import, ABAP data types will be converted to HANA native data types. DATS will be mapped to NVARCHAR of length 8. Also all the DSO active, Cube underlying tables contains DATS as NVARCHAR(8).

This hinders us form using Temporal join to model Transaction data based on Time-Dependant Master data. Example being connecting Time-dependent Customer master data from Q table and Sold-to Party from Sales Line items DSO Active table. As Temporal joins works only with Fields of type SQL Date, Timestamp.

Enriching these tables with Time Dimension(Generated Time data) doesn't help us, as Temporal join requires the Key field coming from Key table of data Foundation and DATE_FROM and DATE_TO coming from other single table.

DSO active table. generating external HANA view from RSA1(PUSH) and Importing BW models into Studio(PUSH); all the ways we have DATS as NVARCHAR8.  We have gone ahead with Script based calculation to achieve.

DSO with only Key Fields(Weirdo): 

 This is peculiar situation we encountered. We have a DSO with only key fields and No data fields. As we moved onto BW 7.4 on HANA Rev 95, Change log started behaving differently, adding Before and after images although there is no change in key fields. As we are doing full load daily with 5 million records, it is adding daily 10 million records to change log and these 10 million will be considered while  loading it to data target. This shot up run times from 20 min to 3 hours. Previously while on oracle, DSO activation used to identify delta records correctly and populates Before/After for only changed records. With the new DB activation procedure, it seems the peculiar case of DSO with only key fields doesn't work. However adding a constant data field make it works fine.






Comments

Post a Comment

Popular posts from this blog

SAP V1 V2 V3 JOBS

Image
Before starting with V-series jobs, lets review some fundamentals. Data base LUW:  It consists of sequence of DB operations(INSERT,UPDATE,DELETE) that needs to be committed to either all or none to keep DB in consistent state. COMMIT will be executed when all DB operations were successfully executed, once COMMITTED these changes can't be ROLLED BACK. This is part of traditional ACID property of any RDBMS. If a failure happens while executing the LUW(will be mostly technical like memory crunch,integrity violation or data base crashed,power failure) and when DB is restarted, DB will be ROLLed BACK to previous state. Which is nothing but the state when last COMMIT was happened. In other words, when ROLL BACK happens DB will be safely brought to previous COMMIT state. DB maintains log of actions performed since last COMMIT and as part of recovery process, all these actions will be reversed. All RDBMS will have in-built locking/multi concurrency control such that dirty READ-WRITE ope...
Read more

Virtualization with SAP HANA

Image
Virtualization Most of Corporate Enterprise warehouse Eco system consists multiple disparate  Data warehouses. reason can be attributed to mergers and acquisitions,  departments using specialized software, databases choose to support specific data needs. All these scenarios result in building multiple data marts over multiple technologies. However, to serve the purpose of single source of truth, we end up building Enterprise Data Warehouse(EDW)  by sourcing data from various data marts across organization. One way of doing is, running a project for establishing standard ETL methods to extract data from regional Data Marts and staging data into EDW. However various departmental/ regional DW already contains highly formatted, information rich and aggregated data built readily available. This implies that we might not need to 1. Perform extensive transformations 2. Source data is meta data rich 3. Less data volumes will be retrieved from source systems Following trad...
Read more

Star Join node Vs Analytic view && Attribute View vs Calculation Dimension View

Analytic views comes with constraint that Measures should be coming from a single of Data foundation, although data foundation could contain any number of tables joined. Previously, we used model multiple Analytic views and combine them using JOIN node of an calculation view, in order to facilitate to Measures from multiple tables.  Star Join solves this by allowing measures coming from multiple tables. So we don't have to use multiple Analytic view to achieve this.  However Analytic views comes enriched with master data through Attribute views. To compensate this, We have Calculation Dimensional Models introduced. These artifacts are same as  Attribute views, but can only be used in a Star Join. So this solves out Master data enrichment issue while using Star Join. Introduction of Star Join Node and Calculation Dimensional Models  certainly introduces more uses cases for Calculation views and avoids scenario of creating multiple Analytic views for e...
Read more