Fresh BW on HANA approach

[Former Member]

Hello All,

I'm planning for fresh BW on HANA implementation. To begin with, we are planning to activate Hana optimized BI content. I see new concepts for LSA++.

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/28/a1065182d3c557e10000000a44176d/frameset.htm

So most of the reporting could directly be on DSOs. The PSA serves as the historical data foundation.

I read that future versions of HANA optimized BI content will have additional DSO layer so that we don't need to keep history in PSA.

Since its not available now, do you think we can proactively create an additional DSO layer for historic purpose and then another layer for actual reporting?

Any thoughts?

Thanks.

Abhijeet

[eduardorodrigue · Accepted solution]

Hi Abhijeet,

Actually as I see LSA++, as was the case with "classical" LSA, has to be understood and then implemented in each customers own reality. Having that said, I´d say you´ve got a few options:

1) you could create and additional DSO and then use first layer for historical data and second layer for reporting (please, remmember there are some limitation for non-cummulative key figures which requires the use of InfoCubes);

2) you could use one single DSO for historical data and reporting (once SAP HANA deals very well with high data volume). Additionally you could use SPOs in order to improve dataload and reporting times.

However, I´d recommed to think in a DW Architecture as a whole. In short, What does your company/your customer need as a architectural solution that will support current and future business needs. Having that broader view, you could conclude that would be a great idea to have a replication layer BEFORE applying business and harmonyzation rules that should be kept for a while, or that you would require a Corporate Memory to store data without transformation for life, then that you could consolidate all your business rules in a single layer, etc.

In short: I would recommed to have two DSO layer only if you have transformations in between that would justify that division. If you report today (and tomorrow) in raw data, you could live only with one layer from a "one scenario" standing point.

I hope it helps!

[former_member71289]

Hi Abhijeet,

you can definitely create your own DSOs as inbound / acquisition data layer if PSA solely does not fit your needs, e.g. if you need/want to add a corporate memory for your data in BW.

Good idea would be to use the BI Content InfoSources (e.g. /IMO/SD_IS11) as template for your DSOs (you only need to add the key definition and decide case by case if write optimized DSO is possible to use) and connect the inbound DSOs with the BI Content InfoSources via 1:1 transformations. Also the transformation between the Data Source and your inbound DSO will be pure 1:1 transformation rules (only exception: logical source system if applicable).

In the new HANA-optimized BI Content all the transformation rules (exception: logical source system) are applied between the InfoSource and reporting DSOs. This makes it very flexible for you to connect other data sources / source systems and add additional inbound DSOs with the content data flow (and you actually don't need a source system being connected to your BW system to be able to have a look into the SAP defined BI Content transformation logic ).

It would make sense to keep and use the transformations Data Source -> InfoSource -> 'reporting' DSO  for loading data directly into the 'reporting' DSO

and to load the data from the Data Source in parallel into the own created inbound DSO used as corporate memory.

In this case you would only load data from the corporate memory DSO into the reporting DSO in exceptional cases (e.g. changes to transformation logic between InfoSource and reporting DSO).

Best regards,

Andreas

[former_member184768]

Hi Abhijeet,

One comment:

Please look into the option of having a layer of write Optimized DSOs as the Inbound Layer and also for historical data and a layer of Standard DSOs with fully consumable data for reporting purpose. You can use the Active - Not active concept of data management and keep the Write optimized DSOs as "Not active" data, reducing your memory requirement.

Regards,

Ravi

[Former Member]

Thanks Ravi for your reply.

But write optimized dso's won't be useful for logistics delta..so in that case having first layer as "not active" standard dsos..can be used.

Basically still having first layer of dsos and next layer for reporting can be approach. Since not all the content is HANA optimized, I can rewrite some content routines between DSO layers...