How to gather requirements and Implement for NON-SAP sources data in HANA

[Former Member]

Hi HANA Experts,

In this blog, I want to share my experience and approach to gather requirements and implement for NON-SAP source data in HANA.

HANA has the interoperability strength for various NON-SAP sources like ORACLE, MSSQL, and DB2 by supporting those data types.

Majority of HANA folks are traditionally from SAP background like ABAP, BW would have strong insights of tables and their relationships between those tables.

In case, if we don’t know the table names and relationship in SAP, still there is SD11 T.code for providing the information. 

Problem arises, when there is requirement to report/model on NON-SAP source.

How do we gather requirements from Business and Typical IT Non-SAP super users?

Below are the few points, which may help in our implementations:

Initial and most crucial step during the implementation is determination the type of data replication methodology to be used.

We know that there are several ways to data replicate like SLT, DXC, SAP data services and Sybase replicator.  I will not get into the best options and procedure of this various replications. 

DXC is not possible for Non-SAP sources systems.  Depending upon on various factors, we choose either of one option SLT, SAP Data services and Sybase replicator.

Once the data replicator is decided, next major steps are to be worked with NON-SAP source team:

     1. Identify the required tables, fields and joins between various tables. (very crucial step)

     2. Identify the measures and key attributes.

     3. In case of real-time reporting, either SLT or Sybase replicator will be opted.

Once the tables are in HANA, then next important step is to identify the JOINS between the tables.

Join type like Inner, left outer, right outer, full join will have different result sets. So it is next very crucial step in the modeling the HANA objects.

After the identification Tables, attributes, key attributes, measures, next step is data modeling in HANA, based on the requirement design the attribute, analytical and calculation models. There after reporting using some reporting tool like BO.

Looks simple, but many problems arise during implementation and also want to share common issues faced and checks to applied for NON-SAP source data.

Common Issues faced with NON-SAP source data:

1. Identification of Primary keys in different data sources.

  •       Identify the primary key and convert them into proper data type like string, date , numeric . example Account number, sales order might be different size and type. 

2. Challenge to synchronize data types.     

• Date format of Oracle, GDW were different formats when compare to SAP and they were appearing as text.

3. Make proper, common formats/types for fields like currency , amount and date.

CHECKS to any for NON-SAP source:

COLUMN TABLE CHECK: Ensure that every table created for NON-SAP source system should be COLUMN table type.

FIELD CONSISTENCY CHECK: Ensure every field created in the table from NON-SAP Source system, which is used to merge with SAP system field should be same and common data type. As best practice convert into SAP field format.

SCHEMA CONSISTENCY CHECK: Ensure Schema names across the different HANA systems (Like PRODUCTION, DEV and QUALITY) are same and it will be helpful for the easy maintenance of the models.

I hope you had good reading and please provide comments on this blog. In my next blog, I’m planning to brief about the best practice and naming standards.

Regards,

Santosh.