analytics architecture guidelines

16
Analytics Architecture Guidelines (based on NetWeaver Release 2004s) Version 1.0 January 31, 2007

Upload: toralber

Post on 27-Nov-2014

79 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Analytics Architecture Guidelines

Analytics Architecture Guidelines(based on NetWeaver Release 2004s)

Version 1.0

January 31, 2007

Page 2: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 2

Table of Contents:

1 Objectives and Approach ..............................................................................................3

2 Analytics Architecture for NetWeaver Release 2004s.................................................5

2.1 General Aspects....................................................................................................................................6

2.2 Frontend Layer ......................................................................................................................................6

2.3 Data Acquisition Layer..........................................................................................................................7

2.4 Conclusion and Outlook .......................................................................................................................8

3 Frontend Tool Decision Tree.........................................................................................9

3.1 General Aspects..................................................................................................................................10

3.2 Feature Aspects ..................................................................................................................................10

3.3 Integration of Visual Composer and BEx Web...................................................................................11

4 Data Acquisition Decision Tree...................................................................................14

4.1 General Aspects..................................................................................................................................15

4.2 Data Warehousing Aspects ................................................................................................................15

Page 3: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 3

1 Objectives and ApproachThe SAP teams that develop Analytical Applications adhere to guidelines and use templates and tools thatdeliver consistent, powerful, and accessible reporting scenarios. As you implement your own scenarios, you'llbenefit by following their lead. The reporting scenarios represent entire analytics processes from dataacquisition (i.e. data extraction, data warehousing) to frontend design and runtime. Figure 1 displays veryroughly these two principal layers of the analytics process: the data acquisition layer and the frontend layer.

Analytics architecture guidelines assure that models within data acquisition and design layers are consistent andharmonized across applications. Furthermore, the applications shall deliver a stable and re-usable dataacquisition layer being basis for various frontend design models:

Analytical applications built by SAP Analytics

Predefined reports (based on SAP NetWeaver Business Intelligence) built by applications of the mySAPBusiness Suite

Easy development and extensions of reporting solutions by customers and partners.

Figure 1: Data Acquisition and Frontend Layer

Page 4: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 4

Note: These analytics guidelines are based on the latest SAP NetWeaver Release 2004s and span from anarchitectural overview (this document) to more and more detailed guidelines on modeling patterns (to bepublished later) and on the building blocks of these patterns (published in SAP Developer Network on page BIData Modeling and Frontend Design).

Page 5: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 5

2 Analytics Architecture for NetWeaver Release 2004s

Figure 2: Analytics Architecture for NetWeaver Release 2004s

Page 6: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 6

2.1 General Aspects

The analytics architecture for SAP NetWeaver Release 2004s provides functionality for reporting, analysis, andplanning of all business data. In general the following functionalities are covered independently from the useddata acquisition path:

Simple access, integration, and analysis of (federated) relational and analytical data from SAP as well as 3rd

party application systems

Integration of analytical (and planning) capabilities into operational processes

Simple modeling of powerful analytical (and planning) applications by the business expert

Distribute reports on relational and non-SAP data to information consumers

SAP NetWeaver Business Intelligence (BI) additionally provides the following functionalities:

A complete data warehousing toolset (including near-realtime data acquisition for data latency reduction)

A business intelligence platform (enabling drill-down navigation in reports, slice and dice analysis of data,external presentation hierarchies)

A suite of business intelligence tools

2.2 Frontend Layer

The frontend layer provides processes and services to meet the needs business users with regards toinformation consumption. Tools that are used during design and run time of the frontend layer are SAPNetWeaver Visual Composer, SAP Web Dynpro for ABASP, and the SAP Business Explorer (BEx) Suite tools:Query Designer, Report Designer, Web Application Designer, Web Analyzer and the Excel-based BEx Analyzer.

These frontend tools are depicted in the architectural overview (see Figure 2) and are described briefly below.

1. BEx Query Designer and Excel-based BEx Analyzer

The BEx Query Designer is the core design tool for reporting in SAP NetWeaver Business Intelligence. Self-contained business data areas called InfoProviders provide the structure for data in SAP NetWeaver BI. TheBEx Query Designer allows you to both limit the data returned from the InfoProvider and add to that data (e.g.,hierarchies, restricted and calculated key figures, etc.), as well as define the report structure of rows andcolumns. With SAP NetWeaver 2004s, the BEx Query Designer is also planning-enabled.

The BEx Analyzer is an add-on to Microsoft Excel that is accessed via the desktop. With this tool, a userdeploys a BI query that was previously defined by using the BEx Query Designer, to an Excel workbook. Theuser can employ Visual Basic for Applications (VBA) to add customized programming.

2. Web Application Designer and Web Analyzer

The BEx Web Application Designer is a desktop tool that allows the user to build BI applications for the Web.To build the BI application, you drag in Web items, which define different ways of displaying BI data (e.g.,analysis grid, chart, report, map), perform functions (e.g., navigation pane, button group, filter pane, dropdownbox, etc.), provide related information (e.g., document list, system messages, information field, etc.) or organizethe output within the page (e.g., tab pages, container, group, container layout, etc.). You configure these Webitems by assigning a data provider (e.g. from a BI query previously defined using the BEx Query Designer) andby setting properties relevant to the type of Web item.

The BEx Web Analyzer is a standalone, convenient Web application for data analysis that you can call using aURL or as an iView in the portal. The Web Analyzer allows you to execute ad hoc analyses on the Web: Whenyou have selected a data provider (BI query, query view, InfoProvider from a linked SAP NetWeaver BI system,

Page 7: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 7

and external data source from a linked third-party BI system), the data is displayed in a table with a navigationpane. You can drag and drop characteristics and key figures in and out of the table to navigate to different levelsof the data and use other Web Analyzer functions available in the application toolbar (applying or removingfilters, and adding, changing or deleting exceptions and conditions).

3. Report Designer

The BEx Report Designer is a desktop tool that transforms the BI query that was previously defined using theBEx Query Designer to provide a formatted report that is optimized for presentation and printing. The ReportDesigner generates group levels according to the drilldown state of a BI query. The Report Designer can, forexample, change fonts, text and background colors, row heights and column widths, insert rows and columns,re-position fields, and add texts, images and charts, and page breaks. You can display this report on the Weband you can also convert the report into a PDF document to print or distribute it.

4. Visual Composer

SAP NetWeaver Visual Composer is a Web-based application-modeling tool. It allows business analystsquickly create and adapt application content, without coding. SAP NetWeaver Visual Composer allows access totransactional as well as BI data (SAP NetWeaver BI and third-party BI data).

You organize and configure components of the application into a logical flow, or model. Through a graphical userinterface, you build the application model by defining the data services and model components, assembling andconnecting them into a task flow that answers the needs of the application. Models designed in SAP NetWeaverVisual Composer can be deployed to run in one or more technology engines, including SAP Web Dynpro andAdobe Flex.

5. Web Dynpro for ABAPWeb Dynpro for ABAP is the SAP standard UI technology for developing Web applications in the ABAPenvironment. It consists of a runtime environment and a graphical development environment with special WebDynpro tools that are integrated in the ABAP Workbench.

You use specific tools to describe the properties of a Web Dynpro application in the form of Web Dynprometadata. The necessary source code is then generated automatically and executed at runtime. You cantherefore generate a large proportion of a Web Dynpro application using the tools provided, without having tocreate your own source code. Using Web Dynpro enables a clear separation of business logic and display logic.

A Web Dynpro application runs on the front end and has local or remote access to the back end system via aservice. This means that the display logic is contained in the Web Dynpro application, while the business logicand the persistence of the business objects run in the back end system.

2.3 Data Acquisition Layer

The data acquisition layer provides processes and services to form the basis of an extensive frontend layeranalytic solution. An integrated data acquisition layer retrieves data from any source (SAP or non-SAP sources)and of any age (historic or current). It allows you to directly access source system data as well as physicallypersistent data in BI.

Different data acquisition paths are depicted in the architectural overview (see Figure 2) and are shortlydescribed below.

1. Standard Data Staging into Warehouse Persistency

Given ‘normalized’ database structures used in the area of source system (OLTP) persistency we encounter theproblem of not being able to retrieve data fast enough for reporting purposes. The approach towards a solutionof this issue is the replication of the data with the help of BI DataSources into read-optimized database tableswithin the data warehouse persistency.

Page 8: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 8

Once the transaction data have been staged to the data warehouse, the analytical engine (OLAP) simplyaccesses the respective BI internal InfoProviders which are primarily InfoCubes and DataStore Objects. As tothe InfoCube option, however, we have the additional possibility of using the BI accelerator, which allow formuch faster data processing with significantly lower administration effort compared to BI’s traditional aggregationcapabilities.

2. Realtime Data Acquisition into Warehouse Persistency

To combine the requirements of standard data staging into warehouse persistency with the need for low latencyof information delivery the replication of data will take place with means of realtime data acquisition. The latencyhere is anticipated to be in the range of five minutes.

One or several daemons on BI side are used, which manage the close to realtime upload to DataStore Objects,where one daemon handles multiple DataSources of the SAP source system. Application data is collected in thesource system in the delta queue of the BI Service API. The daemon (basically a frequently scheduled batch job)then calls a read interface of the BI Service API in the source system. The Service API transfers new andchanged records to the daemon and the PSA and subsequently the DataStore Object is updated.

3. Direct Access via BI-based Virtual Provider

Particularly for simple operative lists there are use cases that can retrieve data fast enough for reportingpurposes from the source system (OLTP) persistency. In this case the appropriate way of data retrieval isaccessing the operational persistency directly instead of replicating data to an additional read-optimizedpersistency.

In our overall architecture picture this approach is illustrated by the data flow which goes directly from theanalytical engine (OLAP) via Virtual Provider down to the DataSource services circumventing the businesswarehouse persistency.

4. Direct Access via OLTP-based Query Service / SAP Query

Transactional applications can also be modeled using a pattern based UI that is modeled with Visual Composer.The source system is accessed via query call that exposes the application tables to the frontend layer throughQuery Services or SAP Query.

2.4 Conclusion and Outlook

In the previous sections, the different frontend tools and data acquisition paths of the analytics architecture forSAP NetWeaver 2004s are described at a glance, which are used in the frontend and data acquisition layer ofyour reporting scenarios.

In the following section this document gives guidance, when to use which frontend tool and data acquisitionpath. Therefore several questions about your reporting scenario are displayed within two decision trees. In orderto choose the frontend tool and the data acquisition path consistently, both decision tree start with the samequestion about the usage of the BI analytical engine. If your reporting scenario needs any functionality of thisengine, your choice will be a BI-based architecture on both the frontend and the data acquisition layer.

Page 9: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 9

3 Frontend Tool Decision Tree

Figure 3: Frontend Tool Decision Tree

Page 10: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 10

3.1 General Aspects

In the area of Analytics you can use different tools to model reporting scenarios and analytical applications.Deciding which tool best meets your requirements depends on several factors - features, UI technology, Usertypes, interaction, OLAP and/or OLTP data needed, for example. The UI tool decision tree (see Figure 3) willsupport you in your choice and will help you determine which tool meets your requirements in the best way. Yourdecision also depends on which criteria (e.g. features) are most important for you.

First you should think about whether you need to use the functionalities of the BI analytical engine (drill-downnavigation in reports, slice and dice analysis, and external presentation hierarchy, for example). If you don’tneed those functionalities, then you should use Visual Composer, especially if you want to use query services(Web Services and/or BAPI‘s) and/or if you want to embed OLAP data into operational processes. Also, use theVisual Composer if your analytic application to be rendered with Adobe Flex. Adobe Flex is a presentation-tierframework and server that enables the development of Rich Internet Applications. With the Adobe Flex UI youcan use interactive UI elements, for example. If you want to use just OLTP data in your reporting scenario, youalso have to use Visual Composer.

If you want to report based only on OLAP data (stored in Info Providers in a SAP BI system), you should use theBI Suite tools. If the end users should access their reports using MS Excel, you must use the BEx Analyzer.Beforehand you have to define a query using the Query Designer that then can be easily embedded into a BExAnalyzer workbook. You can also do basic formatting with standard MS Excel functionality as well as integratingBI Integrated planning functionality.

If you want to use formatted reporting and if you want to display the reports in a Web Browser, you should usethe Report Designer. With the Report Designer you are able to create formatted reports that are optimized forpresentation and printing. You can also access a number of formatting and layout functions.

If you need to deliver standardized reports, you should use the Pattern Wizard (integrated into the WebApplication Designer) to create pattern-based Web Templates. You can create Information Consumer Patternsto ensure a standardized UI for the end users who access the Web Templates via the Enterprise Portal. If youneed special UI elements (for example, Tab Strips) or if you want to build planning applications, you have to usethe freestyle Web Application Designer capabilities.

3.2 Feature Aspects

You must also consider the range of different features provided by the different tools. The following tableprovides an overview of the features available in VC and BI and should help with your decision to use one toolrather than another. The information is grouped by design-time and run-time, and represents the current statusin SAP NetWeaver 2004s.

Runtime feature Visual Composer models BEx Web Applications

Information Broadcasting

Export possibilities (Excel, pfd)

Personalization

BI Planning integration

Adobe Flex rendering

Alert integration

Exceptions / Conditions

Page 11: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 11

Hierarchies

Multi-dimensional analysis(Pivot-Table)

Document services (attachdocuments/comments toreports)

Drag&Drop

Design Time feature Visual Composer BEx Web ApplicationDesigner

Dashboard Development

Design of dataflow (Parametermapping)

Access to Query services(BAPI’s / Web Services)

Access to relationalDataSources

BI Planning integration

Value helps

Creation of pattern based iViews/ Templates

Extensibility of model via codingor scripting / usage of commandwizard

Manipulation of data fromDataSources during dashboarddesign

WYSIWYG

Reuse of parts of the model

3.3 Integration of Visual Composer and BEx Web

You can also combine the advantages of the VC and BEx Web runtime. For example, you can develop a VCmodel that renders the data in Adobe Flex and within this model you can define links to BEx Web Applicationsthat calls the underlying query in order to analyze the data in more detail. There the data will be displayed inDHTML and you can use the BEx features to drill-down in a pivot table, for example.

The following figures show you examples of the integration of BEx Web into a VC model.

Page 12: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 12

Figure 4: VC model rendered in Adobe Flex UI

Figure 5: Open Query using BEx Web

Page 13: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 13

Figure 6: Open Formatted Report using BEx Web

Figure 7: Open Geographical analysis using BEx Web

Page 14: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 14

4 Data Acquisition Decision Tree

Figure 8: Data Acquisition Decision Tree

Page 15: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 15

4.1 General Aspects

As already explained in the previous section 2.3, there are different tools to access data from source system(OLTP) applications. Similar to the Frontend Tool decision tree, the choice of an appropriate data acquisitionpath will be supported by a corresponding Data Acquisition Decision Tree (see Figure 8). This decision tree iscombined with a matrix which provides additional information on features, performance, limitations, and dataaggregation level of each individual data acquisition path. Together with the questions of the decision tree, thismatrix gives you guidance, which data acquisition scenario meets your requirements the best way.

As it also holds for the Frontend Tool Decision Tree, you should first think if you need to use the functionalities ofthe BI analytical engine (e.g. drill-down navigation in reports, slice and dice analysis, and external presentationhierarchy). In this case you should use a BI-based data acquisition architecture (one of the three columns onthe left side of the decision matrix in Figure 8).

On the other hand, if you don’t need the functionality of the BI analytical engine, you can use any previouslydefined query service or SAP query to directly access the data of the source system (OLTP) applicationtables (the most right column of the decision matrix in Figure 8).

If you are arrived at a BI-based data acquisition architecture, the next questions deal with the data latencythat can be accepted by your reporting scenario. In the above decision tree there are three different BI-baseddata acquisition paths distinguished by the level of data latency.

If the reporting scenario is based on replicated data, where any latency can be accepted (e.g. data isloaded daily or monthly to BI), you can load the data into a BI warehouse persistency using standard BIstaging techniques. That means you schedule the data upload by “normal” BI InfoPackages.

If a latency of about 5 minutes can be accepted, you have to use the realtime data acquisition to load thedata into a BI warehouse persistency. For this purpose you use the BI realtime demon to schedule the dataupload with a predefined frequency (e.g. every 5 minutes).

If the reporting scenario is based on realtime, non-replicated data, where no latency can be accepted at all,the BI-based architecture offers the functionality Direct Access via Virtual Provider. This data acquisitionpath uses previously defined BI DataSources to read directly from the application tables of the sourcesystem.

If your reporting scenario leads you to the data acquisition paths with direct access, either BI-based viaVirtual Provider, or OLTP-based via query service / SAP query (one of the two columns on the right side of thedecision matrix in Figure 8), then you should also take seriously into account the performance aspects given bythe decision matrix. Direct access scenarios are always mass data and mass user critical and may interfereheavily the operative data processing. Furthermore, the data selection capabilities from the application tables(provided either by the BI-based DataSource or by the OLTP-based query service / SAP query) determines thereporting performance in a strong way.

4.2 Data Warehousing Aspects

In addition to the considerations on analytical functionalities and on data latency, which build up the dataacquisition decision tree in Figure 8, you should take into account the benefits of a data warehouse scenarioused in the two data acquisition paths “Standard Staging” and “Realtime Data Acquisition”.Company data is usually spread across several source system (OLTP) applications that are used for enteringdata. Analyzing this data is not only difficult because it is spread across several systems but because the data issaved in a form that is optimized for processing, not analysis. Data analysis, which is performed directly in theOLTP system, represents additional OLTP system load which affects operative data processing. Furthermore,the data has come from heterogeneous applications and is therefore only available in heterogeneous formatswhich must first be standardized and cleaned up. The applications also only save historic data to a limitedextent. This historic data can be important in analysis.

Therefore separate systems are required for storing data and supporting data analysis requirements. This typeof system is called a data warehouse.

Page 16: Analytics Architecture Guidelines

Analytics Architecture Guidelines

2007 SAP AG and SAP America, Inc. Page 16

A data warehouse serves to

integrate data from heterogeneous sources,

transform, consolidate master data, clean up,

store this data, retain the history in dedicated data containers,

stage it efficiently (i.e. read-optimized) for analysis and interpretation purposes.

For more information on the architecture of a data warehouse see the online documentation in the SAP HelpPortal: http://help.sap.com/saphelp_nw2004s/helpdata/en/43/4a86b4224847b6e10000000a11466f/frameset.htm