Analytics Architecture Guidelines

(based on NetWeaver Release 2004s)

Version 1.0

January 31, 2007

Analytics Architecture Guidelines

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

2007 SAP AG and SAP America, Inc. Page 2

Analytics Architecture Guidelines

1 Objectives and Approach

The SAP teams that develop Analytical Applications adhere to guidelines and use templates and tools that
deliver consistent, powerful, and accessible reporting scenarios. As you implement your own scenarios, you'll
benefit by following their lead. The reporting scenarios represent entire analytics processes from data
acquisition (i.e. data extraction, data warehousing) to frontend design and runtime. Figure 1 displays very
roughly 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 and
harmonized across applications. Furthermore, the applications shall deliver a stable and re-usable data
acquisition 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 mySAP
Business Suite
Easy development and extensions of reporting solutions by customers and partners.

Figure 1: Data Acquisition and Frontend Layer

2007 SAP AG and SAP America, Inc. Page 3

Analytics Architecture Guidelines

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

2007 SAP AG and SAP America, Inc. Page 4

Analytics Architecture Guidelines

2 Analytics Architecture for NetWeaver Release 2004s

Figure 2: Analytics Architecture for NetWeaver Release 2004s

2007 SAP AG and SAP America, Inc. Page 5

Analytics Architecture Guidelines

2.1 General Aspects

The analytics architecture for SAP NetWeaver Release 2004s provides functionality for reporting, analysis, and
planning of all business data. In general the following functionalities are covered independently from the used
data 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 to
information consumption. Tools that are used during design and run time of the frontend layer are SAP
NetWeaver 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. The
BEx 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 and
columns. 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 user
deploys a BI query that was previously defined by using the BEx Query Designer, to an Excel workbook. The
user 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, dropdown
box, etc.), provide related information (e.g., document list, system messages, information field, etc.) or organize
the output within the page (e.g., tab pages, container, group, container layout, etc.). You configure these Web
items by assigning a data provider (e.g. from a BI query previously defined using the BEx Query Designer) and
by 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 a
URL or as an iView in the portal. The Web Analyzer allows you to execute ad hoc analyses on the Web: When
you have selected a data provider (BI query, query view, InfoProvider from a linked SAP NetWeaver BI system,

2007 SAP AG and SAP America, Inc. Page 6

Analytics Architecture Guidelines

and external data source from a linked third-party BI system), the data is displayed in a table with a navigation
pane. You can drag and drop characteristics and key figures in and out of the table to navigate to different levels
of the data and use other Web Analyzer functions available in the application toolbar (applying or removing
filters, 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 the
BEx Query Designer to provide a formatted report that is optimized for presentation and printing. The Report
Designer generates group levels according to the drilldown state of a BI query. The Report Designer can, for
example, 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 Web
and 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 analysts
quickly create and adapt application content, without coding. SAP NetWeaver Visual Composer allows access to
transactional 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 user
interface, you build the application model by defining the data services and model components, assembling and
connecting them into a task flow that answers the needs of the application. Models designed in SAP NetWeaver
Visual Composer can be deployed to run in one or more technology engines, including SAP Web Dynpro and
Adobe Flex.

5. Web Dynpro for ABAP

Web Dynpro for ABAP is the SAP standard UI technology for developing Web applications in the ABAP
environment. It consists of a runtime environment and a graphical development environment with special Web
Dynpro 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 Dynpro
metadata. The necessary source code is then generated automatically and executed at runtime. You can
therefore generate a large proportion of a Web Dynpro application using the tools provided, without having to
create 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 a
service. This means that the display logic is contained in the Web Dynpro application, while the business logic
and 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 layer
analytic 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 physically
persistent data in BI.
Different data acquisition paths are depicted in the architectural overview (see Figure 2) and are shortly
described below.

1. Standard Data Staging into Warehouse Persistency

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

2007 SAP AG and SAP America, Inc. Page 7

Analytics Architecture Guidelines

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

2. Realtime Data Acquisition into Warehouse Persistency

To combine the requirements of standard data staging into warehouse persistency with the need for low latency
of information delivery the replication of data will take place with means of realtime data acquisition. The latency
here 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 the
source 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 and
changed 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 reporting
purposes from the source system (OLTP) persistency. In this case the appropriate way of data retrieval is
accessing the operational persistency directly instead of replicating data to an additional read-optimized
persistency.
In our overall architecture picture this approach is illustrated by the data flow which goes directly from the
analytical engine (OLAP) via Virtual Provider down to the DataSource services circumventing the business
warehouse 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 through
Query 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 for
SAP NetWeaver 2004s are described at a glance, which are used in the frontend and data acquisition layer of
your reporting scenarios.
In the following section this document gives guidance, when to use which frontend tool and data acquisition
path. Therefore several questions about your reporting scenario are displayed within two decision trees. In order
to choose the frontend tool and the data acquisition path consistently, both decision tree start with the same
question about the usage of the BI analytical engine. If your reporting scenario needs any functionality of this
engine, your choice will be a BI-based architecture on both the frontend and the data acquisition layer.

2007 SAP AG and SAP America, Inc. Page 8

Analytics Architecture Guidelines

3 Frontend Tool Decision Tree

Figure 3: Frontend Tool Decision Tree

2007 SAP AG and SAP America, Inc. Page 9

Analytics Architecture Guidelines

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, User
types, interaction, OLAP and/or OLTP data needed, for example. The UI tool decision tree (see Figure 3) will
support you in your choice and will help you determine which tool meets your requirements in the best way. Your
decision 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-down
navigation in reports, slice and dice analysis, and external presentation hierarchy, for example). If you don’t
need 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 the
Visual Composer if your analytic application to be rendered with Adobe Flex. Adobe Flex is a presentation-tier
framework and server that enables the development of Rich Internet Applications. With the Adobe Flex UI you
can use interactive UI elements, for example. If you want to use just OLTP data in your reporting scenario, you
also 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 the
BI 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 BEx
Analyzer workbook. You can also do basic formatting with standard MS Excel functionality as well as integrating
BI Integrated planning functionality.
If you want to use formatted reporting and if you want to display the reports in a Web Browser, you should use
the Report Designer. With the Report Designer you are able to create formatted reports that are optimized for
presentation 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 Web
Application Designer) to create pattern-based Web Templates. You can create Information Consumer Patterns
to ensure a standardized UI for the end users who access the Web Templates via the Enterprise Portal. If you
need special UI elements (for example, Tab Strips) or if you want to build planning applications, you have to use
the 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 table
provides an overview of the features available in VC and BI and should help with your decision to use one tool
rather than another. The information is grouped by design-time and run-time, and represents the current status
in 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

2007 SAP AG and SAP America, Inc. Page 10

Analytics Architecture Guidelines

Hierarchies

Multi-dimensional analysis
(Pivot-Table)
Document services (attach
documents/comments to
reports)
Drag&Drop

Design Time feature Visual Composer BEx Web Application

Designer
Dashboard Development

Design of dataflow (Parameter

mapping)
Access to Query services
(BAPI’s / Web Services)
Access to relational
DataSources
BI Planning integration

Value helps

Creation of pattern based iViews

/ Templates
Extensibility of model via coding
or scripting / usage of command
wizard
Manipulation of data from
DataSources during dashboard
design
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 VC
model that renders the data in Adobe Flex and within this model you can define links to BEx Web Applications
that calls the underlying query in order to analyze the data in more detail. There the data will be displayed in
DHTML 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.

2007 SAP AG and SAP America, Inc. Page 11

Analytics Architecture Guidelines

Figure 4: VC model rendered in Adobe Flex UI

Figure 5: Open Query using BEx Web

2007 SAP AG and SAP America, Inc. Page 12

Analytics Architecture Guidelines

Figure 6: Open Formatted Report using BEx Web

Figure 7: Open Geographical analysis using BEx Web

2007 SAP AG and SAP America, Inc. Page 13

Analytics Architecture Guidelines

4 Data Acquisition Decision Tree

Figure 8: Data Acquisition Decision Tree

2007 SAP AG and SAP America, Inc. Page 14

Analytics Architecture Guidelines

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 acquisition
path will be supported by a corresponding Data Acquisition Decision Tree (see Figure 8). This decision tree is
combined with a matrix which provides additional information on features, performance, limitations, and data
aggregation level of each individual data acquisition path. Together with the questions of the decision tree, this
matrix 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 of
the BI analytical engine (e.g. drill-down navigation in reports, slice and dice analysis, and external presentation
hierarchy). In this case you should use a BI-based data acquisition architecture (one of the three columns on
the 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 previously
defined query service or SAP query to directly access the data of the source system (OLTP) application
tables (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 latency
that can be accepted by your reporting scenario. In the above decision tree there are three different BI-based
data 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 is
loaded daily or monthly to BI), you can load the data into a BI warehouse persistency using standard BI
staging 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 the
data into a BI warehouse persistency. For this purpose you use the BI realtime demon to schedule the data
upload 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 acquisition
path uses previously defined BI DataSources to read directly from the application tables of the source
system.
If your reporting scenario leads you to the data acquisition paths with direct access, either BI-based via
Virtual Provider, or OLTP-based via query service / SAP query (one of the two columns on the right side of the
decision matrix in Figure 8), then you should also take seriously into account the performance aspects given by
the decision matrix. Direct access scenarios are always mass data and mass user critical and may interfere
heavily 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 the
reporting 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 data
acquisition decision tree in Figure 8, you should take into account the benefits of a data warehouse scenario
used 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 entering
data. Analyzing this data is not only difficult because it is spread across several systems but because the data is
saved in a form that is optimized for processing, not analysis. Data analysis, which is performed directly in the
OLTP 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 formats
which must first be standardized and cleaned up. The applications also only save historic data to a limited
extent. This historic data can be important in analysis.
Therefore separate systems are required for storing data and supporting data analysis requirements. This type
of system is called a data warehouse.

2007 SAP AG and SAP America, Inc. Page 15

Analytics Architecture Guidelines

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 Help
Portal: http://help.sap.com/saphelp_nw2004s/helpdata/en/43/4a86b4224847b6e10000000a11466f/frameset.htm

2007 SAP AG and SAP America, Inc. Page 16