The New Era of SAP NetWeaver BW powered by SAP HANA: Taking Advantage of LSA++

The New Era of SAP NetWeaver BW powered by SAP HANA: Taking Advantage of LSA++
Via Content in SCN

The New Era of SAP NetWeaver Business Warehouse powered by SAP HANA: Taking Advantage of The Power of LSA++

The SAP® NetWeaver® Business Warehouse (BW) powered by SAP HANA is a new, powerful BW capability built using in-memory technology that can help you address business issues and solve problems in ways not previously possible. You may be technically ready to implement SAP NetWeaver BW powered by SAP HANA, but is your organization ready to optimize the performance and value? Sound planning, including thinking about how you manage and model your data, can help you make the most of your investment.

The Pre-HANA World
Before SAP HANA, BW consultants routinely followed a layered, scalable architecture (LSA) methodology for building and structuring the business warehouse. The LSA methodology helped create a standardized approach that organized data by functional area, geography, and other key dimensions. It served as a referenced architecture for comprehensive data warehouse design giving the developers flexible data model layers which allowed for better long term scalability. LSA had several advantages:
It offered a standardized design and implementation methodology.
It structured the data into multiple, progressive layers.
It formed a transparent, service-level-oriented, and scalable base.
It defined key business indicators , such as net sales, within the data model.

LSA used years of SAP experience and best practices to create a common terminology built on enterprise data warehouse (EDW) principles. However, much of the LSA modeling was designed to work within the limitations of the Business Warehouse in the pre-SAP HANA world. When the volumes of information were too big to handle in their entirety, the data had to be aggregated and structured around verticals such as suppliers, partners, and customers creating less transparency across the whole organization.

Life now with SAP HANA
Leveraging SAP HANA as the underlying database for BW removes many o f these data limitations, making it possible to analyze huge blocks of transactional data without aggregations or layers of complex data modeling. The result: better business visibility and performance – but only if companies take advantage of the new capabilities. The unprecedented power of SAP HANA requires companies to rethink their data modeling methodology. As an evolution of LSA, LSA++ approaches data in a new way to take advantage of in-memory capabilities. We are able to simplify many of the complex data layers and optimize SAP NetWeaver BW which creates direct ROI for the value of your SAP HANA investment.

LSA++ Highlights
With LSA++, SAP NetWeaver BW on SAP HANA gives your business more flexibility via a simplified data modelin g approach which supports better decision making decisions and process efficiency. The framework allows for multiple business intelligence (BI) models plus both persistent and virtual data marts. LSA++ structures data by purpose or context with respect to BI requirements, resulting in three categories of data:

Consistent core. EDW context data includes standardized template-based BI and reporting on harmonized, consistent data.
Operational extension. Operational and source context data performs real-time BI on source-level data.
Agile extension. Agile, ad hoc context data includes agile BI on all kinds of data for single use.

The LSA++ model for SAP NetWeaver BW on SAP HANA gives you increased modeling flexibility, decreased load and activation time, and relaxed volume considerations during design. LSA++ also supports comprehensive data content and direct querying throughout the propagation layer.

SAP Services: Expert Planning and Implementation Support
Let SAP Services help you optimize your SAP HANA implementation with the LSA++ methodology. Whether you need initial advisory design or a complete implementation, SAP’s expert planning and installation services can help you streamline and accelerate data modeling.

To learn more about how SAP can help you deliver maximum business benefits, go to www.sap.com/services.

What would be the biggest benefits of LSA++ for your organization?

SAP BusinessObjects BI 4.x with SAP BW and SAP BW on HANA - Latest Documents

SAP BusinessObjects BI 4.x with SAP BW and SAP BW on HANA - Latest Documents
Via Content in SCN

I am using this blog post to update people on my latest documents that are available on SCN now:

Latest update on BEx Query Elements supported in SAP BusinessObjects BI 4.x is available here:
SAP BusinessObjects BI4 - Supported BEx Query Elements

Presentation outlining some important Best Practices for integrating SAP BusinesObjects BI 4.x with SAP NetWeaver BW and SAP ERP is available here
Best Practices for Integrating SAP BusinessObjects BI 4.x with SAP NetWeaver Business Warehouse (BW) and SAP ERP

and also a slide deck which compares the different data connectivity options and the supported elements of a BEx Query, including the option to create a SAP HANA model based on your SAP NetWeaver BW InfoProvider or query:
SAP BusinessObjects BI4.x - Comparing interface options to SAP NetWeaver BW & SAP NetWeaver BW on SAP HANA

I hope people find this information useful and that it helps on the integration of BI4 with BW and ERP and I am looking forward to your comments and feedback.

BEx-Userexits reloaded

BEx-Userexits reloaded

Via Content in SCN

After the initial release of the BI-Tools framework for BEx-Exitvariables in Easy implementation of BEx-Userexit-Variables I got a lot of useful comments and suggestions. And finally, I realized, that I omit a detailed discussion and implementation of the I_STEP 3 ( check after variable-screen ).

Please read first my first blog, because there are a lot more informations about the process and the variable implemenation. This blog talks mostly about experiences and refactoring.

Existing experiences

I have talked to some people, which are using this framework and I have seen some other implementations based on BADI or function modules. 

When introducing the object-oriented approach, you can obtain some advantages:

• Traceability: Every Variable is clearly defined and can be relocated very fast ( without scanning a lot of ABAP coding)

• Self-documenting Implementation: The variable-interface has been defined for an easy use and not for encapsulating the technical customer-exit interface

• Reusablitiy: Reduce variable code by inheritance and specify only the necessary code within your concrete variable

• Stability: If one of the variables has a failure, just this coding is not usable. If you have another approach like includes or big function-groups, this is not guaranteed by default.

• Testability: Using ABAPUnit with ABAP OO-Bex-Variables is very easy and efficient.

Why reloaded?

1. The I_STEP = 3 has been implemented as "normal" variable instance and so it has not been very much possiblities to configure and implement this for special queries/infoproviders. This leads to the situation, that all coding has been implemented in one variable-class which handled a lot of different use-cases (and this has not been the original idea of "Separations of concerns").

1. A spelling mistaked has been slipped into the naming of the methods - so this could lead into a misunderstanded usage when implementing authority-variables.

Refactoring

• The existing variable interface - without step 3 ( and renaming method for i_step = 0)

• A new check-interface handling I_STEP = 3

Details


The usage of the BEx-Variables framework has also shown, that an object-oriented approach is easier than plain function modules, if a clear interface is used. I found one example, where even young developers without a lot of development knowledge implemented BEx-Variables.

The original implementation has two problems:

So, I enhanced the existing solution and perform a small but effective refactoring. The actual code is checked into code-exchange and can be installed via SAPLink.

Instead of having one interface, which implement all steps, I decided to split the existing variable-interface into two interfaces:

A short look into the UML-structure:

As you may notice there is another new class called "ZCL_BIU001_CHECK_COLLECTION". This has been necessary, because a check can be resolved through a infoprovider assignment or a special query. Within the new customizing it is possible, to define checks based upon those two criterias. Not enough: these parameters could be configured as pattern-based parameters, so you can specify a special check for a class of queries / infoproviders.

In the following, I will show the main changes.

Variable-Interface (BTW: I love the new corbu design - well done )

Check-Interface

Additional, the variable-include has been enhanced (a little bit ;-) ):

The customizing has been changed, so that there are two customizing tables: One for the variables and one for the checks.

I would suggest to use them together in one view-cluster. And if you defined the views, think about the DDIC capabilities like search-helps, maintenance-views, foreign-keys. Through the usage of ABAP Interfaces, it is possible, to check at customizing time, if a class implements the correct interface!

I use the described framework intensively and I like the simple usage and the fact, that the original very technical calling has been hidden by two suitable interfaces.

All the coding and documentation will be found within the code-exchange area "BI-Tools": https://cw.sdn.sap.com/cw/groups/bi-tools. Please do not hesitate to join or ask any questions about implementation details or how to install it. I have attached the current nugget to this blog.

Have fun!