Comparing SAP BW on HANA vs. Native Reporting with SAP HANA: Q&A on Design, Optimization, and Troubleshooting

What are the differences when running SAP BW on SAP HANA vs. HANA native reporting? How does SAP HANA change your reporting solution architecture? SAP BW and HANA expert Dmitry Shustov of Xoomworks answered readers’ questions on evaluating and optimizing BW for SAP HANA and moving to native HANA reporting. Questions from readers included:

• For a new ERP implementation on HANA, should you even consider using BW or just report off Business Suite (or S/4HANA) tables?
• We recently migrated SAP BW to run on HANA, and have a lot of data models in BW. Going forward, do we model in native HANA using HANA views or continue to model in BW?
• What are implementation pitfalls for SAP HANA?
• Are there scenarios where native HANA reporting does not compare well to BW on HANA?
• How does performance of a BEx query and BW connection compare to a direct Hana View connection?
• With SAP HANA, do you see SAP BW being sunsetted in the future?
• For a solution requiring native HANA models and data in a BW schema, do you recommend reporting via BW or via direct connection to HANA?
• Do you recommend SLT to replicate to the HANA database or to BW providers?
• What are differences between HANA Analytics views and composite provider in SAP BW 7.4?
• Should we model in the BusinessObjects universe layer if underlying data models are in native HANA?

Transcript

SAPinsider: We’ll kick off our Q&A in just a few minutes. Your posts go to our moderator, Bridget Kotelly, conference producer for BI and HANA 2015 in Nice and our upcoming conference in Singapore.Taking your questions today is BI and HANA expert Dmitry Shustov of Xoomworks.

Bridget Kotelly, HANA and BI 2015: SAP HANA brings changing reporting options: How does BW on HANA compare to native HANA reporting? What is the impact on your architecture, modeling, and long-term planning? We’ll take your questions on these options with Xoomworks’ Dmitry Shustov. Dmitry is now a Principal Consultant at Xoomworks, and previously spent over seven years with SAP as an SAP BW/HANA expert.

Dmitry, thank you for joining us today!

Dmitry Shustov, Xoomworks: Hello Everyone!

Welcome to this Q&A session about BW on HANA and HANA native reporting. I hope you will enjoy it. Feel free to post your question during the next 60 minutes. During this time I’ll try to answer as many questions as possible. Other questions will be answered in final Q&A script and posted in a few days after the session.

Bridget Kotelly: Dmitry, before you dig into readers’ questions, can you just give a quick overview of the differences between BW on HANA and native reporting with SAP HANA?   

Dmitry Shustov: Customers running BW on HANA in addition to classical BW reporting, have possibility to do reporting directly on HANA. In case of BW on HANA reporting tool is connected to BW application server using one of the supported (high-level and application-specific) protocols like BICS. BEx query is used as a data provider, thus leveraging BW OLAP engine for calculation or orchestration.
And in case of reporting directly on HANA (so-called HANA native reporting), the reporting tool is connected directly to HANA DB using one of the DB native communication protocols and reporting is done on top of modeled HANA views or DB tables/views.

Bridget Kotelly: Thank you for starting us off. Now we’ll let you get to the questions that have already been posted by readers!

Comment From Marla

Is it OK to apply support packs to the ECC system at the same time as the implementation of BW on HANA and a BW 7.4 upgrade? Or should these efforts be completed separately? 

Dmitry Shustov:  I don’t see dependencies here, but in order to be on the safe side I’d still recommend consulting corresponding Upgrade Guides and checking the SAP Notes mentioned there.

Comment From DK

What would be the business benefits or use cases for company having SAP BW on HANA and also using native HANA for reporting?

Dmitry Shustov: If I understand it correctly the question is “Why would a customer running BW on HANA want/need to do reporting directly against HANA?”

If so, then I see a couple of reasons:

• If performance of particular report is critical, then reporting on top of fine-tuned and tailored HANA model via native DB communication protocol, in many cases, will provide better performance rather than, e.g., reporting on BW BEx query (OLAP engine) using BICS protocol.
• Using a reporting tool (SAP or third-party) that doesn’t have option of connecting to SAP BW but supports direct connection to HANA (or another DB).

Comment From Francois

There are rumors that BW will soon be dead because of HANA reporting and also because of SAP’s need to push and sell SAP BI4 tools. Do you know if SAP will keep doing upgrades on BW? 

Dmitry Shustov: BW is not (only) about reporting. BW is an EDW application which now can also run on top of HANA and leverage its service. It delivers corresponding services like extraction and load, consolidation, harmonization, integration, etc., of data from various SAP and non-SAP data sources for reliable reporting and analysis. There is also a set of integrated tools for monitoring, scheduling, lifecycle management, and security.
Another thing is that not all reporting applications actually need this. Sometimes is sufficient just to build a data mart to address particular business questions or problems. But when it comes to consolidated and integrated reporting or creating reports for regulators (which must be based on reliable data) then EDW with all its service comes into play.
Of course you can build it on HANA yourself and then you don’t need BW. But do you actually want to invest in this process?

Comment From Devaraj

With SAP HANA, will SAP BW be sunsetted? I am interested in knowing if SAP BW will exist standalone in the near future.  

Dmitry Shustov: According to signals from SAP, BW is definitely not going to disappear. There is a lot of ongoing development and new features are introduced with each new release. It also will remain available for other DBs, but many new interesting features are available only when BW is running on HANA. This should not be considered as the way to push a customer to buy HANA. It’s just because these features are based on services provided by HANA and not available in other DBs.

Comment From Wanda

If BI 7.4 is already in use, what would be the benefit of getting rid of the BI landscape and running all reports solely using HANA? Are there any additional overheads/costs associated with retaining the existing BI landscape?

Dmitry Shustov: If you are talking about SAP BusinessObjects BI then I don’t see how HANA and BW 7.4 change the picture. SAP BusinessObjects BI is positioned by SAP as the main set of tools for a different flavor of reporting and analysis of data stored in BW, HANA, and other data sources.

Comment From SAP HANA CDS

How does SAP HANA CDS (Core Data Services) influence SAP BW on HANA vs. native reporting on SAP HANA?

Dmitry Shustov: CDS is just the way to define database persistence model (tables, views, joins etc.) in HANA. It’s mainly used for native HANA application development. I don’t see how it may influence BW on HANA reporting, where the model is generated automatically by BW.

Comment From RamiE

Is there a difference in the LSA architecture model for SAP BW on HANA vs. native HANA?

Dmitry Shustov: I don’t consider HANA as an EDW and am not aware about LSA for HANA. I’m aware about LSA for BW on HANA and there is definitely a shift comparing to classical LSA for BW on conventional DBs.

Comment From Nabin

Story of the implementation path: What are the potential pitfalls and where we need to concentrate our efforts? Any real-life examples of engagements and durations?

Dmitry Shustov: This is quite broad question. From a project perspective, I don’t see much specific to HANA-related projects. As an example, I can say that PoC projects with limited scope normally take 1-3 months. Migration of BW system to HANA is normally done in the range of 6-12 months, depending on the size and complexity of the system.

Regarding possible pitfalls I’d mention the following:

• Getting HANA hardware may take quite long time and from my experience caused delays in many projects. So I’d recommend considering it and be realistic in your expectations and estimations.
• HANA sizing is very important and quite hot topic in many projects. Systems are often undersized and/or sizing does not taking into account future growth — or projects/applications/business processes which were not planned to be moved/implemented in HANA suddenly realize that they also want to leverage it and get the benefits it offers.
• If we are talking specifically about migration of existing BW system on HANA, then in many cases the capacity of BW application servers is not taken into account and sizing not reviewed. It’s reasonably assumed and expected that the load on BW application servers will be reduced as far as many (heavy) processes will be pushed down from application server to HANA. But in fact often we observe different picture. The load on the application server actually may increase after migration to HANA. The reason for this is that HANA returns data to application (much) faster and users tend to perform more actions (e.g., navigation in reports) in the same period of time then it was done before.
• Last but not least is the expectation around HANA and related projects. Business often expects that all existing applications implemented or migrated on HANA (BW/HANA) will automatically run 10, 100, 1000 times faster than before. This is not really the case — but not because HANA is much slower than it’s promised and expected. In most cases on top of HANA DB there is a stack of component and technologies which are involved in processing of user requests. There may be several application servers, network, some middleware, front-end etc. If most of the time is spent not on DB but somewhere else, then migration on HANA and improving DB time won’t change response time radically.

So there should be clear understanding about which application may and will benefit from HANA and which will not.
Another question is that some applications may benefit also from pushing down the logic to HANA, but this requires additional analysis and consequent implementation efforts.

Comment From Andrea

So if I understood this well, you are saying that for a customer running on BW, the migration to BW on HANA may not lead to better performance even if you make a correct sizing of your HANA appliance? 

Dmitry Shustov: Yes, at least not for all scenarios and/or not out of the box.

Comment From Guest

Hi Dmitry, Can you briefly go over SLT replication? We have migrated to BW on HANA but the target state is to slowly lift and shift to improve financials reporting. We are debating whether to use SLT replication to replicate to HANA database or to use BW providers.  

Dmitry Shustov: I think it’s easier and more flexible to replicate data to tables in HANA, create views on them, and expose to BW for reporting.

Comment From Madhav

What are the scenarios where native HANA does not fare well compared to BW on HANA from a reporting perspective? 

Dmitry Shustov: I cannot say that native HANA may not fare well in some scenarios. I’d say that BW as EDW delivers a set of services that are required by some of you reporting applications or use cases and which not available in HANA out of the box.
It’s also a matter of time and effort to implement something from scratch as a native HANA solution or build the same in BW using its data modeling, query design capabilities, and features/services of OLAP engine (Analytic Manager). This is especially the case if you previously have invested a lot in BW – building data models, BEx queries, etc.

Comment From MK

We recently migrated our SAP BW system to run on HANA. Going forward, do we model in native HANA using HANA Views or do we continue to model in BW (we have a lot of data models already in BW)? What are the pros and cons with either approach? What is SAP’s direction for the future of BW? 

Dmitry Shustov: You can continue using reporting on BW in most of your reporting applications, and report directly on HANA in the case of challenging performance requirements or using the tools which can’t connect to BW. But even with BW reporting, you still may want or need to leverage HANA Views and expose them to BW.

Comment From RamiE

In the case of native HANA reporting, where does the semantic layer reside, assuming that the front end is BusinessObjects tools (e.g. Analysis or WebI)? As you know, in BW it can be at the BW query level and utilized by BusinessObjects tools via a BICS connection without the need to create a BusinessObjects universe with the semantic layer and different type of connection.

Dmitry Shustov: I’d say that in case of native HANA reporting, the semantic layer mainly resides in modeled HANA views (Analytic view, Calculation view).

Comment From Guest

For a new ERP implementation (on HANA) should you even consider using BW or just report off the Business Suite (or S/4HANA) tables?

Dmitry Shustov: You can do reporting directly on Business Suite HANA. But this is a very simple use case. You would need BW in cases where you need to do consolidated reporting across multiple SAP and non-SAP data sources.

Comment From Pooja

Is it recommended to do any modeling in the BusinessObjects universe layer if the underlying datamodels are in native HANA? Are there any plans to eliminate the universe layer from BusinessObjects?

Dmitry Shustov: You can still do some modeling on the universe layer, but you should keep in mind that in this case you won’t (fully) leverage push-down to HANA. It’s preferred to put as much logic as possible into the HANA model. From what I know, CR already has the option for direct connection to HANA and it’s also planned for WebI.

Comment From Francois

Consider a CTO who mandates that operational reporting should be done with HANA, in order to get real-time reporting. So for new projects they do not want to have BW, which they consider more for decisional reporting as an EDW that can contain SAP and non SAP data. (I have read that non-SAP data should not be more than 20%.)  

Dmitry Shustov: You can also use BW for real-time reporting. Just replicate tables, created HANA views on them and expose to BW.

Comment From Francois

Will BEx still be used as the query designer tool in the next years, and can it be used directly on HANA views?

Dmitry Shustov: The next-generation Query Designer is implemented in Eclipse as a part of BW modeling tools. It already available but functionality is still limited. However, in the future, it will fully replace the current Query Designer. For HANA views there is a good modeling environment — HANA Studio — and I don’t see a reason why it would be replaced in the near future.

Comment From Irmantas

Do you see lot of differences between HANA Analytics views and Composite Provider in SAP BW 7.4? 

Dmitry Shustov: Composite Provider is quite limited compared to HANA AVs. It can do joins and unions between various providers in BW. Right now it’s considered as a replacement for MultiProvider to be used in the Virtualization (Reporting) layer.

Comment From RajaRam

For a solution requiring both native HANA models merged with data in BW schema, which approach would you recommend as a long-term strategy: Report via BW (using transient/virtual providers etc.) or report via HANA directly connected to reporting tool? 

Dmitry Shustov: If there are no special performance requirements to a particular application, I’d recommend reporting on BW, exposing data from HANA (if necessary) using CompositeProvider.

Comment From Guest

What are the training courses for SAP BW on HANA? 

Dmitry Shustov: If we are talking about official SAP training, then from what I know at the moment there are quite a number of pure HANA training courses and one course covering specifics on SAP BW on SAP HANA. They can be easily found on the SAP Training and Certification portal where you can check the availability of a particular training in your location and possible delivery options.

There is also an openSAP course on SAP Business Warehouse powered by SAP HANA available for free.

Comment From Guest

Are there license cost considerations if we want to extend our BW on HANA solution with the HANA native offerings?

Dmitry Shustov: From what I know, you may have HANA licenses only for running BW on HANA but without the possibility to create native HANA models. So if you currently have this one, then you will probably need to extend it.

Bridget Kotelly: Thanks everyone for joining today’s chat. Dmitry is still reviewing a few last questions, and will  include additional questions in our online transcript.

Editor’s note: Below are the additional questions that Dmitry reviewed after the Q&A for inclusion in the transcript.

Comment from Guest

Articles I have read suggested that running BW on HANA improves performance from both query runtime and loading, so it is news to hear from you that it is not the total truth?

Dmitry Shustov: HANA can(!) improve performance of loading, reporting and planning. This is absolutely true.
What I wanted to say is that there may be processes/applications that can’t be improved by HANA at all or to the extent expected. I’ve seen many cases when migration to HANA was done with the objective to significantly improve performance of one or several particular applications/processes (loading, reporting etc.) without performing their preliminary analysis, and due to various reasons this didn’t happen.
Some processes can benefit from migration on HANA automatically (but they might still can be improved further), and there are processes that won’t benefit from migration on HANA automatically but can be improved after performing some adjustments, optimizations etc.
Some processes actually might even perform worse after migration to HANA than before without some essential adjustments/tuning – for example, when you have some custom ABAP code which is not optimized for HANA.
At the same time, you should not forget that HANA allows implementing some processes completely differently, so you can get rid of some persistency layers and as a consequence remove corresponding loading processes, etc.
Thus even if the process/application in its current design cannot be improved by HANA, it can be reviewed and redesigned in completely different way and thus achieve radical improvement. But obviously it requires additional time and efforts.

Comment From Ronan BIZEUL

Have you done a performance comparison between a BEx query – BW connection and a direct HANA View connection? 

Dmitry Shustov: In most cases, direct connection to HANA is faster and this is fully understandable. BW delivers additional services, but the price for it is performance.

Comment From Saubhagya

What are the advantages of HANA over BW in terms of reporting? How are BW hierarchies handled with HANA?

Dmitry Shustov: Creating HANA views gives more control to the developer and allows creating more tailored and fine-tuned data and calculation models compared to a BW OLAP engine based on BEx query design. Direct connection of reporting tool to HANA normally leverage leaner database-native protocols compared to high-level protocols like BICS, which are used for connection to BW.
As a result HANA native reporting application may demonstrate (much) better performance rather than similar BW reporting.
I think nowadays this is the main benefit and reason why you might want to develop a particular reporting application as HANA native even though the required time and efforts may be significantly higher than in the case of BW.
At the moment, BW hierarchies cannot be leveraged in HANA — at least not automatically out of the box.

Comment from Michael Brondt Kjaer

In my mind BW is a much more controlled environment then native HANA like you also mention. Do you have any recommendation on how to be in control of HANA native-based reporting when the number of views grows over time?

Dmitry Shustov: I’ve seen many BW systems which also didn’t look organized, integrated, consistent, etc. I think in the first place it’s a question of proper governance, and only then tools, services, and mechanisms that are offered by the system (whether it is BW or HANA) can help to manage and control the environment.

Comment from Mitesh Vijayvargiy

With multi-tenancy options from HANA SPS10 onwards, multiple systems (ECC, CRM, BW, etc.) could run on one HANA instance. Together with additional features like SDA/SDI, data federation accessing data from disparate sources without replicating, and a few others, what’s the recommendation or pointers to consider for choosing the reporting solution – BW on HANA or native HANA?

Dmitry Shustov: I believe that even with all these features you mentioned BW is still relevant here as an integration point where you create and store your central data warehouse models, streamline semantics etc. This data model can be, to a large extent virtual (i.e., actual data persistency can be still in originating systems and all required adjustments, conversions, and transformations can be done on the fly). Probably this is the vision and the future we are moving to.

Regarding reporting itself – BW or HANA native – this question is discussed in this Q&A multiple times and I hope it’s answered already.

Comment from Guest

Is it possible to call HANA SQL from a BW user exit in a transformation or start routine?

Dmitry Shustov: It’s not very clear what do you mean with HANA SQL here. When you are programming in ABAP it’s recommended to use Open SQL (set of ABAP statements for database access), which is database agnostic and can be executed on any DB that is supported by NetWeaver.
From this perspective HANA is no different here. What you could do in ABAP with other DBs you can also do with HANA.

In NetWeaver 7.4 SP5 and SP8, Open SQL was enhanced to enable some push-down to database. For details you may check the following articles:

https://sapinsider.wispubs.com/Assets/Articles/2014/October/SPI-where-ABAP-meets-SAP-HANA

https://scn.sap.com/community/abap/hana/blog/2014/01/22/whats-new-on-abap-74-sp5

Comment From Francois

Which replication tools do you advise using for real-time reporting with HANA views consuming BW? Will you use BEx to consume HANA views? No BW cubes needed?

Dmitry Shustov: To be honest I don’t know many of them – only SAP LT Replication Server (originating from SAP Landscape Transformation) and SAP Replication Server (originating from Sybase Replication Server).
In my practice I was working only with SAP LT Replication Server. I find it quite mature, reliable, functional, performant, etc. Nowadays it supports many combinations of various kinds of sources and targets, scenarios of replication – one-to-one, one-to-many, many-to-one, many-to-many – and also can perform simple transformation of replicated data. So it can cover broad range of use cases, including critical and throughput intensive.
For non-performance-critical scenarios, in most cases I’d still continue using BW and BEx queries for reporting at least, because I think it’s easier and faster to implement semantic and calculation logic in BEx Query Designer and leverage BW OLAP engine rather than develop them in modeled HANA Views. But there is no hard rule about it. You may have different considerations.
InfoCubes in BW on HANA are not required in the vast majority of cases. There might be still some limitations in DSOs (e.g., related to planning or non-cumulative figures), but SAP already resolved many of them and I believe is working on making DSO fully identical, from a functional perspective, to InfoCubes. This replacement will probably be accomplished in Advanced DSO (aDSO).

Comment From Thorsten

What’s the best way to do real-time reporting using BW on HANA?

Dmitry Shustov: The best way of course may vary depending on your particular situation and requirements. I can say that replication using SAP LT and HANA SDA are already proven technologies to serve this requirement.
With SAP LT you can replicate data into tables in HANA managed schema, build views on them, and report directly on these views or expose to BW for reporting. You can also replicate data into BW but from my perspective this approach is less flexible and reliable and requires some more effort for implementation and operation.

Comment From Ronan BIZEUL @Decathlon

Hi Dmitry, we are currently thinking about working on a hybrid scenario: HANA Live in sidecar with BW on top of it. Where shall we handle the master data: in BW and publish it via a HANA view or handle them directly in HANA?

Dmitry Shustov: If you are going to have more than one system then I’d do that in BW. In case of only one source system you may consider both options, whatever is easier for you.

Comment from S4HANA

When I am seeing the reporting functionality in S/4HANA, I am guessing that sidecar will still be a good platform for handling reporting. Do you think sidecar (HANA native) will then move to S4HANA? Dmitry Shustov: I think that at least there will be such an option. Another question is whether you would like to do operational reporting directly on top of the ECC system or replicate data to, for example, some central BW system.

Comment From Aga

If I don’t have SAP ERP but I have multiple ERP systems and I want to build a data warehouse where I can consolidate the data, would BW on HANA or native HANA be a better choice?

Dmitry Shustov: As I mentioned earlier in the Q&A, I don’t consider HANA as EDW solution. It perfectly fits for the purpose of sidecar scenarios or siloed data marts, but if you need to build relatively complex, integrated data warehouse, I would consider BW (on HANA) as a proper tool for this.

Comment From Paul Tikhonov

Which tool would you recommend for ad hoc reporting against HANA?

Dmitry Shustov: The term ad hoc reporting is widely used but not actually strictly defined.  So everyone has his own picture in mind about how it should look like, which functions and features should deliver etc.
Selection of the tool depends on many factors like requirements, users’ preferences, skills, experience, system and reporting landscape.
What I can definitely say is that HANA greatly simplifies scenarios where BW data needs to be combined with some external data for processing, analysis, and reporting. I know it was possible with BW Workspace, but that was not very popular due to various reasons. SAP Lumira looks like a quite suitable reporting tool for such use cases.
Other tools you may have a look at (again, depending on requirements of a particular scenario, users’ preferences, etc.) are Analysis for Office and SAP BusinessObjects Explorer.

Comment from Mitesh Vijayvargiy

BW on HANA has options, like NLS  and dynamic tiering for managing huge data volume as well as data growth, which are cost-effective. Now what options does native HANA bring when it comes to huge data management and reporting?

Dmitry Shustov: It’s clear that storing all data in HANA (in memory) is hardly feasible or at least would be too expensive. At the same time, with hot topics on the agenda such as Big Data and Internet of Things, just storing large volumes of data passively is also not sufficient. It must be easily accessible for processing, analysis and reporting.
SAP definitely takes steps to fulfill these requirements introducing and enhancing various features that help in data lifecycle management, temperature management, federation, etc. One of them you already mentioned is Dynamic Tiering, which is actually a HANA (native) feature leveraged by BW.
Another is well-known HANA data vitalization/federation technology – Smart Data Access (SDA). It’s worth mentioning that in latest HANA releases it supports integration with various Big Data related products, tools, and technologies.
Recently SAP introduced the SAP HANA Data Warehousing Foundation option. One of its core features is Data Lifecycle Manager – an NLS-like solution for HANA native use cases. It supports relocating data using the SAP HANA Dynamic Tiering option or SAP IQ and seamlessly integrating it with data stored in memory for processing and reporting.

Comment From Mitesh Vijayvargiy

I would be interested to know about the comparison for choosing between BW and native HANA with the following parameters:

1. Is there any difference when it comes to the number of concurrent users supported for reporting with system stability?

2. Which is faster when it comes to overall development/implementation time frame – BW on HANA or native HANA reporting?

3. Is there any price/performance matrix available, or how does each fare when it comes to price/performance?

Dmitry Shustov: 1. If you compare BW/HANA and native HANA, then I don’t see any difference for concurrent users. Scalability of the application server can be considered as almost unlimited. Scalability of HANA is limited by available configurations – amount of memory or number of CPUs. But hardware vendors and SAP are constantly working on shifting these limits to new levels.

2. When we are talking about dedicated data marts or sidecar solutions, then building it as a HANA native application would probably be faster. But when it comes to a complex integrated solution, then BW looks more appropriate, especially from a long-term perspective.

3. I haven’t seen such a matrix.

Comment from Francois

Can you expose best practices regarding SAP operational reporting for HANA Live vs. BW? And which ETL or replication tool is best?

Dmitry Shustov: It all depends on your particular situation – requirements, resources, landscape, experience, etc.
What I can say is that technically everything is there to set up real-time operational reporting. You can do reporting directly on the source system; or replicate application tables with SAP LT to HANA or use HANA SDA. You can leverage HANA Live views, and adjust them or develop something from scratch. You can do reporting directly on HANA or expose HANA views to BW and do reporting via BW.

Comment From Guest

Any benefits for native HANA data warehousing/reporting versus BW on HANA? Any limitations on data warehousing/reporting on HANA native versus BW on HANA (for example, exceptional aggregation, other BW/OLAP features, etc.)?

Dmitry Shustov: Some of these questions were already answered earlier, but I can add something on limitations:
Basically when we are talking about limitations of HANA native comparing to BW and which BW features are supported or not, we should understand that it’s about whether we can get it out of the box when we generate HANA views for BW objects or not.  (You can check the details in the documentation.)
But if something is not supported, it doesn’t mean that you can’t do this in HANA native at all. You still can model something similar by yourself, but of course it will require time and efforts.

Comment From Guest

As I understand it, if you are licensed for BW on HANA it is not possible to use native HANA views. Is it necessary to get a HANA enterprise license to cover the volume of data in BW or just for the in-memory views using in native HANA which will be much smaller?

Dmitry Shustov: Licensing of SAP products is quite complicated topic in general. There are many details and things to consider. And for such intensively developed product as HANA it may be also changed quite frequently. I don’t want to be incorrect, incomplete, or not up-to-date here and therefore strongly recommend addressing this question directly to SAP.

Bridget Kotelly: As we come to the end of today’s Q&A, I want to thank you for joining us, and invite you to view past Q&As from Dmitry’s Xoomworks colleagues Johann Kottas and Tom Kornfeld, along with other expert advice on our BI channel. And I hope to see you at our upcoming BI and HANA 2015 conferences
And I hope to see you at our upcoming BI and HANA 2015 conferences – next in Singapore!

Dmitry Shustov: Thank you all very much for attending this very enjoyable Q&A. There were lots of interesting questions which I hope I managed to answer to your satisfaction. The question which were not replied during this hour will be replied and posted in the final script. Please do not hesitate to contact me at bi@xoomworks.com.

Comment From Francois

Thanks Bridget & Dmitry for the great chat.

SAPinsider:  Glad you could join us, Francois! And thanks to all for the great questions! Cheers!