Team-Fly

Business Information
Warehouse for SAP
by Naeem ISBN:0761523359
Hashmi

Premier Press © 2000 (447 pages)

A straightforward account of SAP

BW, providing explanations of
concepts, overviews, and general
references.

Table of Contents
Business Information Warehouse for SAP
Foreword
Introduction
Part I - Introduction to Data Warehousing and SAP Business Information Warehouse
Chapter 1 - Constructing a Data Warehouse
Chapter 2 - Evolution of SAP Business Information Warehouse
Comparing SAP BW with Data Warehouse Solutions Provided by Other
Chapter 3 -
Vendors
Chapter 4 - Getting Started with SAP BW
Part II - Implementing SAP BW
Chapter 5 - Planning for SAP BW Implementation
Chapter 6 - Setting Up SAP BW
Chapter 7 - SAP BW—The Administrator Workbench
Chapter 8 - SAP BW—Loading Business Content
Chapter 9 - Preparing R/3 Data Sources for SAP BW Initial Data Loads
Chapter 10 - Loading Data via Flat Files
Chapter 11 - Analyzing SAP BW Data
Part III - Designing Custom SAP BW OLAP Solutions
Chapter 12 - SAP BW—Defining Custom InfoCubes
Chapter 13 - Enhancing Business Content and Developing Data Extractors
Chapter 14 - Integrating Third-Party ETL Products with SAP BW
Chapter 15 - Integrating Third-Party Data Access Products with SAP BW
Chapter 16 - Managing SAP BW—Performance and Sizing Tuning
Chapter 17 - The Operational Data Store in SAP BW 2.0
Part IV - Appendixes
Appendix A - Data Warehouse Industry References and SAP BW Training
Appendix B - SAP BW and SAP R/3 Transactions, Tables, and Code Examples
Appendix C - Selected SAP BW OSS Notes
Appendix D - Key Enhancements in SAP BW 2.0
Appendix E - What's on the CD-ROM
Index
List of Figures
List of Tables

Team-Fly
Team-Fly

Back Cover

Benefit From the Author's Expertise Gain an understanding

of what it takes to implement SAP BW. Follow along as the
author explains the evolution of SAP BW architecture and its
components. This book describes the roots of SAP BW and
how it has evolved from a simple operational reporting
environment to a full-featured information warehouse. Profit
from a description of the structure of the SAP BW
implementation team and SAP BW ASAP methodology.
Learn how to construct data warehouses using BW based
on the author's experiences during actual SAP BW
implementations.
Master Data Warehouse Concepts

Learn basic data warehouse concepts--including the

technical aspects and performance characteristics
associated with constructing a data warehouse. Then,
advance to a discussion of SAP BW architecture and how it
compares with a traditional data warehouse. Learn what it
takes to build analytical applications in SAP BW and the
SAP BW development environment. Learn how metadata is
managed in SAP BW and how SAP BW compares with data
warehouse solutions provided by other vendors.

About the Author

Naeem Hashmi, a widely known expert in the ERP business

intelligence industry and a pioneer in ERP data
warehousing, has more than 22 years of experience in
emerging Information Technologies research, development,
and e-business; ERP applications; data warehousing; data
mining; CRM; database, Web, object and client/server
technologies; enterprise application integration; and
information structures. He is the chief technology officer of
Information Frameworks, an emerging Information
Technology research and strategic IT consulting group. A
former technical director at Compaq/Digital, he directed
early SAP BW customer projects for the Benchmark and
Engineering Group, and has worked directly with SAP
management and engineering team members in defining
requirements and architecture for SAP BW.
Team-Fly
Team-Fly
Business Information Warehouse for SAP-
Your Guide to Data Warehousing and BW
Naeem Hashmi
SERIES EDITORS Gareth M. de Bruyn
Robert W. Lyfareff

A Division of Prima Publishing

Copyright © © 2000 by Prima Publishing.

All rights reserved. No part of this book may be reproduced or

transmitted in any form or by any means, electronic or mechanical,
including photocopying, recording, or by any information storage or
retrieval system without written permission from Prima Publishing,
except for the inclusion of brief quotations in a review.

Prima Publishing and colophon are registered trademarks of Prima

Communications, Inc. PRIMA TECH is a trademark of Prima
Communications, Inc., Roseville, California 95661.

SAP, Business Information Warehouse, R/3, and BAPI are either

registered trademarks or trademarks of SAP Aktiengesellschaft,
Systems, Applications and Products in Data Processing,
Neurottstrasse 16, 69190 Walldorf, Germany. SAP is not the
publisher of this book and is not responsible for it under any aspect
of press law.

Microsoft, Windows, Excel, Microsoft SQL Server, Microsoft Office,

ActiveX, and FrontPage are trademarks or registered trademarks of
Microsoft Corporation.
Important: Prima Publishing cannot provide software support. Please
contact the appropriate software manufacturer's technical support
line or Web site for assistance.

Prima Publishing and the author have attempted throughout this

book to distinguish proprietary trademarks from descriptive terms by
following the capitalization style used by the manufacturer.

Information contained in this book has been obtained by Prima

Publishing from sources believed to be reliable. However, because
of the possibility of human or mechanical error by our sources, Prima
Publishing, or others, the Publisher does not guarantee the
accuracy, adequacy, or completeness of any information and is not
responsible for any errors or omissions or the results obtained from
use of such information. Readers should be particularly aware of the
tact that the Internet is an ever-changing entity. Some facts may
have changed since this book went to press.
ISBN: 0-7615-2335-9

Library of Congress Catalog Card Number: 99-65114

Printed in the United States of America

00 01 02 03 04 HH 10 9 8 7 6 5 4 3 2 1

Publisher:
Stacy L. Hiquet

Marketing Manager:
Judi Taylor

Associate Marketing Manager:

Heather Buzzingham

Managing Editor:
Sandy Doell

Acquisitions Editors:
Jawahara K. Saidullah,
Deborah F. Abshier

Developmental Editor:
Robert Lyfareff

Technical Reviewer:
Steffen Fischer

Senior Editors:
Kim V. Benbow,
Kevin Harreld

Project Editor:
Lorraine Cooper

Copy Editor:
Anne Owen

Interior Layout:
Marian Hartsough

Cover Design:
Prima Design Team

Indexer:
Sharon Hilgenberg

Proofreader:
John David Rudometkin

About the Author

Naeem Hashmi is a technology evangelist who has more than 22

years of experience in emerging Information Technologies research,
development, and management covering a wide array of
technologies such as information delivery technologies; e-business;
ERP applications; data warehousing; data mining; CRM; database,
Web, object and client/server technologies; enterprise application
integration; and information architectures. He is the chief technology
officer of Information Frameworks, an emerging Information
Technology research and strategic IT consulting group.

A former technical director at Compaq/Digital for Database and

Business Intelligence Engineering, the IT Group, and the SAP BW
benchmark project, he directed the early SAP BW customer projects
(BW l.0E, BW 1.2A, and BW 1.2B). As a senior information
technology architect for the Advanced Technology and Planning
Group, he led several emerging technology development initiatives
within Compaq/Digital IT organizations, consulting and engineering
teams, and technology vendors/partners such as SAP, Oracle, and
Microsoft in the e-commerce and business intelligence industries.

A pioneer in ERP data warehousing even before BW was born,

Naeem worked directly with SAP management and engineering
team members in defining requirements for SAP BW from BW 1.0E
through BW 2.0B. He was a core technical advisor to the SAP BW
development team in the implementation of SAP BW 2.0 ODS and
an advisor for the SAP BW 2.0A ODS pilot implementation at
Hewlett-Packard.

Naeem is a widely known expert in the ERP business intelligence

industry and is a frequent speaker at the industry's leading
conferences: DCI DW World, DW-Institute, SAP TechEd, SAP
ASUG, Oracle Open World, ERP World, and Internet/ERP
Integration Technology. Companies such as SAP, Oracle, Microsoft,
Acta, Informatica, Sagent, Cognos, Brio, and ISG seek his consulting
services on architecting their business intelligence solutions. Naeem
works directly with senior executives as well as development team
members in the architecture, design, and implementation strategies
of their products.

Naeem holds a master of science degree in radiological health and

environment sciences with a specialization in high-performance
computing, simulation, and data mining from Washington State
University. He also has a master of science degree in experimental
nuclear physics and a bachelor of science degree in applied physics,
chemistry, and mathematics from the University of Punjab, Pakistan.

Naeem can be reached at <Nhashmi@aol.com>.

In the memory of parents, who always encourage us to explore and

learn

Acknowledgments

First, I'd like to thank Stacy Hiquet, Debbie Abshier, and Jawahara
Saidullah of Prima Tech for this opportunity to share my experiences
in the ever-evolving industry of business intelligence.

I extend my appreciation to Steffen Fischer, the technical editor, for

making his valuable time available for technical reviews of this book.
Despite the ever-changing functionality in SAP BW, Steffen did an
excellent job in making sure that the content remained up to date. I
also thank Bob Lyfareff for his valuable suggestions in making this
book interesting.

The quality and consistency in this book would have not been
possible without the support of the editorial staff at Prima, especially
Lorraine Cooper, and the rest of the crew who spent their time
editing, organizing, and packaging the material that made the
technical content easier to digest. Their support is very much
appreciated.

Special acknowledgement goes to Wayne Eckerson (The Data

Warehouse Institute), Kevin McDonald (Compendit Inc.), Ray
Bachert (Microsoft), Scott Pietroski (Integration-Technology),
Charlene Mathias (Eli Lilly), Michael Ullman (Integration-
Technology), P.V. Rao (QwestCyber.Solutions), and Dan Spaulding
(KPMG LLP Consulting), who reviewed the initial book draft and
gave their honest opinions. I also acknowledge support from Acta,
arcplan, Hummingbird, Informatica, and SAP for providing material
needed for the book.
A very special thanks goes to my wife, Debra Norton, for her
patience, encouragement, and support in writing this book.

Last but not least, I'd like to thank you, the readers of this book, who
have been waiting for a long time. The SAP Business Information
Warehouse (BW) is still evolving rapidly, and writing about a moving
target is not an easy task. I feel that the content of this book will not
only provide you with what the SAP BW product was or is but also
what it will be in the coming years. Enjoy!

Team-Fly
Team-Fly
Foreword
Information is the lifeblood for today's business.

Information is what lets us understand the past and try to plan for the
future. There is no business without information.

There is no life without blood, either. Blood connects our organs and
transports the oxygen so vital for our existence. But it is the mixture
of our blood, the speed of the bloodstream, and the well-functioning
of all organs that make our body fit for all the challenges in life.

Is your business ready for challenges?

Information is just the starting point; it is an enabler. Today's

business does not lack information; it is the information overload that
represents a challenge.

But how do you use the information captured in all these databases,
in all these files on your computer, in your drawers and in your
Personal Digital Assistant? Does it prepare you to make informed
decisions? Does it enable your company to stay competitive? How
well do you process (and not just access) information? Are you able
to derive knowledge to unlock your information power?

SAP introduced a solution with exactly these business issues in

mind. SAP's Business Information Warehouse is the technological
platform for data warehousing and e-business intelligence on top of
your ERP product. It uses the veins put into place by ERP to pump
through all the information to the consumer. It allows anybody to
access critical information anywhere anytime.

Naeem Hashmi is one of the pioneers for this new technology. His
extensive background in science and technology and his knowledge
of today's most challenging business issues put him in a premier
position to guide you through the first steps with SAP BW.
I am confident you'll enjoy Naeem's style of presenting even very
complex subjects in a very easy-to-read format with his own sense of
humor.

Steffen Fischer, Director, SAP America

CRM Workplace Product Management

Team-Fly
Team-Fly
Introduction
Fast and complete access to corporate operational, tactical, and
strategic information is key to success in today's business world.
Whether it is customer relationships, shorter time to market a
product, or services profitability analysis, robust business intelligence
technology is the foundation on which such integrated business
intelligence systems are built.

Today's business intelligence environment consists of a myriad of

technologies that are offered by a similar number of hardware,
software, and consulting vendors. Determining which combination of
hardware and software is best suited for a particular data
warehousing need is complicated; acquiring the knowledge to
adequately design and support the configuration is equally difficult.

One of the core components of the SAP business framework is a

business intelligence solution called SAP Business Information
Warehouse (SAP BW). SAP BW is a complete data warehouse and
information delivery framework and is very tightly coupled with the
SAP R/3 OLTP environment. This makes it easier to implement an
autonomous data warehouse environment without the challenge of
dealing with SAP R/3 data extraction and data management
complexities.
Intended Audience
This book is intended for non-technical and intermediate-level
technical professionals who want to understand emerging trends in
Enterprise Resource Planning (ERP) data warehousing. This book
will provide readers with sufficient information on SAP BW
architecture, how to build reporting and analytical applications using
SAP BW, and how SAP BW addresses issues facing large global
companies in implementing information delivery environments. Data
warehouse and SAP R/3 developers and consultants and data
warehouse industry analysts will find this book very useful.

Readers are expected to have some basic understanding of data

warehousing as well as some knowledge of SAP R/3 applications
and technologies. However, a list of books, Web sites, and other
material on the basics of data warehousing and SAP R/3 are
provided. This book covers SAP BW versions 1.2B and 2.0A.

Team-Fly
Team-Fly
How to Use this Book
Because of the amount of information covered in the book, a guide
follows to help readers navigate to appropriate content.

Team-Fly
Team-Fly
How this Book is Organized
This book consists of four parts.

Data Warehousing and SAP BW

Implementing SAP BW

Designing Custom SAP BW OLAP Solutions

Appendixes

Team-Fly
Team-Fly
Part 1: Data Warehousing and SAP BW
Chapter 1 outlines basic data warehouse concepts and technical
issues one faces when constructing a data warehouse and describes
performance characteristics of a data warehouse. It then describes
details of traditional data warehouse components and services
needed at each architectural layer. After a description of traditional
data warehousing, you are given a quick history of ERP applications
and data warehousing history and how they are converging into a
seamless integrated environment called ERP data warehousing to
meet today's business needs.

Chapter 2 is a good start to understanding SAP BW architecture and

its components. It describes the roots of SAP BW and how it has
evolved from a simple operational reporting environment to a full-
featured information warehouse. The chapter briefly describes SAP
R/3 OLTP architecture and reporting systems built within SAP R/3.
You will then learn the SAP BW architecture and how it compares
with a traditional data warehouse. The chapter also describes how
several customers attempted to exploit SAP R/3 technologies to
construct data warehouses. Here you will learn about SAP BW
components such as OLAP engine, data management, staging
engine, and data access methods.

Chapter 3 presents a comparison of SAP BW with data warehouse

solutions provided by other vendors. Here, you will learn the cultural
impact of ERP data warehousing on organizations as well as
implementation teams.

Chapter 4 introduces the SAP BW environment. Here you learn how

to log on to SAP BW and access data stored in SAP BW data
objects.

Team-Fly
Team-Fly
Part 2: Implementing SAP BW
This section covers the nuts, bolts, and plumbing needed to
implement SAP BW.

Chapter 5 describes the structure of the SAP BW implementation

team and SAP BW ASAP methodology. It then identifies technical
infrastructure requirements, such as sizing, to implement a data
warehouse using SAP BW.

Chapter 6 describes the SAP BW server and client installation

process. This chapter is slightly technical in nature, and readers are
assumed to have some understanding of the SAP administration
technology BASIS.

Chapter 7 is an important one. You must read and understand this

chapter to learn what it takes to build analytical applications in SAP
BW. Here you learn the development environment in SAP BW, called
the Administrator Workbench. This chapter describes how you define
data sources, master data, transaction data, and all the objects and
procedures necessary to construct InfoCubes in SAP BW from within
the Administrator Workbench.

Chapter 8 describes how information flows in SAP BW. Here you

learn how SAP BW manages metadata and associated business
content in SAP BW and SAP R/3 for change capture. This chapter
describes how to install SAP BW business content and activate data
objects to build analytical applications.

Chapter 9 focuses on SAP R/3 as a data source for SAP BW.

Because you need to interact with the SAP R/3 OLTP instance, a
careful analysis of data objects and planning is critical to move such
large data volumes efficiently in SAP BW. Here you learn SAP BW
data load strategies using IDOC and Transactional RFCs (TRFCs)
methods.
Chapter 10 describes the steps to take to load data in SAP BW from
flat data files.

Chapter 11 describes how to define queries against SAP BW and

build simple to complex analytical applications and solutions. You
learn simple tips and tricks on customizing SAP BW queries and
reports.

Team-Fly
Team-Fly
Part 3: Designing Custom SAP BW OLAP
Solutions
Chapter 12 describes how to design custom objects in SAP BW.
Modeling is key to successful SAP BW implementation. Performance
of new InfoCubes and associated reporting objects depends on a
careful modeling of individual objects. Though the subject is
somewhat technical, the content is geared toward data warehouse
analysts and designers, who are assumed to have a basic
understanding of data modeling concepts. You also learn new SAP
BW 2.0 features, such as defining InfoCubes based on existing
InfoCubes, sometimes called InfoCube Joining or Multi-Cube
InfoCube.

Chapter 13 takes you to the next level of SAP BW customization.

Here you learn how to extend SAP BW business content or design
new InfoObjects, InfoSources, and data extractors. The reader is
assumed to have some understanding of ABAP and familiarity with
the SAP R/3 LIS environment.

Chapter 14 describes SAP BW staging Business Application

Program Interface (BAPI) to load data in SAP BW and how to load
data in SAP BW using non-SAP data warehouse construction
products.

Chapter 15 explains how to access data from SAP BW via the

industry-accepted standard, Microsoft's OLE DB for OLAP. It also
describes how to integrate non-SAP data access tools with SAP BW
to build pure Web-based applications using ActiveX controls.

Chapter 16 is designed for SAP BW administrators. It covers SAP

BW management issues, such as performance and tuning, sizing the
SAP BW environment, and benchmarks for SAP BW.

Chapter 17 describes the Operational Data Store (ODS) in SAP BW

2.0. This very significant change in the SAP BW architecture will take
SAP BW from a simple OLAP environment to an extraprise data
warehouse. This chapter describes how ODS implementation in BW
2.0 differs from the data warehouse industry definition of an ODS.
When designing analytical applications in SAP BW 2.0, you have to
think quite differently when modeling and accessing information. You
have to decide on data sets that reside in an InfoCube and the
associated ODS environment; this chapter teaches you how to
define an ODS environment in SAP BW 2.0A and access data
directly from ODS or drill down from InfoCube to ODS.

Team-Fly
Team-Fly
Part 4: Appendixes
This section provides data warehouse references and supporting
material to supplement the book content.

Appendix A lists a collection of data warehouse books that you will

find helpful in understanding the data warehousing industry, data
warehouse tools providers, and good data warehouse Web sites for
keeping up to date on ongoing data warehouse industry
developments.

Appendix B lists most common transactions, tables, and programs in

SAP BW and SAP R/3 OLTP that you often need to implement SAP
BW.

Appendix C is a collection of useful OSS notes for SAP BW

implementation. Note that these OSS notes often change; therefore,
they are provided as a reference point. Please read the latest
changes in such OSS notes.

Appendix D describes SAP BW 2.0 features such as metadata

management, the InfoCube star schema model, Web reporting, and
the Business Document Services. Step-by-step instructions on how
to design Web reporting against SAP BW using SAP Internet
Transaction Server (ITS) technology are also provided.

Appendix E explains the CD-ROM that accompanies this book. It

contains several Lotus ScreenCam movies to describe SAP BW
design sessions and has additional information on third-party
products that interface with SAP BW.

Vendor Product Information: Acta Technology, arcplan,

Hummingbird, and Informatica Corporation

Date Warehouse Resources: List of data warehousing books and

Web sites of data warehousing vendors Sample Code: Simple
update programs, generated by SAP BW, to populate InfoCubes in
BW 1.2B and BW 2.0A ScreenCam Movies: 18 ScreenCam movies
to demonstrate SAP BW 1.2B and SAP BW 2.0B features

Team-Fly
Team-Fly
Part I: Introduction to Data Warehousing and
SAP Business Information Warehouse
Chapter List
Chapter 1: Constructing a Data Warehouse

Chapter 2: Evolution of SAP Business Information Warehouse

Chapter 3: Comparing SAP BW with Data Warehouse Solutions

Provided by Other Vendors

Chapter 4: Getting Started with SAP BW

Team-Fly
Team-Fly
Chapter 1: Constructing a Data Warehouse
What is Data Warehousing?
William H. Inmon, known as the father of data warehousing, defines
a data warehouse as "a subject-oriented, integrated, non-volatile and
time-variant collection of data in support of management decisions"
(Building the Data Warehouse). See Appendix A, "Data Warehouse
Industry References and SAP BW Training."

This simple concept has recently become a multibillion-dollar

industry. New breeds of vendors are introducing tools and
technologies at an alarming rate to deliver data warehouse solutions.
This fast-paced and fluid data warehousing industry makes it difficult
to select a set of technologies to implement a data warehouse that
will stay in the data warehousing industry in the coming years. The
construction of a data warehouse requires three key steps:
1. Extract data from transaction systems.

2. Manipulate extracted data to generate reports.

3. Make such reports accessible to the decision-makers.

Though the concept behind a data warehouse is simple,

construction, deployment, and management of a data warehouse
that changes as business processes change is a huge challenge.
Knowledge workers, decision-makers, executives, and analysts
expect fast, quality, and up-to-the-minute information about strategic
and tactical business operations. The need to access information
quickly is blurring the line between data warehouses and On-Line
Transaction Processing (OLTP) environments. E-commerce is an
example. When you process a credit card transaction (even at a gas
station), chances are that your transaction request will pass through
a very large data warehouse (to detect fraud using data mining
techniques) before an authorization number is issued.
Due to this trend in tight integration between OLTP, data
warehouses, and business application vendors-especially ERP
vendors-all are working hard to provide to their customers robust,
scalable, and reliable business intelligence solutions that go far
beyond traditional data warehouses.

Traditional data warehouses are usually after-the-fact phenomena,

because reporting requirements and On-Line Analytical Processing
(OLAP) needs are often not brought to the table during the
requirement-gathering and implementation phases of OLTP
applications.

Often during final reviews of OLTP application deployment plans,

reporting requirements are brought to the attention of the
deployment team. Management teams want business performance
and operation reports available soon after going live with a new
OLTP application. Then at that time, reporting and data warehouse
projects are launched.

This after-the-fact reporting requirement often impacts OLTP

performance due to system configuration, especially when SAP R/3
is your corporate transaction processing system. If SAP R/3 OLTP is
not configured properly, business content may not capture needed
data for analysis. Based on your data needs, you may configure
additional workflows or update rules in SAP R/3 to capture needed
data elements required for analytical applications. If such workflows
and update rules are not implemented correctly, they may impact
OLTP transaction performance. Therefore, in SAP R/3, the data
capture schemes for analytical applications must be designed as a
part of OLTP configuration of OLTP business transactions. You will
learn about this subject in more detail in Chapter 2, "Evolution of
SAP Business Information Warehouse."

Today, accurate and quick access to corporate information sources

is key to the success of a business. Most organizations have, or will
launch, an enterprise data warehouse project with the same priority
level as the OLTP applications. This is needed to effectively manage
corporate-wide data and knowledge. While corporate operations
managers want to know the state of business operations within the
corporation, executives are primarily interested in business
performance benchmarks against industry Key Performance
Indicators (KPI). Building such dynamic enterprise data warehouses
that go far beyond enterprise boundaries, or extraprise data
warehouses, is an enormous challenge.

Business Intelligence

Data warehouses drive the corporate information supply chain to

support corporate business intelligence processes. Business
intelligence, introduced by Howard Dresner of the Gartner Group in
1989, is a set of concepts and methodologies to improve decision-
making in business through the use of facts and fact-based systems.
These fact-based systems include the following:

Executive Information Systems

Decision Support Systems

Enterprise Information Systems

Management Support Systems

OLAP

Data and Text Mining

Data Visualization

Geographic Information Systems

Each subsystem under the business intelligence umbrella has a

limited scope and view of data to serve a very special function.
Having so many subsystems beneath this umbrella may lead to data
puddles, or data sets that flow from one subsystem to another. Data
content in such data sets is altered at each subsystem to meet
special business needs, and then pushed out to the next application.
By the time it (the data set) reaches the decision-maker, no one
knows of its origin or transformations applied to it before it reaches
its destination, leaving behind a stream of small data objects called
data puddles. These non-traceable data puddles lead to severe data
quality and data management problems across an enterprise. In the
next section, I discuss how problems like data puddles are resolved
by using data warehouse architectures.

Data Warehouse Categories

Terms used to define data warehouse objects vary from one vendor
to another and can be divided into the following categories:

Data Warehouse. This is conceptually the same as defined

by Inmon. It could be one large physical instance or a
collection of several physical data object instances (detailed
and aggregated), each serving a special purpose conforming
to a grander corporate vision.

Data Mart. Data marts are stand-alone small data

warehouses limited to a subject area (for example, Sales
Analysis), as shown in Figure 1-1. Data marts can be
extracted views of a corporate data warehouse. Such data
marts, called dependent data marts, contain qualified data
and conform to corporate data standards. Data marts built
directly against the transaction systems, called independent
data marts, are often deployed in less time. Such data marts
are quickly implemented because they do not have to first
conform to central data warehouse standards and
processing, which usually takes a lot of time. Independent
data marts often result in data quality problems because they
do not conform to the corporate data standards.
 Figure 1-1:
Independent and Dependent Data
Marts.

Operational Data Store (ODS). The operational data store

is a central data repository that consists of very detailed level
transaction data. Data warehouses and data marts are built
by fetching data from ODS instead of transaction systems.
Moreover, ODS is a data consolidation and integration point
for several transaction systems. Instead of building
application-to-application interfaces, all transaction systems
have access to data in ODS to view consolidated and
detailed transaction-level information, such as a person's
name and street address for shipping an order. This detailed
information may be needed by a shipping application to print
the shipping label and not necessarily needed in a
warehouse or analytical application, where you may be
interested in using the company or Zip code for analysis
rather than individual names and street names. The ODS
becomes the data hub for both data warehouses and
transaction systems.

Extraprise Data Warehouse. Extraprise data warehouses

are the future trend in data warehousing. Such data
warehouses, along with typical decision support operations,
become an integral component of enterprise business-critical
applications-such as order administration, order fulfillment,
Customer Relationship Management-across the globe, as
well as meet business-to-business and business-to-
consumer information needs. I discuss this in detail in
Chapter 2.
Team-Fly
Team-Fly
Data Warehouse Architecture
Building a house is analogous to building a data warehouse. The
architect draws up a blueprint based on your needs and
requirements. During the design process, the architect makes sure
that your living requirements are met, house structures comply with
all building codes, and utilities and services are based on industry
standards. If the house does not adhere to an architectural plan, its
integrity will always be in question.

The key benefit of a well-architected data warehouse is that it will fit

right into your current corporate information-supply-chain framework
and will adapt to new and changing business intelligence and the
OLTP application landscape. An enterprise data warehouse
architecture defines basic principles, standards, technologies,
methodology, and common services needed to meet diverse data
objects needed for business intelligence across the corporation.
Examples of such services are a common metadata repository, data
replication or transformation standards, data access, and data load
APIs. When data marts are designed based on enterprise data
warehouse architecture, problems associated with information
content inconsistency are eliminated, and information encapsulated
in data objects has the same meaning across the enterprise decision
support systems-data marts or data warehouse. This architected
approach eliminates the data quality problems associated with data
puddles.

The SAP Business Information Warehouse (SAP BW) follows this

paradigm. Under one framework, you can have a huge extraprise
data warehouse or a hierarchy of enterprise data warehouses or
data marts, all conforming to the same architecture, infrastructure,
and information delivery methods.

Team-Fly
Team-Fly
Components of a Data Warehouse
Inmon, Ralph Kimball, and Doug Hackney have published several
books articulating traditional data warehouse architectures and
construction processes (see Appendix A). Following are the four
layers required to construct a data warehouse, which are critical to
understanding SAP Business Information Warehouse architecture
(see Figure 1-2).

Figure 1-2: The

Architectural Layers of a Data Warehouse.

Data Provider

Service Provider

Information Consumer

Data Warehouse Management

Data Provider Layer

The Data Provider layer is the primary gateway to the data sources
(OLTP applications or other). Major tasks performed at this layer
provide an environment in which to construct subject-oriented data
analysis models. Metadata (data about the data) is pulled in to a
data warehouse environment from its data sources. Extraction,
Transformation, and Transport services fetch data from data
sources, qualify, perform value-added data manipulation, and push
data out to data warehouse data objects. Key services performed at
this layer are the following:

Data Transport

Data Transformation

Data Cleansing

Data Extraction

Subject Models

Service Provider Layer

The Service Provider layer is responsible for managing and

distributing data objects across the enterprise to support business
intelligence activities in a controlled and secured fashion. At this
layer, data is further transformed for specific data analysis tasks
such as drill-down analysis and predefined reports integration with
third-party subscribed data. Moreover, data/text-mining data services
transform data into knowledge by applying analytical techniques or
combining structured and unstructured data, such as building a Web-
centric environment by authoring Web pages to merge product sales
data, charts, graphs, and product images. This layer is very complex
within the data warehouse architecture. Key services performed at
this layer are the following:
 Analytical Applications Integration

Data Distribution

Data Profiling

Data Partitioning

Information Authoring

Data Consolidation

Data Staging

Data Storage

Information Consumer Layer

The Information Consumer layer accesses information objects from

a data warehouse. Information delivery services, provided by service
providers, must be robust enough to handle large data volumes and
multimedia objects. Keep in mind that not all end users have the
same needs. Some users simply want to look at a list of numbers.
Some may want to have push-button models to see charts and
graphs, and analysts may need access to large volumes of data to
do extensive data analysis. Data access and delivery services must
be robust enough to handle all such scenarios. Key services
performed at this layer are the following:

Information Presentation

Search Engines

End-User Data Synchronization

Data Conversions

Information Access APIs

 Information Consumer Profiling

Global Catalogs

Information Delivery

Data Warehouse Management Layer

The Data Warehouse Management layer provides services to

manage all data objects in all layers. Additional services at this layer
include component installation, monitoring, tuning, scheduling,
networking, database operations, and component problem
tracking/analysis that can be performed globally. Key services
performed at this layer are the following:

Governing Services

Track Resource Utilization

Audit and Controls

Scheduling

Client Profile

Multi-Tiered Models

Warehouse Operations

Source/Target Management

Data Dictionary

Development Management

Hardware/Software

Security
 Metadata

Team-Fly
Team-Fly
Technical Issues in Constructing a Data
Warehouse
Due to Internet business activities and intense business-to-business
activities, today, enterprise data warehouses are not limited to the
four walls of a corporation. Today's mobile workforce and
partnerships with vendors and suppliers are forcing data warehouse
builders to provide secure access to corporate data from many parts
of the world.

Data warehouses must therefore operate in 24-7 mode. How is this

possible? Figure 1-3 shows technical issues that need attention to
support such environments.

Figure 1-3: The

Technical Aspects of a Data Warehouse.

Follow clockwise starting with Global Information Delivery.

Global Information Delivery

Global information delivery services are a must in today's data

warehouse environment. The Internet and intranets are becoming
the primary vehicles for information delivery. Though Internet
technology remains very fluid, it is still the first choice to deliver
information to end users. One must understand robustness
(scalability, security, reliability, and cost) of Web services needed to
deliver information to end users. Moreover, it is critical that such Web
services provide seamless integration and provide similar
development/management environments with the rest of the data
objects in all data warehouse layers.

Global Catalog

Global catalog goes hand in hand with the information delivery

services. Today, it is hard to find what you need because catalogs
are based on an individual data warehouse. End users spend a lot of
time finding what they need. The support of one global catalog is a
key component of a global information delivery system.

Metadata Management

Metadata management plays an integral role in the quality of

information managed in a data warehouse. Metadata is information
about the data such as data source type, data types, content
description and usage, transformations/derivations rules, security,
and audit control attributes. Access to metadata is not limited to the
data warehouse administrator but must also be made available to
end users. For example, users want to know how revenue figures
are calculated. Metadata defines rules to qualify data before storing
it in the database. The end result is a data warehouse that contains
complete and clean data.

Manageability

Managing a traditional central data warehouse is a relatively simple

task. However, in today's environment where data objects are
distributed across the world and also reside on end-user
workstations (laptops), it is a nightmare to manage such
environments. This is exactly what we are facing today. One must
question vendors on how they will manage such mobile data
warehouse environments. As part of its Customer Relationship
Management (CRM) initiative, SAP is planning a Mobile Sales
Automation (MSA) server that integrates and manages data between
the SAP Business Information Warehouse and the data sets on a
salesperson's laptop.

Adaptation of New Technologies

Implementation of an enterprise data warehouse is usually a multi-

year project. By the time you go live with a data warehouse, you
probably will have found several new technologies that are very
powerful and flexible to manage, access, and present information.
Technically, as long as you have built your data warehouse based on
an architecture using accepted industry standard APIs, you should
be able to incorporate emerging technologies without extensive
reengineering. For example, Microsoft has a generic data access
API named Open Database Connectivity (ODBC) that accesses data
from just about any relational and flat file sources.

Because ODBC cannot access data from multidimensional data

sources, Microsoft proposed another standard, OLE DB for OLAP
(ODBO), to access data from multidimensional databases. Today, if
your existing data warehouse environment uses open APIs, you can
easily join information from multidimensional and relational data
sources using ODBC. ODBO, for example, integrates
multidimensional data from SAP BW and Microsoft's OLAP server.
Soon, in-memory database technology will emerge to process large
volumes of data in memory for fast data access and manipulation.
Can your data warehouse use new technologies without overhauling
the existing design? Make sure that the data warehouse can adopt
new emerging technologies with the least amount of work. Look for
the data warehouse construction technologies that have published
APIs and automatically understand interface definition of new objects
and methods to manipulate data.

Security
In the past, data warehouse security was much easier to manage
because data warehouses were centrally controlled and end users
remained within the walls of a company. Today this has changed.
Individual roles are not defined by whom you report to but rather by
what your functions are. Moreover, mobile workforces across the
globe take on multiple roles. This makes security administration a big
challenge. A data warehouse environment must support a very
robust security administration by using roles and profiles that are
information object behavior-centric rather than pure database-
centric. For example, a role such as cost center auditor defined in a
data warehouse allows one to view cost center information for a
specific business unit for a given quarter but not to print or download
cost center information to the workstation.

Reliability and Availability

Reliability and availability are important areas in successful use of a

data warehouse. Users always want to know if the quality of
information is reliable. How is the Key Performance Indicator (KPI)
calculated? Additionally, does the infrastructure (networking gears,
hardware, database management systems) comprise reliable
products that handle large data volume needs? Are such systems
highly available? Can on-line backup and recovery/restoration of
data objects be performed without having the user log off? If a
system fails, how quickly does a standby system come up online?
Can it preserve end users' state information and allow them to
restart their work where they left off when primary systems crash?
Based on data warehouse availability needs, one can use hardware
clustering and appropriate high-availability software technologies to
build a 24-7 data warehouse environment.

New data warehouse construction products provide methods to

make systems highly available during data refresh. Products like
SAP BW refresh a copy of an existing data object for incoming new
data updates while end users keep using the existing information
objects. However, when a new information object is completely
refreshed, all new requests are automatically pointed to the newly
populated information object. Such technologies must be an integral
component of enterprise data warehouses.

Upgradability and Continual Improvements

The ability to upgrade and continually improve a data warehouse

environment without disruptions is necessary for a 24-7 environment.
What this means is that if any component of a data warehouse
(database management system, hardware, network, or software)
needs upgrades, it must not lock out users, preventing them from
doing their regular tasks. Moreover, any time a new functionality is
added to the environment, it must not disrupt end-user activities.
This may seem impossible, but it's not. For example, one can apply
certain software patches or expand hardware components (storage)
while users are using the data warehouse environment. During such
upgrades, end users may notice some delays in retrieving
information, but they are not locked out of the system.

Scalability and Data Distribution

Scalability and data distribution are major challenges facing today's

data warehouses. Often, scalability of an environment is equated to
data volume or number of users. This assumption is somewhat true
for OLTP applications. In a data warehouse, hundreds of users may
be accessing a predefined report without any performance
degradation. On the other hand, a few analysts can bring the entire
system to a grinding halt by performing very complicated queries or
doing data mining against large data volumes. Note here how a data
warehouse environment scales to support both types of users, those
performing complex and light data manipulations, under one
umbrella by using application servers.

Due to large data volume movement requirements, data warehouses

consume enormous network resources (four- to five-fold more than a
typical OLTP transaction environment). In an OLTP environment, one
can predict network bandwidth requirements because data content
associated with each transaction is somewhat fixed. In data
warehousing, it is very hard to estimate network bandwidth to meet
end-user needs because the data volume may change for each
request based on data selection criterion. Moreover, large data sets
are distributed to remote locations across the world to build local
data marts. The network must be scalable to accommodate large
data movement requests.

To build dependent data marts, you need to extract large data sets
from a data warehouse and copy them to a remote server. A data
warehouse must support very robust and scalable services to meet
data distribution and/or replication demands. These services also
provide encryption and compression methods to optimize usage of
network resources in a secured fashion.

Team-Fly
Team-Fly
Data Warehouse Performance Metrics
It is a known fact that once you have a data warehouse, sooner or
later you will start receiving feedback on poor data warehouse
performance. Data warehouse performance has different meanings
to different users. For example, an end user may decide a data
warehouse is performing poorly because it takes too long (several
minutes) to run a report that displays requested data. This poor
response may happen for several reasons. It could be that the end-
user workstation does not have enough memory to display graphics,
the database engine is not configured properly, or the database
server has a slow processor. Perhaps the user encounters slow
response at a certain time of the day. But what does this all mean?
How do we assess data warehouse performance?

A data warehouse has several characteristics-dimensions-

responsible for its performance. Often only one dimension
contributes to poor data warehouse performance. For example,
narrow network bandwidth causes delays in moving data from
transaction systems as well as delivering information to end users
while data transformation and end-user query execution are not
performance issues. To end users, poor network bandwidth is
perceived as poor data warehouse performance.

Figure 1-4 shows characteristics of a high-performance data

warehouse. It shows that this data warehouse supports a large
number of users. Most users issue less complex queries without any
performance issues and have a low data warehouse
operations/maintenance time requirement, making this data
warehouse highly available. Under this environment, everyone is
satisfied with the data warehouse performance. In reality, this
seldom happens.
 Figure 1-4: Data
Warehouse Performance Characteristics.

The number of users, however, is not a good indication of data

warehouse performance. One hundred users may be issuing simple
queries and not have a problem until one analyst starts a complex
analytical job that virtually joins a large number of tables to do
complex sales trend analysis. This exercise will probably block the
data warehouse server for hours. Data warehouse architects must
design governing features to control such runaway resource-
consuming processes during peak hours.

Improving data warehouse behavior associated with individual

performance dimension translates into significant cost. For example,
if data extraction from OLTP systems takes more time than expected
due to an increase in the company business, what can be done to
fetch all newly changed data quickly? Assume that the OLTP
systems are made available for four hours each day to do regular
operations and maintenance. During this period, it is also expected
to extract new transaction data for data warehouses, but this is not
working. It requires one additional hour to extract current transaction
volumes for data warehouses.

Due to the high business activity that results from global operations,
businesses cannot afford to freeze order-processing activities
beyond four hours per day. So what choices do you have?

Keep OLTP systems down one additional hour to complete data

extraction for the data warehouse and lose new business, or just
extract all data possible during the maintenance time and then stop-
complete or incomplete data for the data warehouse?

The consequence of not having complete order operation

information in the data warehouse is that the planning, finance,
sales, and marketing organizations will not have a full view of
corporate operations, such as product inventories and what to stock
to fulfill consumers' demands. Not having this information will result
in loss of business revenues as well.

The performance issue here is that extracting complete data sets

from OLTP and loading that information in a data warehouse all in
one step can consume significant OLTP and data warehouse
resources, such as the locking up of source and target data objects,
network bandwidth, and CPU/memory usage.

One possible solution is to keep the data extraction process out of

the daily OLTP maintenance operation and break down large data
extraction processes into multiple tasks. Each task is scheduled
several times during regular OLTP business operations to extract
and move new data in the data warehouse in an operational data
store. Then refresh the data warehouse once or twice a day by
combining all incremental data sets from the operational data store
without touching the OLTP systems. Of course, this will require
planning, negotiating options with business organizations, and work
to modify data extraction code to accommodate the new extraction
scheme, hence resulting in expense.

Note In the data warehousing world, you will run into business-
and culture-related issues more often than technical.
Success of a data warehouse requires creative thinkers
with superb negotiation and people skills to resolve
organizational issues while keeping business profitability in
mind.

Change capture in OLTP applications is a complex process.

Application vendors are implementing methods to move changes to
data warehouses without locking OLTP activities. SAP has
implemented sophisticated change capture methods in OLTP R/3
applications. I will discuss SAP BW change capture techniques in
detail in Chapters 2, 8, and 13.

Data scrubbing and transformations often take a lot of time in

preparing data for a data warehouse. When, where, and how such
transformations are applied can impact data warehouse refresh time.
For example, you need to qualify an incoming order to assure
product ID, customer ID, sales organization, and order quantity
before loading it in the data warehouse. In this case, it will be worth
doing such qualification during the change capture process in an
OLTP system and not in the data warehouse. Then do additional
transformation and aggregations in the data warehouse.

Loading large data volumes in a data warehouse is an enormous

challenge. Today, in a 24-7 environment, it is not easy to bring down
a data warehouse for several hours a day to refresh with new
changes. Reducing large data load time requires a combination of
high-performance hardware gears and software components to load
and process data in parallel. Another option to reduce data load time
in a data warehouse is to drop table indexes prior to loading data:
Load data in the warehouse and re-create indexes.

Network topology is one area that needs special consideration

when measuring data warehouse performance. A high-speed
network connection between OLTP and data warehouse servers will
definitely reduce the time it takes to transport large data volumes. If
your data warehouse uses multi-tiered architecture, put data-volume-
intense application servers on a high-speed network channel with
fewer network hops. Moreover, put OLTP and OLAP users on
separate network routes. This way OLAP users do not cause any
network contention for the OLTP users.

The next chapter discusses how SAP BW addresses such data

warehouse performance metrics when implementing an extraprise
data warehouse.
Team-Fly
Team-Fly
Evolution of ERP Data Warehousing
One of the most difficult problems in building a data warehouse is
selecting the right mix of data warehousing products and tools. The
continual rapid evolution of data warehousing tools makes the
determination of a short list of products even more difficult. By now,
you realize that a data warehouse consists of several architectural
layers, each requiring a unique set of functionality, and hence
several tools/technologies for each layer providing unique services.
A typical data warehouse may have data extraction tools from one
vendor (or homegrown), databases from a different vendor, and data
warehouse construction tools from another vendor, with end-user
data access applications built using several development tools. This
situation becomes worse when individual organizations within a
company select their own tools to develop data warehouses or data
marts. Managing, training, and supporting several technologies,
negotiating contracts for each product, and dealing with several
vendors becomes a very expensive proposition.

The data warehouse construction scenario sounds very familiar to

what happened to the earlier OLTP applications. Take a look at a
typical applications landscape in a corporation.

Typically, a corporation may have one application for human

resources, one for order administration, one for finance, one that
tracks manufacturing, one for planning, and another to track
deliveries-each serving a unique and discrete function. Fortunately,
the OLTP world has some industry standards for business
communications and technologies. Though the OLTP applications
vendors provide similar products and speak common terminology to
build mission-critical applications, they seldom use the same
technologies. Integrating business processes among several OLTP
applications to build a seamless supply chain management solution
is still a major challenge. Here comes ERP to address the very same
issue: business process integration.
Let's take a quick look at the evolution of ERP. Figure 1-5 shows the
convergence of ERP industries over time. During the 1970s,
manufacturing resource planning (MRP) systems evolved in the
manufacturing industries to manage inventories. These applications
worked but were not business-process-aware. Then, during the
1980s, MRP II was developed to improve process efficiency and
data integration. During the late 1980s, Internet technology flowed
out of the academic world into the business community; all the
application vendors started to patch Web front-ends onto their
applications, and the nightmarish task of integrating legacy
applications over the Internet befell IT workers. Supporting hundreds
of applications-sometimes similar in functionality-within a company,
as well as the interfaces among them, became a very expensive
proposition.

Figure 1-5: Evolution of

ERP Applications and Data Warehousing.

A few application vendors took this opportunity and packaged

common business applications under one technology framework.
The essence behind such packaged applications was integration and
optimized resource utilization. Thus ERP was born. Most ERP
vendors were also quick to declare their products to be Y2K-bug
free. The early to mid-1990s were very good years for ERP vendors.
That these applications were Y2K-bug free and provided integration
had much to do with their acceptance in the business community.

The data warehousing industry, like ERP, has gone through its own
evolution. In the 1970s, as shown in Figure 1-5, data warehouses
existed just to track business processes and print those famous
"greenbar" reports in batches for distribution to managers, who
usually needed only a few sheets off the thick stack of reports.

Then, in the mid-1980s, a few companies launched departmental

data warehousing projects, and a new term, "data mart," became
common in the data warehouse industry. These data marts were
quick to build and were used to understand business processes.
Then, mostly spreadsheets were used for data storage and analysis,
which in the 1990s led to extensive use of multidimensional and data
mining technologies to analyze large amounts of data to improve
business processes. Toward the late 1990s, the data analysis trend
began shifting from business process improvements to prediction of
business trends and provision of almost real-time feedback to OLTP
processes to complete an in-progress transaction, such as detection
of a fraudulent transaction.

This brings us to the beginning of the new millennium, when mission-

critical applications and analytic applications are converging on a
common infrastructure to provide robust enterprise information-
supply-chain frameworks. This tight integration between OLTP and
data warehousing is the essence of ERP data warehousing.

Today, the business world is characterized by an environment in

which responsiveness and globally integrated operations are key to
success. This success is achieved by using Enterprise Resource
Planning (ERP). Software packages that support ERP are known as
Enterprise Applications. Enterprise Applications, such as SAP R/3
and PeopleSoft, are sophisticated software suites that enable an
organization to automate and integrate its supply-chain processes.
ERP vendors have bundled several business-critical applications in
an integrated fashion under one framework that is configurable
based on individual company business models (rules).

Until recently, ERP vendors focused mostly on enhancing the

infrastructure to deliver high-performance OLTP solutions. Very little
attention was given to providing business intelligence applications to
analyze massive amounts of data collected, or "jailed," within the
ERP applications data repositories. Customers were left to building
data warehousing and reporting solutions without any help from ERP
vendors.

As stated earlier, one of the most difficult problems in constructing a

data warehouse is selecting the right mix of data warehousing
products and tools. Today, ERP vendors have recognized this need
and have launched major development programs to deliver data
warehousing solutions. Along with the ERP vendors' data warehouse
initiatives, a wave of traditional data warehouse tools providers have
launched ERP data warehousing initiatives. These ERP data
warehousing initiatives extract data from ERP package applications
to build reporting and data analysis environments, called ERP data
warehousing. But what is ERP data warehousing?

ERP data warehousing is a framework of information objects that

become the foundation of business intelligence and knowledge
support systems across the enterprise, leveraging the infrastructure
of ERP applications.

Note Simply extracting data from an ERP application package is

not ERP data warehousing. An ERP data warehouse
supports a collection of integrated applications to report,
analyze, and control business events across the enterprise,
not just the data extractions.

True ERP data warehouses leverage the OLTP applications'

infrastructure. But what is an ERP infrastructure?
ERP infrastructure is much more than a hardware configuration or
networking gears; it is defined and characterized as the following:

System Configuration and Support. Similar methods and

technologies to manage OLTP and data warehouse
environments.

Development Life Cycle (Development-Quality

Assurance-Production). Similar methodology between
OLTP and data warehouse application development, change
management, release control, project management, and
path-to-production procedures.

Administration and Monitoring of Data Warehouse

Operations (Performance, Logs, Backup, Restores,
Batch Processes, Real-Time Processes, EDI). Similar
tools and technologies to monitor and administer OLTP and
data warehouse environment.

Enabling Technologies (DBMS, Middleware, Client),

Multi-Tiered Architecture, Load Balancing, Debugging,
Problem Tracking and Reporting, Intra-Instance
Communication, High Availability, Database
Performance Monitoring, Security Models, Metadata, and
More.

Similar Implementation Methodologies and Support

Structures.

These are just a few characteristics of an ERP infrastructure. When

OLTP and data warehousing solutions are based on similar
architectures, tools, technologies, and development and deployment
methodologies, you do not need to build teams dedicated to support
unique applications.

Among all ERP vendors, SAP is leading the ERP data warehousing
initiatives with its offering, SAP Business Information Warehouse
(SAP BW). Note that the SAP BW scope and function is not limited
to traditional data analysis and reporting, but that SAP BW is the
core product among SAP's New Dimensions product set (which
includes Customer Relationship Management and Advance Planning
Optimizer). SAP BW will support several business processes within
an enterprise as well as the information needs of partners, vendors,
and customers. SAP BW is truly an extraprise data warehouse.

Team-Fly
Team-Fly
Summary
In this chapter, you learned about the basic concepts behind data
warehousing and its building blocks. You also now have a good
understanding of technical issues in constructing a data warehouse
and the areas that affect data warehouse performance. You have
also learned what ERP data warehousing is and how it is different
from other data warehouse solutions.

In the next chapter, you will learn reporting strategies for SAP R/3,
including the type of reporting and analysis suitable on SAP R/3,
common reporting architectures, and the SAP Business Information
Warehouse system architecture and its components.

Team-Fly
Team-Fly
Chapter 2: Evolution of SAP Business
Information Warehouse
A Quick Look at SAP R/3 Architecture and
Technologies
Founded in 1972 in Mannheim, Germany, as Systemanalyse und
Programmen-twicklung to produce and market standard software for
integrated business solutions, today that company is known as SAP
(Systems, Applications and Products in Data Processing),
headquartered in Walldorf, Germany. SAP built packaged
applications for mainframe computers, called SAP R/2. As the
client/server technologies emerged in the early 1980s, SAP
launched a major initiative to engineer powerful three-tiered
integrated business applications under one framework. The SAP R/3
product is the outcome of that initiative.

Note Often, people ask what R/2 and R/3 mean. The letter R
stands for real-time, and 2 and 3 represent two-tiered and
three-tiered architectures, respectively. SAP R/2 is for
mainframes only, whereas SAP R/3 is three-tiered
implementation using client/server technology for a wide
range of platforms-hardware and software. When
implementing a Web front-end to an SAP R/3
implementation, the three-tiered architecture becomes
multi-tiered depending on how the Web server is
configured against the database server or how the Web
server Itself distributes the transaction and presentation
logic.
 Figure 2-1: SAP R/3
Business Applications.

All SAP R/3 business applications use an active dictionary to store

all business rules defined to run business. These business and
workflow rules keep information flowing among application modules
in a controlled and secured fashion. The "ABAP Workbench" is used
to develop business programs using the Advanced Business
Application Programming (ABAP) language. The Basis technology is
responsible for managing R/3 infrastructure such as software
installation, operations, and administration.

SAP R/3's multi-tiered architecture enables its customers to deploy

R/3 with or without an application server. Common three-tiered
architecture consists of the following three layers:

Data Management

Application Logic

Presentation

The Data Management layer manages data storage, the Application

layer performs business logic, and the Presentation layer presents
information to the end user.
Most often, the Data Management and Application Logic layers are
implemented on one machine, whereas workstations are used for
presentation functions. This two-tiered application model is suited
best for small business applications where transaction volumes are
low and business logic is simple.

When the number of users or the volume of transactions increases,

separate the application logic from database management functions
by configuring one or more application servers against a database
server. This three-tiered application model for SAP R/3 keeps
operations functioning without performance degradation. Often,
additional application servers are configured to process batch jobs or
other long and intense resource-consuming tasks. This separation of
the application server enables system operations staff to fine-tune
individual application servers suited for specific data processing
tasks, as shown in Figure 2-2.
 Figure 2-2: SAP R/3 Deployment Architecture.

Team-Fly
Team-Fly
Reporting Environment in SAP R/3
SAP offers a collection of more than 2,000 powerful and flexible
business reports in R/3. These reports are spread across all
application modules. Navigating through several information systems
to find specific reports is a huge challenge. SAP also provides
several reporting tools in R/3 to build queries and reports against
operational data. Details of such tools are discussed later in this
chapter.

The Simplification Group at SAP has developed Report Navigator

and Report Tree tools that make it easier to organize and search
reports in R/3. For additional information on Report Navigator, visit
the SAP simplicity Web site at http://www.saplabs.com/simple.

Major application modules in R/3 fall in the following business areas:

Logistics

Financials

Human resources

Industry specific

Several information systems exist in R/3 that provide a reporting and

data analysis environment limited to specific application modules.
Information systems in R/3 are similar to data marts where subject-
specific data is collected and stored in database tables dedicated for
reporting. R/3 information systems provide you with information that
enhances the capabilities of more than 2,000 standard R/3 reports.
Here you can combine data from non-R/3 data sources with R/3 data
for reporting. In the following sections, I will discuss data
warehousing environments provided within R/3 for data analysis and
reporting for information systems relevant to Business Information
Warehouse.
Open Information Warehouse and Information Systems
in SAP R/3

Information systems in SAP R/3 are components of SAP's Open

Information Warehouse (OIW) framework. The vision behind OIW is
to provide a cross-application data analysis environment providing
very summarized information with charts and graphs suited best for
senior executives, as shown in Figure 2-3.

Figure 2-3: SAP R/3

Reporting Environment.

Individual information systems-LIS, FIS, HIS, and so on-in SAP R/3

are limited to a specific application area and associated data objects,
except the EIS. These information systems provide an effective
method of retrieving summarized data. Following are the major
information systems in R/3:

Executive Information System (EIS)

Logistics Information System (LIS)

Financial Information System (FIS)

Human Resources Information System (HIS)

Granularity of data available in information systems depends on the

type of reporting environment selected. At the EIS level, you access
summarized information that can go horizontally across one or more
application modules. In other information systems, you are limited to
only one application area at a time. With ABAP/Query and ABAP,
you can access transaction tables; hence, access to transaction
level detailed information is available. ABAP Query and Report
Writer/Report Painter are regarded as ad hoc reporting tools.

Logistics Information System (LIS)

The LIS is widely used by R/3 customers and plays a major role in
preparing information for SAP BW. It consists of the following sub-
information systems (the list may vary based on the SAP R/3 OLTP
release):

Sales Information System (SIS)

Purchasing Information System (PIS)

Inventory Controlling (INVCO)

Shop Floor Information System (SFIS)

Plant Maintenance Information System (PMIS)

Quality Management Information System (QMIS)

Retail Information System (RIS)

Warehouse Management Information System (WMIS)

Transportation Information System (TIS)

Under the LIS environment, several predefined database tables

enable customers to quickly develop reports. The following describes
how LIS reporting systems work.

Based on business events in R/3-for example, creating an order

(transaction VA01)-the LIS Interface (Communication Structure)
gives selected data generated by transactions to update rules that in
turn update special tables, called information structures.

R/3 transaction tables and LIS information structures are updated in

two modes: synchronous and asynchronous. When the synchronous
mode is selected, both the transaction tables and information
structures are updated simultaneously. However, when the
asynchronous mode is selected, transaction tables are updated first,
and information structures later. In this case, you will not find up-to-
the-second information in LIS info structures for reporting. The
reason is that the R/3 system commits transaction data quickly and
notifies the end user that the transaction is complete. This enables
the end user to start another transaction. But in the background,
SAP R/3 delivers the LIS table update job to another dialog work
process to update LIS information structures. This delay might range
from a few seconds to a few minutes, depending on your system's
available resources. Transaction OMO1 is used to define the
synchronization scheme for a specific LIS information structure. LIS
information structures are simple database tables named S001
through S499. These tables are used for reporting and analysis. You
can define your own custom information structures to capture
specific data for reporting (name range S500 through S999). SAP
BW pulls data from all LIS information structures defined in SAP R/3;
however, the update logic for SAP BW-specific information structures
varies from traditional update rules used for LIS reporting.

Tip The LIS-supported reporting environment does not access

original transaction tables at analysis time. You are limited to
the analytical data stored in an information structure but have
full visibility to the reference data stored in SAP R/3. Design
your custom information structures to capture document-
level details if that is what you need for analysis.

Financial Information System

The Financial Information System consists of the following major
sub-information systems:

Treasury Information System (TIS)

Finance Information System (FIS)

Controlling-Profitability Analysis (CO-PA)

Enterprise Controlling-Profit Center Accounting (EC-PCA)

The FIS allow users to carry out evaluations for customers, such as
payment and cash-flow history; currency risk; and overdue items,
such as due-date breakdown. The financial accounting tables are the
primary data source for FIS.

Profitability analysis provides sales, marketing, product

management, and corporate planning analysts with information for
the purpose of controlling and decision making. This requires data
from several application modules within SAP R/3, such as revenue
and sales deductions from the sales and distribution module, special
direct cost from financial accounting, and project costs from project
systems.

Executive Information System (EIS)

Under the OIW framework, information objects are stored in their

own database objects within an R/3 instance. Information in such
data objects is designed for summarized data for senior
management. Data in EIS is pulled from any SAP module desired
into a structure called an aspect. An aspect can have up to 256 fields
split between characteristics and value fields. Two hundred user-
defined characteristics are available for all aspects within an
instance.

SAP delivers programs that can pull data from the Sales and
Distribution Sales Information System (SD-SIS), Controlling-
Profitability Analysis (CO-PA), Controlling Overhead Management
(CO-OM), Enterprise Controlling-Profit Center Accounting (EC-PCA),
Financial General Ledger (FI-GL), Financial Special Purpose Ledger
(FI-SL), and Financial Consolidation (FI-LC).

Data is loaded via batch jobs, not as in LIS, which is based on SAP
R/3 business events. EIS reports are client specific and have to be
created from scratch. A client is a logical organization of a specific
business community and associated configurations in one SAP R/3
instance. Several clients can co-exist in an R/3 instance, each
governed by its own configuration, the business rules.

Data from an aspect can be pulled in an Excel spreadsheet for

analysis. Report Painter is used to create forms for the report and
provides powerful graphical capabilities such as charts and graphs,
with the exception of visual controls and drill-down reporting
capabilities, such as buttons and navigation tree visual controls.

Comparing SAP R/3 Reporting Systems

A common feature among R/3 reporting systems is that they all

collect data in special data tables. This is a preferred method for
operational reporting due to real-time data acquisition from linked
SAP modules. Several reporting systems derive data based on
update rules.

External data can also be imported in the reporting information

structures for consolidated information view.

These information systems use a variety of tools for presentation

and analysis such as ABAP, ABAP Query, Report Writer/Painter, and
LIS.

All information systems require in-depth R/3 configuration

knowledge.
This is the most important reason that reporting requirements must
be a part of overall OLTP business workflow-business rules.

Using linked SAP modules requires absolute integration with process

configuration teams. The process requirements must be stable,
because the workflow determines what data is captured based on a
variety of states and conditions defined to meet business operations
and analysis requirements.

SAP R/3 is primarily designed for a high transaction rate. Information

processing in an OLTP and a data warehouse are very different. A
few differentiating characteristics between an OLTP and a data
warehouse are listed in Table 2-1. Data warehouses require a very
different configuration due to large data volume and unpredictable
data navigation schemes. It is impossible to configure an OLTP
system as a full-featured data warehouse without having an impact
on OLTP operations. Therefore, the nature of reporting on OLTP
systems must be limited to support real-time operations and not
historical reporting. The next section addresses reporting issues
associated with R/3 information systems.

Table 2-1: Comparison of Operational and Reporting/OLAP

Environments
Characteristics Operational Reporting/OLAP
Transactions
High Volume Low to High
Rate
Response Time Very Fast Reasonable
Updating High Volume Very Low
Past, Present,
Time Period Current Period
Future
Data Volume
Low High
Per Request
Characteristics Operational Reporting/OLAP
Scope Internal Internal, External
Focused, Analytical,
Activities Clerical, Exploratory,
Operational Managerial
Predictable, Unpredictable, Ad
Queries
Periodic Hoc

Team-Fly
Team-Fly
Limitations of SAP R/3 Reporting
One of the hardest tasks in developing a reporting environment in
R/3 is selecting one data access and analysis tool that satisfies end-
user needs. The following are the major shortfalls of native SAP R/3
reporting:

Information on existing reports is either missing or unclear.

Searching a report among thousands of available reports in
R/3 is a big problem. The Report Navigator, developed by
SAP's Simplification Group, is a good attempt to solve this
problem.

Available reports are designed to meet operational and

transactional information needs. Most reports are predefined,
list oriented, and provide very limited OLAP functionality.

Several reporting modules and associated reporting tools

make it hard to select a specific tool. Reporting tools are
inconsistent, and designing reports is a complex process.
Maintenance of thousands of reports for software upgrades
is a huge challenge. Knowledge of how often a report is used
is not available, such as which reports are frequently used or
ever used. As a consequence, all reports need to be
maintained regardless of their usage. Recently, SAP has
provided utilities to track report-usage statistics that will help
identify which reports are to be upgraded or dropped in a
release upgrade or support.

Fragmented reporting menu access requires extensive end-

user training to navigate through several multi-level menus to
display a few reports.

Performance impact on R/3 OLTP operations due to

reporting is another major issue. The R/3 systems are
configured to provide high OLTP transaction rates. Building a
robust reporting and OLAP environment under an OLTP
 environment requires different configuration parameters that
will degrade OLTP operations. See Table 2-1, which lists the
common differences between OLTP and Reporting/OLAP
environments.

To overcome OLTP and reporting co-existence problems, several

customers have attempted to build a separate R/3 environment
dedicated to reporting. I discuss a few such models in the next
section. But first, I'd like to look at how SAP planned to re-architect
R/3 application components in the early '90s.

Application architects at SAP planned to break down the traditional

SAP R/3 very tightly integrated application modules into several
loosely coupled applications; these applications would still be
connected to each other by use of Application Link Enabling (ALE)
technology (ALE is SAP's EDI-like middleware. I discuss ALE in
much more detail in the next few sections.). This new distributed
application concept became what is known as SAP Business
Framework Architecture, as shown in Figure 2-4. Due to the
mySAP.com initiative, the SAP Business Framework today looks
quite different from when it was proposed in the early 1990s, as
shown in Figure 2-4. However, the core concept behind the SAP
Business Framework remains the same-loosely coupled business
components. The only difference is that today the integration
technologies are becoming Internet-centric, replacing pure ALE and
new business components to support business to business (B2B),
business to customer (B2C), Customer Relationship Management
(CRM), and business intelligence, and have taken higher priority
than breaking SAP R/3 modules into individual stand-alone
applications.
 Figure 2-4: SAP
Business Framework Architecture.

The intent of Business Framework is to make individual application

components stand-alone manageable entities that still have a robust
business level integration among all. ALE technology became the
"glue" that holds all application modules together. All SAP New
Dimension products are built under this business framework. The
Business Information Warehouse is one such product.

Now I'll return to reporting issues in R/3 and how customers are
building reporting environments.

Team-Fly
Team-Fly
Strategies to Build SAP R/3-Centric Data
Warehouse Environments
You now have a good idea about R/3 reporting systems and their capabilities
and limitations. When you decide to build a data warehouse within or outside
of R/3, think of the following key functions:

Separate OLTP/OLAP Environments

Optimized Reporting Environment

Loaded Daily or More Frequently

Historical Information

Flexible Software Releases

Incorporate Non-SAP Data

Open Environment

SAP customers have taken several approaches to building a data warehouse

using R/3 technologies. In the next section, you will see common R/3 data
warehouse models, and later in this chapter, I will discuss how they meet the
key functions listed earlier.

Database-Centric Data Warehouse

The database-centric approach is simple. Make a copy of an R/3 database for

users to report against. Conceptually, the idea is simple, but it is an
operations nightmare to keep R/3 OLTP and R/3 reporting in synch.

As shown in Figure 2-5, to do a full backup of the OLTP database (Step 1)

and restore it for reporting is a very time-consuming task (Steps 2 and 3).
 Figure 2-5: R/3 Database-Centric
Reporting Environment.

Then prepare the copied instance for the reporting environment (Steps 4
through 6). Here you load new users and security profiles needed for
reporting. When the newly refreshed database server is ready for production
reporting, the old database server is moved back to the staging state for the
next OLTP data refresh, as indicated in Step 7, which is repeated to refresh
the reporting environment again using another set of hardware gears. This
approach may work for small R/3 OLTP instances, but for large databases, it
is virtually impossible to rebuild another R/3 database daily. Typically, you
need to perform all seven steps, as shown in Figure 2-5, which is very time
consuming. This means you also need two sets of database servers for
reporting-one for production reporting and another for refreshing-an
expensive proposition.

The benefit of this model is that you will have no performance degradation on
your R/3 OLTP environment due to reporting and data analysis activities. You
can define special user authorization and profiles for reporting users (Step 5).
This R/3 can also become the data source for intra-application data instead of
OLTP R/3.

The problem in this approach is that you have access to only the data that
exists in the OLTP instance; you have no historical data to report on.
Moreover, you will face the same limitations and complexities of R/3
information systems and reporting tools that are not Web enabled. This
database-centric approach will be an expensive proposition due to additional
hardware and intense operations tasks to keep both instances operational at
all times.

ALE-Centric Data Warehouse

Using the ALE model, you do not copy a full database but rather use ALE to
propagate specific changes into the reporting environment-another R/3
instance. Originally, ALE technology was designed to move data from one
instance to another based on a workflow model triggered by business events.
However, customers have used ALE technology to propagate data
programmatically from one R/3 instance to another instead of its being
triggered by business events.

Based on the customer's business model, ALE packages transaction and/or

master data in the form of Intermediate Documents (IDOCs). IDOCs are data
containers similar to EDI standard documents. Figure 2-6 shows an example
of how Digital Equipment Corporation used this approach to implement an
ALE-based reporting environment in 1997.

Figure 2-6: SAP ALE-Centric R/3 Reporting Environment.

Under this distributed R/3 business model, four individual R/3 instances were
connected via ALE: one R/3 instance to manage master data; one R/3
instance for financial operations; one instance for logistics operations; and
one instance for reporting. Under this model, special SIS structures and
special ledger structures are transferred to reporting instances using ALE,
copy management, and some homegrown techniques to synchronize objects
across all instances. ALE copied new changes in the reporting instance at 10-
minute intervals. In this example, ALE could not move all needed data from
SAP R/3 OLTP to the reporting SAP R/3 instance. The copy management
technique was used to move the data that ALE could not move.
Additional SIS structures were updated within the reporting instance using
copy management techniques to build additional tables containing several
levels of aggregated data for reporting. This enabled end users to access
near real-time data without impacting performance on the R/3 OLTP
operations. For corporate central data warehouses, new data was extracted
from the reporting instance instead of the R/3 OLTP instance.

The ALE-centric reporting environment has several advantages, such as the

following:

Contains only that data required for reporting and analysis. It is not an
identical copy of OLTP R/3 instances.

Can accumulate historical data.

Can import non-R/3 data for reporting.

The disadvantages of this environment are the following:

Has the same inflexible R/3 reporting tools.

Requires additional application servers to manage ALE traffic for all

four instances.

ALE technology is not rich and mature enough to handle large data
volumes and user-specific data objects.

Physical database implementation is still R/3-transaction-centric. Has

no true multidimensional star data structures.

Is heavy on hardware/software/network resources.

Third-Party-Tool-Centric Data Warehouse

Almost all customers have implemented data warehouses using technologies

provided by third-party vendors. Most SAP customers write custom data
extraction programs in R/3 using ABAP. In recent years, several data
warehouse tool providers have offered sophisticated data extraction
techniques to extract data from R/3 and other ERP data warehouses.

Often, third-party data extraction tools work to a point when transaction and
associated data volume is small and business rules/configuration behind such
data sets is simple. Some data extraction tools extract data at the database
level, leaving critical data behind in pool and cluster tables (SAP proprietary
database tables from which data is accessed or manipulated through ABAP
programs and not directly via SQL statements). Often, the ABAP code
generated by these tools is not optimized enough to fetch and transport data
in the most efficient manner. One of the major problems in implementing a
third-party solution is that the OLTP and data warehouse/OLAP teams do not
share the same infrastructure. You end up managing, training, and supporting
two completely different teams (skills, knowledge, and resources). It is
expected, however, that such data warehouses will still exist even with all the
difficulties described here.

It is clear from data warehouse models and the functionality comparison, as

shown in Figure 2-7, that the only benefit of building a reporting environment
in the R/3 OLTP environment is that you have access to transaction-level
detail. The database-centric model has the same advantage as R/3 OLTP but
with one difference: R/3 OLTP and the reporting environment are separate
instances. On the other hand, the SAP ALE-centric model does satisfy
several requirements but still is limited by R/3 schema and reporting tools
functionality. SAP BW is expected to meet all data warehouse and reporting
requirements.

Figure 2-7: Functionality Comparison of R/3 Data Warehouse Models.

Team-Fly
Team-Fly
Evolution of Business Information Warehouse
In 1997, SAP launched an initiative to extend the reporting and analysis
capabilities in the R/3 OLTP environment. This initiative was a direct result of
SAP customers' strong, unified voice on providing a robust, stand-alone data
warehousing environment. This initiative, once called the Reporting Server,
became the largest development project in the history of SAP after the SAP R/3
development. SAP selected five companies to pilot SAP BW in 1997. In 1998,
SAP launched a so-called Early Customer Program (ECP) with six customers to
gather requirements and to do a proof of concept at customer sites. Digital
Equipment Corporation was among the participants in the ECP program.
Release 1.2A of BW was made available to the public in September 1998.

SAP Business Information Warehouse is the latest generation of business

intelligence solutions. SAP BW is not only a data warehouse, but also forms a
data integration hub for SAP New Dimension products. BW is also one of the
New Dimension products. From data extraction to data management and
analysis, SAP BW provides a robust set of decision-support and reporting
capabilities that function as a single packaged software solution. SAP BW
software enables users to build an open and dynamic data warehouse needed to
share information across the New Dimension products under the mySAP.com
framework.

The Accelerated SAP (ASAP) methodology for SAP BW is an excellent way to

implement BW.

Though SAP BW ASAP methodology is comprehensive, individual consulting

and system integration organizations may enhance or add value to SAP BW
ASAP methodology due to their business practices and methodologies. Make
sure that their SAP BW methodologies are aligned with the SAP BW ASAP
methodology.

Business Information Warehouse Architecture

Business Information Warehouse is an end-to-end data warehousing solution.

BW is not an add-in reporting module in an R/3 OLTP system. BW is a
standalone product built on top of R/3 BASIS technology. Chapter 1 discusses
four technical layers needed to build a data warehouse. In this section, you learn
how these four layers are architected in BW, as shown in Figure 2-8.
 Figure 2-8: Architecture of Business
Information Warehouse.

The data provider services manage all interfaces to all inbound data objects. The
inbound data may come from R/2, R/3, or files with known data structures. An
SAP BW instance can be a data source to another SAP BW instance. A special
programming interface, called Staging Business API (BAPI), is used to pull data
in BW. To implement Staging BAPI solutions, I have used Informatica's Power-
Center, ActaWorks for SAP BW from Acta Technology, and Genio from
Hummingbird. Today, several Staging BAPI-certified data Extraction,
Transformation, and Load (ETL) tools from several third-party vendors are
available. You learn more about Staging BAPI implementation in Chapter 13,
"Enhancing Business Content and Developing Data Extractors."

The service provider layer in Figure 2-8 is the heart of the BW engine. It is here
that SAP BW manages all data objects in several persistent data objects such as
Metadata, InfoCube, and ODS. Services at this layer interface with data provider
services to offer a robust data staging process. The intelligent OLAP processor
manages all end-user OLAP activities and processes user requests in a very
efficient way. Based on the Microsoft multidimensional database access
standard, OLE DB for OLAP (ODBO), SAP has implemented a set of BAPIs that
enables third-party tools to access BW data without knowing the complexities of
BW data structures. The list of ODBO-certified vendors is rapidly growing. Check
the SAP Web site at http://www.sap.com/bw for an up-to-date list of ODBO-
certified vendors. To demonstrate ODBO integration with SAP BW 1.2B and
2.0A, I used third-party vendor products from arcplan, Brio Technology, and
Business Objects to build analytical applications; I also used inSight from arcplan
to build pure ActiveX/ODBO-based pure Web analytical applications. Use ODBO
implementation to build a pure Web application using ActiveX controls. You learn
how to use ODBO to access data from SAP BW in Chapter 15, "Integrating
Third-Party Data Access Products with SAP BW."

The information provider layer in SAP BW is a powerful information delivery

architecture using Business Explorer. The Business Explorer Analyzer enhances
Microsoft Excel 97 with additional functionality to analyze data combining several
workbooks to build a complex data analysis environment. Services at this layer
manage all user activities. Information is delivered to authorized consumers from
a global catalog, which is tightly integrated with user profiles. The information
delivery and service provider services work hand in hand to optimize resource
utilization.

Prior to SAP BW 2.0, the only way to publish SAP BW reports/queries on the
Web was to save a BEX Analyzer-generated worksheet on the Web server that
could be launched via Internet Explorer; however, the SAP BW front-end must
be installed on the client workstation to navigate data received. Internet Explorer
can open the BEX worksheet, and it will launch the BEX Analyzer session for
data navigation and analysis. However, in BW 2.0, you can use the SAP Internet
Transaction Server to publish BEX Analyzer Queries in HTML format, which can
view data from SAP BW dynamically from Internet browsers, as shown in Figure
2-8 on the top left block enclosed with dotted lines.

The SAP BW data warehouse management layer manages all operations, such
as software upgrades, change management, performance tracking, scheduling
jobs, and security management. It is similar to the R/3 administration
environment.

This means that the R/3 BASIS and database support team can manage the
SAP BW environment without much training.

Note SAP BW is not just a collection of integrated tools to build and support
data warehouses. It comes with rich business content (predefined data
extractors, InfoCubes, and analytics) with a predefined reporting
environment that is ready to use against your SAP R/3 OLTP Instance.

The staging engine is a "process" that facilitates data sourcing and construction
of information objects within SAP BW. The staging engine process spreads
across the data provider and service provider architectural layers. You learn
more about the staging engine in the next two sections.

Business Content in the Business Information Warehouse

SAP BW is built on several classes of "information objects," which come in many

shapes and forms. The best way to understand these objects is to install SAP
BW business content and understand how such objects are defined, linked, and
configured in SAP BW. The business content in SAP BW 1.2B and BW 2.0
comes with several demo applications, such as Sales and Distribution and
Profitability Analysis. These are good examples, and I suggest you explore these
demo applications before designing your own.

Business content, as shown in Figure 2-9, consists of the following objects (in
BW 1.2B and BW 2.0A):

Figure 2-9: Business Content in SAP BW 1.2B and BW 2.0A

InfoObject. An InfoObject is a basic entity defined in SAP BW. There are

two types of InfoObjects: characteristics such as customer, product, and
vendor; and key figures such as total cost, revenues, and so on. More
than 1,000 InfoObjects are predefined in BW 1.2B, and more than 2,000
in SAP BW 2.0A, across all application modules of R/3.

Data Extractor. Several function modules and generic data extractors

fetch master data, text, hierarchies, and transaction data from an R/3
instance. Customers can enhance existing data extractors or write their
own extractors using BW data extraction protocol.

InfoSource. An InfoSource is a collection of InfoObjects that are logically

connected. Data that logically belongs together from a business point of
view and can be transported from the source system into SAP BW is
offered together in one InfoSource. The InfoObjects, as shown in Figure
2-10 within the dotted circle, represent one InfoSource. SAP BW 1.2B
provides more than 90 InfoSources; BW 2.0A has more than 110. In SAP
BW 2.0A, the InfoSource boundaries, the dotted line in Figure 2-10, are
no longer valid.
 Figure 2-10: SAP BW Staging Process in SAP BW 1.2B and SAP BW
2.0A.

InfoCube. An InfoCube is a collection of several database tables that

supports multidimensional slicing and dicing for OLAP analysis. An
InfoCube is based on an extended star-schema model. A fact table
containing individual transaction facts (measurements) is attached to a
unique set of dimension tables needed to view facts at different angles
(dimensions). SAP provides 45 prebuilt InfoCubes in BW 1.2B and more
than 100 in BW 2.0A.

Query. A query is a data subset of a specific InfoCube. These queries

are designed to capture most common business analysis scenarios.
More than 180 queries across 45 InfoCubes are available in BW 1.2B
and more than 450 in SAP BW 2.0A.

Workbook. A workbook is a collection of Microsoft Excel spreadsheets

with embedded queries to provide a solution set. More than 180
workbooks are available in BW 1.2B, and more than 500 in SAP BW
2.0A.

Key Performance Indicators (KPI). More than 1,000 KPIs are available
in BW 1.2B. KPI is a result of a query or subset of a specific measure
permanently stored in an InfoCube.

Channels. A channel is a mechanism that organizes information

catalogs to disseminate information. Channels use push technology.
SAP provides 10 channels in BW 1.2B. End users can create their own
channels and assign reports to channels by using the InfoCatalog
manager. In SAP BW 2.0A, the channels are called Activity Groups.
More than 70 Activity Groups are available in SAP BW 2.0A.
Business content in SAP BW is increasing with each release. In SAP BW version
1.2B, the business content covers logistics, accounting, and human resources. A
complete list of business content is included in the SAP BW kit on CDs. A very
brief summary of business content is listed here.

With the release of SAP BW 2.0, the business content strategy has changed
from application specific to horizontal and vertical industry focused, such as
retail, high tech, utilities, finance, and energy.

The logistics area covers sales controlling, procurement, inventory

control, warehouse management, plant maintenance, quality
management, production planning, service management, and project
system. Key performance indicators for the logistics area include
incoming orders, sales, returns, order fulfillment rate, inventory turnover,
material days of supply, delivery time, scrap, service level, lead time,
scheduled delivery date variance, and capacity utilization. These KPIs
are provided in the form of a query or a pre-calculated fact stored in an
InfoCube.

The accounting area consists of a general ledger, a special ledger,

accounts receivable, accounts payable, asset accounting, cash
management controlling, product costing, overhead cost, profitability
accounting, profit center accounting, enterprise consolidation, and
investment management. SAP provides a rich set of KPIs in this area
such as profit, return on investment (ROI), contribution margins,
liabilities, Day Sales Outstanding, cash position by day or currency,
deprecations, cost variances, cost of overhead, and investments.

Human resources business content includes personnel administration,

payroll accounting, time management, recruitment, and training and
event management. The HR KPIs in SAP BW 1.2B consist of headcount,
productivity rate, illness rate, overtime, wage type overview, applications
per offer, applications per entry, fluctuation rate, event costs, and fees.

The business content in the preceding list is not complete. It simply outlines the
subject areas that SAP BW business content addresses. I recommend reviewing
the documents that come with the SAP BW installation CDs for a detailed list of
business content.

Staging Engine

The staging engine in SAP BW consists of several processes that gather data
from data sources, clean and perform data transformation, and populate
InfoCubes.

In BW terminology, the staging process is described in the following five steps

(when the data source is SAP R/3), as shown in Figure 2-10. Though the staging
process steps in SAP BW 1.2B and BW 2.0 have remained the same, the
boundaries, shaded areas in Figure 2-10, of the InfoSource have changed. Note
that in SAP BW 1.2B the scope of InfoSource spans all the way to the source
OLTP systems, as shown by the shaded area. In SAP BW 2.0, the original
InfoSource is broken into two separately logically connected objects, the
DataSource and the InfoSource, as shown on the left in Figure 2-10. The reason
for this InfoSource separation is that in SAP BW 1.2B, when you load data, you
schedule at an Info-Source level, meaning to pull data from all source systems
attached to an InfoSource. You could not load data selectively from one data
source when an InfoSource had multiple data sources attached. In SAP BW 2.0,
due to Info-Source and Data-Source logical separation, one can select a
DataSource to pull data from.
1. SAP R/3 OLTP prepares needed data using the Extract Structure.

2. Extractor in SAP R/3 OLTP moves data to a Transfer Structure.

3. Using ALE or tRFC technology, SAP R/3 copies data to SAP BW in the
form of Transfer Structure.

4. Using transfer rules defined in SAP BW, SAP R/3 data is transferred
into the Communication Structure.

5. The Update Rules in SAP BW update InfoCubes out of the

Communication Structure.

The data staging process is responsible for processing transaction data, master
data, text, and hierarchies needed to build the extended star schema in SAP
BW. Because update rules are source system independent, it is here that you
qualify data coming from several R/3 instances and/or external data before
updating an InfoCube.

Data Access Using Business Explorer and OLAP Processor

SAP BW does not use traditional R/3 OLTP reporting tools such as ABAP Query
or Report Writer. It uses the Business Explorer (BEX). Business Explorer
consists of two components: Browser and Analyzer, as shown in Figure 2-11.
The BEX Browser is a Web-centric environment that provides access to a
corporate information repository primarily based on SAP's BW InfoCatalog.
 Figure 2-11: Business Explorer Browser and Analyzer.

You can use BEX Analyzer to execute queries without the BEX Browser. Note
that the BEX Browser, and not the BEX Analyzer, has complete access to all
objects in the Enterprise catalog that stores SAP BW and non-SAP BW
references. Therefore, using BEX Analyzer, you are limiting visibility to the global
catalog content that relates to the InfoCubes queries only. You learn more about
developing queries using BEX Browser in Chapter 11, "Analyzing SAP BW
Data."

BEX Analyzer is an Excel add-in (SAPBEX.XLA), as shown in Figure 2-12, that

turns an ordinary Excel spreadsheet into a powerful SAP BW query development
and end-user data access and analysis environment. You will do most of the
development work using drag and drop or built-in functions. You could use VBA
code to integrate several spreadsheets in a workbook to build dynamic windows
event-based data analysis solutions. Appendix B "SAP BW and SAP R/3
Transactions, Tables, and Code Examples," lists available VBA function
modules. For complex computation and data navigation schemes, you use user
exits and write some ABAP code for data manipulation.

Figure 2-12: Business Explorer Analyzer.

Caution Most seasoned ABAP programmers will jump right into ABAP;
however, I recommend that you first explore all available features in
BEX Analyzer before you start writing code in ABAP.

Data Manager
The Data Manager manages data flow and storage in the InfoCubes, the
Operational Data Store, and other database objects needed to maintain data
integrity across the BW systems.

SAP BW was first implemented on Windows NT 4.0. There were two main
reasons for developing SAP BW on Windows NT 4.0: first, to support SAP BW
on the Microsoft platform using MS SQL Server 7, and second, to support Oracle
DataBase Management Systems (DBMS) prior to implementing on a UNIX
platform. At that time-early to mid-1998-Microsoft SQL Server 7 was still a beta
product; therefore, SAP focused most BW development work on Oracle8 under
Windows NT 4.0. However, toward midsummer 1998, SAP customers pressed
SAP to implement SAP BW 1.2A on the UNIX platform as well. BW 1.2A
supported the first UNIX implementation.

SAP BW's multidimensional capability is based on a Relational OLAP (ROLAP)

model, that is, data is stored in a collection of relational database tables. This
model is similar to the industry standard OLAP model called star schema. The
star-schema model consists of one central database table, called fact, containing
numerical measures (key figures) of business variables. This fact table is
connected with several relational tables, each containing a business data
analysis view, called dimension. This cluster of fact and associated dimension
tables looks like a star, hence the name star schema. Alternatively, this star-
schema data model is known as a cube; in SAP BW terminology, it is known as
the InfoCube.

A typical star schema for sales analysis is shown in Figure 2-13. Four
dimensions-product, store, time, and order-surround the sales fact table. This
model enables analysts to view sales measures across a store in a particular
geography, across a given time granularity (specified in time dimension), and
across any product and order.
 Figure 2-13: A Typical Star-Schema Model for Multidimensional Data
Analysis.

In a star-schema model, the fact table is usually very large; it can consist of
millions to billions of rows. On the other hand, dimension tables are relatively
small, ranging from a few thousand to a few million rows. In a typical industry
standard (as in Figure 2-13), the dimension table contains master data. These
dimension tables are specific to a fact table. This means that dimensions are not
shared across other fact tables (and cubes). When another fact table, such as a
product forecast, needs the same product dimension data, another dimension
table that is specific to a new fact table is needed. This situation creates data
management problems because the very same information-in this example, the
product-is duplicated in several dimension tables instead of sharing data from
one single master table. You next learn how SAP BW handles this sharing of
dimensions problem.

BW star schema is an extension of a star schema, as shown in Figure 2-14.

Under the BW star-schema model, the dimension tables do not contain master
data. The characteristics in a dimension table point to the relevant master data
by use of a Set ID (SID) table. The SID table points to characteristic attributes,
text, and hierarchies. This multi-step navigational task adds extra overhead
when executing a query. However, the benefit of this model is that all fact tables
(InfoCubes) share common master data tables. Moreover, the SID table concept
allows users to implement multi-language and multi-hierarchy OLAP
environments. Another benefit of this model is that it also solves data analysis
problems associated with the dimensions that change with time, called slowly
changing dimensions. I discuss these advanced topics in Chapter 12, "SAP BW-
Defining Custom InfoCubes," where you learn about the dimensional data
modeling and extensive query modeling needed to implement a custom
InfoCube.
 Figure 2-14: Star-Schema Model in SAP BW 1.2B.

Note SAP chose Oracle8.0.x.x over Oracle 7.3.x.x.x because Oracle8

supports bitmapped indexes and star-joined query optimization
methods that speed data access from large databases where data is
stored in the form of a star schema. Appendix A lists all supported SAP
BW platforms.

A bitmapped index is an alternative to the B-tree index structure. For

the star-schema relational model, bitmapped indexes increase
performance data access significantly. SAP BW will automatically
determine and define appropriate bitmapped indexes needed for
optimum data access performance. Additional information on
bitmapped and B-tree indexes is available in Appendix B.

Today, SAP BW supports several other database management

systems, such as Informix, DB2, and MS SQL Server 7. The MS SQL
Server does not support bitmapped index technology. SAP BW uses
other DataBase Management System specific methods to optimize
data access from the InfoCubes.

Note To implement such an extensive SAP BW physical data model, you do

not need to learn and to write SQL language, SAP's BW Administrator
Workbench provides a Windows GUI interface to define dimensions
and fact tables, and does the actual table creation in the background.

The Operational Data Store (ODS) in SAP BW 1.2B consists of relational

database tables. An ODS table is specific to a transfer structure. At present,
ODS tables and InfoCubes must reside in one SAP BW instance. A stand-alone
ODS environment is still under development. The structure of the ODS table is
the same as that of a transfer structure of an InfoSource. SAP provides several
options to load data in BW. You can load data in ODS only and then build cubes
directly from ODS, you can load data in ODS and cubes in parallel, or you can
load data in cubes without populating data first in ODS. In BW 1.2B, ODS has
very limited functionality, such as no drill-down capability or modification of data
prior to storage in ODS. Moreover, data transformations (using transformation
rules) are not possible on incoming data before storing content in ODS. The
ODS architecture in SAP BW 2.0 is very different than in SAP BW 1.2B. The new
ODS is very flexible; the ODS 1.2B limitations described have been resolved in
the SAP BW 2.0 implementation. Chapter 17, "The Operational Data Store in
SAP BW 2.0," discusses SAP BW 2.0A ODS architecture and its implementation
techniques. However, a stand-alone SAP BW ODS implementation is still under
discussion.

BW OLAP Processor

The BW OLAP processor is a redesigned version of the SAP R/3 drill-down

reporting environment but with a richer set of analysis and display functions
integration with BEX.

The BW OLAP processor plays an integral role in analyzing the incoming

queries. It is here that the OLAP processor decides whether to process data
from a query cube (an in-memory multidimensional data view of an InfoCube
based on query definition) or to fetch data from an InfoCube or an aggregate
cube (a pre-summarized subset of InfoCube for specific query selection criteria)
to meet end-user needs.

The OLAP processor accepts all requests generated from BEX or an ODBO
compliant client application. The only difference is that the OLAP processor first
translates ODBO requests from a Multidimensional Expression (MDX) to
formulate SQL statements to fetch data from the InfoCubes or aggregates. By
doing so, all non-R/3 client requests make use of BW services such as
authorization, Info-Catalog, master data, and hierarchies navigation. You learn
more about SAP BW ODBO implementation in Chapter 15.

Team-Fly
Team-Fly
Data Flow in BW
When the user launches a report from BEX Explorer, it starts a BEX
Analyzer session and opens an Excel workbook that contains an
embedded BW query. BEX Analyzer sends a request to the BW
application server for relevant data. If this is a new query for a user,
no data is found at the application server level. The query is then
pushed further down to the database server to fetch a result set from
an InfoCube or an aggregate associated with an InfoCube.

The database server fetches data from an InfoCube and hands it

over to the application server, where it restructures the table-oriented
data to a multidimensional structure, called a query cube, as shown
in Figure 2-15.

Figure 2-15: Data Flow

Within SAP BW 1.2B.

A query cube is the subset of an InfoCube, which is specified by the

query. Some characteristics are restricted to specific values,
whereas some are not chosen in the query. For this reason, the size
of the query cube is much smaller than the actual InfoCube.

Note A query cube is unique to a user request and, hence, is not

shared by other users. If several users start the same
query, all will have their own unique query cubes built at the
 application server. This is because the result set may vary
based on selected dimensions or special filters. Also, each
will have full control on how to navigate through the query
cube (slicing and dicing) without interfering with analytical
work done by others.

Note As the number of query cubes increases, the application

server may run out of memory very quickly. For this reason,
the application server for SAP BW requires more memory
(2 GB) as compared to traditional SAP R/3 for OLTP
instance. Moreover, the SAP BW application server needs
more computer power due to data aggregations and
computation requirements to satisfy end-user data analysis
needs. A dual high-speed processor is suggested for an
SAP BW application server. Chapter 16, "Managing SAP
BW-Performance and Tuning," describes SAP BW sizing
requirements.

Once a query cube completes, a portion of data from the query cube
is pushed up to load data in Microsoft Excel worksheets based on
the current end user's data view, as shown in Figure 2-15. From this
point on, the end user performs typical slice-and-dice and drill-down
data analysis using BEX Analyzer functions. If the user needs
additional drill-down data that is not presented at a given time, the
request is sent to the query cube to send data in the spreadsheet for
drill-down analysis. If that detailed data is not in the query cube, the
OLAP processor will refresh the query cube from the InfoCube. This
navigational and data refresh process continues until the data
requirements are met at each level.

Note A query cube always relates to only one InfoCube. In other

words, you cannot build a query cube that gets data from
more than one InfoCube. The cross-lnfoCube queries are
supported in the BW 2.0A release in the form of MultiCube
implementation. However, if you are using SAP BW 1.2B,
and you really need data from multiple InfoCubes, a
 temporary solution can be built by embedding SAP BW
queries from different InfoCubes in individual spreadsheets
of a workbook. Then you can manipulate data from such
spreadsheets using Microsoft Excel macros or VBA code to
build another spreadsheet to display a final data set,
charts, and graphs. Chapter 11 describes how to build
query and workbook solutions.

It is not expected that analysts will complete all the data analysis in
one session. SAP BW users have a choice to save the result set of
their analytical work at any time and in any state. They can save it
back in the SAP BW server or on their desktop in the form of a
Microsoft Excel workbook, as shown in Figure 2-15. This enables
them to restart their analytical work where they left off or mail the
results to other users if needed.

Team-Fly
Team-Fly
Sample SAP BW Report
As mentioned earlier, SAP BW comes with predefined InfoCubes and a rich
set of reports. In this section, you will see how this reporting and data
analysis looks.

The first step to access SAP BW reports is to start the BEX Browser. You
will be prompted for your user name and password assigned by your SAP
BW administrator.

Once SAP BW accepts your user name and password, the BEX Browser
displays all reports and analytical applications for which you are authorized.
On the left are the channels. Each channel contains one or more reports.
Figure 2-16 shows that you are in the General Purpose Channel; the title
also shows the channel name. This channel has two clusters. Clusters are
used to logically group a set of reports that address a similar subject area.
This example uses Customer and Employee channels. In SAP BW 2.0A,
channels are replaced with Activity Groups, and BEX Browser has different
icons for clusters.

Figure 2-16: SAP BW Business

Explorer Browser with Sample Reports.

To launch an analytical application from the BEX Browser, simply right-click

the report text, Sales Distribution by Employee, as shown in Figures 2-16
and 2-17. This action gives you several options, such as Execute, Preview,
and Change. Select Execute to open the selected report.
 Figure 2-17: SAP BW Business Explorer Browser-Starting Data Analysis
Tasks.

Now BEX Analyzer launches, MS Excel starts, and SAP BW requests data.
The result then appears in the Analyzer, as shown in Figure 2-18.

Figure 2-18: SAP BW 1.2B Business Explorer Analyzer.

Here you can drill down by product hierarchy (see Figure 2-19) or some
other navigational attributes. You can also normalize data in several ways to
meet your analytical needs. You learn about such techniques in Chapter 11.
 Figure 2-19: SAP BW 1.2B Business Explorer Analyzer Drill-Down by
Product Hierarchy.

Team-Fly
Team-Fly
Summary
In this chapter, you learned about reporting systems in SAP R/3,
their capabilities, and their limitations. Then you learned how SAP
R/3 customers attempted to use SAP R/3 technologies to build a
separate data warehousing environment before SAP developed the
SAP BW product.

This chapter also provided you with the basic concepts of the SAP
BW product, its architecture, and its components. By now you should
also have some understanding of how information flows when users
access data from SAP BW for analysis and how data is analyzed in
SAP BW.

Team-Fly
Team-Fly
Chapter 3: Comparing SAP BW with Data
Warehouse Solutions Provided by Other
Vendors
Cultural Impact of ERP Data Warehousing
Organizations that have implemented an ERP application or are in
the process of implementing an ERP packaged application have
found that these applications force a change in traditional business
organization. In a traditional organization, for example, a vice
president of finance owns financial applications and has full control
over how financial applications are to be managed and configured.
The vice president of manufacturing is the sole owner of
manufacturing applications and data. The only link between financial
and manufacturing applications is via flat-file data feed exchanged
via batch processes. This practice creates stovepipe IT cultures with
very little knowledge of enterprise integrated business processes.

Today, the key to a successful business is business process

integration. Due to heavy emphasis on integrated business
functions, ERP packages force organizations to share information
and integrate business processes. For this very reason, when an
ERP system is implemented, the vice president of finance is now
forced to work closely with the vice president of manufacturing, and
vice versa. Both lose full control on their part of the business, and
they lose full control of their own application functions. Now they
have to work as a team or as partners, each thinking how any
change in business rule or data content in his or her area will affect
other areas. ERP solutions require changes in corporate culture to
force and create team-centric organizations to eliminate stovepipe
culture.

Data Warehouse and OLTP Teams

ERP data warehousing adds additional cultural changes in the

Information Technology (IT) organization. Culturally speaking, there
are two breeds of people in the IT business: those who build and
manage OLTP applications, and those who build and manage data
warehouses. Traditionally, these two types have not worked together.
The only interface between these two camps has been limited to flat
file design and actual data extracts. ERP data warehousing is forcing
the OLTP and data warehousing groups to work together for the first
time. This involves drastic cultural changes between the traditional
OLTP and data warehousing people and between the ERP OLTP
and ERP data warehousing people.

Caution SAP R/3 application developers and solution

implementers need to understand data warehousing
concepts to design SAP BW data objects and analytical
applications. Without data warehousing knowledge, the
SAP R/3 application developer and consultant will
implement SAP BW very much like data marts or
functional reporting systems mimicking SAP R/3 OLTP
reporting systems.

Data Warehouse Industry Analysts and Consulting

Services Providers

Initially, SAP struggled in the data warehousing industry to position

SAP BW as a viable business intelligence solution. The main reason
was the company name itself. Even today, when people talk about
SAP, right away people think of R/3. When SAP started to discuss its
SAP BW products with industry data warehouse analysts, it took a
long time before industry analysts started to write about SAP BW.
This is because SAP analysts were not quite "data-warehouse-
aware," and at the same time, data warehouse analysts were not
"ERP-aware." For this very reason, most SAP BW knowledge still
remains within the SAP-oriented culture.

Today, several consulting firms offer SAP BW services. Most

consultants in such organizations have an SAP R/3 background.
They will definitely help jump-start your BW project from an R/3
infrastructure perspective. But make sure that they include non-SAP
R/3 data warehousing experts on the team; these experts will
leverage SAP BW capabilities to deliver corporate-wide business
intelligence architecture and solutions instead of functional reporting
data marts.

Team-Fly
Team-Fly
SAP Business Information Warehouse and Third-
Party Data Warehouse Solutions
SAP BW is based on common industry-accepted standards that enable third-
party vendors to integrate their products with SAP BW. Since 1998, several
third-party vendors have certified their products to load data to and access it
from SAP BW. Data loading tools use Staging BAPI, and data access tools
use ODBO. At present, the products listed in Tables 3-1 and 3-2 have been
certified by SAP BW 1.2B as part of the SAP Complementary Software
Program. These vendors are in the process of BW 2.0 certification for their
products.

Table 3-1: Products to Load Data in SAP BW 1.2B

Vendor Product Version Web Site
Acta Technology
ActaWorks 3.0 www.acta.com
Inc.
DataStage
Ardent Software load pack for www.ardent.com
SAP BW
Evolutionary
ETI*EXTRACT 1.0 www.eti.com
Technologies
Hummingbird
Genio 3.0 www.hummingbird.com
Communications
Informatica
PowerCenter 4.5 www.informatica.com
Corp.
Information SNAPpack
2.6 www.ibi.com
Builders Inc. Data Migrator
Prism Solutions Prism Connect
2.0 www.prismsolutions.com
Inc. for BW
SuperNova Supernova for
International Business www.supernova.com
B.V. Warehouse
 Vendor Product Version Web Site
Business
systemfabrik
Warehouse 4.0 www.systemfabrik.com
GmbH
Connector
TSI International Mercator for
1.4.2 www.tsisoft.com
Software R/3

Table 3-2: Products to Access Data From SAP BW 1.2B

Vendor Product Version Web Site
arcplan
Information inSight 2.35 www.arcplan.com
Services
Brio
Brio
Technology 6.0 www.brio.com
Enterprise
Inc.
Business Business
www.businessobjects.com
Objects Objects
Power-Play
Cognos Inc. SAP BW 1.0 www.cognos.com
Interface
MIS
MIS Alea 3.7 www.mis-ag.de
Technologies
PointOut PointOut
www.pointout.de
GmbH for BW
Seagate
Seagate
Crystal 7 www.seagatesoftware.com
Software
Reports
Seagate Seagate
7 www.seagatesoftware.com
Software Holos
Seagate Seagate
7 www.seagatesoftware.com
Software Worksheet
Ton Beller
wwwEIS www.tonbeller.com
AG
 Vendor Product Version Web Site

E-Portal 6.0 www.viador.com

Viador, Inc.
Suite

Note For the latest SAP BW 2.0 certified products, visit the SAP Web site
at www.sap.com/solutions/compsoft/cspdirectory and select the
Software category option. Then search by Data Migration-BW for
certified SAP BW products that load data in SAP BW, or search by
Reporting Tools-OLAP, BW for ODBO-certified products to access
data from SAP BW.

Note The data warehouse industry is very fluid. Every day, companies are
either going out of business or merging, and that makes it very hard
to track products. For example, Prism Solutions Inc. and Ardent
Software products are certified to load data in SAP BW 1.2B.
However, in 1999, Ardent acquired Prism Solutions, soon after
Informix acquired Ardent. Today it is hard to track down what
happened to Prism Connect for BW. Is it still there, or has it been
integrated with Ardent's certified product DataStage load pack for
SAP BW? Check with the vendors to be sure you are looking at the
right product. Moreover, visit SAP's Web site for the latest SAP BW
certifications.

Most data warehouse and business intelligence vendors provide a collection

of tools that support a specific function needed to construct a data warehouse
such as data extraction, data transformation, and end-user data access tools.
Often, tools provided by vendors, even from one vendor, do not support a
common development environment or user interface. This situation makes it
difficult for organizations to build dedicated teams for specific tasks of a data
warehouse construction process.

Though the number of vendors providing data warehousing solutions and

tools is increasing, the following section compares only a few tools available at
the time of this writing that interface with SAP R/3 and SAP BW.

Figure 3-1 shows a list of a few data warehouse tool providers and their
limited functionality when compared to SAP BW. SAP BW functions are
represented as bullets one through eight. The vendor tools addressing similar
(but not exactly the same as SAP BW) functions are shown along with the
product vendor. The following section provides my hands-on working
experience with and research on a few SAP ODBO and Staging BAPI-certified
products from November 1999 through January 2000. The information
provided here should not be considered a recommendation of one or another
product; rather, this should be considered simply an academic discussion,
because the data warehouse capabilities in some of the products discussed
may have changed.

Figure 3-1: SAP BW and Third-

Party Vendors' Data Warehouse Products.

ActaWorks for SAP from Acta Technology is a data extraction,

transformation, and data-loading product. Though ActaWorks provides
some initial SAP R/3 data extraction schemes and generates ABAP
code to populate data marts, you must develop change identification
and delta change capture techniques for transaction data in SAP R/3.
ActaWorks is a good product, but from an overall global information
delivery perspective, it is not an information delivery environment. To
fill this gap, Acta is partnering with Cognos and other vendors to
provide a frontend environment to complete its data warehouse
solution.

inSight from arcplan is among the first few ODBO-certified products

for SAP BW. inSight is a very mature product. You can access EIS
data from SAP R/3 and SAP BW queries. arcplan has gone one step
further when it comes to delivering SAP R/3 and SAP BW data
analysis and reporting environments to the Internet by providing
ActiveX controls for pure Web clients. arcplan has introduced another
product, DynaSite, for pure Java-based clients. Note that arcplan
products provide an end-user reporting and OLAP environment, and
they assume that an appropriate data warehouse is already made
available for reporting and analysis.

Products from Business Objects and Cognos have been in the

reporting and midrange OLAP business for a long time. Due to a large
existing customer base, both vendors are working very hard to deliver
powerful SAP BW frontends for end-user data access and analysis. In
comparison to SAP BW, both vendors provide a sophisticated frontend
(more than with Microsoft Excel). However, they do not provide tools
to extract data from SAP R/3 or other sources to construct and
manage an enterprise data warehouse. Cognos bundles ActaWorks
from Acta Technology as a solution to extract data from SAP R/3 if a
customer decides to extract data from SAP R/3. Recently, Business
Objects acquired OLAP@WORKS, a powerful ODBO-compliant
product that makes Business Objects a powerful OLAP environment
to pull data from SAP BW as well as other OLAP engines, such as
Microsoft OLAP Services.

Evolutionary Technology Inc. (ETI) is best known for its data

extraction technologies. Its products are powerful and can extract data
from just about any data source, including SAP R/3. Its products are
also certified to load data in SAP BW using Staging BAPI. In
comparison to SAP BW, ETI covers only data functionality in BW.

Genio from Hummingbird is another powerful product to load data in

SAP BW. Genio, among the first few Staging BAPI-certified products
for SAP BW, was the Leonard's Logic flagship product that
Hummingbird acquired in March 1999 to complete its hub for an
enterprise data warehouse framework. Data quality and metadata
management, real-time enterprise application interconnects, and now
data mining are Genio's strengths. Like ActaWorks, Genio MetaLink
for SAP can extract data from SAP R/3 using IDOCs or directly from
SAP R/3 OLTP application level APIs using RFCs and load data in
SAP BW. Today Genio Suite 4.0 provides powerful enterprise data
warehouse construction tools; their solution does not provide
predefined business content, as do solutions from Acta and
Informatica.

Information Builders, Inc. (IBI) is one of the pioneers in enterprise

reporting and data warehousing. IBI provides several tools that cover
similar functionality as SAP BW. However, such tools still use old
technologies and are not integrated. They do, however, provide a
robust Enterprise Data Access (EDA) server that supports distributed
queries across homogeneous and heterogeneous data sources and
platforms. Though SAP BEX Analyzer supports only a Microsoft
Windows platform, IBI supports clients on multiple platforms, including
Microsoft Windows. IBI has a large customer base and will remain
visible in the data warehousing industry.

Informatica has been a leading data mart construction tool provider

for more than a decade. Informatica products can extract data from
flat files and relational databases to process and load data in target
data marts. Informatica was late to enter the ERP data extraction race.
Recently, Informatica has filled the ERP data extraction gap by adding
new data extraction components for SAP R/3 and PeopleSoft.
Informatica's PowerCenter was among the first wave of products
certified for Staging BAPI to load data in SAP BW. When compared
with SAP BW, Informatica's products are limited to the data extraction
and data load capabilities of SAP BW.

Oracle is in direct competition with SAP BW in the data warehouse

market. Oracle provides many tools to build data warehouses and
deliver information. Oracle has a good potential to provide a unified
data warehouse environment but still lacks product integration when
compared with SAP BW. Oracle also provides Oracle Tool Kit for SAP
R/3. But the metadata repositories used by the SAP R/3 extractor,
Oracle development tools such as Oracle Designer/Developer 2000
and Oracle Data Mart Designer, do not share the same metadata. All
have their own metedata repositories. On the OLAP side, Oracle
Express has its own development and management environment. This
makes it very hard to build a unified data warehouse environment
using common tools and technologies. Oracle provides very powerful
products, but it lacks in the integrated environment to construct,
manage, and deliver information of SAP BW.

SAS Institute is best known for analyzing very large data sets. SAS
provides several integrated products to build a data warehouse. The
Enterprise Miner is a very visual environment to construct the data
mining environment against large data sets. SAS provides SAP R/3
data extraction tools to perform data transformations and loads in the
SAS data warehouse similar to SAP BW. However, SAS supercedes
SAP BW when it comes to data mining and analyzing large data sets.
 Seagate is a midrange data warehouse construction and information
delivery tool provider. Seagate is acquiring technologies from several
vendors and offers an integrated data warehouse solution. Seagate
Holos OLAP is the OLAP engine. The Reporting tools come from
Crystal that can access data from most relational databases. Seagate
also announced that it will build data extraction tools for SAP R/3. The
Crystal Info product version 7 is certified to access data from SAP BW
using ODBO. None of the Seagate products load data in SAP BW.

Just as any other IT industry segment, the data warehouse industry is going
through a rapid change. Every day, new tools and vendors emerge. A few
acquire data warehouse technologies from other vendors to build a strong
solution-integrated tools offering. I have discussed only a few vendors; several
provide data warehouse construction functions ranging from low-end to high-
end. Such data warehouse vendors are listed in Appendix A, "Data
Warehouse Industry References and SAP BW Training."

Tools integration, however, is just one piece of the puzzle when it comes to
building a data warehouse. The business content is another. The real value of
SAP BW is not in the integrated set of data warehouse construction tools but
in the business content that makes SAP BW a far superior solution than any
offered by other data warehouse vendors.

Team-Fly
Team-Fly
Summary
A data warehouse usually requires data from applications owned by
several business organizations. Dealing with several organizational
cultures is a hard task. Some organizations are team oriented, but
others are very strict when it comes to accessing data from their
applications. These cultural issues are compounded when ERP
applications are implemented in a company, followed by an ERP
data warehouse implementation. In this chapter, you learned about
cultural issues related to ERP data warehousing. In addition to
cultural issues, you learned how a selected third-party data
warehouse offering compares with SAP BW, at a higher level, and
the tools currently certified to access/load data from SAP BW.

Team-Fly
Team-Fly
Chapter 4: Getting Started with SAP BW
In this Chapter
This chapter introduces the SAP BW application development,
administration, and data access environments. Notice that SAP BW
screen menus and options are quite different from typical SAP R/3
application modules. The purpose of this chapter is to provide you
with a visual tour of the SAP BW environment. In later chapters, you
learn the steps needed to configure SAP BW, develop applications,
and manage the SAP BW environment.

In traditional SAP R/3 OLTP instances, SAPGUI is the primary

frontend used to administer and develop applications or to access
data. SAP BW, however, supports multiple user interfaces based on
the user role.

In SAP BW 1.2B, SAPGUI is primarily used by administrators to

administer instances and manage data warehouse objects such as
InfoCubes. The data warehouse developers use SAPGUI to
implement data warehouse objects that store data. The analytical
application developers and end users use SAP BW BEX Analyzer to
develop analytical applications in Microsoft Excel.

In SAP BW 2.0A, however, the applications developers may develop

queries in the InfoSet Query that need SAPGUI, and the users of
such queries also require SAPGUI rather than the BEX Analyzer.
The administration and development of analytical applications
becomes even more complex when you implement SAP Internet
Transaction Server (ITS) to develop Web-centric analytical
applications. Here, the SAP BW administrators also need to learn
the ITS administration on the Microsoft NT Internet Transaction
Server. Moreover, the Web-based SAP BW 2.0 applications
developers need to learn Web authoring tools, such as Microsoft
FrontPage and HTML, to develop professional-looking Web
applications.
In this chapter, you will learn how to log on to the SAP BW backend
and frontend using SAPGUI and BEX Analyzer, respectively.

Team-Fly
Team-Fly
Log On to the SAP BW Administration Environment
SAP BW release 1.2B is based on the SAP R/3 4.5x version but doesn't include
business application modules such as FI, SD, and MM. SAP R/3 and SAP BW
share the same BASIS technology. SAP BW is installed as a separate instance.
SAP R/3 and SAP BW cannot coexist on one database instance. Usually, the
system administrator might configure one or more application servers to log on to
SAP BW. The SAP BW administrator creates a logon account for you based on
your role in the organization and SAP BW usage.

The logon process for SAP BW 1.2B and SAP BW 2.0 remains the same.
However, SAP BW 2.0A is based on BASIS 4.6 and requires the new SAPGUI 4.6
frontend. SAPGUI 4.5 and 4.6 are similar, but the 4.6 version has a lot more
graphics than 4.5.

SAP user interface, SAPGUI, software is needed to make a connection to SAP BW

for administration and to design data warehouse objects Along with the SAPGUI
frontend, Microsoft Office 97 and special SAP BW frontend components are
installed on the SAP BW developer and end-user workstation. After the SAPGUI
installation, the system administrator sets up logon properties needed to connect
the SAP BW instance from your workstation.

To log on to SAP BW, double-click the SAP logon icon, as shown in Figure 4-1.
This opens the SAP Logon server window, as shown in Figure 4-2. Select a BW
server you want to log on to. Now select SAP BW 1.2B and double-click the Logon
button.

Figure 4-1: The SAP BW Logon Icon.

 Figure 4-2: The SAP BW Logon Server Selection Screen.

Depending on network and SAP BW server activity, the SAP BW startup screen
might stay on the screen for a while until connection to SAP BW is established.
SAP BW then sends a message back to the end user's workstation and displays
the SAP BW session logon window requesting user logon information as shown in
Figures 4-3 and 4-4.

Figure 4-3: SAP BW Client Session Starts.

Figure 4-4: SAP BW Session Startup Screen.

To complete the logon session to SAP BW, you need a client, user name, and
password. SAP BW security administration staff assigns you this information based
on your SAP BW interactions. Enter client, user name, and password information in
the SAP BW user logon screen, as shown in Figure 4-5. Language entry is
optional. SAP BW supports multiple languages. If you do not enter a language key,
the default language is used. In Figure 4-5, the user is BWUSER, logged under
client 100, and the selected language is English (EN). After entering this
information, press the Enter key or double-click the check mark located in the
upper-left corner of the logon screen.

Figure 4-5: SAP BW User Logon Information Screen.

Note When you log on to SAP BW for the first time, you are immediately
prompted to change your password. You are asked for your initial and
new password. Enter your old and new password and click OK. SAP BW
confirms if your new password is valid and accepted.

Note SAP R/3 supports multiple clients within one instance, such as training,
development, and testing. This is possible in SAP R/3 because all
entities, except master data objects, are client dependent.

In SAP BW, you cannot have multiple clients because SAP BW data
objects are client independent. Client 000 in SAP BW is reserved for SAP
internal usage. One additional active client is defined for the rest of the
SAP BW activities. The reason for a client-independent environment in
SAP BW is that a data warehouse holds and shares information across
all business units, organizations, or legal entities of an enterprise as well
as data that does not belong to any organization such as industry
business performance benchmarks and Key Performance Indicators
(KPI). Data consistency is another reason for having one single client in
SAP BW. You need consistent business rules regardless of who owns the
transaction data. Having clients in SAP BW will restrict or add complexity
 in data navigation and management across multiple clients and will
introduce data quality problems.

When your user name, password, and client information are confirmed, SAP BW
displays the SAP Copyrights window showing license information and the user
logon statistics. Click the Continue button to proceed to the SAP BW
Administration window, as shown in Figure 4-6. Notice that SAP BW 1.2B and SAP
BW 2.0B user interfaces are somewhat different. In this book, I will use both
interfaces to demonstrate SAP BW 1.2B and SAP BW 2.0A and 2.0B capabilities.

Figure 4-6: SAP BW Main Screen for SAP BW 1.2B (SAPGUI 4.5A Frontend)
and SAP BW 2.0A (SAPGUI 4.6A Frontend).

To log off from SAP BW, click the Exit session icon (shown in Figure 4-7), or press
Shift+F3. The SAP Log Off dialog box prompts for confirmation, as shown in Figure
4-8, to log off from SAP BW. Click the Yes button.

Figure 4-7: Exiting From SAP BW.

 Figure 4-8: SAP BW Session Log Off Confirmation Dialog Box.

Team-Fly
Team-Fly
Log On to the SAP BW Data Access Environment
Logging on to the SAP BW data access environment is different from the typical
SAP R/3 logon process. Along with the standard SAPGUI interface, SAP BW
and SAP Business Explorer (BEX) components are required for OLAP
application developers and end users to access data from SAP BW. Microsoft
Office 97 is also needed on the workstations to complete the data access and
OLAP development environment.

Yes, you still need a valid user name and password to log on to SAP BW to
access data. As mentioned in Chapter 2, "Evolution of SAP Business
Information Warehouse," BEX consists of two components: the BEX Browser
and the BEX Analyzer. You can log on to SAP BW through the BEX Browser,
the BEX Analyzer, or SAPGUI as shown in Figure 4-9.

Figure 4-9: SAP BW Logon Paths in

SAP BW 1.2B and SAP BW 2.0.

Log On to the BEX Browser

The BEX Browser is the main entry point to the enterprise reporting global
catalog. To log on to the BEX Browser, click the SAP Business Explorer
Browser icon, as shown in Figure 4-10. The BEX Browser momentarily displays
the SAP BW logo (see Figure 4-11) followed by the SAP BW Logon screen (see
Figure 4-12).
Figure 4-10: The Business Explorer Browser.

Figure 4-11: The SAP Business Warehouse Logo Window.

 Figure 4-12: The SAP BW Server Selection Window.

Note Do not get confused when the BW logon window reads SAP R/3
Logon instead of SAP BW. SAP has not changed the title of the initial
logon window yet. Just ignore the title. You will log on to the selected
SAP BW instance.

In the SAP logon window, select one SAP BW server you want to connect to,
and then click OK. To complete the SAP BW logon, the SAP logon window
prompts you for your user name, password, language, and the client you want
to log on (see Figure 4-13). Enter this information in the SAP logon window and
click OK.

Figure 4-13: The SAP BW Logon User Information Window.

After validating your logon information, SAP BW momentarily displays the

Business Information Warehouse logo window with the message "Loading your
Favorites and channels. Please be patient" as shown in Figure 4-14.
 Figure 4-14: SAP Business Warehouse Copyright Window for SAP BW 1.2B.

The BEX Browser then displays all valid channels in SAP BW: the activity
groups, associated reports, and queries for which a user has authorization. To
execute a report, right-click an entry and select Execute, as shown in Figure 4-
15.

Figure 4-15: The SAP BW Browser is a Corporate Information Repository

that Contains Information Objects Such as Reports, Analytical Applications,
or Web Sites.

At this point, the BEX Browser launches Microsoft Excel and passes on the SAP
BW login information to Microsoft Excel. Microsoft Excel then establishes a
connection to SAP BW and downloads the query results in Microsoft Excel for
end-user data analysis (see Figure 4-16). From here on, data analysis is
performed in Microsoft Excel using the BEX Excel add-in.
 Figure 4-16: Simple Sales by Employee Data Analysis Report via BEX
Analyzer.

To exit the BEX Analyzer, simply close the workbook or close Excel. Before
exiting Excel, you have the option to save your data analysis results in Excel
format on your desktop. When prompted, provide a file name to save your
results.

When you exit the BEX Analyzer, the BEX Browser session remains active.
Select another report for analysis to continue your data analysis. To exit from
the BEX Browser, press Alt+F4 or simply close Excel.

Log On to the BEX Analyzer

As shown in Figure 4-9, you can directly access data from SAP BW using the
BEX Analyzer, bypassing the BEX Browser. Click the BEX Analyzer icon (see
Figure 4-17) to launch Microsoft Excel. As part of the SAP BW frontend
installation, the BEX add-in sapbex.xla is added in your Excel configuration. You
will see BEX icons in your spreadsheet, as shown in Figure 4-18.
 Figure 4-17: The SAP Business Explorer Analyzer.

Figure 4-18: SAP BEX Analyzer Microsoft Excel Add-In.

To connect to SAP BW, click the Select from InfoCatalog icon (see Figure 4-19).
You are asked for the same SAP BW login information, as shown earlier in
Figures 4-12 and 4-13.

Figure 4-19: Starting Connection to SAP BW From the SAP BEX Analyzer.

After the user logon information is validated, you will see a dialog box listing
InfoCubes and Queries available in the SAP BW instance, as shown in Figure
4-20. Select one query and click the Open button. SAP BW fetches data from
the database and loads it in the Excel spreadsheet, as shown in Figure 4-16.
 Figure 4-20: SAP BEX Information Catalog to List the Defined Query in SAP
BW 1.2B.

Notice that Microsoft Excel manipulates the data received from SAP BW
regardless of your path choice.

The BEX Analyzer is also a developer workbench. It is here that developers

compose new queries against SAP BW and publish them in the information
catalog. You learn how to create and publish queries later in Chapter 11,
"Analyzing SAP BW Data."

Caution By selecting this SAP BEX Analyzer path, you will have limited
access to information objects defined within SAP BW. None of the
other pointers and Web links defined in the global information
catalog is visible from within the BEX Analyzer. For the end user,
the BEX Browser is the best way to log on to SAP BW.

Team-Fly
Team-Fly
Summary
This chapter gave you a brief but visual overview of the SAP BW
logon process. You also learned that logging on to SAP BW varies
based on user type. If the user is an SAP BW administrator, logging
on to SAP BW is similar to the logon process to SAP R/3. However,
for users who access data from SAP BW, the logon process will vary.
You also learned that most of the data analysis is performed in
Microsoft Excel. At present, only the BEX Browser is Web based. In
SAP BW 2.0B, you can implement a pure Web data access
environment; however, the development process still requires
SAPGUI or BEX Analyzer to compose queries before they are Web-
enabled. SAP is planning to provide a pure Web reporting
environment in the future in SAP BW 2.0B GA.

Team-Fly
Team-Fly
Part II: Implementing SAP BW
Chapter List
Chapter 5: Planning for SAP BW Implementation

Chapter 6: Setting Up SAP BW

Chapter 7: SAP BW-The Administrator Workbench

Chapter 8: SAP BW-Loading Business Content

Chapter 9: Preparing R/3 Data Sources for SAP BW Initial Data

Loads

Chapter 10: Loading Data via Flat Files

Chapter 11: Analyzing SAP BW Data

Team-Fly
Team-Fly
Chapter 5: Planning for SAP BW
Implementation
In this Chapter
Implementing an enterprise data warehouse is not a simple task.
The key reason is that the reporting and data analysis requirements
for a data warehouse never end. That's why the data warehousing
industry calls data warehousing a process and not a product. The
data warehouse has to be in constant evolution as well as a stable
environment to fulfill end-user needs. For this reason, the initial
introduction of a data warehouse in an organization must be very
well planned and executed. The purpose of this chapter is to provide
readers (data warehouse architects and designers, business
analysts, project managers, and technical infrastructure capacity
planners) with some guidelines and steps to take before, during, and
after launching an SAP BW project.

Team-Fly
Team-Fly
Starting an SAP BW Project
The first step toward acceptance of any new technology is providing
a compelling and effective business case. Customers who have
already implemented SAP R/3 are eager to use SAP BW, but first a
good case must be made for SAP BW. Why do you need SAP BW?
How will SAP BW benefit your organization? How does SAP BW fit
in the rest of your company information delivery and management
strategy?

Data Warehouse Implementation Methodologies

Before charting an SAP BW project, take a quick look at data

warehouse development methodologies.

Top-Down Approach
The top-down approach is usually business driven, meaning that the
data warehouse is a corporate directive. It has full support, business
and financial, from senior management of a company, who has a
clear understanding of what to expect from a data warehouse. The
hardest part of top-down methodology is that all business
organizations have to agree on a common set of Key Performance
Indicators and other analytical key measurements needed to make
tactical and strategic business decisions.

The benefit of this approach is that you have full corporate-level

sponsorship to implement a data warehouse. However, in a
corporate-wide initiative, the initial scope of what to implement can
be very broad. Also, it will take a long time before end users actually
see the value of a data warehouse. This does not mean that the top-
down approach is not suitable; it depends on how you define scope,
prioritize deliverables, set expectations, and execute your project
deliverables on time in phases.

Bottom-Up Approach
The bottom-up approach has been the most common way of
implementing data marts. In this case, either a business manager or
a department manager steps up to launch a data warehouse project
with full financial support. This approach has several advantages:
limited scope of what to implement, control over what to analyze,
and easier rollout at a department level.

Sometimes, technology evangelists quickly master an emerging data

warehouse technology and convince the department head to show
the business value of adopting the new technology. Here, the
departmental IT team and the technology evangelists win the
business sponsorship, and data marts go live quickly.

The problem with this approach is that the implementation scope is

very limited. The implementation is not visible at the corporate level
and carries with it typical data-mart-related issues, such as
inconsistent enterprise-wide data definitions and supporting
technologies.

Hybrid Approach-SAP Approach

SAP proposes a hybrid approach for BW that takes advantage of the
top-down and bottom-up methodologies. Customers who
implemented SAP R/3 have already gone through the pains of data
standardization and implementing scalable technology infrastructure
at the corporate level. This is one key feature of the top-down
methodology: the corporate directive. On the other hand, individual
department business drivers can exploit SAP BW technology to
implement a specific, business-focused data mart solution today by
leveraging the same corporate-wide OLTP infrastructures and data
structures. These data marts do not become obsolete when a
corporate-wide initiative is launched; instead, they become an
integral component of the corporate information supply chain. The
SAP Accelerated SAP (ASAP) methodology for BW is a hybrid of the
top-down and bottom-up approaches in implementing data
warehouses.
Planning for SAP BW

The ASAP methodology for SAP BW is the right place to start. It

outlines five major milestones, as shown in Figure 5-1.

Figure 5-1: ASAP

Methodology Road Map for Business Information
Warehouse.

Initially, there is a lot of excitement about new technology, launching

a project, and forming a new team. Then comes the settling-in stage,
which involves realizing how much work is necessary and wondering
if it is all possible. Then comes getting everything down to a
deliverable model and implementing and supporting the solution.

To meet this challenge, ASAP methodology for SAP BW comes with

several accelerators and "how-to" guides and templates that speed
up the SAP BW learning and implementation process. These
accelerators and how-to guides are available at the SAPNET Web
site (new SAP workplace portal, http://service.sap.com). You need
an SAP Online Service System (OSS) account to access SAPNET.

Note SAPNET is a knowledge base of SAP customers. Here you

will find the latest information on product patches, problem
reporting and resolutions, tips and tricks, methodology
guides, and on all SAP products one can think of. The OSS
also provides other services, such as Early Watch to
monitor the state of your implementation and recommend
solutions to resolve future problems, as well as to log on
remotely to apply special patches to resolve problems
immediately.
 The Basis team configures its SAP R/3 or SAP BW
instances for OSS connections. Check with your Basis
team to set up an OSS account.

Several SAP BW partners and consulting organizations provide

additional SAP BW implementation accelerators and business
content that significantly reduce implementation time. Figure 5-2
shows ASAP methodology guidelines for SAP BW 1.2B. At the time
of this writing, most implementation guides refer to SAP BW 1.2B
implementation models. This methodology will be revised for SAP
BW 2.0 functionality at some later time.

Figure 5-2: ASAP Methodology Templates and Accelerators for

Business Information Warehouse.

Initial Assessment-Making a Case for SAP BW

As a starting point, do a quick assessment of your existing SAP R/3
reporting environment. Identify what users like and dislike when
doing reporting on SAP R/3. Ask users, reporting developers, and
data warehouse administrators questions such as, "How long does it
take to implement a report on SAP R/3?" Take a look at the rest of
the company data warehouses beyond SAP R/3 reporting. How do
they construct and manage data warehouses? How do they deliver
information to the end users? How many different technologies are
used to support data warehouses and from how many vendors? How
much data is extracted from SAP R/3 on a daily basis if most of the
reporting is done outside SAP R/3? How is data extracted from SAP
R/3, and what is its performance impact on R/3 business operations?
What is the corporate SAP R/3 strategy? How does senior
management want to manage information across the enterprise? Is
senior management fully committed to SAP products?

Identify major reporting and data analysis problems and causes of

such problems for both SAP R/3 and non-SAP R/3 data analysis
environments. For example, users may complain that it takes too
long to implement a report on SAP R/3. In some cases, when a
report program is implemented and made available to users, it is no
longer needed. A few users may find that SAP R/3's flexible analysis
is not flexible enough to analyze data the way they want, or that it
simply takes too long to run the reports.

From this fact-finding mission you will have sufficient material to

justify SAP BW-not because it is a new technology but from a total
cost of ownership (TCO) perspective. Initially, limit the scope of an
SAP BW project to one of the common business process areas,
such as Sales and Distribution, Financial Accounting and Material
Management, or Human Resources. Draft a project charter that
articulates the value of SAP BW in terms of its data analysis
flexibility, speed, manageability, and information delivery. Present a
case for SAP BW to your senior management. Get commitment from
a high-level business sponsor before doing further SAP BW project-
detailed scoping.

Note It is critical that you have a business sponsor for this

project, such as a CIO or vice president of a business
process. Make sure that the business sponsor is well
respected in the company and has full financial
commitment to support this project. Without solid business
sponsorship, an SAP BW project will not do anything but
become a prototype.
 Caution Having more than one business sponsor for your first
SAP BW project is not a good idea, because you will
end up spending a lot of time prioritizing whose
analytical needs should be implemented first. This will
definitely delay the success of your first SAP BW
implementation and reinforce the perception that SAP
BW will take years to implement, just like SAP R/3
implementations. In reality, this is not the case, but don't
try to oversell your first SAP BW implementation. Make
sure that you set expectations right away and are fully
understood by end users and the implementation team.

SAP BW Project Scope

Like any software product, SAP BW is still maturing, so keep this in
mind when defining the scope of an SAP BW project. Limit the initial
scope of data analysis needs to SAP BW provided business content.
SAP BW version 1.2B is suitable for multidimensional data analysis
against data at the summarized level. In SAP BW 1.2B, ODS drill-
down capability to the document level is not possible from within the
BEX Analyzer. Keep such detailed drill-down data analysis capability
out of the BW project scope. However, SAP BW 2.0 overcomes the
scope of SAP BW implementation due to new ODS capabilities that
hold detailed data along with summary level information in the
InfoCubes.

The SAP BW project scope outlines what data analysis functionality

will be delivered. Be careful in defining the actual deliverables.
Figure 5-3 shows end-user data analysis areas that will help you
define the scope of the BW project. Data analysis and reporting
needs are classified in the following groups:
Figure 5-3: Reporting and Data Analysis Categories and
Boundaries of an SAP BW Project.

Operational Reporting. Requires real-time state-of-

business operations, such as overdue orders, orders on
hold, or released sales orders at the time of inquiry. These
types of inquiries are very much transaction-centric. Do not
force real-time or near real-time reporting into the scope of
an SAP BW project.

Management Reporting and Analysis. Do not require a

real-time state-of-the-business performance. Rather, use an
agreed-upon time period.

Business managers or business analysts define what that

time period should be and for what data set. This could be
daily, weekly, or monthly. For example, every morning, sales
analysts want to know daily sales by product, by distribution
channel, or product inventory on hand. Here, day-old data
from transaction systems is sufficient to meet business
needs. On the other hand, cost managers want to analyze
reported expenses by employees by the cost center on a
weekly basis. In general, management reporting such as
overdue orders and backlog reporting, profitability analysis,
and variance analysis (performance versus plan) assist in
analysis or measurement based on key performance
indicators or metrics of the business. Most often, the
 management reporting and data analysis are subject-centric,
such as sales, finance, and human resources. These types
of analytical applications are well suited for the SAP BW
project.

Enterprise-Wide Reporting. Covers a broad range of data

analysis needs across several subject areas spanning
several years of data. Here, analysts and data-mining
experts explore large amounts of data for strategic planning.
SAP BW 1.2B is not suited for a very large corporate-wide
database (terabytes database) environment to handle
hundreds of end users. However, with new ODS capability in
SAP BW 2.0, the scope of a data warehouse can easily
reach to a large enterprise data warehouse.

Figure 5-3 shows the boundaries of data analysis requirements and

how SAP BW meets specific reporting and data analysis needs. This
figure suggests that SAP BW is very suitable for management
reporting and analysis when data refresh is done daily or weekly.
Therefore, when you define the scope of the SAP BW project, stay
within these boundaries. Note that due to new data management
capabilities in SAP BW 2.0 such as ODS and multi-InfoCube joins,
the scope of BW expands deep in to the corporate enterprise data
warehouse implementation.

Figure 5-3 also shows that real-time operational reporting should not
be considered when defining the SAP BW project scope. Depending
on the business activity on your transaction systems (such as orders,
invoices, and deliveries), you can refresh SAP BW with new data two
or three times a day. However, if you include near real-time
operational reporting in your first SAP BW project scope, make sure
that the data volumes will remain low for several months. This will
ensure that frequent data extracts from SAP R/3 for SAP BW have
no impact on the OLTP operations and that SAP BW can update
InfoCubes without interruptions. Keep operational reporting out of
the SAP BW project scope.
 Caution Some data warehouse vendors provide data replication
tools. A data replication scheme copies a data set,
usually a database table, from one source to a target
and keeps the target in synch with the source. Often, it
is assumed that SAP BW, being another data
warehouse environment, "replicates" transaction tables
to another database (R/3 or non-R/3). Note that SAP
BW does not provide data replication services. Instead,
SAP BW pulls predefined transaction data objects from
one SAP R/3 instance to one and only one SAP BW
instance. The structure of "changed" data-in SAP BW
terminology, delta-does not resemble any transaction
tables. In some data, such "change capture" tables may
not even reside in any R/3 database tables. It may have
been a buffered table or derived value processed during
a transaction and captured for SAP BW.

If you need to replicate SAP R/3 tables, database-

specific replication techniques are a good way to
achieve that goal. Keep pure database-level data
replication out of your SAP BW project scope.

SAP BW is very suitable for management reporting and typical

OLAP needs, but to succeed in your first SAP BW project, you
should remember the following:

Select a single subject area; for example, Sales and

Distribution, Financials, or Human Resources.

Keep the project scope as simple as possible; limit

dimensions

Document the scope

Balance business benefit and feasibility

Sell iterative-phased implementation

 Get management sign-off

After management sign-off, manage the project scope effectively. In

data warehousing projects, often project scope grows bigger and
bigger or changes. To be successful in your first SAP BW project,
hold firm to the signed-off project scope. If for some reason scope
has to be revisited, immediately establish the impact on the project
schedule, resources, and costs associated with this change.
Immediately update management of the changes in the project
scope, and get management sign-off again. Design an SAP BW
model for the future but deliver a focused, high-value, high-impact
solution immediately. Your goal here is to show the results as soon
as possible and retain the project momentum for the next subject
areas.

Team-Fly
Team-Fly
Creating the SAP BW Project Team
The next step in the SAP BW project is building a team. First, form a
steering committee, which consists of key business drivers such as
the CFO, CIO, corporate data warehouse manager, SAP program
manager, SAP BW program manager, business process expert, and
SAP BW expert. It is important that the steering committee members
meet regularly to discuss the project status to be aware of any
unforeseen business problem, the project scope, or technical issues.
The steering committee is responsible for resolving, prioritizing, and
recommending alternatives to keep the project on track. The steering
committee must establish a problem escalation process to the SAP
BW support center and SAP BW engineering team, and designate
one contact person between SAP and the SAP BW implementation
team. Figure 5-4 describes SAP BW team roles and their
interactions.

Figure 5-4: SAP BW

Project Team Members.

The Data Warehouse Lifecycle Toolkit by Ralph Kimball is a good

reference book that describes data warehouse team structures,
roles, and responsibilities for traditional data warehouses. The ASAP
methodology for SAP BW provides several templates to build the
SAP BW implementation team and their roles and responsibilities. I
won't repeat the same information here, but I will describe the
relationships among the team members, keeping the SAP BW
project in mind.

Figure 5-4 shows the SAP BW team structure at a higher level. The
actual number of team members depends on the scope of the SAP
BW project. For example, if SAP BW business content does not
meet data analysis needs, you may need one or more ABAP
developers to code extract programs or enhance existing extractors
in SAP R/3.

Because SAP BW is an SAP product, it is assumed that, like SAP

R/3, it will require a large team to implement. In reality, the SAP BW
implementation team is relatively small, and members come from the
following five areas:

Business Partners

Corporate Data Warehouse Program Office

SAP R/3 Program Office

SAP BW Experts

Corporate Information Architects and Technologists

Business Partners

The business partners and analysts play a major role in defining

business and end-user requirements and quality of information
needed for the reporting and analysis processes. Business partners
are responsible for defining business architecture and how reporting
and data analysis will be performed in the business model. For
example, does the data warehouse need to support an enterprise-
wide workforce or is support limited to their business unit? This
information is critical in defining the SAP BW deployment
architecture: data marts or central data warehouses or a combination
of both that satisfy business analysis needs.

Corporate Data Warehouse Program Office

It is critical to involve the existing corporate data warehouse team in

the SAP BW project. Though its members may not be familiar with
SAP BW, they will provide a wealth of information on the present
state of the information supply chain in the company. For example,
they can quickly provide data models, present KPI definitions, data
sources, data volumes, and data extraction/transformation
techniques. The corporate data warehouse, business, and technical
analysts must work together for a successful SAP BW
implementation.

SAP R/3 Program Office

Involvement of the SAP R/3 program office is very important as well.

Two major areas should be focused on with the SAP R/3 operation
team:

How do SAP R/3 path-to-production and SAP BW path-

to-production need to be coordinated? It is expected that
SAP R/3 will have a different life cycle than SAP BW.
However, you need to implement SAP BW extractors in SAP
R/3, and you might not have anticipated this in an earlier
SAP R/3 project life cycle. SAP expects to have minimal BW-
related interruptions in SAP R/3, but you will have to apply
special hot packs related to SAP BW business content in
SAP R/3. These hot packs do not enhance SAP R/3 OLTP
functions but will enhance SAP BW extractors or business
content functionality. Scheduling non-OLTP maintenance
work in SAP R/3 may impact SAP R/3 OLTP operations, and
the SAP R/3 OLTP production team must understand this.
 In addition to data extractors, you need to configure ALE and
other SAP BW-related parameters in SAP R/3. Some ALE
parameters, such as packet size, may be suitable for SAP
BW but not for SAP R/3 OLTP-related ALE messages.
Balancing these two environments requires frequent
parameter adjustments for DBMS, R/3, and ALE to handle
the increase or decrease in transaction volume. Though
adjusting such parameters on SAP R/3 boosts performance
for SAP BW operations, it may result in poor OLTP
performance. For these reasons, involvement of the SAP R/3
OLTP operations staff is very important from the beginning
stage of SAP BW configuration and project definition.

How do you manage SAP R/3 and SAP BW production

operations? When do you schedule data extracts from SAP
R/3 to SAP BW? How does it impact R/3 performance? SAP
R/3 and SAP BW project teams need to work very closely to
assess the overall impact of data extractors on SAP R/3
performance.

Modules in SAP R/3 can use LIS, but SAP BW uses special LIS
structures to capture delta changes. Include one person on the SAP
BW team who is familiar with LIS setup and configuration.
Depending on what subject area you plan to implement, include one
person on the team who has an in-depth understanding of business
process flows and associated data objects in SAP R/3. For example,
if you are planning to implement the Sales and Distribution area,
your SAP R/3 subject expert must know how the SD system works.
Your subject expert must also know how order documents are
invoiced, how deliveries are generated, and how order documents
flow in the SD system.

SAP BW Experts

In any SAP BW project, you need SAP BW experts, who actually

implement the reporting and data analysis environment. This team
consists of an SAP BW business content specialist-an SAP
consultant who works with business and data warehouse teams to
understand business requirements. The SAP BW consultant
facilitates mapping end-user requirements against SAP BW business
content. This exercise helps the team in assessing the development
work: how much predefined business content is usable, what needs
to be enhanced, or what new data objects need to be designed from
scratch to satisfy business requirements. When it comes to modeling
SAP BW schema, one must have a good understanding of the star-
schema model to model InfoCubes. However, to model Operational
Data Store, you need to understand overall data warehouse
modeling and normalization techniques beyond multidimensional
star-schema modeling.

Caution Often, when SAP R/3 developers trained in LIS

technology are asked to model an InfoCube in SAP BW,
they will model the InfoCube model that resembles the
LIS structures in SAP R/3 rather than the SAP BW
InfoCube. Make sure that this does not happen. First,
take the TABW20 training course on SAP BW modeling
before embarking on modeling and defining custom
InfoCubes or Operational Data Store. SAP BW specific
training courses are listed in Appendix A.

Initially, one ABAP developer is sufficient. You also need at least one
developer on the team who is fluent in Microsoft Excel VBA and
ODBO programming. An existing SAP R/3 Basis administrator must
be trained in SAP BW database and ALE administration. If you need
to import non-SAP R/3 data in SAP BW, get support from a
corporate data warehouse group, which might already have
someone trained in products (from Acta, Ardent, Hummingbird,
Informatica, and other vendors) that use Staging BAPI to load data in
SAP BW.

The purpose of a data warehouse is to provide accurate information

to the end user. Simply presenting fancy charts and graphs is not the
purpose of a data warehouse. The quality assurance engineer
establishes all project-deliverable quality and audit standards that
are in accordance with corporate standards and also meet end-user
requirements.

Corporate Information Architects and Technologists

A corporate information architect should be on the SAP BW team

because he or she has a much broader view of the corporate
information supply chain that includes the data warehouse,
transaction systems, and other information delivery systems. He or
she can help teams build data objects and definitions based on
corporate data standards. In SAP R/3, you are very limited on how
you can name an object. Object names must start with Y or Z. In
SAP BW, you do not have such restrictions. You can name your
objects using any combination of characters other than a zero prefix.
Objects prefixed by 0 (zero) are reserved only for SAP BW. I
recommend not using the SAP R/3 naming scheme. Instead,
develop a new naming scheme that is more suitable to end users
and that conforms to corporate naming standards.

Team-Fly
Team-Fly
Business Requirements
Collecting business and end-user requirements for a data
warehouse is a big challenge. Chapter 4 of The Data Warehouse
Lifecycle Toolkit covers this subject in great length. The ASAP
methodology for SAP BW provides several templates and guidelines
to collect user requirements.

For an SAP BW project perspective, SAP R/3 business subject

analysts and SAP BW business content experts need to interview
business executives, analysts, and end users to understand and
identify their needs and how they want to benchmark business
performance.

First, find out how end users do data analysis today. What methods
do they use to access information? How do they process and work
with the information? What is the outcome of their data analysis? Do
they simply print, mail, or download in XLS on their workstations?
Often, it is much easier to start with a clean slate. Define new
performance measurements and metrics. Look at the business
drivers and company strategic directions, and define new Key
Performance Indicators (KPIs).

Today, business performance is based on an individual business

process. Is this the best way to assess overall business
performance? The answer to this question is no. For example, the
manufacturing process performance is measured based on whether
a product is manufactured on time. However, if that product is not
shipped or received by the customer at the promised time, the
customer satisfaction performance indicator goes down. Here,
logistics and manufacturing organizations need to work closely to
define new KPIs that span manufacturing and logistics organizations
and their business processes. This cross-business process KPI
helps business grow.
SAP BW consists of several KPIs, and this list is growing. Take a
closer look at how such KPIs are calculated. Verify if these KPI
calculations meet your business rules. If they do not, either enhance
such KPIs or define new ones.

Business and data warehouse analysts must understand data

requirements, data sources, and granularity of data needs to meet
end-user requirements. Understand how and where data analysis
will be performed by the end users. This helps drive the SAP BW
deployment model that is in synch with the business process model.
Understanding the corporate data sensitivity issues helps define user
profiles in SAP BW that address end-user data access/security
concerns.

Team-Fly
Team-Fly
Technical Requirements
The most time-consuming process in constructing a data warehouse
is identifying the source systems, mapping data elements between
source and target systems, and performing data transformation to
build navigational data objects for reporting. Most of these processes
are already taken care of in SAP BW if you use standard business
content. Because SAP BW is based on the SAP R/3 infrastructure,
you already have that in place as well. You are left with the following
technical tasks for SAP BW:

Sizing

Interface with Non-R/3 Data Sources

Data Modeling

Information Delivery Infrastructure

SAP BW sizing is a very complex task. A variety of factors are

important to consider when estimating hardware requirements for
SAP BW. Estimating the appropriate system landscape, projecting
database loads, and examining data design issues and their possible
impact on system performance seem challenging-especially when
these considerations impact not only the database/application
server-level hardware requirements, but also the operating system,
database, and application tuning requirements, as well as end-user
workstations.

SAP describes BW configurations in terms of T-shirt sizes as Extra

Small (XS), Small (S), Medium (M), Large (L), and Extra Large (XL).
Based on present customer configurations, SAP has proposed some
basic configurations for SAP BW, as shown in Table 5-1.

Table 5-1: SAP BW Hardware Configuration Model (Source:

SAP)
 Number of
BW
Configuration Hardware Concurrent
Category
Users
DB + app >=1GB RAM,
XS server (in one >=2 CPUs, 1-10
box) DB 30-50 GB
>= 1.5 GB
DB + app
RAM, 2-4
S server (in one 10-20
CPUs, DB 50-
box)
100 GB
>=1.75 GB
DB and app
RAM, 2-4
server on
M CPUs on both 20-50
separate
servers DB
servers
100-200 GB
>=2 GB RAM,
DB server >=
One DB server 6 CPUs, app
L with multiple server >=2 50-100
app servers CPUs >=2 GB
RAM DB 200-
1000
>=4 GB RAM,
DB server >=8
One DB server CPUs, app
XL with multiple server >= >100
app servers 2CPUs >=
22GB RAM
DB >1000GB

Consider the following factors when deciding which of the SAP-

recommended configurations to use as a baseline for estimating
your hardware requirements:

How much source data is going to be extracted from other

systems (both R/3 and non-R/3)?

How many concurrent users will access SAP BW?

What is the query mix? How many users will be performing

light (lookup, snapshot), moderate (navigation across few
dimensions), or complex analyses?

What availability features, such as Redundant Array of

Inexpensive Disks (RAID) and system redundancy, are
required?

What is the complexity of the database design? Will many

InfoCubes be required? This will help assess the total
storage requirements, in addition to the query mix.

How fast is the system likely to grow in terms of users or

data?

Recently, SAP has asked hardware vendors to provide systems

configurations for SAP BW and OLAP benchmarks based on sales
order data. These configurations will provide some reasonable
system configurations on specific hardware platforms. At the time of
this writing, only IBM had announced SAP BW 1.2B benchmarks on
DB2. The benchmark details are available at the SAP corporate Web
site, www.sap.com/BW. None of the hardware vendors had
published BW 2.0x benchmarks.

Caution SAP BW benchmarks are based on data loads using

flat files not from an SAP R/3 data source. Similarly,
query execution does not represent real end-user
interaction. Business Explorer Analyzer is not used for
query execution; rather, queries are simulated via
 scripts bypassing Microsoft Excel and network usage.
So read these benchmarks carefully.

These benchmarks provide information on two areas: data staging

and data access. The SAP BW staging process includes loading
data (full and delta) in the ODS and InfoCubes and building
aggregates. Database activity processes the same query in parallel
with different navigation modes. According to benchmarks, the
average query-response time must be less than or equal to five
seconds.

SAP BW benchmarks are a good way to compare SAP BW

platforms offered by several hardware vendors. Based on
benchmarks, price/performance analysis, and overall operations
costs, you can decide if the platform that you use for SAP R/3
operations is suitable for your SAP BW operations. In some cases,
you may elect to use a different platform for SAP BW than what you
use for SAP R/3 operations.

Don't forget network requirements. Because SAP BW is using a

standard R/3 4.x core system, the same network requirements apply
to an inter-server connection. SAP recommends a 100 Mbit
connection. Nevertheless, the data traffic between the application
server and the client is three to five times higher than with a standard
SAPGUI (2 kbaud/user). Both LAN and WAN connections are
possible and deliver high performance.

Note Remember that SAP R/3 is a data source for SAP BW.
Calculate database table growth in SAP R/3 when
preparing the initial data loads for SAP BW. You also need
to account for additional table space and memory needed
for IDOC processing for SAP BW. Note that IDOC
processing is very CPU intense. Add additional CPUs, and
memory needs to be added at the application-server level.
The best option is to configure one dedicated application
server against SAP R/3 to process IDOCs for SAP BW.
 This overcomes any SAP R/3 system-resource contention
problems associated with the data extractor.

For SAP BW, you need a fast end-user workstation compared to that
of the typical SAP R/3 SAPGUI client. SAP suggests the following
SAP BW client configurations:

Windows 95: Minimum 64MB (128MB is strongly

recommended), Pentium 300MHz

Windows NT4.0/2000/98: Minimum 64MB (128MB is strongly

recommended), Pentium II 300MHz

Windows NT 4.0 with 128MB of memory with fast graphics display is

the ideal configuration for an SAP BW client.

Team-Fly
Team-Fly
Summary
In this chapter, you learned how to define your first SAP BW project,
and the importance of having full sponsorship from your business
sponsor. You also learned data warehouse development
methodologies, including ASAP methodology for SAP BW. Following
the methodology discussion, you learned how to build a team to
deliver an SAP BW project. At the end of the chapter, you learned
the technical requirements for SAP BW and sizing information.

Team-Fly
Team-Fly
Chapter 6: Setting Up SAP BW
In this Chapter
The purpose of this chapter is to discuss the steps necessary to set
up SAP BW for the project and to activate SAP-provided business
content. At the end of this chapter, you will be ready to do
development work. To fully understand this chapter, you should be
somewhat familiar with SAP BASIS terminology.

Team-Fly
Team-Fly
Getting Ready for SAP BW Software Installation
One major benefit of ERP data warehousing is that OLTP and data warehouse
environments use the same infrastructure. Because SAP BW is built on top of
SAP R/3 BASIS technology, the core software-installation process is very similar
to installing an SAP R/3 instance. The assumption here is that you have
implemented SAP R/3 and are planning to install SAP BW. Your BASIS support
team is fully trained in installing SAP R/3. This chapter describes the process for
setting up SAP BW, not installing the SAP R/3 kernel and BASIS layer. For
information on how to install SAP R/3, see the SAP R/3 installation guides that
are packaged with the software. Also refer to Basis Administration for SAP by
Robert E. Parkinson, et.al., published by PrimaTech.

Note You can implement SAP BW without SAP R/3 as a data source. Here
you are working with flat files or third-party tools that are certified to
load data in SAP BW. But you still need trained individuals on your
teams who are fluent in SAP R/3 architecture, BASIS, and Application
Link Enabling (ALE) technology.

Assuming that you have the core SAP R/3 component installed, configuring SAP
BW consists of the following four steps:
1. Configure the SAP BW database and application server.

2. Configure the SAP BW administrator's workstation.

3. Install SAP BW extractors in SAP R/3 OLTP instances.

4. Install frontend components for end-user reporting and analysis.

Figure 6-1 illustrates these four steps. This chapter covers only those items
related to SAP BW as marked by the dotted gray area in Figure 6-1.

Figure 6-1: SAP BW Installation

Steps-Backend and Frontend. The Shaded Area Represents the SAP BW
Specific Component Installation.
Like any SAP R/3 implementation, SAP BW supports several platforms and
databases. Selecting a platform (hardware and software) for SAP BW mostly
depends on your current SAP R/3 platform. Because the SAP R/3 operational
staff is already trained on a specific SAP R/3 environment, you may use the
same hardware and database engine for SAP BW. Often, an OLTP instance
does not require Very Large Memory (VLM)/64bit processor support. However,
due to large data volumes in a data warehouse per data request/transaction,
complex and compute-intense data analysis requirements, you may consider a
different hardware vendor than your OLTP platform that best suits your SAP BW
usage needs.

After deciding on the platform, sizing questions come to mind, such as the
following:

How big should my machine be?

How many CPUs should that machine have?

How much memory do I need?

How much storage do I need?

What are the network requirements?

The answers to such questions are still evolving. SAP has proposed basic SAP
BW configurations; Table 5-1 in Chapter 5 lists these. These recommendations
are based on a few initial SAP BW customers (SAP BW 1.2B versions).
However, to provide realistic configurations for SAP BW on supported platforms,
SAP is working with hardware vendors such as Compaq, Hewlett-Packard, IBM,
and Sun to conduct SAP BW benchmarks and provide realistic sizing
information. At the time of this writing, only IBM had published SAP BW 1.2B
benchmarks using DB2 database on IBM hardware. Check SAP and the
hardware vendor's Web sites for the latest SAP BW configurations.

The SAP BW implementation landscape is another factor to consider when

sizing SAP BW. SAP recommends a three-phase rollout strategy for SAP BW
that includes the following individual systems, as shown in Figure 6-2.
 Figure 6-2: SAP BW System Landscape-Path to Production.

Pilot/Development System. This system is used to do initial SAP BW

assessment and then extend to develop custom analytical applications.
Developers mostly use this system.

Test System. The test system is used to test and verify data access,
reporting, and analytical applications to qualify end-user acceptance
tests before rollout onto the production system. The test system can also
be used to do stress testing and fine-tuning of data objects for optimum
performance. Quality assurance and development teams have access to
this system.

Production System. The production system is the "live" SAP BW

implementation. The objects in the production system are transported
from the test system and connected to production SAP R/3 production
instances to meet end-user data analysis needs.

Collectively, these three classes of systems are known as SAP BW System

Landscape. The Correction and Transport Organizer (CTO) is used to move
objects between these systems: development to test and test to production.

In a typical SAP R/3 implementation, the system landscape is relatively simple.

However, for SAP BW, the path to production is complex. Here you are moving
objects between SAP BW systems and at the same time, the corresponding
SAP BW-related objects in SAP R/3 are moved between SAP R/3 OLTP
systems. It is important to note that the individual SAP R/3 system is connected
to the corresponding SAP BW system via Remote Function Calls (RFC) instead
of Correction and Transport System (CTS). The reason is that communication
between SAP R/3 and SAP BW is from a metadata and data perspective, and
not at an object (program, transaction, or table) level.

The order in which objects are transported between SAP BW and SAP R/3
systems is discussed in Chapter 12, "SAP BW-Defining Custom InfoCubes."
Database size, as with any other data warehouse, grows rapidly. Often, the
actual size of a database is almost two or three times the size of the actual
transaction data received from the transaction systems. It is expected that
master data will change, but the growth of master data in SAP BW is not that
significant after initial loads. Plan for plenty of storage space, at least 50 percent
more than your estimate, when configuring an SAP BW system.

SAP BW, like any other data warehouse, needs to handle large data volumes-to
load new data or to read data from a database for end-user queries. Therefore,
SAP BW requires a fast disk I/O subsystem. This means large bandwidth, which
is achieved by spreading the database across a large number of array
controllers. The number of I/O controllers is derived from the estimated
bandwidth required by the workload, typically 10MB/sec for each CPU. For
example, a system with eight CPUs should have enough I/O controllers to
support 80MB/sec bandwidth. Adding more memory and faster processors will
not necessarily improve SAP BW performance if disk I/O subsystems are
causing the problem-I/O bandwidth that is not large enough.

Based on your SAP BW landscape, the first step is to set up a

Pilot/Development SAP BW and associated SAP R/3 system for your project.

Team-Fly
Team-Fly
Installing and Configuring SAP BW Servers
SAP BW supports several platforms: hardware, operating systems,
and database management systems (DBMS). In this section, I
describe how to install and configure SAP BW database and
application servers on a Digital Alpha server, UNIX operating
system, and Oracle DBMS.

First install and configure the UNIX base system. This includes
hardware components, storage devices, networking gears, the
operating system (UNIX), and the file system, as listed here:

Set UNIX Kernel Parameters (/etc/sysconfigtab)

Partition the System Disks

Configure the Swap Space

Install Licenses

Configure the Network Interface

Configure the Network Time Protocol (NTP)

Install Patches

Install the Advanced File System (AdvFS) Software

Label External Disks and Configure the File System

Note Before starting SAP BW, read the following documents:

Installation of the SAP Business Information
Warehouse on UNIX/Oracle Database Release
1.2B

Installation of the SAP Business Information

Warehouse on UNIX-OS Dependencies
 Installation of 32-bit SAP BW Frontend Software
under Microsoft Windows NT and Windows 95/98

Make a copy of all OSS notes relevant to your BW

platform.

Chapter 4 of SAP's Installation of the SAP Business Information

Warehouse on UNIX lists individual operating systems' specific
parameters. In this case, edit /etc/sysconfigtab to adjust UNIX kernel
parameters.

Configuring the file systems on external storage devices consists of

determining a database layout, labeling the external storage disks,
and using AdvFS to physically set up domains, file sets, and mount
points. Before you physically configure an SAP BW file system,
examine and determine the data layout for your data sets. This helps
in determining the amount of disk storage required for each mount
point.

Note SAP BW enables customers to define individual

tablespaces for specific fact tables. This capability gives
SAP BW the flexibility to distribute data evenly across
available storage devices. If you are using Oracle8, you
must also become familiar with the SAP BW/Oracle8
tablespaces and projecting placement within the file
systems.

Review file system requirements in Chapters 1 and 2 of Installation

of the SAP Business Information Warehouse on UNIX- OS
Dependencies.

The next step is installing the SAP R/3 kernel, the BASIS layer, and
the SAP BW database (Oracle8). This requires the following steps:
1. Review Installation of the SAP Business Information
Warehouse on UNIX/Oracle Database.
 2. Review all OSS notes specific to SAP BW installation on
your platform of choice (for example, UNIX/Oracle8).

3. Check kernel parameters and swap space (as described in

Chapter 3 of Installation of the SAP Business Information
Warehouse on UNIX/Oracle Database Release 1.2B
Guide).

4. Select a system name (using SAP R/3 naming

conventions).

5. Create the Mount and Transport directory (needed for

CTS).

6. Set up the Installation directory.

7. Create the Oracle Staging directory.

8. Create the Central Instance database (run shell script

CEDBBW.SH).

9. Launch R3SETUP script to install SAP BW software.

10. Install the Oracle database. Verify that all OS level

parameters set in /etc/sysconfigtab, as described in OSS
notes and Chapter 4 of Installation of the SAP Business
Information Warehouse on UNIX/Oracle Database, are
correct (for example, shared pool size).

Caution Default values for several database

parameters have been changed for SAP
BW/Oracle8. There are new database
parameters that you must define in the Oracle
initialization file (init<sid>.ora where sid is your
oracle system ID). New parameters related to
Oracle Star Query optimization, bitmap
indices, and so on need to be defined to
improve SAP BW data access performance.
 Such parameters are needed only in SAP BW
and not in SAP R/3 OLTP instances. Check
OSS notes for the latest list of Oracle8
parameter settings.

11. Set the password for operating system users (see Chapter
5 of the Installation of the SAP Business Information
Warehouse on UNIX/Oracle Database Release 1.2B).

12. Restart INSTGUI and R3SETUP.

13. Run ORAINST to install base Oracle DBMS.

14. Run ROOT.SH shell script. You must run this script after
Oracle DBMS installation. This establishes environment
variables needed for the SAP BW instance.

15. Install DBMS specific patches.

16. Adjust tablespaces.

17. Create and load the database. This is the longest part of
the SAP BW base installation. Depending on the size of the
database to create, it might take several hours.

18. Perform post-installation tasks. Read OSS notes and apply

appropriate OSS notes (see Chapter 6 of Installation of the
SAP Business Information Warehouse on UNIX/Oracle
Database Release 1.2B).

19. Install the license. Initially, you have a 30-day temporary

license for SAP BW. Follow the standard process to get a
permanent license from SAP and activate the key using the
saplicense command.

20. Set Transport Permissions to be used by CTO.

This completes the first step of SAP BW installation. The next step is
installing SAPGUI on the SAP BW administrator workstation.

Team-Fly
Team-Fly
Configuring the SAP BW Administrator
Workstation
If you are an SAP customer, you may already have SAPGUI installed
on a workstation. Because SAP BW uses new features of SAPGUI
4.x, uninstall the current SAPGUI from your workstation (Windows
95, Windows 98, or NT Server 4.0) and re-install the SAP BW
SAPGUI that came with your SAP BW installation kits (possibly
version 4.5 or 4.6).

Caution Do not delete the SAPGUI directory or remove files

manually from your SAPGUI directory. The Windows
registry contains several SAPGUI entries. Manually
removing files from the SAPGUI directory on disk does
not remove such entries from the system registry. This
will cause problems when you install new SAPGUI for
SAP BW. The correct method to remove SAPGUI is to
run the uninstall program provided by SAP.

As shown in Figure 6-1, there are two types of SAP BW frontends.

One type is for the SAP BW administrator, and the other is for end
users or analytical application developers. Install SAPGUI for the
SAP BW administrator workstation. This easy installation process is
listed here:
1. Insert the SAP BW FrontEnd CD in your system's CD drive.

2. Double-click the Setup icon.

3. Select the SAPGUI applications and development

components (see Figure 6-3), and click Next. Make sure
that you have at least 100MB of disk space available for
the SAPGUI components.
 Figure 6-3:
SAP BW Frontend Installation on the Administrator
Workstation.

Team-Fly
Team-Fly
Installing Frontend Components for End-User
Reporting and Analysis
Installation of SAP BW for end users and BW application developers is similar to
that of the frontend for the SAP BW administrator. The only difference is that the
end-user and developer workstation must have Microsoft Office 97 and Service
Pack 1 installed. Run the SETUP program from the SAP BW presentation CD.
When asked for the components to install, check BW AddOn, OLE DB for OLAP
Provider, and SAPGUI (see Figure 6-4), and install the SAP BW client.

Figure 6-4: Installing SAP BW

Components for End Users and Developers.

Reboot the workstation when the BW client installation has finished. Verify the
SAP BW client, as described here.

Launch the SAP Business Explorer Analyzer from the SAP frontend 4.5A group,
as shown in Figure 6-5. This launches Microsoft Excel. You should see the SAP
Business Explorer menu bar (see Figure 6-6). If you do not see the SAP
Business Explorer menu bar, add it manually. Use the following menu path to
add the SAP BW Excel add-in SAPBEX.XLA.
 Figure 6-5: Launching the SAP Business Explorer Analyzer.

Figure 6-6: SAP BW Explorer.

Tools, Add-Ins, Browse

Select the directory where the SAP BW frontend is installed on your workstation;
for example, C:\SAPpc. The name of the BEX add-in is Sapbex.xla. You will find
this in a subdirectory called BW (for example, C:\SAPpc\BW\). Select
Sapbex.xla and click OK. This adds the BEX add-in (macro) in Excel. Save it.
Close and restart a Microsoft Excel session. When Microsoft Excel starts, it
launches the SAP Business Explorer Analyzer menu as part of the Microsoft
Excel menu.

Team-Fly
Team-Fly
Initializing SAP BW Global Settings
In addition to SAP R/3 basic components, SAP BW requires additional
customization and settings in an instance. Log on to SAP BW though SAPGUI to
verify that basic SAP R/3 components needed are correctly installed.

Check Installation

Log on to SAP BW in client 000. Execute transactions SM28 and SM21. They must
report no errors, as shown in Figure 6-7.

Figure 6-7: SAP BW Installation

Checkup.

After verifying that the SAP BW basic components are operational, enable CTO by
executing transaction SE06, followed by transaction STMS, which sets up the TMS
environment. Transaction SMLT loads languages you want to support.

SAP BW Active Client

To this point, you have a standard SAP BW (basic) system that is functionally ready
for business operations. It is common practice in an SAP R/3 OLTP system that you
create multiple clients, each serving a special function. For example, one client 050
for training, another client 100 for development, and another client 800 for testing.

In SAP BW, you cannot have multiple active clients. Only one active client is allowed
in SAP BW (other than client 000 and 066, which are both reserved for SAP).
Therefore, you must define a BW active client to develop analytical applications.

Defining an active client is a two-step process. First, define an active client using
transaction SM31, as shown in Figure 6-8. Second, log on to the SAP BW active
client and copy it (transaction SCCL) using profile SAP_ALL (see Figure 6-9).
 Figure 6-8: Defining the SAP BW Active Client.

Figure 6-9: Copying the 000 Client to the SAP BW Active Client.

For the active BW client, the start menu must be RS00. This requires you to modify
the active client profile and set the default login menu to RS00. Any changes made
to system parameter files are applicable after system reboot.

After creating an active client, you must also define a logical system for the newly
created client in table T000. This is necessary to uniquely identify the client to the
transport system. To do so, you must log on to the newly created account as SAP*
(or another privileged user) and execute transaction SALE. Follow the guidelines for
the logical systems as proposed by SAP, such as <SID>CLNT<client>. For example,
if your instance name is BWD and client 100, then the logical system name is
BWDCLNT100. Make sure that you add the logical destination (using transaction
SM31) to the BW active client entry table T000. Remember, once a logical name is
defined and activated in an SAP BW instance, it may never be changed. After
making such changes, restart the SAP BW instance.

Customizing the SAP BW Instance Configuration

SAP BW requires several layers of SAP BW configurations. So far you have learned
about hardware, database, and SAP R/3-centric parameters. Now you need to set
up parameters that are applicable only to SAP BW-related development and
operational work. The following lists the two types of BW-centric customizations:

Basic setting that refers to transaction and reference data elements such as
currency conversions, fiscal year variant, and unit of measure, as shown in
Figure 6-10.

Figure 6-10: Basic SAP BW Setting. The Left Shows the Setting Menu for
SAP BW 1.2B, and the Right Shows the Same Setting Menu in SAP BW
2.0A.

Customization of the SAP BW Administrator Workbench and SAP BW

operational items, such as ALE settings, and other parameters that support
SAP BW operations, as shown in Figure 6-11.

Figure 6-11: Customizing SAP BW Operational Parameters.

You need to know several transactions or menu paths to customize all SAP BW
settings. The BW Customizing Implementation Guide (transaction RSIMG) is a
method to customize SAP BW from one view instead of navigating through several
menu options or remembering transaction names. Figure 6-12 shows the path to the
BW Customizing Implementation Guide (Tools, Business Engineer, BW
Customizing). Figures 6-13 and 6-14 show BW customization trees.
 Figure 6-12: SAP BW Customizing Implementation Guide.

Figure 6-13: SAP BW Instance and Applications Specific Customization and

Configuration Parameter Settings.

Figure 6-14: SAP BW Customization and Configuration Global Parameter

Settings.

Most of the entries in this tree will take you to another transaction without your
knowledge. You need to log on to the SAP BW active client as a privileged user to
do customization.

Note The RSIMG transaction covers most of the global SAP BW settings;
however, you still need to customize the remaining parameters, such as
Currencies, Translation keys, as shown in Figure 6-10, and Global
settings, as shown in Figure 6-11. Make sure that you set these
parameters before loading data in SAP BW.

Setting SAP BW Parameters in the RSADMIN Table

The RSADMIN table is an important table in SAP BW that sets data administration
parameters. To modify entries in RSADMIN, log on to SAP BW under the active
client (menu RS00) and start the Administrator Workbench (or run transaction
RSA1). Then select Global settings from the Settings menu entry, as shown in
Figure 6-15.

Figure 6-15: Setting Global Data Administration Parameters.

This displays the RSADMIN table contents, as shown in Figure 6-16.

Figure 6-16: Modifying the SAP BW Operation Configuration Table RSADMIN.

Most entries are self-explanatory in the RSADMIN table, but a few need more
details, as described in the following sections.

ALE Users
Because ALE is the main data transport method between SAP BW and SAP R/3
OLTP instances, you need to assign a user name in SAP BW and the SAP R/3
OLTP instance that will be used to communicate between the source and the target
system. In the example in Figure 6-16, ALEREMOTE user exists in both systems
and is used for ALE communication. You do not have to use the same username in
SAP BW and SAP R/3. You can use whatever you decide and assign such users in
the RDADMIN table.

ALE IDOC Setting

In typical OLTP applications, the frequency of ALE messages is usually high, but the
actual data volumes are low. In the OLAP environment, it is quite the opposite.
There are fewer ALE messages, but the data volume is very high. This means
tuning the ALE process for SAP BW operations. Based on the large data volume
and complexity of data loads in SAP BW, the number of data records per IDOC and
the number of data packets after which Info IDOCs are created needs to be
adjusted. Remember that you also need to adjust ALE parameters on the SAP R/3
OLTP instance (table ROIDOCPRMS). SAP recommends setting the number of
records per IDOC between 5,000 and 20,000. In Chapter 9, "Preparing R/3 Data
Sources for SAP BW Initial Data Loads," and Chapter 16, "Managing SAP BW-
Performance and Tuning," you learn more about how changing records per IDOC
impacts the performance of the SAP BW instance.

Flat-File Processing

SAP BW can load data from flat files. If you use special data files that do not
conform to standard files and record delimiters (tab, csv, and xls), specify your field
and record terminators in the RSADMIN table. Remember that these settings are
global and are used as default delimiters. If you have only a few files that do not
conform to standard file structures, you can always identify such delimiters at data
load scheduling time specific to individual data files.

Release of SAP R/3 OLTP Application Hierarchy

This parameter specifies the newest application release used in SAP R/3. This
release number is checked during the importing of metadata from the SAP R/3
OLTP instance. In SAP BW, the application hierarchy does not rebuild if the
metadata is updated from a lower version of SAP R/3, as specified in the RSADMIN
table.

Caution Never run Administrator Workbench (transaction RSA1) from any other
client than the active SAP BW client.

Team-Fly
Team-Fly
Installing SAP BW Extractors in the SAP R/3
OLTP Instance
The SAP Business Information Warehouse Business Content and
Extractor installation guide from SAP describes in detail pre- and
post-installation steps. The interfaces of SAP BW in SAP R/3, known
as extractors, are treated as all other add-ons. You can find BW-
BCT, the name of the add-on, in table AVERS.

SAP BW 1.2B data extractors that come with the SAP BW 1.2B CDs
do not support all versions of SAP R/3. Generally, BW extractors are
available only for R/3 maintenance releases (and not for functional
releases) during the maintenance period of that specific R/3 release.
It varies with the hot pack level in the SAP R/3 release and the
application area. Carefully read the add-on installation guide as well
as the OSS notes related to business content and data extractors. In
most cases, the minimum requirement for SAP BW extractors in
SAP R/3 versions is 3.0D.

After installation of the SAP BW add-on in SAP R/3, perform the

following steps to prepare SAP R/3 to communicate with SAP BW:
1. Verify the add-on release by executing transaction BAOV.

2. Make sure that the upgrade status is +. This means that

the upgrade or the add-on update ended successfully.

3. Create the ALE user. Make sure that ALE user has the
profile S_BI-WX_RFC.

4. Create the Source System (SM30) in Table T000.

5. Define the RFC Connection for SAP BW using SM59; test

the connection between SAP R/3 and SAP BW, as shown
in Figures 6-17 and 6-18.
 Figure 6-17:
Defining RFC Destination for Remote Data Source SAP
R/3 Instance.

Figure 6-18: Testing RFC Destination for a Remote SAP

R/3 Data Source.

6. Clean up table TBATG. Run SE14 to check that TBATG is

empty.

7. Perform backup.

This completes the BASIS level configuration of SAP BW, SAP BW

clients, and SAP R/3.
I also installed SAP BW 1.2B and BW 2.0A on Microsoft Windows
NT 4.0 Service Pack 5 and Oracle DBMS. The installation process
appears to be somewhat simpler than with UNIX. SAP BW 2.0 has
much tighter integration with Microsoft Windows NT than its earlier
versions. The SAP BW operations are integrated with Microsoft
Management Console (MMC) to start/stop the BW 2.0 instance and
its associated processes, as shown in Figure 6-19.

Figure 6-19: SAP BW Operations on Microsoft Windows NT 4.0.

On the Left is the Service Manager to Start and Stop the SAP BW
1.2B Instance. On the Right is the Service Manager Integration
with Microsoft Management Console to Manage SAP BW 2.0
Services and Associated Processes.

Team-Fly
Team-Fly
Summary
In this chapter, you learned about all the steps necessary to set up
SAP BW on a UNIX/Oracle8 platform. This consists of installing
several SAP BW basic components, followed by SAP BW
administrator and client software. Once that is done and verified, you
install SAP BW business content and extractors. Test RFC
connections between SAP R/3 and SAP BW. This prepares SAP BW
and SAP R/3 for the next step: loading SAP BW business content.

Team-Fly
Team-Fly
Chapter 7: SAP BW-The Administrator
Workbench
In this Chapter
Chapter 6 focused on how to set SAP BW as an OLAP server and
SAP R/3 as an OLTP data source. Now it's time to take a look at
SAP BW in more detail. This chapter describes some of the major
components of the Administrator Workbench used to construct the
building blocks of InfoCubes. This chapter provides information on
how and where individual objects are managed within the
Administrator Workbench.

Note The design windows in the SAP BW Administrator

Workbench are very large. These windows are not sized to
fit a typical display monitor screen. A video monitor with at
least 1024 x 768 resolution is recommended to view full
SAP BW design windows.

Team-Fly
Team-Fly
SAP BW Administrator Workbench
In Chapter 2, you learned about the SAP BW object at a higher level. Here you learn
that such objects communicate with each other as well as how they are defined and
maintained in SAP BW using the Administrator Workbench.

The SAP BW main menu (transaction RS00) consists of two groups of transactions:
SAP R/3 BASIS Administration and SAP BW Administration, as shown in Figure 7-1.

Figure 7-1: SAP BW Main Menu. The

Menu on the Left is for SAP BW1.2B, and the Menu on the Right is for SAP BW
2.0A.

Notice that in SAP BW 2.0, the Administrator Workbench layout has been changed.
Instead of tabstrips on the top for individual categories of Objects, you see objects in
the tree format, as shown in Figure 7-1. The ScreenCam movie
SAPGUI_BW20_vs_BW12B.SCM on the CD-ROM gives you a visual tour of the
Administrator Workbench in SAP BW 1.2B and BW 2.0A.

The typical SAP R/3 BASIS administration tasks are listed on the right side of the
main menu, and the SAP BW-related activities are listed on the left. The Business
Explorer and the BW Administration options are shown in Figure 7-2.

Figure 7-2: SAP BW 1.2B Administrator Workbench.

The SAP R/3 BASIS tasks are the same as for SAP R/3 OLTP BASIS administration,
such as installing software, software patches, database administration and
monitoring operations, and user administration.
The SAP BW administration activities are related to SAP BW analytical applications
design, implementation, and administration, such as defining data load structures,
scheduling loading data in SAP BW data objects, and monitoring analytical
applications-specific data objects.

SAP BW Content Delivery Functions of the Administrator Workbench

The SAP BW Administrator Workbench is functionally divided into two groups of

menus-Content Delivery and Content Management, as shown in Figure 7-2.

The content delivery functions are responsible for creating, managing, and delivering
information to end users. The Business Explorer is the primary menu option for
managing content delivery functions. The Business Explorer enables you to manage
analytical applications and associated objects to support the content delivery function
of SAP BW. The Analyzer takes you out of the SAPGUI interface and into the
Business Explorer Analyzer (Excel) to develop queries, reports, and other analytical
applications. The Delete query object option enables you to remove queries from the
SAP BW instance. Here you also maintain variables for queries to obtain user input
and pass that input to the SAP BW OLAP processor.

For example, if you want to analyze product revenues from two fiscal periods, you
define two variables (variables in SAP BW are like parameters associated with a
characteristic); for example, Begin_FY and End_FY. You use these variables to
define filters in your query for calendar year. Upon execution of the query, the user is
prompted for Begin_FY and End_FY before fetching data from the database. You
learn more about defining and using variables in SAP BW in Chapter 11, "Analyzing
SAP BW Data."

SAP BW 1.2B supports batch printing, which enables you to print long or common
reports in the background. You learn more about developing queries and working
with Business Explorer Analyzer and batch printing in Chapter 11.

The Administrator Workbench is a data warehouse development, maintenance, and

operations environment to manage content in the data warehouse. It is here that you
construct InfoCubes, manage metadata, and define transformation rules needed to
qualify data for the InfoCubes. From the Administrator Workbench, you schedule and
monitor data load activities that pull data from data sources to populate InfoCubes.

The Administrator Workbench, as shown in Figure 7-3, consists of five key data
warehouse objects (tabstrips), titled InfoCubes, InfoObjects, ODS, InfoSources, and
Source systems. This Administrator Workbench view is called Startup view. In SAP
BW 2.0, instead of tabstrips, you have to select such objects from a drop-down
menu, as shown in Figure 7-3.
 Figure 7-3: SAP BW Administrator Workbench (Transaction RSA1). The Top
Section Shows the SAP BW 1.2 Administrator Workbench with Tabstrips to
Manage Object Types. The Bottom Shows the SAP BW 2.0A Administrator
Workbench. The Only Major Difference is that in BW 2.0A, You Select the Object
Type From a Drop-Down Menu.

In Figure 7-3, the default view is set to Source systems. Anytime you open the
Administrator Workbench, you see this view. However, once source systems have
been defined in SAP BW, you seldom need to view the source system's tree.
InfoCube or InfoSource view is more appropriate as the Startup view for the normal
development process.

To change the Administrator Workbench startup view, select Settings, Startup view,
as shown in Figure 7-4. Here you set the Administrator Workbench Startup view to
InfoCubes. This is the default view when you launch the Administrator Workbench.

Figure 7-4: SAP BW Administrator Workbench-Changing the Startup View.

Note Most of the data warehouse construction process in SAP BW 1.2B and BW
2.0A is quite similar. From here on, I limit my discussion to SAP BW 1.2B.
Only when the two are significantly different in functionality or operations
will I include SAP BW 2.0A references.

At each step in the InfoCube construction process, the Administrator Workbench

displays several icons indicating object states. Due to screen-display limitations, you
may display only those objects in which you are interested, as shown in Figure 7-5.
To change display options, select Setting, Select display options from the
Administrator Workbench.

Figure 7-5: SAP BW Administrator Workbench-Selecting Display Options.

The Administrator Workbench is further divided into two functional groups. One is for
the application design and development environment where you design all objects
leading to construction of an InfoCube, and the other is for the operational
environment where you schedule data extraction jobs, monitor data loads, and
change the management environment, as shown in Figure 7-6.

Figure 7-6: SAP BW Administrator Workbench-Operations and Development

Environment and its Relationship with the SAP BW 1.2B Staging
Process.

Note Notice that Figure 7-6 illustrates one-to-one correspondence between an

InfoSource and the data source. In SAP BW 2.0, the InfoSource is now
broken into two objects-DataSource and InfoSource. However, the overall
staging process remains the same in BW 1.2B and BW 2.0A.
Chapter 2 describes the SAP BW staging process at a higher level. In this chapter,
you learn more about the staging process and how the Administrator Workbench
facilitates this process.

Source Systems

SAP BW data sources are divided into five classes, as shown in Figure 7-7. Notice
that one SAP BW instance can be a source to another BW instance. This SAP BW-
to-SAP BW linkage can support several data marts to form an integrated enterprise
data warehouse.

Figure 7-7: Classes of Data Sources for SAP BW.

You can also load data in SAP BW using common flat files such as XLS, CVS, Fixed
Length, and Tab Delimited. The third-party data extraction tools provide additional
flexibility to populate data in SAP BW using Staging BAPI. Loading data using flat
files and third-party tools in SAP BW is discussed in Chapter 14, "Integrating Third-
Party Products with SAP BW," and Chapter 15, "Integrating Third-Party Data Access
Products with SAP BW."

Defining an SAP R/3 as a Data Source System in SAP BW

Based on SAP BW and SAP R/3 versions and patches, the actual screens and menu
paths may change. Consult the SAP BW Installation Guide on the steps to define
RFC/Logical destinations.

In SAP BW 1.2B Patch 10, follow these steps to create a new source system in SAP
BW:
1. Launch the SAP BW Administrator Workbench.

2. Go to the Source systems tab. You will see the present source system in
SAP BW in a tree format.

Note Before you define a new SAP R/3 data source in SAP BW, you
need to set up a network level communication link between them.
 This requires maintaining an RFC destination and basic ALE
setting in the source SAP R/3 for SAP BW and in SAP BW for
SAP R/3. Verify that the SAP BW administrator has already
confirmed that RFC connections are defined between these
systems and that ALE workflow in the source system is also set
up for SAP BW.

3. Select the Source systems folder, in the Source system tree root node, and
right-click. From the context menu, click Create Source System.

4. Select the source system type of your choice (as shown in Figure 7-7). In
SAP BW 1.2B Patch 10, you have two methods, automated and manual, to
create a new SAP R/3 data source definition in SAP BW. In the automated
method, you provide source SAP R/3 instance information (application
server name, system ID, system number, and login user number) and
system defines, and verify needed communication components in both
systems.

This example uses the second option, the manual source creation method,
to complete the connection setup process.

5. Enter the source name (which is actually an RFC destination defined in

SAP BW-transaction SM59 or customizing) and its description, as shown in
Figure 7-8.

Figure 7-8: Creating a Source System in SAP BW. The Source System
is the Logical Name Assigned for a Remote
Connection.

Note The technical name for the source system is XDWCLNT050. It is a

combination of source Instance System Identifier and CLNT, client
number. In this example, XDWCLNT050 means that the Source
instance System ID (normally known as SID) is XDW, and the
client from which to get data is 050.

SAP suggests this naming convention to name data sources in

SAP BW. However, though this scheme works for SAP products, it
fails when defining non-SAP data sources. For example, there are
no SID or client numbers for flat files and data sources that use
third-party data loading tools.
 I suggest using a meaningful naming scheme that applies equally
to SAP and non-SAP data sources.

6. Referring to Figure 7-8, click the green check mark to accept this entry. The
assumption is that XDWCLNT050 is a new source system, and your system
manager has not defined this source in SAP BW. You will define this new
RFC destination (transaction SM 59), as shown in Figure 7-9.

Figure 7-9: Defining an RFC Definition in SAP BW for SAP R/3 as a

Data Source.

7. Enter the target host, system number, and description of this source
system. To connect to the source system, you need a valid account. Enter a
client number, user name (for example ALEREMOTE), and password that
will be used to log on to the SAP R/3 instance and extract data for SAP BW.
SAP recommends defining a user, ALEREMOTE, in SAP BW and SAP R/3
data sources with sufficient privileges to perform ALE tasks. After entering
user account information, save this entry.

8. Click Test Connection to verify the RFC destination (see Figure 7-10). The
status message on the bottom left of the window displays Connecting
XDWCLNT050 followed by the connection time statistics window. Click the
green left arrow to go back to the RFC Destination window.
 Figure 7-10: RFC Destination Connection Verification.

9. Exit the RFC Destination window. Now SAP BW makes the connection to
the source system and generates IDOC basic types, port descriptions,
partner agreements, and so on. After successful ALE setup for the new
source system, the newly defined source system appears in the Source
System Tree, as shown in Figure 7-11.

Figure 7-11: Source Systems Tree in the Administrator Workbench to

Show Data Sources Connected to SAP BW.

Once you have attached a data source, you can collect information about metadata
and common business data that resides in a source system. To see source system
options, right-click the data source name. A pop-up menu displays available options,
as shown in Figure 7-12.

Figure 7-12: Maintaining Data Sources in SAP BW, Such as Updating InfoSource
 Metadata from Source R/3 to SAP BW or Enhancing SAP-Provided Data
Extractors.

The metadata and data load techniques depend on the data source type. In the case
of SAP R/3 as a data source, metadata load is automatic by selecting the Update
InfoSource metadata option. You learn about metadata load methods in the next
section.

InfoObjects

InfoObjects are the basic entities defined in SAP BW. They become the foundation of
the metadata repository in SAP BW. The metadata repository is shared across all
InfoCubes.

InfoObjects are grouped in the following classes:

Characteristics used to view data for analysis, such as material, customer,

and region

Key figures that represent measurements, such as product inventory and

revenue

Time characteristics to view data at different time periods, such as year and
fiscal period

Units such as quantity and currencies

Data package characteristics to track groups of data for audit and version
controls

An InfoObject can have several attributes to describe its behavior in SAP BW. For
example, material has attributes such as material number, material description, and
material family.

InfoObjects are building blocks of analytical applications in SAP BW. For example, to
do sales analysis, you use several InfoObjects, such as material, customer, sales
organization, time, unit of measure, and key figures, such as units sold, margin and
total order amount. As part of SAP BW business content, common InfoObjects are
added to the SAP BW repository. The following lists the three possible versions of
InfoObjects that exist in SAP BW:

D: SAP Delivered version. The original content reserved for SAP; however,
customers can use such objects as templates or copy them in an active SAP
BW client.

M: Revised version. This is an InfoObject that is under revision. This could

be a copy of an SAP delivered InfoObject under an active SAP BW client or a
 new InfoObject being defined by the customer.

A: Active version. This is an InfoObject that meets all specified rules and is
ready for use in the SAP BW active client.

Before you use InfoObjects, you need to transfer needed InfoObjects from SAP
version (D) to an active SAP BW client, and then activate.

You are not limited to only the SAP BW defined InfoObjects. You can create custom
InfoObjects for your own applications. For example, you may need to define a set of
new InfoObjects to describe your custom data files to load data in SAP BW.

The InfoObject's tabstrip in the Administrator Workbench shows the existing

InfoObjects tree structure, as shown in Figure 7-13.

Figure 7-13: Managing InfoObjects in the Administrator Workbench.

Under the InfoObjects tree folder, you define the InfoArea (subject-oriented objects
such as orders and invoices), followed by the InfoObject catalog, and then the
individual InfoObject within the InfoObject catalog.

One method to create or edit an InfoObject is to click the InfoObject icon in the
Administrator Workbench menu. This takes you to the InfoObject maintenance
screen (see Figure 7-14), described in the next section.
 Figure 7-14: Maintaining InfoObjects in SAP BW 1.2B.

Another method to maintain an InfoObject is to use the InfoObject tree structure, as

shown in Figure 7-13. The InfoObject tree structure allows you to group InfoObjects
under an InfoArea (subject area such as Accounts Payable, Sample Application, or
Human Resources). Within an InfoArea, you group individual InfoObjects under
InfoObject catalogs (such as characteristics and key figures). The logical grouping of
InfoObjects serves no purpose other than organizing InfoObjects under logical
names, which then are later used to reference InfoObjects collectively. InfoObjects
are stored in an InfoObject repository and exist independently of InfoCubes.

Creating a new InfoObject requires a good amount of business analysis work that
defines its behavior in SAP BW. Typical questions, besides standard data types, are
what attributes this InfoObject needs. Does it require master data? Does it need
hierarchies? How will the end user interact with this new InfoObject? These topics
are covered in great detail in Chapter 12, "SAP BW-Defining Custom InfoCubes."

All types of InfoObjects (characteristics, key figures, units, and time characteristics)
are maintained within the Administrator Workbench. In the following section, you see
how to maintain characteristics. For other types of InfoObjects, the process is very
similar.

InfoObjects: Characteristics
Take a look at the 0MATERIAL InfoObject structure. Note that MATERIAL is prefixed
by a zero. This means it is an SAP-provided object. All SAP-defined basic
InfoObjects defined in SAP BW are zero prefixed. There are several paths to get to
the InfoObject Maintenance window. A simple way to get to the InfoObject Edit
window is to click the InfoObject icon in the application menu bar (not in the
InfoObjects tabstrip), as shown in Figure 7-13.

This takes you to the Edit InfoObjects window, as shown in Figure 7-14.
Here you can list all characteristics, key figures, units, or time characteristics by
selecting the appropriate radio button. Then click the InfoObject drop-down box. For
example, if you want to select all characteristics, select the Char radio button and
click the InfoObject drop-down box. A list of available InfoObjects appears, as shown
in Figure 7-15.

Figure 7-15: Characteristics in SAP BW 1.2B.

Figure 7-15 shows the technical name, description, current version, activation state,
and data type of characteristics defined in SAP BW. This list is very useful for seeing
the status of InfoObjects and processing them in a batch fashion. For example, while
viewing the InfoObjects list, you may notice that several InfoObjects are inactive.
Select an inactive InfoObject and click the Activate icon. This activates all selected
InfoObjects.

Select 0MATERIAL from this list (refer to Figure 7-15) and click the Display button.
This displays a detailed window to describe all properties of the 0MATERIAL
InfoObject. As shown in Figure 7-16, InfoObject properties are classified in five
groups: General, Master data/texts, Hierarchy, Attributes, and Compounding.

Figure 7-16: Maintaining Individual InfoObjects in SAP BW 1.2B.

Due to metadata changes in the master data structures, the InfoObject maintenance
window has some changes. A new tabstrip has been added to capture Display
attributes for Business Explorer and Geographic Information System data mapping.

General Metadata
Under the General tabstrip, you see most common metadata definitions of the
InfoObject (see Figure 7-16). Note that a few fields are already filled in with values. In
this example, you see /BI0/0IMATERIAL in the data element field. This is the name of
the MATERIAL InfoObject in the data dictionary-SAP R/3 basis metadata
management repository.

Master Data and Text Tables

SAP BW supports a multi-language environment. However, you need to set up
language data objects specific to an InfoObject. The Master data/texts tabstrip shows
table names in which master data and associated text is stored, as shown in Figure
7-17.

Figure 7-17: Assigning Master Data and Text Elements to an InfoObject.

With SAP BW's multi-language functionality, end users can analyze data and
generate reports in the language of their choice. The language preference is
established when an end user logs on to an SAP BW instance. Suppose two sales
managers log on to the same SAP BW instance. One manager selects English, and
the other selects German. Both managers are looking at the same sales analysis
query to see product sales for the quarter. The person who chose English sees the
product family description for printers as Printer, and the person who chose German
sees the product family as Druker. Moreover, with multi-currency support in SAP BW,
both can see product revenues in local currencies. This powerful multi-language and
multi-currency implementation is quite suited to today's global business climate.

In earlier data warehouse models (William H. Inmon's data warehouse theory), the
master data was assumed to be a static data entity, meaning that master data does
not change in a data warehouse. However, in today's world the master data often
changes. Such change is identified as slowly changing dimensions.

To manage changes in the master data, you can make master data elements time
dependent when defining an InfoObject.
In the Master data/texts tabstrip, select the master data time-dependent check box.
This makes master InfoObjects time dependent. Again you see several table names
that store text-related information that SAP BW assigns and creates automatically.

Note Time dependencies require additional system resources to update an

InfoCube and to fetch data from SAP BW for the end user's queries. Make
sure that such time dependency is necessary for business analytical
applications. If business requires reporting on only the most current state of
data, do not implement time-dependent master data. However, when the
business community wants to see accurate analytical data at the time it was
collected, only then implement time-dependent master data.

For example, suppose a new general manager wants to see sales revenue
by sales area during the past two years grouped by months, regions, and
sales organizations to benchmark which sales organization structure
generated the most revenue. During those two years, the sales organization
was reorganized several times. To analyze such product sales data
correctly, you must time-stamp the sales organization hierarchy and the
associated product sale transaction data. With this master data time-
stamping, you can accurately analyze data that reflects the state of the
organization and the generated revenues.

To add complexity to this analysis, during those two years, product

hierarchies may have been changed, which also could have affected
product revenues. This is where multidimensional analysis plays a major
role in such analytical applications as profitability and financial analysis.

Hierarchies
SAP BW supports robust hierarchy structures. You have several options to assign
one or more hierarchies (internal or external) to an InfoObject. Hierarchies are
assigned to an InfoObject through the InfoObject maintenance window, as shown in
Figure 7-18.

Figure 7-18: Maintaining an InfoObject and Assigning Hierarchies.

SAP BW supports four types of hierarchies, as listed here:

 Version-dependent hierarchy. Such types of hierarchies have the same
name but support several versions. A product hierarchy is an example where
a planned product hierarchy is usually different than the actual product
hierarchy.

Time-dependent hierarchy name. The time-dependent hierarchies are valid

only within a given time period. In today's business climate where business
reorganizations are very common, the organizational hierarchies for a
business unit may change several times in a year. This is when you would
use a time-dependent hierarchy.

Time-dependent hierarchy structure. For these kinds of hierarchies, the

actual items in a hierarchy change for a fixed time period. The name and
version of the hierarchy still remain the same. Such time-dependent hierarchy
structures are common for sales and marketing packages for seasonal
product campaigns.

Hierarchy intervals. The hierarchy interval permits grouping together a

range of logically grouped objects under one hierarchy node. This type of
hierarchy is common in product sales analysis. If you want to analyze product
revenues by class, you build a product hierarchy in such a way that nodes
represent a range of product groups. For example, one node represents
products P100 to P200 while a second node represents products P300 to
P500. This logical grouping is ideal when analysis is to be done at different
hierarchy levels. This type of hierarchy is best suited for executive
information systems where information has to be processed and presented at
very summarized levels.

Hierarchies provide a powerful method for visual data navigation and data
aggregation at an object hierarchy level. Selecting a hierarchy model requires
extensive modeling effort to evaluate what works best for your business analysis
needs.

Note that hierarchies are shared across all InfoCubes. Dimension tables point only to
an InfoObject hierarchy structure. An InfoObject can have multiple hierarchies. Like
any other object, hierarchies support active and inactive versions. If you use object
hierarchies in SAP R/3, you can bring them directly to SAP BW. Moreover, you can
always manually define a hierarchy structure in SAP BW, and then load hierarchies in
SAP BW using flat files.

Chapter 12 discusses defining and implementing hierarchies.

InfoObject Attributes
InfoObject attributes provide detailed descriptions on characteristics associated with
an InfoObject. Figure 7-19 shows the attributes of the 0MATERIAL InfoObject.
Attributes in a master data table are also referred to as navigational attributes that
support data navigation capability.

Figure 7-19: Assigning Attributes to an InfoObject.

Like the master data, attributes are shared across all InfoCubes. Deciding when to
set a navigational attribute depends on how end users want to analyze data. The
data modelers need to understand how end users plan to view and analyze data
before setting navigational attributes. The use of large numbers of navigational
attributes (see Figure 7-20) can lead to poor query performance. Chapter 12
discusses SAP BW data modeling techniques in detail.

Figure 7-20: Navigational Attributes of an InfoObject.

Compounding
The compounding feature enables data warehouse designers to build a relationship
between one or more InfoObjects to give more meaning for evaluation. For example,
you might want to evaluate the characteristics of Vendor in connection with Material.
Here, you create compound characteristics Vendor to Material, as shown in Figure 7-
21. With this link between Material and Vendor established, you have access to
Vendor InfoObjects in queries that reference Material. It simplifies the end-user data
analysis task.
 Figure 7-21: Building Compounding Functionality for an InfoObject.

Compounding should be used as an exception because it can result in poor

performance. The preceding scenario can easily be handled in an InfoCube by using
Material and Vendor dimensions.

Key Figures
The process for defining key figures is similar to that for characteristics. However,
because key figures are measures of some entity, they differ in data types and
include mathematical attributes. The Key Figures maintenance window has three
tabstrips-Type/unit, Aggregation, and Other attributes, as shown in Figure 7-22.

Figure 7-22: Defining Basic Data Types for a Key Figure.

SAP BW supports five types of key figures: amount, quantity, number, integer, date,
and time. You specify such types in the Type/unit tabstrip.

The Aggregation tabstrip is used to define evaluation methods for a key figure. Four
methods (summation, minimum, maximum, and no aggregation) are used by which
key figures are aggregated in the Business Explorer. You can also specify how a key
figure is aggregated in the Business Explorer with regard to an exception
characteristic that is optionally provided in the aggregate reference characteristics
field, as shown in Figure 7-23.
 Figure 7-23: Defining an Aggregation Scheme for a Key Figure.

The Other attributes tabstrip is used to define how data is displayed in the Business
Explorer. The display attributes, such as decimal places and display text selections
(short or long), are selected in that window.

Time Characteristics
Time is the most important dimension in data warehousing. Every data analysis is
time-based such as revenues today, this quarter, yesterday, this year, last year, and
on and on. For this reason, SAP requires you to have at least one time dimension in
an SAP BW InfoCube. SAP provides a set of predefined time characteristics as part
of Business Content. With SAP BW 1.2B Patch 12, you cannot create your time
characteristics. SAP provides the following nine time characteristics:

Calendar day (0CALDAY)

Calendar week (0CALWEEK)

Calendar month (0CALMONTH)

Calendar quarter (0CAL QUARTER)

Calendar year (0CALYEAR)

Fiscal year variant (0FISVARNT)

Fiscal year (0FISCYEAR)

Fiscal period (with year) (0FISPER)

Fiscal period3 (without year) (0FISPER3)

Figure 7-24 shows how calendar-year time characteristics are defined in SAP BW.
 Figure 7-24: Definition of Calendar Year (0CALYEAR) Time Characteristics.

Unit of Measure Characteristics

Any key figure defined in the fact table has to be measured against some unit of
measure, such as sales amount per product unit sold or amount in currency units.
SAP BW supports two types of units: quantity and currency. The unit characteristics
are used as a reference point in InfoCube facts. For example, a currency
characteristic in the fact table is of document or local currency type. Similarly, the
sales amount in a fact table often refers to per unit sold. Figure 7-25 shows the
definition of 0BASE_UOM characteristics.

Figure 7-25: Definition of Unit of Measure, 0BASE-UOM InfoObject.

Note By now you may have noticed that some fields in the InfoObject screens
are automatically filled in with text values prefixed by /BIC/ or /BI0/. This is
 the SAP BW object's naming scheme for customer created objects. Object
names prefixed with /BI0/ are SAP defined objects for SAP BW. BIC stands
for Business Information Warehouse Customer Defined Object, and BI0 for
SAP Reserved Object.

This section looks at the 0MATERIAL InfoObject. From a database point of view, the
system generated several tables to capture all the detailed information on
0MATERIAL. A few such tables are listed in Table 7-1; these tables are specific to
managing the 0MATERIAL InfoObject definition. Note here that you do not need to
define these tables using SQL. SAP BW automatically created these tables.

Table 7-1: Master Data Tables for 0MATERIAL InfoObject in SAP BW 1.2B
Table Name Description
/BI0/MMATERIAL Master data
/BI0/TMATERIAL Text data
/BI0/HMATERIAL Hierarchy
/BI0/SMATERIAL Master data IDs (SID table)
/BI0/IMATERIAL SID structure of hierarchies
/BI0/KMATERIAL Conversion of hierarchy and SID
/BI0/JMATERIAL Material interval hierarchy
/BI0/NMATERIAL Attributes and SID relationship
/BI0/UMATERIAL View of text and SID tables

Working with the InfoObjects Tree

InfoObjects tree allows you to group InfoObjects in logical groups, called InfoAreas.
The benefit of InfoAreas is that when you reference an InfoArea, all InfoObjects
assigned to an InfoArea become visible to you. Working with the InfoObjects tree
requires the following three steps:
1. Create/maintain an InfoArea.

2. Create/maintain InfoObject catalogs.

3. Create/maintain an InfoObject.

SAP BW gives you several paths to perform all the preceding tasks. Figure 7-26
shows paths you can take to manage the InfoObjects Tree structure.
 Figure 7-26: Managing InfoObjects in SAP BW 1.2B.

Creating an InfoArea
To maintain an InfoObjects tree, right-click the InfoObject catalog line of the
InfoObjects tree (see Figure 7-27) and select Create InfoArea. You are prompted for
the InfoArea technical name and its description. Click the green arrow to save
InfoArea information.

Figure 7-27: Creating an InfoArea, Demo Info Area, to Group Analytical

Applications for Product Demonstration.

When back in the Administrator Workbench window, make sure to click the Refresh
icon in the Application menu. You must refresh the screen to see the InfoArea you
have just created in the InfoObjects Tree, as shown in the bottom right of Figure 7-
27.

Creating an InfoObject Catalog

InfoCatalog usually consists of two types of objects: characteristics and key figures.
To create an InfoObject catalog, select an InfoArea, right-click, and select Create
InfoObject catalog, as shown in Figure 7-28.

Figure 7-28: Creating a New InfoObject Catalog.

Now you need to define InfoObjects with an InfoCatalog. In the Create InfoObject
Catalog window, select the appropriate radio button to identify the type of catalog,
characteristic or key figure, as shown in Figure 7-29. Click the green arrow to accept
your entry. This takes you to the Edit InfoObject Catalog window.

Figure 7-29: Defining Characteristics for an InfoObject Catalog.

The edit window has two sections. The bottom-right section displays existing
InfoObjects as templates, and the bottom-left section displays the InfoObject
structure of your InfoObject catalog. Initially, the structure area is empty when
creating a new InfoObject catalog.

To assign an InfoObject in the InfoObject catalog, select one or multiple InfoObjects

displayed as templates, on the right, and press the left-arrow button. This copies the
selected InfoObject definitions in the InfoObject catalog, as shown in Figure 7-30.
 Figure 7-30: Editing an InfoObject Catalog for Characteristics.

By default, all available InfoObjects are displayed as templates. This can be a very
large list, and it can be time consuming to find the InfoObjects you need. For this
reason, you can narrow the list of InfoObjects by selecting all InfoObjects in an
InfoSource, InfoCube, another InfoObject catalog, or by specifying a criterion. This is
achieved by using the icons on the right of the Template type selections. Figure 7-30
shows an InfoObject catalog named "BW Sample Application: Characteristic"; it is
used as a template to define the characteristic structure for a new InfoObject catalog.

To verify that all individual InfoObject definitions are correct and active, click the
Check icon . Then click the Activate icon to activate and save the InfoObject
catalog. The window's status message line displays any activation errors or success
messages. When activation is successful, the Object status is changed to green,
indicating that it is active and executable.

Exit from the Edit InfoObject Catalog window to go back to the Administrator
Workbench. Here you see the InfoObject catalog in the InfoObjects Tree structure.

Repeat the same steps to create another InfoObject catalog for the key figures
associated with the InfoArea, as shown in Figure 7-31.
 Figure 7-31: Editing an InfoObject Catalog for Key Figures.

For key figures, you also need to specify units of measure. Check and activate the
key figures InfoObject catalog and go back to the Administrator Workbench. You will
see both InfoObject catalogs listed under your InfoArea. Expand the InfoObject
catalog for characteristics and see individual InfoObjects that build an InfoObject
catalog structure. By selecting an individual member InfoObject-for example,
Customer Number-you will see all attributes of that InfoObject, as shown in Figure 7-
32.

Figure 7-32: Viewing InfoObject Details of an InfoObject Catalog.

InfoSources

An InfoSource is a logical view of information and the business rules that transform
data coming from a source system to the business analysis view needed to construct
an InfoCube. Each InfoSource can be assigned to one or more source systems. You
can also think of an InfoSource as a collection of rules and transformations needed to
stage data in SAP BW.

As discussed in Chapter 2, the scope of the InfoSource has been changed in SAP
BW 2.0A. As shown in Figure 2-10, the InfoSource is divided into two sets of objects:
DataSource and InfoSource. This breakdown makes SAP BW much more flexible in
defining and managing InfoSources that require data from several source systems.
Before creating or maintaining InfoSources, you must have at least one source
system defined in SAP BW. If your source system happens to be SAP R/3,
InfoSources for transaction and master data are automatically pulled in SAP BW
using the Source System tree, as shown in Figure 7-33.

Figure 7-33: Importing InfoSource Metadata in SAP BW From an SAP R/3 Data
Source.

After updating InfoSource metadata, you see a list of InfoSources in the InfoSource
Tree.

To create a new SAP R/3 InfoSource, select the InfoSources Tree in the
Administrator Workbench and right-click. Select Create application component (see
Figure 7-34).

Figure 7-34: Creating New Application Components to Set up an InfoSource.

You define individual InfoSources within an application component area. The

following lists the two classes of InfoSources:

Transaction data

Master data/text/hierarchies

The transaction data and master data InfoSources behave differently from one
another in SAP BW. For transaction data InfoSources, you associate one InfoSource
with one or more source systems. For master data InfoSources, you associate
source systems through an InfoObject.

InfoCubes

InfoCubes are the heart of SAP BW analytical data stores. An InfoCube is SAP BW's
equivalent of a logical data mart. A cube consists of characteristics and key figures.
The updated rules define how an InfoCube is populated. The InfoCubes tabstrip of
the Administrator Workbench is used to define all steps needed to build an InfoCube.

The InfoCubes allow you to view information from different angles. Profitability
Analysis, Sales Analysis, and Cash Flow Analysis are just a few common
multidimensional analytical applications. For example, you have an InfoCube with
five dimensions (Sales Organization, Customer, Product, Time, Unit of Measure) and
three indicators (Cost, Margins, Units Sold).

In this sales analysis InfoCube, senior management is interested in revenue by year,

and the sales district manager is interested in monthly sales analysis by product line,
by customer, and unit sold.

Suppose you have 10 sales representatives, 20 product lines, 1,000 customers and
are looking at them for two years' worth of data. You have 14.4 million ways (10 sales
rep x 20 products x 1,000 customers x 3 indicators x 48 months) to view this data.
Without multidimensional technology, doing such extensive analysis would not be
possible. The sales InfoCube can provide summary-level information for senior
management as well as for the district sales manger, depending on dimensions
selected and the level of aggregation information.

The first step in the design of an InfoCube is multidimensional modeling. This

assures that needed characteristics and key figures are fully understood and all rules
to compute key figures are well defined. The multidimensional modeling process is
discussed in detail in Chapter 12.

The InfoCube Tree, as shown in Figure 7-35, shows an InfoCube Tree structure. First
you create an InfoArea, and then you create InfoCubes under the InfoArea. The
purpose of an InfoArea is to group subject-oriented InfoCubes together, somewhat
like a group of subject-centric data marts. Figure 7-35 shows the Sales and
Distribution InfoArea that consists of the Customer InfoCube. In the future, one can
define additional InfoCubes related to sales and distribution such as Deliveries.
 Figure 7-35: Sales and Distribution InfoArea and Associated InfoCubes.

Viewing an InfoCube Data Model

To view the data model of an InfoCube, select an InfoCube and right-click. This
displays several options, as shown in Figure 7-35. Select Display InfoCube data
model. The data model displays all dimensions, their attributes, key figures, and
navigational attributes defined in a selected InfoCube, as shown in Figure 7-36.

Figure 7-36: SAP's Customer InfoCube Data Model.

This is a quick way of displaying the structure of an InfoCube. The InfoCube shown in
Figure 7-36 has eight dimensions named Customer, Material, Sales area data,
Version, Value type, Time, Unit of measure, and Data packet. The last three
dimensions are automatically assigned, but the rest are assigned by the user when
defining the InfoCube.

Viewing an InfoCube Definition

To view the structure of an InfoCube to see how dimensions, key figures, and
navigational attributes are defined in an InfoCube, select an InfoCube and right-click.
Then select Change InfoCube. This opens the Edit InfoCube window, as shown in
Figure 7-37.

Figure 7-37: Definition of SAP's Customer InfoCube Data Model.

The Edit InfoCube window is where you actually start to construct the physical
structures of an InfoCube. It has three tabstrips. The Chars (Characteristic) tabstrip
(shown in Figure 7-37) is used to select characteristics and to define dimensions and
navigational attributes. The Time chars. (Characteristic) and Key fig. (Figures)
tabstrips enable you to select or define time periods and key figures needed for your
analysis.

Instead of searching through hundreds of InfoObjects to select a few for your

InfoCube, you can use templates to build InfoCubes. Templates are a predefined
collection of objects, such as InfoObjects, InfoObject catalogs, and InfoCubes. After
selecting a template, you simply transfer objects from the Template list to the
InfoCube Structure by clicking the left-arrow buttons between the Template and
Structure lists (refer to Figure 7-37). Because you are transferring the object
definitions to the InfoCube, this view is called the Transfer view. However, when you
click the Detail view button, you see more information on data definitions associated
with each characteristic.

To define or view the dimensions for an InfoCube, click the Dimensions button. This
shows you all dimensions defined in an InfoCube, as shown in Figure 7-38.
 Figure 7-38: Defining Dimensions for an InfoCube and Assigning Characteristics
to the Dimensions.

Figure 7-38 shows that the Customer dimension is mapped to Sold_to party
characteristics, and the Material dimension is mapped to Material number. Another
method for dimensions assignment is to view the dimension assignment in a tree
fashion; click the Grphcl assgnmnt (graphical assignment) button in the Options
group. This displays dimension assignments in a very readable fashion, as shown in
Figure 7-39.

Figure 7-39: Graphical View of Dimension Assignments for an InfoCube.

So far you've looked at the Characteristics tabstrip to see how characteristics and
associated dimensions are defined. The process for defining time characteristics and
key figures is very similar to that of defining characteristics in the InfoCube. In the
Edit InfoCube window (see Figure 7-37), click the Time chars and Key fig tabstrips,
respectively, to define time characteristics and key. You see available InfoObjects on
the right. Transfer needed time characteristics and key figures in the Cube model.
Then save the InfoCube.

Viewing InfoCube Content

The best way to view an InfoCube's contents is to write a query and verify if the
numbers are correct. However, in the development and operations environment, you
may want to review loaded data in SAP BW directly from within the Administrator
Workbench to verify if the data has been loaded correctly. To do so, select an
InfoCube, right-click, and select Maintain InfoCube content (refer to Figure 7-35).
This opens the InfoCube content window, as shown in Figure 7-40. Another method
to view data from an InfoCube is to run the LISTCUBE transaction to list content from
an InfoCube.

Figure 7-40: Viewing InfoCube Content.

This window has six tabstrips. The first, InfoCube contents, shows a list of all objects
defined in the selected InfoCube. Click InfoCube content or the Fact table button.
Both list the fact data content, but the data selection criterion is different. Using the
InfoCube content button is preferred because it provides you with more options to
select data sets from an InfoCube. The Fact table button only lists data from the fact
table, including the dimension columns in the fact table.

The Performance tabstrip displays the database-specific options, such as InfoCube

index verification. The other tabstrips provide information on data load statistics. You
learn more about these areas later in this book.

Team-Fly
Team-Fly
Summary
In this chapter, you learned the basics of the Administrator
Workbench. Now you have sufficient background on how to define
source systems, InfoObjects, and InfoSources in SAP BW. Other
components such as InfoCubes, ODS, and Scheduler are discussed
in the next chapters.

Team-Fly
Team-Fly
Chapter 8: SAP BW-Loading Business
Content
In this Chapter
SAP BW content consists of all objects needed to deliver several
ready-to-go analytical applications across many subject areas, such
as Sales and Distribution, Financial, and Human Resources. In this
chapter, you first learn about the basic data flows in SAP BW and
SAP R/3 needed to build InfoCubes. After importing metadata from
an SAP R/3 data source, you learn all the steps necessary to
activate business content in SAP BW to implement working
analytical applications.

Team-Fly
Team-Fly
Data Flow between SAP R/3 and SAP BW
Unlike traditional data warehouses where OLTP applications
schedule and trigger data extracts for data warehouses, called the
push model, SAP BW uses the pull model to pull needed data from
its data sources. You schedule data extracts from within SAP BW.
SAP BW sends data extract requests to the appropriate data
sources. The OLTP system collects/extracts and transports
requested data to SAP BW. SAP BW loads its data in its data stores.

The entire data load process is managed from within the SAP BW
Administrator Workbench, as discussed in Chapter 9, "Preparing R/3
Data Sources for SAP BW Initial Data Loads," and Chapter 10,
"Loading Data via Flat Files." The SAP BW administrator and
operations staff are responsible for scheduling data load jobs.
However, the business analyst and SAP BW developers need to
make sure that the data loaded in SAP BW is accurate and resolve
problems if data loads fail or report several warnings. Figure 8-1
shows data flows between SAP BW and its data sources. Notice that
the SAP BW staging engine needs to know full metadata and data
content definitions (structures) from its SAP R/3 data source
(extraction engine layer). This is achieved by importing metadata
from the source SAP R/3. But how is SAP BW specific metadata
captured and managed in SAP R/3? Here is how it works.

Figure 8-1: Information

Flow between SAP BW and its Data Sources.
The SAP BW specific content and environment setup process in
SAP R/3 is very similar to the SAP R/3 OLTP release upgrade. To
verify that the SAP R/3 OLTP instance is properly upgraded with the
SAP BW add-on, list table AVERS using transaction SE16. It must
list BW-BCT, as shown in Figure 8-2.

Figure 8-2: Verification of an SAP BW Add-On in an SAP R/3

OLTP Instance.

SAP provides several transports to load business content in SAP

R/3. The actual number of transports varies based on your SAP R/3
version (3.0D through 4.6B) and the SAP BW version (1.2A or 1.2B
and Patch numbers 1-12). These upgrade programs load objects in
SAP R/3 for SAP BW data extractors in terms of database tables,
InfoObject definitions, Extract structures, Extract programs, and
other programs needed to build and set up data extraction schemes
for SAP BW.

Note SAP BW business content in SAP R/3 is like a release

upgrade. You must read, collect, and apply all relevant
patches and OSS notes needed for a specific SAP R/3
version. Always check the OSS notes for the latest updates
for business content because they frequently change.

Metadata Management in SAP R/3 OLTP

After installing business content in SAP R/3, you need to create a
logical system name using transaction SM59 for SAP R/3 instance
as a data source. You will use this instance logical name to connect
SAP BW to SAP R/3. Transaction SM59 requires special user
privileges. In the SAP R/3 OLTP environment, the basis
administrator usually has privileges to create logical system names.
However, in the SAP BW development environment, a few SAP BW
developers may require Basis-level privileges to define logical
system names for data sources.

Metadata is stored in several tables, both in SAP BW and SAP R/3.

Figure 8-3 shows the main tables in SAP R/3 that manage metadata
for SAP BW.

Figure 8-3: SAP BW 1.2B Metadata Management in SAP R/3

OLTP Instance. Tables that Manage SAP BW Specific
Metadata.

Table RODIOBJ contains metadata for all InfoObjects in the source

system defining its associated key figures, characteristics, time, and
unit of measure in tables RODKYF, RODCHA, RODTIM, and
RODUNI, respectively. Table RODIOBJCMP contains only the
compounded InfoObjects associated with an InfoObject for the
source system.
On the right of the RODIOBJ table in Figure 8-3 are two groups of
information objects: transaction data and master data. The ROIS is a
very important table for transaction data. It contains information on
InfoSources, function modules, and extract structures needed to
extract data from OLTP and prepare such data for SAP BW using
transfer structures defined in the table for ROISGEN. For example, if
you view table ROIS using transaction SE16, you will see that for SD
InfoSource 2LIS_01_S001, SAP R/3 will use function module
MCS_BIW_LIS_API to extract data using extract structure
S001BIWS. This simple method of calling data extractors from SAP
BW enables customers to implement their own data extractors by
entering their function module, extract structure, and other
parameters in ROIS. You learn more about extending SAP business
content and writing custom extractors in Chapter 13, "Enhancing
Business Content and Developing Data Extractors."

Caution One must be very careful when altering entries in any of

the listed tables. Inaccurate changes made in these
tables will cause erroneous results not only in SAP R/3,
but also in SAP BW when metadata is refreshed. You
must be trained in writing data extractors before
defining your own custom data extracts and including
such data extract information in these tables.

The ROIS table contains the InfoSource definition for transaction

data; the RODCHABAS table lists function modules for basic master
data elements, their associated text, and hierarchies used to prepare
transfer structure for SAP BW 1.2B.

Metadata Management in SAP BW

As shown in Figure 8-1, to load data in SAP BW, you need several
data structures that receive information from data sources to
populate InfoCubes. In SAP BW 1.213, metadata is similar to
InfoObject metadata in the SAP R/3 OLTP instance. Figure 8-4
shows tables in SAP BW that store metadata for all information
objects associated with InfoSources. Table names in italics represent
master data entities.

Figure 8-4: Metadata Tables in SAP BW 1.2B.

You may have noticed that identical objects are maintained in

SAP BW and SAP R/3 that support entire information flow. How
do you know where these objects reside? The simple rule of
thumb is that RS-prefixed objects reside in SAP BW instances,
and RO-prefixed objects reside in SAP R/3 OLTP instances. The
RS stands for Reporting Server, and RO stands for the Reporting
Server component in OLTP. For example, tables RSIS and ROIS
hold InfoSource metadata in SAP BW and SAP R/3 OLTP,
respectively. This naming scheme is not limited to tables; it
applies to most other objects such as programs and function
modules as well.

Because master data elements tend to be less complex than

transaction data, notice that in Figure 8-4 there are only a few tables
that handle master data metadata. However, for transaction data,
there are individual tables for all data staging levels.

Note Today, metadata on SAP R/3 data sources is very tightly

coupled with SAP BW 1.2B. In many ways, metadata for
 business content objects is duplicated in SAP BW and SAP
R/3. For example, for InfoSources, the same mapping and
transfer rules exist and are managed in both SAP BW and
SAP R/3 data sources. The SAP BW 2.0 metadata model
is not very tightly dependent on the SAP R/3 OLTP data
sources. For this reason, the metadata mode in SAP BW
version 2.0 will be very different from SAP BW 1.2B as
described. In SAP BW version 2.0, most of the metadata
will be managed from within SAP BW. Very minimal SAP
BW-centric metadata will be kept in the SAP R/3 OLTP
instance.

Loading Metadata in SAP BW

Two methods can be used for defining InfoSource metadata in SAP

BW. The first method involves importing directly from SAP R/3 as
part of business content, and the second method is to define
inbound data structures manually in SAP BW for SAP R/3 and non-
SAP R/3 data sources.

When SAP BW add-ons have been completed and the SAP R/3
logical system name for SAP BW has been defined, you are ready to
connect SAP BW and load metadata. In SAP BW, first define a
source system in SAP BW pointing to an SAP R/3 instance, as
described in Chapter 6.

After defining a source system and testing RFC level connections to

the source system, you are ready to load metadata for InfoSources
and other SAP BW specific objects defined in SAP R/3. Click the
Source systems tabstrip. Expand the Source systems tree, and then
right-click the Source System you want to load metadata from, as
shown in Figure 8-5.
 Figure 8-5: Loading InfoSources Metadata From an SAP R/3
Data Source.

Select the Update InfoSource metadata function, as shown in Figure

8-5. Metadata for all InfoSources defined in SAP R/3 is automatically
transported in SAP BW.

Note You can refresh metadata any time. It is a common and

recommended practice that when a data source happens to
be SAP R/3, you enhance or create new InfoObjects in
SAP R/3, and then refresh data in SAP BW 1.2B; for
example, if you add a new field in the SAP provided
Customer InfoSource 2LIS_01_S001 or you define a
custom InfoSource in SAP R/3. By refreshing metadata, as
shown in Figure 8-5, you will automatically bring new
definitions in SAP BW.

After updating metadata in SAP BW, go to the InfoSources and

InfoObjects tabstrips. Expand the respective object trees. Many new
entries are now listed as a result of the metadata update. You need
this metadata before activating predefined SAP business content
such as InfoSources, transfer rules, communication structures,
update rules, InfoCubes, queries, key performance indicators, and
channels.

For non-SAP R/3 data sources, first you define a data source in SAP
BW for a flat file. Then depending on the content of the flat file, you
may create a new InfoSource for master or transaction data.
If the flat file contains master data, it must have only one type of
master data InfoObject. In other words, from one file you cannot load
master data for customers and material. They have to be in separate
files, each uniquely identified in SAP BW via unique InfoSources.
When you attach a source system to an InfoSource, SAP BW asks
for the metadata for the flat file. You learn more about loading data
file flat files in Chapter 10.

Once metadata has been captured and validated in SAP BW, the
rest of the staging process is the same as if the data source were
SAP R/3.

Team-Fly
Team-Fly
Activating Business Content in SAP BW
As discussed in Chapter 7, objects in SAP BW can have three versions: D, M, and
A (delivered, maintained [revised], and active, respectively). You cannot work
directly with D-versioned objects; therefore, you need to make a copy of D-
versioned objects in your active client and then modify as needed. The business
content activation process consists of the following steps:
1. Transfer SAP-delivered content to the active client.

2. Make changes as needed.

3. Activate objects.

SAP BW business content consists of several InfoObjects, InfoSources,

InfoCubes, transfer/update rules, queries, and channels. It takes several hours to
activate hundreds of objects in the SAP BW data dictionary and SAP BW specific
tables that you may not really need. There is no need to activate the entire
business content all at once. Instead, activate only those objects required to build
a specific InfoCube, queries, and channels to implement your current
requirements. For example, if you are implementing a sales analysis InfoCube for
Customers, activate all objects ranging from InfoObjects through the channels
needed for the Customer InfoCube and skip the rest.

Business content consists of complete, ready-to-run business analytical

applications-data extracts, InfoSources, InfoCubes, queries, and solutions. For
example, say you activate Customer, Invoices, Billing and Orders InfoCubes and
associated queries and reports. Soon after loading data in SAP BW, business
analysts are ready to do typical business analysis, such as revenue analysis by
customers, products, sales areas, and planned versus actual cost analysis.
Chapter 2 lists the relative business content that comes with SAP BW 1.2B and
2.0A.

Note Often, it is hard to know all the InfoObjects and the base level objects
needed to activate specific InfoCubes. Activating objects that depend on
base InfoObjects such as InfoSources, transfer rules, update rules, and
InfoCubes results in errors. Resolving these errors and activating
InfoObjects one by one can be very time consuming. To avoid this
situation, I suggest you always activate all InfoObjects in the SAP BW
active client and activate the rest of the objects when needed, such as
InfoSources, InfoObjectCatalogs, and InfoCubes.

The order in which business content objects are activated is important (numbers
as of SAP BW 1.2B Patch 12):
 1. InfoObjects

2. InfoObject catalogs

3. InfoSources

4. InfoCubes

5. Update procedures

6. Query objects

7. Channels

Note In SAP BW 2.0, most of the dependent objects activation process is

automatic. For example, if you activate Customer InfoCube, then all
relevant InfoObjects, transfer rules, InfoSources, InfoCubes, and update
rules are automatically activated as well. This automation saves lot of
time in implementing business analytical applications.

Preparing the SAP BW Instance for Business Content

First, you need to pull configuration information about a source SAP R/3 OLTP
instance. This requires the following steps:
1. Verify that the SAP BW add-on has been installed on the Source SAP
R/3 instance.

2. Create the Source SAP R/3 OLTP System in SAP BW as described in

Chapter 7.

3. Update metadata for InfoSources from the source system, as shown in

Figure 8-5.

4. Transfer exchange rates from the source system to SAP BW; this is
shown in Figure 8-6. The system prompts for exchange rates and update
mode for the exchange rate-a new exchange rate or an update to an
existing exchange rate in SAP BW.
 Figure 8-6: Importing
Exchange Rates From an SAP R/3 OLTP Instance.

SAP BW leverages business rules available in SAP R/3 instances that

can be used to process information in SAP BW. These exchange rates
are used to perform currency conversion calculations at the transfer,
communication, and update rules level. Moreover, currency conversion
rules can be used within SAP BW Business Explorer to dynamically
convert multi-currency figures to a standardized currency. For example,
in a global business level transaction, you may be working with vendors
from several countries to fulfill an order. However, from a data analysis
point of view, one needs to convert multi-currency figures to a standard
currency figure, such as the U.S. dollar. Here you apply these currency
conversion rules to convert specific currency figures to a standard
currency of choice.

5. Transfer the global settings, as shown in Figure 8-7. You have the choice
of transferring all currencies, units of measure, and fiscal variants defined
in the SAP R/3 data source instance. This saves you some time by
loading global settings automatically instead of defining them manually in
SAP BW.

Figure 8-7: Importing Global Settings From SAP R/3.

Enabling Business Content in SAP BW

The enabling of business content is a long process. First, make sure that you have
SAP R/3 instances defined as a data source in SAP BW. Then select object
categories one by one, transfer SAP versioned objects to your active client, and,
depending on individual object types, construct or verify transfer/communication
structures and update rules to populate the InfoCubes. Finally, activate queries
and channels associated with an InfoCube.

From the Administrator Workbench, choose Tools. From the drop-down menu,
select Business Content. This opens another submenu and displays a list of
objects, as shown in Figure 8-8.

Figure 8-8: Activating Business Content in SAP BW 1.2B.

Activating InfoObjects
To activate InfoObjects for a specific InfoCube, such as the Customer InfoCube,
select InfoObjects from the Business Content menu. This launches the InfoObject
display screen, as shown in Figure 7-14. Then display all InfoObjects associated
with an InfoCube.

Note Make sure that the Edit InfoObject window is set to the SAP Delivered
version. The field version on this screen displays "D" SAP delivery; if it
does not, then click the Change system Setting to Delivered version.

Select all InfoObjects, transfer the SAP delivered version, and save. Then go back
to the InfoObject Edit window, select these new InfoObjects, and click the Activate
icon. This activates all selected InfoObjects.

After you activate InfoObjects, SAP BW displays an activation report. Make sure
that there are no activation errors. If there are, first correct the InfoObjects causing
the problems and then activate only the inactive InfoObjects.

Note Often, an InfoObject may have several dependent InfoObjects. When

activating an InfoObject, you are prompted to activate the dependent
objects. You can also display all dependent objects. You should activate
the dependent objects option to ensure that when an active version of an
InfoObject is saved, it is complete. Otherwise, you will encounter
problems later because the InfoObject will be only partially correct.
 For example, the 0CUSTOMER InfoObject has dependency on other
InfoObjects such as 0COUNTRY, 0REGION, and 0CITY. If any one of
these dependent InfoObjects is not active in the SAP BW dictionary,
saving an incomplete 0CUSTOMER InfoObject will not serve any
purpose.

Activating InfoObjectCatalogs
After activating the InfoObjects, activate the InfoObjectCatalogs. Select the
InfoObject Catalogs option from the Business Content menu. The activation
process is similar to activating the InfoObjects, but you select InfoCatalog for
characteristic or key figure for individual InfoCubes. The process to activate an
InfoObjectCatalog is described in Chapter 7.

Activating InfoSources
You can activate InfoSources for a specific source SAP R/3 release (3.0D through
3.1I); however, this is optional because when SAP BW is connected to an SAP R/3
source system, the needed InfoSources are automatically defined in SAP BW as
part of the metadata import.

Activating InfoCubes
Business Content (SAP BW 1.2B Patch 12) provides more than 45 InfoCubes
(more than 100 in SAP BW 2.0). Again, not all customers need to activate all
InfoCubes. Most customers will load specific InfoCubes to assess their
functionality and enhance the content to meet their needs. You can create new
InfoCubes based on SAP BW-provided InfoCubes as templates. Then you remove
or add elements as needed to implement your analytical applications.

To activate an InfoCube, select InfoObjects from the Business Content menu, and
then select an InfoCube to activate. For example, to activate the SD Customer
InfoCube, select 0SD_C01 from the list of available InfoCubes, as shown in Figure
8-9. Click the Display button to display the InfoCube in the InfoCube design
window.
 Figure 8-9: Activating an InfoCube in SAP BW.

Click Transfer SAP version to transfer the Customer InfoCube model from SAP
delivered business content, as shown in Figure 8-10 and Figure 8-11.

Figure 8-10: Transferring InfoCube Definition From SAP BW Business Content

to Local Implementation.

Figure 8-11: Maintaining an InfoCube Schema in SAP BW.

Notice that now the InfoCube version is changed from SAP Delivery to Revised
version, as shown in Figure 8-11.

As mentioned earlier, an InfoCube consists of a fact table and dimensions. The

InfoCube that you have just transferred from SAP delivered version should also
have transferred its dimension assignments.

Click the Dimensions button (see Figure 8-11) to verify that all dimensions are
assigned correctly. Before activating the InfoCube, click the check icon . If no
errors are reported, click the activate icon . Notice that after activation, the
InfoCube version is changed to Active and Saved. Exit the InfoCube Edit window.

Until now, you have an InfoCube, but SAP BW does not know how to fill data. The
update rules define how an InfoCube, fact, and dimensions tables will be
populated. After you have a physical data model active in SAP BW, you need to
define the update rules. Transfer the update rules for the InfoCube 0SD_C01 from
the Business Content menu. Verify that all rules for characteristics, key figures,
and time references are correct. Transfer these rules and activate the InfoCube, as
shown in Figure 8-12.

Figure 8-12: Maintaining InfoCube Update Rules.

After activating the update rules, you will see that the Update Rules icon turns
green. Select the Customer InfoCube, right-click, and select Display InfoCube Data
Model. This displays dimensions, navigation attributes, and key figures for the
selected InfoCube, as shown in Figure 8-13. This is a good way of looking at the
SAP BW InfoCube data model for discussion and business analysis.
 Figure 8-13: Visual View of the InfoCube Model for the Customer InfoCube in
SAP BW.

Loading Queries for the InfoCubes from the Business Content

To actually use an InfoCube for business analysis, you need queries. Four types of
Query objects are provided in SAP BW business content:

REP: Query

STR: Templates

CKF: Calculated Key Figures

VAR: Variables

A REP is a complete query that is ready to perform an analytical function; for

example, Sales Analysis by Geography. Moreover, REP-type queries are formatted
specifically to customer needs.

The query template STR is simply a raw definition of a query to fetch data from an
InfoCube. Because these templates are generic, they are not very sophisticated in
terms of query formats and restrictions. These are used to quickly build queries for
end users.

A query consists of several elements. Calculated Key Figures, CKF, and Variables,
VAR, serve a unique role in query logic. The CKF are used to define a new key
figure based on some existing key figures or by means of formulas. Calculated Key
Figures can be defined at the InfoCube level or within a query.

Note If Calculated Key Figures need to be used by many queries or users,

define them at the InfoCube level. You do this because when a key figure
is defined in a query, it is limited to that specific query. However, when
you define it at an InfoCube level, it is available to all users.
Calculated Key Figures in SAP BW queries are used to compute values for new
data elements. For example, a new key figure sales tax is calculated based on an
order taxable amount multiplied by the tax rate. However, the Variables, VAR,
defined in SAP BW queries, are most often used to filter data for the queries.
Sometimes such variables are also used in formulas for Calculated Key Figures.
For example, if you want to select data for a specific time period, you can define
two variables to hold start and end dates for that selection criterion. Moreover,
begin and end date periods can also be used by a Calculated Key Figure for
average sales during that begin and end date period.

SAP BW business content consists of all of the preceding types of query objects
for InfoCubes. To activate query objects for a specific InfoCube, select Query
Objects from the Business Content menu, and select the query type and the
InfoCube. The system displays all available queries. Select all queries and
activate, as shown in Figure 8-14.

Figure 8-14: Loading Queries From Business Content for Customer InfoCubes.

Then activate the Templates, Calculated Key Figures, and Variables associated
with each InfoCube.

Activating Channels
Channels are primary components of the SAP BW information delivery model.
Channels are based on information objects, such as queries, that are managed
within the InfoCatalog. To use SAP delivered channels, select Channels from the
Business Content menu.

Select Channels from the Technical Name list, as shown in Figure 8-15. In this
example, I selected 0SD_CH01, Sales and Distribution Channel to copy from the
SAP delivered content. After successfully loading the selected channel in SAP BW,
verify that InfoCatalog recognizes the added channels. To do so, go back to the
Administrator Workbench and click the InfoCatalog icon.
 Figure 8-15: Activating SAP Delivered Channels.

From the Channel InfoCat tabstrip, click the Channel drop-down box. This lists all
available channels in the InfoCatalog, as shown in Figure 8-16. Select a channel
from the channel list, say 0SD_CH01, and click the Save icon.

Figure 8-16: Adding Channels in the InfoCatalog.

To assign channels to users, click the User channel assignment tabstrip. All users
defined in SAP BW are listed on the left under the User tree. All channels defined
in the InfoCatalog are shown on the right. To assign channels to users, select a
user from the left, then drag and drop to the User-channel assignment folder, as
shown in Figure 8-17.

Figure 8-17: Assigning Users to Channels.

This completes the Business Content activation in the SAP BW instance. You may
have noticed that it is a very manual process. In SAP BW version 2.0, however,
these processes are very much automated. Once you activate a higher level object
(for example, an InfoCube), the system automatically activates everything needed
to completely build and activate the InfoCube. In SAP BW 1.2A Patch 12, a similar
automated process is used to activate the SD Demo InfoCube. You simply click the
Activate demo cube icon, as shown in Figure 8-18, and the system does the rest of
the work for you. It also creates InfoPackages to load data in the demo cube, and
then you're ready to run queries after activating channels and user assignments.

Figure 8-18: Activating the SAP Demo Cube.

To learn more about business content, look at the business content definition
document, Cube_Que_e.pdf, which describes in detail all cube structures and
associated queries. This 288-page document (SAP BW 1.2B) is included on the
SAP BW installation CDs and SAPNet.

Note Activating business content in SAP BW 2.0 is very simple. Activating one
InfoCube will activate all dependent and associated objects
automatically.

Team-Fly
Team-Fly
Summary
In this chapter, you learned the basics of data flow in SAP BW. Most
of the data flow discussed was limited to business content. Now you
also should have a good understanding of metadata management in
SAP BW and in SAP R/3. You also learned what constitutes SAP
BW business content and how to activate individual objects to build
an information delivery environment. The next chapters describe in
detail the necessary steps to prepare SAP R/3 for data loads and
how data is extracted from SAP R/3 and moved in SAP BW.

Team-Fly
Team-Fly
Chapter 9: Preparing R/3 Data Sources for
SAP BW Initial Data Loads
In this Chapter
One of the key benefits SAP BW enjoys is its tight integration with
the SAP R/3 OLTP system. This tight integration, however, can have
significant impact on SAP R/3 operations when preparing initial full
data loads for SAP BW to set a baseline for analytical data. In this
chapter, you learn how to prepare SAP R/3 for SAP BW and how to
load data in SAP BW.

Team-Fly
Team-Fly
Preparing SAP R/3 for SAP BW
Depending on your SAP R/3 OLTP and SAP BW project time line,
you may be able to share one SAP R/3 instance to do development
for OLTP and SAP BW. However, I recommend a stand-alone SAP
R/3 OLTP production instance as a data source for an SAP BW
development project. Do not work with dummy data; instead, make a
copy of your SAP R/3 OLTP instance or an SAP R/3 instance that
really reflects your current SAP R/3 configuration with a decent
amount of reference and transaction data.

The SAP R/3 OLTP preparation for SAP BW begins with the
installation of SAP BW objects, such as tables, programs, and data
extractors, as described in Chapter 8. Before installing any SAP BW-
specific objects on SAP R/3 OLTP, make sure that the BASIS team
understands all prerequisites for an SAP R/3 OLTP corresponding to
the SAP BW version and check the OSS notes for the latest news on
installations. Depending on the version-SAP R/3 OLTP (3.0F-4.5B)
and SAP BW (1.2A, 1.2B, 2.0A)-you may need to install hot
packages before installing any SAP BW objects on the SAP R/3
OLTP. Note that starting with SAP BW version 2.0x, the BW add-on
to SAP R/3 is now called Plugin for SAP BW.

After installing the BW add-on in the SAP R/3 OLTP instance, you
need to define the remote logon connection in SAP R/3 OLTP for the
SAP BW instance. This is a five-step process for the SAP BW 1.2B
add-on, as outlined here:
1. Create an ALE user, transaction SU01, to be used for
remote logon to SAP BW from SAP R/3 OLTP. Make sure
that this user, usually ALEREMOTE, has sufficient
authorizations for the RFC and ALE components, as
described in the installation guide. The ALE user must have
profile S_BI-WX_RFC. This profile consists of sub-profiles
such as B_ALE_ALL, S_APPL_LOG_A, S_IDOC_ALL, and
S_RS_ALL.
2. Set up a logical system name for SAP BW. The logical
system is used by SAP R/3 to connect the SAP BW
instance for data transfer. To set up a logical system name
on SAP R/3 OLTP, run transaction SM30 and edit table
V_TBDLS. Create a new entry for the SAP BW logical
name, such as XDWCLNT100.

3. Assign SAP BW client to the logical system name. Here

you associate SAP BW client to a logical name. Using
transaction SM30, edit table T000 and add entry.

4. Define an RFC destination for SAP BW. In Steps 1 and 2,

you simply defined a logical system name and associated it
to an SAP BW client, but you cannot connect to the remote
SAP BW instance. This is because you have not defined
the network-level information for such communication links.
To make this happen, you need to define an RFC
destination in SAP R/3 OLTP for SAP BW using transaction
SM59, as described in Chapter 7. Here the DEST is your
system logical name defined in Step 1, XDWCLNT100, and
the connection type is 3; enter the IP address and other
user information to log on. Select the Test Connection and
Remote Logon options to make sure that you can access
the remote BW instance. If the Test Connection option fails,
check to make sure that SAP R/3 and SAP BW are on the
network, that SAP BW is running, that both have the
correct network configuration, and that both servers are
visible on the network. Check with your networking support
team to resolve these issues.

5. Verify the workflow basic setting. Run transaction SWU3

and create the workflow basic setting. Click the
AutoCustomize menu option to verify that the workflow
setting for SAP BW components is set properly, as shown
in Figure 9-1 on SAP R/3 version 3.1H. Remember that
only the Workflow runtime system needs to be confirmed
 here. Verify that the results show a green check mark or
traffic lights for the following items:

Figure 9-1:
SAP R/3 OLTP Verification of the Workflow Runtime
Environment for SAP BW.

An active plan version exists

RFC Destination Workflow

Workflow runtime customizing complete

Perform additional installation verification steps as described in the

installation guide. Next, you need to analyze data present in SAP
R/3 OLTP and prepare data sets to load in SAP BW.

Information Collection Process in the SAP R/3 Data

Source

SAP BW 1.2B business content covers a wide range of functional

areas; in this book, I discuss the data associated with the Sales and
Distribution (SD) module of SAP R/3 and relative SD business
content in SAP BW.

Though order processing in SAP R/3 is a complex process and most

customers do customize data flows based on their business rules,
Figure 9-2 shows a common order processing transaction data flow
and how transaction data sets are physically stored. Each drum
object in Figure 9-2 represents one or more database tables. Text in
each drum shows table names. Solid connecting lines show the
relationship among such data set objects. Darker drums represent
data sets for InfoCubes in SAP BW. The text in each darker drum
shows the LIS table name in SAP R/3 OLTP and its corresponding
InfoCube in SAP BW. For example, S260 is an LIS table, and
ORDERS is the InfoCube in SAP BW based on S260. Dotted lines
show the source tables for specific SAP BW InfoCube data stores in
SAP R/3.

Figure 9-2: A Typical Order Processing Transaction Data Flow in

SAP R/3 and Associated Data Sets for InfoCubes in SAP BW
1.2B.

You are not limited to SAP standard LIS or SAP BW specific LIS
structures; you can use or create custom LIS structures as data
sources for custom InfoCubes in SAP BW. For example, S001 is a
standard LIS structure in SAP R/3 OLTP, and S260, S261, and
others are SAP BW specific LIS structures that are installed as part
of an SAP BW add-on.

Note In SAP R/3, all S prefixes followed by 3-digit LIS tables,

S000-S499, are SAP standard LIS infostructures. Custom
LIS infostructure names must be between S500 and S999.
Just by looking at this naming scheme, one can easily
 identify SAP-provided and custom-defined LIS tables in
SAP R/3.

In this example, to build initial data loads for SAP BW, you need to
first populate LIS tables S260, S261, S262, and S263. The process
of populating such tables is called the statistical update. The
statistical update for individual data sets may take from a few
minutes to several hours and sometimes days based on the volume
of transaction data in SAP R/3. No transaction activity is advised
while statistical updates are in progress to avoid database tables
locking and data inconsistencies, which will be further discussed
later in the chapter.

Note The statistical update needs to be run for LIS-based data

sets only. The generic or custom-designed data extractors
do not require execution of statistical programs, depending
on the data extractor logic needed to collect and transform
data for SAP BW.

When transaction volumes are high or in global SAP R/3

implementations, the business community cannot afford to keep SAP
R/3 instances down for several hours to run statistical updates.
Under such a scenario, you need to analyze transaction data for
logical groupings and run such statistical updates in small segments,
as described in the next section.

All data warehouses start with baseline data from their transaction
data sources. After loading initial data, only new or changed data is
needed in a data warehouse. During the SAP BW add-on process in
SAP R/3, several LIS primary and change capture tables are defined
and initialized. The change log tables are called DELTA logs. To
implement delta change capture in SAP R/3, you will find two tables
associated with each LIS table. For example, Figure 9-3 shows two
tables, S261BIW1 and S261BIW2, to capture information about new
or changed orders for S261. All tables, S261, S261BIW1, and
S261BIW2, have the same metadata definitions. The only difference
is that table S261 is used to load the initial data set for SAP BW, and
S261BIW1 and S261BIW2 are used to capture incremental order
changes.

Figure 9-3: Statistical Update to Prepare Initial Data Loads and

Process of Incremental Data Capture in SAP R/3 for SAP
BW.

Having two delta tables per LIS table is a big advantage in high-
volume SAP R/3 implementations. One table actively captures new
or changed data, and the other table remains idle. When SAP BW
requests data, the active delta table is immediately locked, and the
standby table becomes active to collect new changes, as shown in
Figure 9-3. When all open transactions in the locked table are
completed, data is shipped to SAP BW, and then this table goes in a
standby mode.

But how does SAP R/3 or SAP BW know which delta table is
currently active and collecting new data? The table TMCBIW in SAP
R/3 flags the active LIS table name. When SAP BW issues a delta
capture request, it looks in this table to find the active table name,
Step 2 in Figure 9-3. Then it empties the standby table (Step 3 in
Figure 9-3), locks the currently active table, and sets the flag in the
TMCBIW table for standby table as an active table (Step 4 in Figure
9-3). Finally, it sends data to SAP BW from the locked populated
standby table. This cycle continues for subsequent data requests
from SAP BW.

Team-Fly
Team-Fly
Strategies to Prepare Initial Data Loads
Before loading transaction data in SAP BW, you need to load the
reference data. Reference data is master data, texts, hierarchies,
and other configuration-specific data that is used across all analytical
applications in SAP BW. Moreover, having master data in SAP BW
first speeds up the InfoCube population process. This is because
SID tables for master data are created during master data loading,
and these SIDs are used in InfoCube dimensions as pointers for
master data.

SAP BW version 1.2B does not support incremental data load

services for reference data. This means that you need to load full
reference data in SAP BW and then execute change run procedures
to reconcile data that is already populated in InfoCube structures.

To load master data in SAP BW, you do not need to. run any
statistical update procedures. However, the order in which you load
reference data in SAP BW is very important, as listed here:
1. Master Data

2. Texts

3. Hierarchies

The actual disk space used by reference data tables in SAP BW will
be almost the same as in SAP R/3. If you are planning to support
multi-language SAP BW implementation, the number of master data
text records may be several times that of the actual master data
record, just as in SAP R/3. For example, assume you have one
million material master records and support three languages. You will
have master data text in three languages, resulting in three million
material master text records. Make sure that you have sufficient disk
space in SAP BW to accommodate fivefold material master text
records.
 Note In a multi-language SAP BW environment, only the TEXT
elements are stored in multiple languages. The basic
master data attributes are only stored once.

Quality of master data for SAP BW is important. Make sure you load
only the data that you really need from SAP R/3 in SAP BW. When
SAP BW requests master data from SAP R/3, it pulls all master data
records, including those that are marked as delete or obsolete. This
may cause problems when loading master records.

For example, say a user created a master material record in SAP

R/3 with the Material ID of 16-6667-AR#. After updating this record,
the user realized that the Material ID has a # character, which is an
error. It is supposed to be a 3. The user deleted this record and re-
created it with a correct Material ID of 16-6667-AR3. Remember that
SAP does not physically delete the master data; rather it flags it to
be deleted. No one can use this for new transactions. However,
when SAP BW requests material master data from SAP R/3, the
deleted flag master records are also shipped to SAP BW.

You now have two problems with this data. First, it contains an
invalid character, and the loading job will fail when it encounters this
record. Second, this record is not needed because it is an invalid
record in SAP R/3 OLTP.

Note When you delete master data from SAP R/3 OLTP, it is
"marked for deletion" instead of "physical deletion" to
preserve transaction data integrity. The reason that SAP
R/3 does not physically delete master data from its
database is that some transaction records may have
references to "to be deleted" master data records. In this
case, removing master records will result in data
inconsistencies. Hence, master data is preserved in SAP
R/3.
Luckily, SAP BW provides a mechanism to identify permitted
characters beyond typical text and numbers, as shown in Figure 9-4.
There you identify characters that will be acceptable in SAP BW.
This is a quick fix to acknowledge invalid data, but you need to
simply exclude such data sets at the data source level, SAP R/3.

Figure 9-4: Identifying

Permitted Characters in SAP BW Beyond Standard Text and
Numeric Characters in SAP BW 1.2B. A Similar Method Exists in
SAP BW 2.0A.

This is a typical data quality issue in data warehousing. SAP BW

data quality is no exception, even when data is coming from an SAP
R/3 instance. Receiving data from SAP R/3 does not mean that you
have quality data. For this reason, you need to establish data quality
guidelines to qualify data before loading it in SAP BW.

For efficient data loading in SAP BW, collecting and grouping

information about data sets in SAP R/3 is very important for
reference and transaction data.

Analyze your master data and identify ways to group master data in
small buckets. Estimate the number of records in each group.
Suppose you have four million material master records in SAP R/3.
You need to find a way to group four million records in a good
sizable bucket that is right from your SAP R/3, network, and SAP
BW resources. You may group material master records by Product
Family or by range of Material IDs. Schedule 400K data records per
request. To load all four million records, you will schedule 10 jobs. If
400K records are processed within a reasonable time period, say 10
minutes, you may increase the number of records and determine
what number of records per data request is best for your
environment.

Note You cannot store reference data in SAP BW 1.2B ODS. All
master data sets are sent to SAP BW via IDOCs and not
tRFC. Therefore, processing very large IDOC data
requests will time out before data loads are completed.
Moreover, resolving data load issues by correcting large
IDOCs and re-processing is a time-consuming proposition.
The recommendation is to start with a small number of
records per request. Then Increase or decrease the
number of records per request based on your system
resources and performance.

For a full initial SAP BW data baseline, analyzing transaction data is

much harder than master data. For the Sales and Distribution (SD)
subject data warehouse, first you need to analyze base SAP R/3 SD
transaction tables to run a statistical update in groups, and then
segment statistical data to load in SAP BW.

For example, one cannot assume that all orders always have the
same number or line items or number of shipments or invoices. For
this reason, you need to do extensive analysis of existing order data
and identify a collection of orders, invoices, and delivery records for
an acceptable statistical update and data sets for SAP BW loads.

After running statistical updates, one way to get a count of records

per order by field combination is to execute a few SQL queries
against SAP BW LIS tables in SAP R/3. Use these statistics to
process groups of orders at a time.

For transaction data loads in SAP BW, you can use TRFC and store
data in ODS before loading it in an InfoCube. This way, large data
sets are first sent to ODS. Then in SAP BW, you can make additional
data quality or data selections to populate InfoCubes without having
to pull data from SAP R/3.

Preparing Statistical Data in SAP R/3 for SAP Standard

SD InfoCubes

Preparing and loading initial statistical data for SD InfoCubes

consists of the following for primary LIS structures.

Set up an LIS environment using report RMCSBIWC. SAP

provides several programs in SAP R/3 that set up other
objects for LIS environment in SAP R/3. To set up LIS
structures for SAP BW, use report RMCVNEUA for S260,
S263, and S262; RMCVNEUL for S261; and RMCVNEUA for
S264 (new in SAP BW 2.0A).

Deactivate LIS structures using transaction OM01 to disable

LIS updating. Make sure to turn on updating after initial loads
in SAP BW.

Execute statistical update program. Use transaction OLI7 for

S260, OLI8 for S261, OLI9 for S262, and OLI7/OLI8 for
S263. Based on the transaction data volume in your OLTP
instance, you may need to run several statistical updates to
fully populate one LIS table, say S260. Here you will use
information that you have collected in the previous section,
grouping transaction data for statistical updates. For
example, you may decide to run one statistical update
session that updates only orders with Document numbers
range from 1 through 3000, as shown in Figure 9-5. You may
also have an option to restrict the transaction data set by
company code or sales organization or other parameters as
shown in Figure 9-5. Remember that you can run one or
more such groups of statistical updates over several days
based on your OLTP system availability. This technique
 reduces the downtime needed to complete full statistical
updates.

Figure 9-5: Setting Statistical Update for SAP BW LIS

Structures in SAP R/3 OLTP Data
Source.

Load data in SAP BW. This is done from SAP BW by

scheduling InfoPackage for a specific InfoSource. You learn
more about loading in SAP BW in the next section.

Activate LIS structures updating (OM01, OM02).

For delta updates, several programs fill LIS structures for BW. As
shown in Figure 9-3, these programs first determine the status of
which table to fill (xxxBIW1 or xxxBIW2) by looking in the TMCBIW
table. For example, program RMCSS260 fills S260 LIS table, and
RMCSS261 updates S261 table.

Table RSSGTPDIR contains the program names of SAP BW load

programs. The function module, SAPLMCSBW, is used to fetch data
from these tables.
 Note The function module MCS_BIW_UPDATE_SWITCH is
another important function module that comes in handy in
resolving change log tables update problems.

In cases when programs are looking for the wrong delta

table (trying to read from xxxBIW1 when it should be
xxxBIW2 or vice versa), running this function module will
switch the table TMCBIW to the other status.

Team-Fly
Team-Fly
Data Loading Strategies in SAP BW
InfoCubes
By now, you are quite familiar with SAP BW architecture and
different ways to load data in SAP, such as SAP R/3, SAP R/2, flat
files, and staging BAPIs. This chapter discussed data loading
techniques from SAP R/3 as the data source. Chapter 10, "Loading
Data via Flat Files," describes how to load data from flat files, and
Chapter 14, "Integrating Third-Party Products with SAP BW,"
describes methods to load data using staging BAPIs as well as third-
party products.

Four classes of data objects exist in SAP BW. They store data for
InfoCubes, ODS, Reference, and Warehouse operations. InfoCubes
and ODS are primary objects to store transaction data. Note that you
cannot store master data in the ODS. The question is why and when
one needs to store data in ODS.

The original intent behind ODS implementation was to store raw data
from its data sources, and then be able to manipulate data in ODS
tables. However, in SAP BW 1.2B, once data was stored in the ODS,
SAP did not provide any facility to manipulate data in the ODS; the
only option was for someone to write ABAP code to clean or qualify
data. By manipulating original data, you lose the originality of the
data received, and the ability to trace it back to its origin in SAP R/3
is lost. SAP has virtually redesigned the ODS in SAP BW 2.0 to
support the data warehouse industry's acceptable ODS model.
Chapter 17, "The Operational Data Store in SAP BW 2.0," describes
SAP BW 2.0A ODS architecture and possible implementation
models in detail.

Though the scope of ODS in SAP BW 1.2B is limited, there are

some scenarios in which you should consider storing transaction
data in ODS:
 Limited access to SAP R/3. Here you load small data sets
in ODS frequently and run InfoCube loads based on data in
ODS at a different time. For example, you want to load
transaction data from SAP R/3 in ODS on an hourly basis but
update the InfoCubes once a day or weekly from data in
ODS.

One InfoSource to populate multiple InfoCubes. SAP BW

does not support the broadcast model, meaning that the
same data sets are sent to multiple SAP BW instances or
multi InfoSources. In SAP BW 2.0, this logic may change, but
such functionality still needs to be verified.

Resolve data quality problems. During loading data in an

InfoCube, if a few records had invalid data or invalid master
data references, you can edit such records in ODS and re-
load selected records in the InfoCube.

Keep detailed data in ODS and summarized information

in the InfoCube.

Figure 9-3 simply indicates that populated LIS structures are sent to
SAP BW. But how and which method is used to send data to SAP
BW is not known. The actual transfer method for such data objects is
defined in SAP BW and not in the data sources, in this case SAP R/3
OLTP. The next section describes SAP BW data transfer options.

Data Transfer Methods

Figures 9-6 and 9-7 show transaction data paths in SAP BW. The
data objects loading scheme is defined at InfoPackage schedule
time. However, before you store data in ODS, you must define the
data transfer mode to be tRFC with ODS as shown in Figure 9-8.
 Figure 9-6: Data Load
Paths in SAP BW 1.2B.

Figure 9-7: Data Load Paths in SAP BW 2.0A. The Early

Customer Release is SAP BW2.0B, But it May
Change.
 Figure 9-8: Editing Transfer Rules for an InfoSource to Define
InfoSource Data Transfer Method.

The transfer method needs to be set because SAP BW generates

ABAP code in the background that defines how incoming data is to
be dispersed and stored. If the tRFC with ODS option is not
selected, the generated ABAP transfer program will not contain code
that lets you save data in ODS. Moreover, by selecting this option,
SAP BW will create an ODS physical database table. The ODS
tables in BW 1.2B (PSA in BW 2.0) are named /BIC/B000000123.
The ODS table is a transparent table and is defined the same as the
transfer structure of associated InfoSources. All ODS tables in BW
1.2B (PSA in BW 2.0) are /BIC/B prefixed followed by a number
sequence.

Note Remember the SAP BW 1.2B ODS objects are called PSA
objects. The PSA object names are system-generated,
such as /BIC/B00000123. However, the ODS objects in BW
2.0 are not system generated. They are user defined, such
as /BIC/ORDDETAILS.

What are the consequences of storing data in ODS? The biggest

concern is disk space and extra data management. The data will
grow faster than you anticipated. Moreover, saving data in ODS
takes additional system resources. If you have low data volumes,
InfoCubes have all the detailed information that is needed for your
business and can be updated with new data in an acceptable
timeframe; you can skip ODS completely.

When the transfer method is set for TRFC with ODS option and
transfer rules are activated, you need to activate corresponding
update rules for an InfoCube. Then you are ready to load data from
SAP BW data sources.

Note You can load transaction data in ODS from any data source
that SAP BW supports, such as SAP R/3, flat files, SAP
R/2, or third-party data loading tools using staging BAPIs.
You are not limited to storing transaction data in ODS when
the data source is SAP R/3 OLTP.

Team-Fly
Team-Fly
Loading Data in Data Objects in SAP BW
Figures 9-6 and 9-7 show transaction data options but do not show paths
for reference data. This is because when reference data is loaded in SAP
BW, master data, texts, and hierarchies are stored in individual tables
where texts and hierarchies are linked to the master data records using
primary/foreign key relationships. Once saved, reference data requires no
further data manipulation. The tables are just lookup tables. However, when
you have transaction data, you have several options to save in several data
objects, and this sometimes gets confusing-especially in SAP BW 2.0A, as
shown in Figure 9-7.

To load data in SAP BW, you define an InfoPackage. An InfoPackage is

defined at an individual InfoSource level. While in BW Administrator
Workbench, select an InfoSource, right-click, and select Create
InfoPackage as shown in Figure 9-9. You are asked for the InfoPackage
name, in this example Load Customer. To schedule this InfoPackage to
load data in SAP BW, right-click on the InfoPackage and select Schedule.

Figure 9-9: Creating an

InfoPackage to Load Data in SAP BW 1.2B.

InfoPackage is like a job stream that links incoming data requests to SAP
BW internal data objects by scheduling several activities as defined by the
user, such as data selection criterion, sequence of data objects to populate,
or additional processes needed to be run before or after the data load.
Figure 9-10 shows the InfoPackage Scheduler window. Depending on the
SAP BW version and the data source type, you may find different sets of
folder tabs and options under each section. For example, Figure 9-10
represents the InfoPackage Scheduling option for an InfoSource when the
data source is an SAP R/3 OLTP instance. However, the same window
looks somewhat different in SAP BW 2.0A. Overall the content is the same
but with one exception. The SAP BW 2.0 InfoPackage Schedule option, as
shown in Figure 9-11, also allows you to set up several pre- and post-data
load activities. This simplifies the process of typical data warehouse
construction where you need to validate or perform operational tasks before
and after building InfoCubes. For example, maybe you want to first delete
existing working tables, back up existing tables, drop indexes and then build
the InfoCubes, then later notify operations staff or other parties if the job
was successful. It is up to individual database operations teams to decide
how to put together such job streams.

Figure 9-10: InfoPackage Scheduling for SAP R/3 Transactional

InfoSources Based on SAP BW Version 1.2B.

Figure 9-11: InfoPackage Scheduling for SAP R/3 Transactional

InfoSources Based on SAP BW Version 2.0A.
You can either run this job instantaneously or define a background job to
run at a given time. To submit this job, click the Start button. You will receive
a message when the job has been scheduled successfully. Now you can
monitor the job activities and verify that your job has been completed.

Note You need to define a data load scheme once and use it repeatedly
to load subsequent data loads. Once you have verified that a data
load scheme works as defined, you can submit such data load
jobs to be run periodically-for example, daily at 1:00 A.M. to load
new order changes and populate the Sales Analysis InfoCube.
Such job scheduling is done right from within the InfoPackage
Scheduler window, as shown in Figure 9-10.

When the InfoSource is based on an SAP R/3 instance, SAP BW knows

how to connect and get data. However, when InfoSources are based on flat
files of third-party data extraction and load products, you need to provide
the location of data sources in the InfoPackage Scheduler, as shown in
Figures 9-12 and 9-13. The actual mechanics of working with flat files and
third-party tools is discussed in Chapter 11, "Analyzing SAP BW Data," and
Chapter 14.

Figure 9-12: InfoPackage Scheduling Options for Flat File InfoSources.

Figure 9-13: InfoPackage Scheduling for Third-Party Data Loading Tools

 that Use SAP BW Staging BAPIs.

Before an InfoPackage job is scheduled, you should know target data

objects in SAP BW and the sequence of data processing needed before
storing. The data flow, as shown in Figures 9-6 and 9-7, is defined at this
stage.

While in the InfoPackage Scheduling window, click the Data target tabstrip.
Two options are available: ALE inbox only and ALE inbox and InfoCube, as
shown in Figure 9-14. For a visual aid, click the question mark icon on the
bottom-right of the window. This shows the path of data for updates.

Figure 9-14: Defining Data Load Flow in SAP BW When the Data
Transfer Method is ALE IDOC.

Note The data load method is defined when you define the transfer
rules. Here you are simply defining the data execution flow.

By selecting either option, you are using the ALE IDOCs mechanism to
move data from the SAP data source and save it in IDOC data tables in
SAP BW and then build the InfoCubes. Saving data in the IDOCs is similar
to saving data in ODS, but data is stored using IDOCs structures. Here you
can use the ALE transaction to edit, simulate, or process for downstream
data loads.

Though the ALE method works fine, due to ALE record size limitations-
1,000 bytes/record-and intense IDOC processing resources, you should
define the transfer method for an InfoSource as tRFC with ODS. Once this
mode is set at the transfer rules level, you have several options to define
data load paths during job schedules, as shown in Figure 9-15.
 Figure 9-15: Defining Data Load Flow in SAP BW When the Data
Transfer Method is tRFC with ODS. In SAP BW Version 2.0A, ODS
Means PSA.

Note The ODS options shown in Figure 9-15 are only available when
the transfer method for the InfoSource is elected as tRFC with
ODS, as shown in Figure 9-8 and discussed earlier in this chapter.

Note that in SAP BW 1.2B, Figure 9-15 should work. In SAP BW 2.0A, this
scheme will work as well, but here ODS means PSA. True ODS integration
with the InfoPackage scheduling process will be integrated with the SAP
BW Administrator Workbench in SAP BW 2.0B. That will allow you to select
all possible data paths defined as shown in Figure 9-7.

Initial Data Loads

Before an InfoPackage job is scheduled, you should have a rough estimate

of incoming data, especially during the initial data loads. Moreover, you
should know the target data objects in SAP BW and the sequence of data
processing and storage, as shown in Figures 9-6 and 9-7. You need to
identify these update modes at this time.

When you have large volumes, break one long running data load job into
several small jobs. The InfoPackage scheduler provides a data selection
screen to set this scheme. Click the Select Data tab and enter a range of
records you want to fetch from its data source, as shown in Figure 9-16.
Here, for example, all order transaction data for materials with 8000 to 9000
ID ranges has been selected.
 Figure 9-16: Loading a Large Amount of Data in SAP BW by Splitting
One Huge Task into Multiple Data Load Sessions. Each Session is
Limited to a Given Range of Material Values.

Because initial data loads can take several hours to several days, by
scheduling data in small segments over several days, you will not cause
any interruptions to daily SAP R/3 OLTP operations. However, you need to
plan full data loads in conjunction with statistical updates on the OLTP side,
which means that if you are loading initial order transaction data from an
SAP R/3 instance, select the Full Load option (see Figure 9-17) when
scheduling the job, and that you have executed the statistical run for that
data set on SAP R/3.

Figure 9-17: Loading Incremental Changes in SAP BW.

Loading master data is similar to loading transaction data. You do not have
many options other than data selection criterion at the scheduling time.
Remember, you cannot use tRFC or store data ODS for master data
elements.

From a database perspective, make sure that your database administrator

is aware of incoming initial large data volumes. Make sure that the
database tables have sufficient space available and that the database
tables extents for master and transaction data are large enough to speed
up data loads.
Delta Data Loads

Once initial data has been loaded in SAP BW, you can only pull new data
from SAP R/3. Before you can pull new data from SAP R/3, you need to
activate updates for LIS structures by use of transaction OMO1 or OMO2.
Then select the delta update option available in the Update parameters
tabstrip of InfoPackage Scheduler, as shown in Figure 9-17.

When delta update requests reach SAP R/3, data is pulled from the Delta
Change table currently active and not from Source LIS structure, as shown
in Figure 9-3 and described earlier in this chapter.

Most LIS-based InfoSources can automatically capture new data for SAP
BW. However, for other application modules and reference data, one has to
either write specific delta update programs to capture new data for SAP BW
or do full update loads. For low volumes or small SAP R/3 operations, full
loads are always preferred over writing change capture programs. This
subject is discussed in Chapter 13, "Enhancing Business Content and
Developing Data Extractors."

Team-Fly
Team-Fly
Monitoring Data Loads
SAP BW provides an excellent data load monitoring utility to check
running data loads or those that have been executed in the past. You
also have the option to view data load jobs started by a user or by an
InfoCube or other parameters, as shown in Figure 9-18 in the
Further selections options. Clicking the Monitor icon in the
application menu bar of SAP BW Administrator Workbench launches
this utility. The inverted tree icons on the selection buttons in Figure
9-18 show that you will view data load activities for selected
InfoCubes and InfoSources.

Figure 9-18: SAP BW

Data Load Monitoring Environment in SAP BW
2.0A.

Note that Figure 9-18 shows the data load monitoring facility for SAP
BW 2.0A. You will see a new option, Output as tree control, in the
Display type section. This option displays monitoring statistics in a
tree format. Clicking the Execute button, you will see results in tree,
overview list, or Gantt chart format. Figure 9-19 shows an output list
of selected data loads. The traffic-light symbols represent the state
of individual data loads. Green indicates that the data load was
successful. Yellow means either that the job is still in progress or a
state could not be resolved. Red means fatal errors have occurred
and need to be resolved.

Figure 9-19: Data Load Job Statistics Summary. The Lights

(Green, Red, and Yellow) Show the Current State of Individual
Jobs.

Note Often, yellow indicates an unknown or in-limbo state. Drill

down for detailed data load information and identify its
cause. The red light timer is a global setting. When a data
load job exceeds that set time, the red light turns on and
remains red even if the data load job completes
successfully. If this happens quite often, change the
Waiting time until light turns red in Monitor parameter value
in the SAP BW global settings.

For further details, click on an individual traffic-light symbol. This

opens a Monitor Assistant window, as shown in Figure 9-20, and
details incoming data packet information. Monitor Assistant shows all
steps needed to successfully process incoming data. For further
details, click the Analysis button. This will provide more information
to help resolve the problems. When you exit Monitor Assistant, you
can look at individual data records that are in SAP BW, edit
individual records, simulate processing, and reload the corrected
data in the data warehouse.
 Figure 9-20: Monitor Assistant (Renamed Wizard in BW 2.0)
Displays the State of Individual Data Load
Tasks.

When the problem resides in the source system, you need to look at
the data sets generated in the source system to identify the root
cause. To do a complete end-to-end problem resolution from within
the Monitor facility, you can view IDOCs generated in the source
system by checking IDOCs in the source system boxes on the
bottom of the window, as shown in Figure 9-21. Select a row with
yellow or red traffic-light symbols and click the Analyze Tool icon on
the bottom left of the window. Here you will be able to view IDOCs
current and previous content. After correcting erroneous records,
update records in the SAP BW warehouse manually or restart the
data load job using current IDOCs.
 Figure 9-21: Data Load Detailed Analysis to Identify and Resolve
Update Problems.

Often, when you request full data loads from an SAP R/3 data
source, you receive an "Error in the source system..." message. The
problem probably is not with the data but rather that you have update
mode enabled for the LIS structures. Use transaction OMO1 or
OMO2 to disable LIS structure update mode and resubmit the full
data load. And remember to reset it as soon as you finish your data
loads.

Team-Fly
Team-Fly
Summary
Loading data in SAP BW requires an in-depth understanding of data
volumes in the data sources. For initial data loads, you need to
prepare several data feeds to optimize system resources. In this
chapter, you learned the basics of the data loading process in SAP
BW and the steps you need to take in preparing data feeds.

You also learned about methods to load data in SAP BW. Actual
data flow in SAP BW depends on the method you choose, ALE or
tRFC with ODS. Moreover, you gained some insight into BW 2.0A
data load scheduling options.

This chapter did not cover data load techniques for flat files and
third-party data sources. These subjects are covered in Chapters 10
and 14, respectively. After reading these three chapters, you will
have a good understanding of data loading methods available in
SAP BW 1.2B and 2.0A.

Team-Fly
Team-Fly
Chapter 10: Loading Data via Flat Files
In this Chapter
In Chapters 8 and 9, you learned how data flows in SAP BW and
about the process of loading data in SAP BW from SAP R/3 as a
data source. In this chapter, you learn how to load data in SAP BW
from data sources other than SAP.

Team-Fly
Team-Fly
Non-SAP R/3 Data Source Loading Methods
One of the key requirements for a data warehouse is that the
environment must be able to accept data from several data sources
in a seamless fashion. I have yet to see one enterprise data
warehouse that does not use flat files to load data. Flat files are an
inexpensive method of preparing a data feed for the data
warehouses. However, flat files do require manual work to prepare
and move to the right place at the right time for the data warehouse
to load data.

In the SAP BW environment, the data sources could be SAP R/3

OLTP instances, other ERP package applications, flat data files, or
data from data providers such as Nielsen. In Chapters 8 and 9, you
learned how SAP BW loads data when the data source is an SAP
R/3 OLTP system. SAP BW provides the following three methods to
load non-SAP R/3 data:

Flat Files

Staging Business API (BAPI)

Data Providers

In this chapter, you learn how to load data in SAP BW via flat data
files. Loading data from flat files is a simple process. However,
implementing staging BAPIs and data providers to load data in SAP
BW is a complex process. For this reason, several data extraction
tool vendors have implemented staging BAPIs in their products to
easily implement data loading schemes in SAP BW. The staging
BAPI implementations enable you to automatically load data in SAP
BW after extracting data from any data source, such as DB2,
Informix, Oracle, Microsoft SQL Server, or other proprietary data
sources that a third-party tool can read data from. You learn about
staging BAPIs and data provider implementation in Chapter 14,
"Integrating Third-Party Products with SAP BW."
 Note In traditional data warehouses, large data volumes are
often loaded using bulk-load utilities provided by the
database vendors. These utilities are fast and highly
optimized. However, SAP BW 1.2B does not support any
database-specific bulk-load options. Though database-
specific bulk-loading utilities provide highly optimized
services, they do not provide needed information to SAP
BW warehouse managers to track all aspects of data flows
from sources to destinations. No bulk-load services are
planned for SAP BW version 2.0.

SAP exploits its own platform-independent data movement

technologies, such as IDOCs and tRFC. These
technologies provide a reliable mechanism to move data
between data sources and the target. These services
provide additional data management facilities, such as
temporary data storage, simulation of uploads prior to
actual updates, error and corrections, and guaranteed
delivery. SAP data movement technologies also provide
compressions services that improve overall data movement
performance across the network.

The difference between the two technologies is that the

database-centric bulk load services are designed to only
optimize the data loading process in a database specific to
a database engine and are not aware of any analytical
application logic. On the other hand, the SAP data
movement technologies are designed to optimize and
manage data movement across several platforms, and data
load services are built on top of a database engine,
bypassing database-specific bulk load services.

Team-Fly
Team-Fly
Loading Data using Flat Files
Loading data in SAP BW is a simple process. The design of the loading process is
done by an SAP BW application developer, but production data load tasks are done
by the Basis and SAP BW operation team.

The data loading process from flat files is very similar to loading data from SAP R/3
with one key difference: the metadata. When you define an SAP R/3 source system
in SAP BW, by updating metadata, SAP BW automatically brings in the needed
metadata from the SAP R/3 instance for all InfoSources. Because SAP BW does not
know the external data file structure, you must first define metadata associated with
individual data flat files. After metadata has been defined, the rest of the InfoCube
construction and data load process is the same. Logically, an InfoSource in SAP BW
associated with a flat file is the same as if an InfoSource is connected to SAP R/3
objects.

You can load the following types of data in SAP BW via flat files:

Master Data

Text

Hierarchies

Transaction Data

SAP BW accepts most common data file formats, such as Microsoft Excel's Comma
Separated Files (CSV), ASCII (ASC), or other known field delimiters of your choice to
define a data file.

File definitions for master data, text, and transaction data are very simple. However,
hierarchy data file definitions can be very complex based on levels of hierarchy
nodes. Often, it is worth building hierarchies manually after the needed InfoObjects
and their master data have been loaded in SAP BW.

I'll show you how to define a flat file data source, then load master data, texts, and
transaction data in SAP BW. Finally, you'll see how to load transaction data in a
predefined InfoCube.

Flat File Scenario

In this situation, you want to load master data for products. The master data consists
of an 18-character product code and its 9-character group. Text associated with
products is in English and German, E and D, respectively. The transaction data
consists of customer order data that references the products in the product flat files.
All files are in Microsoft Excel CSV format.
Defining a Flat File Data Source in SAP BW

From the Administrator Workbench, click the Source systems tabstrip. You will see
the source system tree. Select the Source systems node, right-click, and select
Create source system. Select the flat file source system icon (blue PC), and click the
check mark to accept your choice, as shown in Figure 10-1.

Figure 10-1: Defining a Flat File Data

Source.

You are then asked to select the source system type. Enter a source system technical
name and description, as shown in Figure 10-2. The descriptive name will be
displayed in the source system tree list. After saving your source system, you will see
this source system tree list.

Figure 10-2: Creating a Source System for Flat File Data Sources.

Until now, SAP BW did not know the structure of this new data source and had no
association with any other objects. Association between this new flat file and the rest
of the SAP BW data load environment is made via an InfoSource.

In the Administrator Workbench, click the InfoSources tabstrip. Then create a new
InfoSource in an Application Component to be used for flat files. SAP BW supports
two types of InfoSources: transaction and master data types. Here you are asked to
identify the type of flat file source, either transaction or master data, as shown in
Figure 10-3.
 Figure 10-3: Defining InfoSource Type for Flat File Data Sources.

Select master data and click the check mark, as shown in Figure 10-3. When asked,
enter the InfoObject you want to associate with and save. In this example, an
InfoObject ZPRODUCT is selected. After the InfoSource has been created, the next
step is to link this InfoSource to a data source, the flat file.

Defining Metadata for Flat Files

From a metadata point of view, master data and transaction data flat file sources
behave differently. Through SAP BW 1.2B Patch 12, the master data InfoSource is
associated with one InfoObject coming from one data source. This logic has changed
in SAP BW 2.0.

On the other hand, a transaction InfoSource can consist of several InfoObjects

coming from several data sources. For this reason, you will notice that metadata for a
master data flat file InfoSource is automatically pulled from its InfoObjects, and you
will be asked to enter metadata manually for the transaction InfoSource flat file. This
metadata transformation takes place when you assign a source system to an
InfoSource.

To assign a source system to an InfoSource, right-click the InfoSource and select

Assign source system. Select the flat file source system, for example, SS_FF_PROD,
as shown in Figure 10-4. Because the InfoSource type is master data, SAP BW
displays metadata for the master data, text, and hierarchies, as shown in Figures 10-
5, 10-6, and 10-7.

Figure 10-4: Assigning a Flat File Source System to a Master Data InfoSource.
 Figure 10-5: Attributes Definitions for Master Data.

Figure 10-6: Texts Definitions for Master Data.

Figure 10-7: Hierarchies Definitions for Master Data.

It is important to note that for master data flat file InfoSources, the input data file must
conform to the field layout as defined in the metadata window. For example, Figure
10-5 shows that each record in the master data Attributes file must consist of a
product and its group type value separated by a field delimiter. Similarly, the Texts
master data file (see Figure 10-6) defines the structure of a data file as language key,
product, and product description, each separated by a field delimiter.

Note When defining a time-dependent master data, you need two additional
fields, DATEFROM and DATETO, in master data records attributes. In the
case of time-dependent hierarchies, you also need to define these two date
fields for each item. This master data time-dependency plays an important
role in the modeling of analytical application objects such as InfoCubes.
Multidimensional modeling is discussed in Chapter 12, "SAP BW-Defining
Custom InfoCubes."
As mentioned earlier, SAP BW supports two types of InfoSources: transaction and
master data types. If an InfoSource is of transaction type, SAP BW displays the
Maintain Meta Data window. At this moment, SAP BW has no physical connection to
a transaction data file to read the file structure. You need to manually define the
transaction file structure. Assign appropriate InfoObjects that map to the flat file field
definitions, as shown in Figure 10-8 for customer sales data.

Figure 10-8: Metadata Definition for Transaction Data Flat Files.

Once you have metadata for master data and transaction data files, the rest of the
data loading process is very similar to loading from SAP R/3.

Remember that this metadata is used to define the transfer structure for the related
InfoSource. Make sure that it is complete.

Data Type for Flat Files

It is a common practice that flat files contain plain ASCII data. After defining the input
data file layout, make sure that the data values stored in the flat files are consistent
with the SAP BW data types used to define the metadata for the file. The following
guidelines must be followed when preparing data files.

Data files must not include a header line. The actual data values must start
from the very first record.

Dates must be in YYYYMMDD format.

Time must be in HHMMSS format.

Sort input files, when possible, based on characteristics that identify each
record uniquely. This improves data load performance.

Due to IDOC record size limitations, you are restricted to 1,000 bytes per
record. This 1,000 bytes record limit does not apply when data is to be stored
 in ODS. When data consists of more than 1,000 bytes and you do not want to
store it in ODS, split the file but keep the same characteristics in the same
order in all files, each assigned to an individual InfoSource. Because each file
has the same characteristics or dimensions, when data is loaded in an
InfoCube, records from individual data files are rolled up correctly for end-
user queries and reports as if they came from one data file.

Team-Fly
Team-Fly
Loading Data via Flat Files
Assuming that you have defined and activated transfer and
communication rules for individual InfoSources and have created an
InfoPackage, you're ready to load data in SAP BW.

Right-click the InfoPackage and select InfoPackage scheduler, as

shown in Figure 10-9. For a master data type InfoSource, you are
asked to identify whether this request is for Master data, Texts, or
Hierarchies, as shown in Figure 10-10.

Figure 10-9: Scheduling

an InfoPackage to Load Data in SAP BW.

Figure 10-10: Scheduling Data Load in SAP BW.

Loading Data for Master Data Attributes

Before loading transaction data in SAP, first load the relevant master
data. To load primary master data, click the Master data button (see
Figure 10-10). The icon's color changes from gray to green.

Select the ExternData tabstrip to provide file location information. You

have two options to identify the location of the data file, as listed here:

Client workstation. An end-user personal computer. It is

assumed that data files reside on the personal computer or on
a shared network device. This method works well when you
are developing or testing new data files or do not have access
to the SAP BW application server for storage of data files.

However, this method is not recommended for production data

files or for large data files. Usually, end-user workstations do
not have wide network bandwidths to load large data files in
SAP BW. This slows down the overall data load process.

Moreover, the client workstations are not very reliable or

secure for daily production tasks. Limit the use of this method
to development or testing purposes only.

In Figure 10-10, a file named PROD_MD.CSV resides on the

C drive of the client workstation to load master data only.
Because it is in Microsoft CSV format, the data separator is
identified with a semicolon.

Application server. This choice means that data files reside

on the SAP BW application server. Check with your SAP BW
administrator to find out the shared work area defined on your
SAP BW application. Because the application server and
database server share wide network bandwidth, large data
files must reside on the application server to minimize the
network transport time. Moreover, application servers are
secure and configured for high availability and other
 production operations such as backup. When you select this
option, SAP BW will look for the given file on the shared work
area on the SAP BW application server.

To schedule data loads, click the Schedule tabstrip. You have a

choice to load data in the background or in real time. Then click the
Start button.

Note When loading data in the background, all external data files
must reside on the application server. The reason is that
when a background job is launched, SAP BW has no
knowledge of which workstation to go to in order to fetch the
needed data files.

Loading Text and Hierarchy Data in SAP BW

Loading text and hierarchy data in SAP BW is similar to loading data

for master data attributes. The only difference is that for text data, you
need to first click the Text button and provide the name of the file that
contains text data. Then you schedule the job.

To load hierarchy data in SAP BW, click the Hierarchies button, as

shown in Figure 10-11. After entering the data file name, click the
Select hierarchy tabstrip. Because a master data can have one or
more hierarchies associated with it, here you will see a list of defined
hierarchies for the InfoSource-in this example, it is Product. Select the
hierarchy for which the data file contains the data. Finally, schedule
the data load.
 Figure 10-11: Loading Hierarchy Data in SAP BW

Remember that the structure of a hierarchy data file must match the
hierarchy metadata definition sorted by CHILDID and NEXTID, as
shown in Figure 10-7. The top node ID, the root, is always 00000000,
and the next level down, child nodes, has the ID 00000001. These
IDs are used to define treelike structures in flat files to build
hierarchies in SAP BW.

Team-Fly
Team-Fly
Loading Transaction Data From Flat Files
Loading transaction data from a flat file is no different than loading
from SAP R/3. When you schedule an InfoPackage for a transaction
data InfoSource, you are asked to provide the file name that contains
the transaction data, as shown in Figure 10-12.

Figure 10-12: Loading

Transaction Data via Flat Files.

After providing the data file name, select the InfoCube to load data
into by clicking the InfoCubes tabstrip, as shown in Figure 10-13.
Submit the data load job to populate the InfoCube.
 Figure 10-13: Selecting InfoCubes to Load Data into From
External Data Flat Files.

After data loads have been scheduled, you can monitor the progress
of individual data load job requests and resolve data load issues
accordingly. Often, data in the flat file does not map properly with the
transfer structure, and the data load job fails. Make sure that the file
definitions map correctly with the metadata defined in SAP BW.

Caution Often, not all fields in a data file have values assigned.
For missing values in CSV-type data files, SAP BW sets
a blank for a character field and zero for numeric fields.
This may lead to some erroneous results when data is
fetched back from the InfoCubes. From a data quality
perspective, define your flat file values in a way that will
identify missing values as something that you can report
on. For example, for character type fields with no
values, set the default value to MISSING. This way you
can filter out records from your analysis that have
incomplete data.

Team-Fly
Team-Fly
Summary
In this chapter, you learned how to load data via flat files. You can
load both the master and transaction data in SAP BW. The overall
process is very similar to loading data from SAP R/3. The only major
difference is that you need to define metadata for the transaction and
new master data InfoObjects. Then you need to provide file names
that contain data for master and transaction data files needed to
schedule data loads.

In the next chapter, you learn how Business Explorer works and how
to analyze data from SAP BW.

Team-Fly
Team-Fly
Chapter 11: Analyzing SAP BW Data
In this Chapter
In this chapter, I will use an InfoCube that has product sales data.
You learn how many different ways you can analyze and present
sales data using the SAP BW data access and reporting
environment.

Team-Fly
Team-Fly
Business Explorer Architecture
The overall intent of gathering data and constructing a data
warehouse is to be able to access data for strategic and tactical
decision-making processes. To build such an environment, SAP BW
provides two major components known as the Business Explorer
(BEX) Browser and BEX Analyzer. As mentioned in Chapter 2, the
BEX Browser is used to publish available corporate information sets,
such as a global repository of reports, documents, knowledge
resources, and analytical applications. The BEX Analyzer is used to
build analytical applications against SAP BW InfoCubes. These
applications could be a simple query in Microsoft Excel or a
combination of several worksheets in the form of a solution
workbook using VBA programming to switch worksheets.

The BEX Browser is a Web-centric interface that presents analytical

applications and reports. The BEX Browser acts very much like a
portal to access information from diverse sources, including SAP
BW. The BEX Browser directly communicates with InfoCatalog to
identify target queries. If the target happens to be a BEX Analyzer
application, BEX Browser will launch a Microsoft Excel session and
transfer the query definition (metadata from the SAP BW metadata
repository) to the BEX Analyzer. The BEX Analyzer is a Microsoft
Excel-based interactive environment that defines and executes
queries. When the user refreshes a BEX Analyzer query, the BEX
Analyzer sends a request to the OLAP processor and the application
server to fetch data. The OLAP processor decides how and from
where to get data (InfoCube or Aggregate) to satisfy the query. The
BW database server then sends data to the OLAP processor. The
OLAP processor caches data in a virtual multidimensional cube for
the end user (see the cube object at the application server layer in
Figure 11-1). After building the virtual cube at the application server
level, the OLAP processor sends the needed data to the BEX
Analyzer (in Microsoft Excel) for further local analysis. At any
moment during analysis, the user can save the current result back in
the SAP BW database server for future use or mail it to other users if
desired.

Figure 11-1: SAP BW

Business Explorer Browser and Analyzer Architecture in BW 1.2B
and BW 2.0A.

As shown in Figure 11-1, SAP BW 1.2B does not support pure Web
reporting. You can publish a BW report (BEX Analyzer Excel with an
embedded query) over the Internet; however, to do interactive
anlysis, you need to install SAPGUI and SAP BW client components
at the client workstation. In SAP BW 2.0, you can publish and
execute pure Web queries by implementing the Web interface using
the SAP Internet Transaction Server (ITS), as shown in Figure 11-1.

Note In SAP BW 2.0B GA, you will be able to build queries on

the intranet. SAP will provide an ActiveX control called
Query Builder. This Web Query Builder does not use a pure
HTTP protocol. It requires an RFC connection to connect to
the SAP BW instance, bypassing the Web server and
restricted to Microsoft Internet Explorer 5.0 or later.

In SAP BW 1.2B, you were unable to access data from ODS. In SAP
BW 2.0, you can access data from ODS via BEX Analyzer or by
using InfoSet Query (previously known as SAP Query). Notice in
Figure 11-1 that you now have several choices to access data from
SAP BW. In this chapter, you learn about how to develop queries
and reports against SAP BW using Business Explorer. Key
enhancements, InfoSet Query, and Web reporting are discussed in
Appendix D, "Key Enhancements in SAP BW 2.0," and Operational
Data Store in SAP BW 2.0 is discussed in Chapter 17, "The
Operational Data Store in SAP BW 2.0."

Team-Fly
Team-Fly
Business Explorer Analyzer
Business Explorer Analyzer functions are driven within a Microsoft
Excel add-in called SAPBEXO.XLA. As part of the SAP BW frontend
installation, this add-in is automatically included in Microsoft Excel,
as shown in Figure 11-2. The BEX Analyzer menu bar is
automatically loaded and displayed in a blank spreadsheet when you
launch Microsoft Excel. Figure 11-2 shows the BEX Analyzer menu
bar for both SAP BW versions 1.2B and 2.0A. Notice that BEX
Analyzer menu options in SAP BW 2.0A are quite different than in
SAP BW 1.2B.

Figure 11-2: SAP BW

Business Explorer (BEX) Analyzer Add-In and BEX Analyzer
Menu Bars for BW 1.2B and BW 2.0B.

The BEX Analyzer for BW 2.0A will be used to describe SAP BW

reporting capabilities using a simple InfoCube for product sales
analysis, as shown in Figure 11-3.
 Figure 11-3: InfoCube Model to Demonstrate BEX Analyzer for
Reporting and Analysis.

The demonstration InfoCube has six dimensions (Material,

Customer, Distribution channel, Time, Unit of measure, and Data
packet) and one key figure (Amount).

Team-Fly
Team-Fly
Defining Queries
Before defining a query, outline what you want to inquire about. Which
InfoCube do you need to write a query against? What data elements do
you need, and how do you want to filter, navigate (drill down), or slice and
dice data? Select only data elements that you need by limiting your
dimensions or applying filters to restrict the query view.

Queries in SAP BW consist of four major sections: Lines, Columns, Free

characteristics, and Filter, as shown in Figure 11-4.

Figure 11-4: Defining a New

Query in the BEX Analyzer.

1. Lines. This is the area where you place characteristics that will
appear as rows of the query result.

2. Columns. This is the area where you place the selected key
figures. If you want to define new calculated key figures local to
your query, this is where you define the calculated field.

3. Free characteristics. In this area you place characteristics to

filter the query result or for drill-down analysis. These filters are
used to restrict data for display but without displaying restricted
elements in the row.

For example, if you want to list products sold and revenues by all
distribution channels except Direct Sales, you set the distribution
channel filter to Direct Sales.
 4. Filter. You use the Filter area to place characteristics for
restricting query data; you do not use this area for navigation. For
example, you use this area if you want to list only the filter on the
Distribution channel but never want to navigate or drill down
using the Distribution channel.

Figure 11-4 shows the steps to define a new query. First click the Open
icon in the BEX Analyzer menu bar. This opens the dialog box to define
the type of query and the InfoCube data source. Click the Queries button,
select an InfoCube, and click the New button. This displays the query
definition window, which shows all dimensions and key figures defined in
the selected InfoCube.

To show Material on Lines and Amount in Columns, simply drag Material

characteristics from the InfoCube tree to area 1, the Lines area. Similarly,
you drag and drop other elements, as shown in Figure 11-5. Notice that as
you drag lines and key figures in respective query sections, the bottom-
right section, section 6, displays the data presentation layout.

Figure 11-5: Selecting Data Elements of a BEX Query.

Click the Save icon to save the current view of the query.

Click the Check icon to execute a query. This launches the query in
Microsoft Excel and displays the results, as shown in Figure 11-6.
 Figure 11-6: The Default Query Results Based on the Global Query
Setting. You Can Change the Look and Feel of the Query by Changing
its Properties.

Customizing the Query Data Display Layout

The BEX Analyzer provides several options to customize the data

presentation in your report.

For example, you can display descriptions of all characteristics in the

query or only a few.

As shown in Figure 11-6, the Material values seem to be duplicated. The

reason is that by default, the query will display a characteristic's key value
and its description. Here, the Material master key and descriptions are the
same in the database. Suppose you want to display only Material
descriptions on each line. This can be done for all characteristics in the
query or by an individual characteristic. Select the characteristics for which
you want to set the display attributes-in this example, Material, as shown in
Figure 11-7. Right-click Material. Navigate the menu as shown in Figure
11-7. Note that by default Key and description was checked. This was the
reason that you saw duplicate material values in the query results. Instead,
select Description. The query will restructure itself and display Material
descriptions only.
 Figure 11-7: Selecting Characteristic Display Options.

Note You must first select a characteristic in a query region to change

OLAP attributes. To change fonts, color, or other query display
attributes, you must use the format options using the icon.
Instead of Microsoft Excel formatting, you can use Microsoft
formatting features for spreadsheet areas that are not included in
the BEX query area.

Team-Fly
Team-Fly
Attaching a Chart
Attaching a chart to display data is a simple process. Click the Query
Layout icon and select Attach chart, as shown in Figure 11-8.
This automatically displays the currently selected characteristics and
key figures on the x-axis and y-axis, respectively.

Figure 11-8: Creating

Charts and Graphs in the BEX Query.

By default, the chart includes all rows in the query result set.
However, you can select a specific rows and columns range, as
shown in Figure 11-9, to custom design your chart.

Figure 11-9: Selecting Chart Display Options.

Right-click in the chart area and select the Source Data option.
Select a Data Range. You can create as many charts and graphs as
you like, each with a different range and type, as shown in Figure 11-
9.
You can also change chart types, such as to bar charts, pie charts,
line charts, or any other type that will best present your results. To
change chart types, right-click in the chart area, select Chart Type,
and select the chart type of your choice.

Team-Fly
Team-Fly
Navigating and Slicing and Dicing Data
The Navigational feature allows you to drill down data based on
individual characteristics. For example, you can analyze revenues by
material and associated navigational attributes such as Material
Type. On the other hand, slicing and dicing data allows you to switch
dimensions on the fly; you can also set filters or ranges to move data
in available dimensions to understand data behavior. For example, if
you want to analyze revenues by material and customer, switch
Customer dimension with Material and then restrict results by a
Distribution channel.

Team-Fly
Team-Fly
Filters and Restricted Key Figures
Filters and restricted key figures are two common methods for
limiting the scope of the result set. Filters can be fixed or a range of
values that are passed on to select a data set for the query.

The restricted key figures are virtual key figures in the Query
definition that are derived based on the InfoCube Key.

For example, suppose you want to display only the sales revenues
for the current and previous years in your report. To do so, create
two restricted key figures: Current Year and Previous Year. Use
these restricted key figures in your query, as shown in Figure 11-12,
instead of the Amount key figure, as shown in Figure 11-9.

Follow these steps to define restricted key figures:

1. Create a new query or, in this case, open a query defined
earlier in this chapter and edit. Figure 11-5 shows the
characteristics and selected key figures for this query.

2. Right-click the folder labeled Key figure, on the top left in

the query edit screen, and select the New restricted key
figure option.

3. Right-click Calendar year in the key figure definition area

and select Restrict.

4. As shown in Figure 11-10, a new dialog box appears to

define new key figures. Because sales revenues need to
be restricted to the previous year (that is, 1998), drag and
drop the key figure Amount in the restricted key figure
definition area.
 Figure 11-10:
Creating Restricted Key Figures in the BEX Analyzer
Query.

Also drag characteristic Calendar year from Time

Dimensions in the Key figure definition area, as shown in
Figure 11-10. Here you either list all available calendar
years in the SAP BW instance or enter a year. In this case,
enter 1998 to restrict Amount values for the year 1998.
Instead of restricting Amount values to one fixed number,
you can select a range of values or a hierarchy node to
restrict the scope of data. Give a descriptive name to this
field.

5. Save this definition and click the icon to exit.

6. The query definition shows two restricted key figures

defined in the query Key figures folder. Simply drag and
drop these two new restricted key figures in the Columns
definition area to display the results, as shown in Figure 11-
11.
 Figure 11-11: Using Restricted Key Figures in the BEX
Analyzer Query.

7. Save the query definition and click the icon to go back in

Microsoft Excel. The BEX Analyzer refreshes data and
displays the results, as shown in Figure 11-12. Note here
that by using restricted keys, you can present data very
effectively as compared to the straight drill-down method,
as shown in Figure 11-12.

Figure 11-12: Displaying Current and Past Year

Revenues by using Restricted Key
Figures.

Team-Fly
Team-Fly
Analyzing Data in the BEX Analyzer
By filtering and restriction, you simply limit the scope of data you
want to analyze. However, after getting the needed data set, you
might need to do further analysis, such as on the most profitable
products by region or the best salespersons for specific products,
and so on.

Before navigating data, take a look at the Query Display sections, as

shown in Figure 11-13. The top section shows selected navigational
attributes of a query. The bottom half shows the results based on the
selected navigational drill-down values. Drilling further down
expands aggregated data to its individual entities based on selected
characteristic values.

Figure 11-13: SAP BEX

Analyzer Query Navigation and Result Areas.

The two quick techniques for drilling down data are described here:

Right-click the query navigational attributes. Select Drill-

down and display the view horizontally or vertically-as Across
and Down, respectively-as shown in Figure 11-14. For
example, right-click the Customer navigational attribute,
select Drill-down, and select the Down display view. The
BEX Analyzer adds a new column, Customer, and displays
 individual revenues by material and customer. It displays
total revenues by the material but breaks down the list by
individual customer. To remove this breakdown, select the
navigational attribute, right-click, and select Remove drill-
down.

Figure 11-14: Drill-Down Methods to Navigate Data in

SAP BW BEX Analyzer.

The second technique is to right-click the characteristic

currently present in a row in the query result section; for
example, Material. Then select Insert drilldown according to
Customer, as shown in Figure 11-14. Interestingly, the end
result is the same. The only advantage of this technique is
that you have several additional options.

Figure 11-15 shows revenue breakdown by product among all

customers. If you would like to see revenue breakdown by individual
Customer instead of Material, you can swap dimensions easily.
Right-click any Material value in the row and select Exchange
Material with Customer. The query recalculates the numbers and
displays data, as shown in Figure 11-15.
 Figure 11-15: Swapping Dimensions. Revenues are Broken
Down by Material and Customer on the Left and Revenue by
Customer and Material on the Right.

Suppressing Repeated Key Values and Row Totals

Thus far, you have seen query results without repeated characteristic
values. For example, as shown in Figure 11-15, the query result on
the right shows the customers only once and displays blanks in
subsequent rows if the customer has ordered multiple material-
products. The data is easy to read and looks good.

You might also notice a subtotal line that gets added for each
product, customer, and calendar year combination. This makes data
very hard to read and understand, as shown in the left side of Figure
11-16.

Figure 11-16: The BEX Analyzer Default Displays Data with

Repeated Characteristic Values. Setting the Query Property to
 Suppress Repeated Values Makes the Same Data Display Much
Clearer and the Data More Presentable.

You can suppress repeated values by changing the Query property.

Right-click anywhere in the Query area and select Properties. In the
Query Properties dialog box under Display, check Suppress
repeated key values and click OK. With this setting, BEX Analyzer
reformats data and displays it nicely, as shown on the right side of
Figure 11-16.

Now the repeated key values are not displayed in Figure 11-16, but
too many subtotals are listed in the results. You may want to list only
the subtotals by Material and not subtotals for all characteristics. To
do so, select a characteristic for which you want to suppress
subtotals and right-click to display the available options. Select
Customer, Suppression of totals row, and Always, as shown in
Figure 11-17. This recalculates subtotals and displays subtotals by
Material; however, it still shows revenue breakdown by Calendar
year without its subtotals, as shown on the right side of Figure 11-17.

Figure 11-17: Displaying Subtotal Values Against a Given

Characteristic During Drill-Down Navigation.

Team-Fly
Team-Fly
Use of Variables in BEX Analyzer Queries
Variables make queries flexible and dynamic. With variables, you set
selection values at runtime instead of hard coding in the query
definition. These variables are defined in the SAP BW instance, via
transaction RSZV or from the main SAP BW menu option. From the
SAP BW main menu, select Business Explorer and select the option
Maintain Variables and define a new variable, for example,
ZCUSTMR, associated with characteristic 0CUSTOMER, as shown
in Figure 11-18. This means that when you refer to characteristic
0CUSTOMER, the variable ZCUSTMR is accessible. You can
include these variables in the query definition to filter data.

Figure 11-18: Defining

Variable ZCUSTMR in SAP BW using Transaction RSZV that Will
be Used to Dynamically Set Values for a Customer to
Select.

Note The creation of variables requires special authorizations.

Normally, variables are defined and maintained by the SAP
BW application developer or the BASIS administrator.
Make sure you have the right authorizations for creating
variables.
To add a variable in an existing query, you need to edit the query and
assign a variable to a characteristic, as shown in Figure 11-19. Save
this query and exit the Edit Query window. The BEX Analyzer
refreshes the query and prompts for a Customer. Enter a Customer
or use the default value; in this example, the default value is
DIGITAL. The query then takes this value, sends the variable value
to the OLAP server, and uses it to select data (see Figure 11-18).

Figure 11-19: Customizing the BEX Analyzer Query to Select

Customer Data Based on User Input using a Variable. At the
Query Runtime, the User is Prompted for Variable Value. This
Variable Value is Used to Select Data at the Database
Level.

You can define variables for Characteristic, Texts, Formulas,

Hierarchies, and Hierarchy nodes. Variables play a key role in
implementing slowly changing dimensions, the characteristics of
other data objects that change in time. For example, the Material
structure often changes. To implement this time dependency, the
material must also be stored with valid time periods. Then from the
query, a variable, for example ZTIMPRD, is sent to the OLAP
processor to select master data valid for the selected time period. To
transfer this variable from the query to the OLAP processor, you
need to edit the Query properties and enter a variable name in the
Key date field, as shown in Figure 11-20. To open the Query
properties window, open your query in edit mode, and then click the
Query Properties icon.
Figure 11-20: Setting up the Query Global Properties for Time-
Dependent (Slowly Changing Dimensions) Data
Objects.

Note The variable names in the Query property must start and
end with &. For example, the Time Period variable
ZTIMPRD in Figure 11-20 is recorded in the Query
properties as &ZTIMPRD&.

Another thing worth noticing in the Query properties dialog

box is the Release for OLE DB for OLAP check box. Only
those queries with this checked will be visible to a third-
party tool that uses OLE DB for OLAP to access SAP BW.
For example, to access data from Business Objects,
inSight, Cognos, Brio, or another tool, you must enable the
query ODBO.
Often, a single query per spreadsheet is not sufficient to build a
complex solution. Instead, worksheets are used as a collection of
spreadsheets to build a complete solution; for example, you may
want to build a reporting application that uses several queries to
fetch data from orders, deliveries, and invoices. It saves retrieved
data in several sheets with charts, graphs, and VBA programming
that enables you to navigate from one sheet to another based on
what the user has selected. With VBA programming, you can call all
functions available in the BEX menu bar. Table 11-1 lists such VBA
callable functions in SAP BW 1.2B.

Table 11-1: VBA Routines in SAPBEX.XLA to Customize

Workbooks
Function Name (Parameters)
Function SAPBEXgetWorkbookID(wbName
As String
As String)
Function SAPBEXreadWorkbook(wbID As
As String
String)
Function SAPBEXgetErrorText() As String
Function SAPBEXsetFilterValue(intValue As
String, Optional hierValue As String, As Integer
Optional atCell As Range)
Function SAPBEXgetFilterValue(intValue As
String, hierValue As String, Optional atCell As Integer
As Range)
Function SAPBEXsetDrillState(newState As
As Integer
Integer, Optional atCell As Range)
Function SAPBEXgetDrillState(currentState
As Integer
As Integer, Optional atCell As Range)
Function SAPBEXrefresh(allQueries As
As Integer
Boolean, Optional atCell As Range)
Function Name (Parameters)
Sub SAPBEXpauseOn()
Sub SAPBEXpauseOff()
Function SAPBEXfireCommand(fCode As
As Integer
String, Optional atCell As Range)
Function SAPBEXcheckContext(fCode As
As Integer
String, Optional atCell As Range)

Team-Fly
Team-Fly
The InfoCatalog
The InfoCatalog is a repository of all reports and solutions. Here you
implement your information delivery model; you organize data
objects and their consumers, the end users. You define Channels (in
SAP BW 1.2B) or Activity Groups (in SAP BW 2.0), assign specific
reports to Channels/Activity Groups, and finally assign users to
specific Channels/Activity Groups. This top layer is the Enterprise
catalog that contains all queries and reports. When a user signs on
to the SAP BEX Browser, based on a user profile, all reports defined
in the Channel/Activity Group are made available to the user. Figures
11-21 through 11-24 show how the InfoCatalog is used to publish
reports.

Figure 11-21: Enterprise

InfoCatalog. A Collection of Enterprise-Wide Reports and Other
Information Objects. Use Simple Drag-And-Drop Techniques to
Move Objects.

Figure 11-22: Channel InfoCatalog. Common Repository of

Channels. Here You Create New Channels and Manage and
Assign Reporting Objects to the Channels. Note that You Assign
 Only Reports or Other Information Objects to a Specific Channel
and Not to an End User.

Figure 11-23: User Channel Assignment. All Users in SAP BW

are Listed Alphabetically on the Left. All Defined Channels are
Listed on the Right. Select a User, and Drag and Drop it in a
Channel to Make an Assignment.

Figure 11-24: Assigning Reports to Individual Favorites. The

InfoCatalog Administrator Can Manage an Individual's Entries in
His or Her Favorite Folders. You Can Organize Entries Simply by
Dragging Them From One Folder and Dropping Them into
Another Folder.

Team-Fly
Team-Fly
The Business Explorer Browser
The BEX Analyzer is ideal for power users and query developers; however, the best
way to deliver information from SAP BW or other repositories and information
sources is to use the BEX Browser. The BEX Browser presents information to users
in an organized fashion. In SAP BW 1.2B, users were grouped by Channels, such
as Operation Manager, Sales Manager, and Marketing Manager, as shown in Figure
11-25. In SAP BW 2.0, Channels are replaced with Activity Groups.

Figure 11-25: The BEX Browser Lists

Only Assigned Channels to User BWADMIN. These Assignments were Made in
the InfoCatalog as Shown in Figure 11-24.

On occasions when you are not familiar with the content of published reports, you
can easily preview individual reports. Move the cursor to the report and select
Preview. The report layout and data elements in the report are displayed on the
bottom half of the browser, as shown in Figure 11-26. This is a nice feature to use to
understand how reports are constructed.

Figure 11-26: Viewing Query Properties From the BEX Browser.

As stated earlier, the BEX Browser can also manage non-SAP BW information
objects, such as URL links and other pointers to other documents (see Figure 11-
27). To include a URL in the BEX Browser, use the drag-and-drop area of the BEX
Browser, a light blue horizontal strip on the bottom left of the BEX report list area.
Drag the URL from your Internet browser and drop it in the BEX drag-and-drop area.
Then drag the URL to connect to a cluster to organize objects.

Figure 11-27: Including Non-SAP BW Information Objects in the BEX Browser.

To execute a report, move the cursor on the report and select the EXECUTE option.
The BEX Browser launches a Microsoft Excel session, and then you are right back
in the BEX Browser to analyze data.

Remember, your BEX Browser session remains active while you are in BEX
Analyzer. The BEX Browser and BEX Analyzer establish two separate connections
to SAP BW. So any time you launch another report from the BEX Browser, it will
open another BEX Analyzer session. Now you have one BEX Browser and two BEX
Analyzer sessions. Close the sessions you no longer need. Each session uses your
workstation resources as well as SAP BW connection resources.

Team-Fly
Team-Fly
Summary
This chapter covered the SAP BW data access and reporting
environment. The BEX Analyzer provides a good data analysis
environment, and the BEX Browser publishes information across the
enterprise in a very organized fashion. This chapter provided you
with a solid understanding of how to present and analyze data in
many different ways. You also saw how to define queries and format
data in a way that is most useful to you.

This chapter was dedicated to accessing data from SAP BW; it did
not cover how to access data from SAP BW third-party tools.
Chapter 14 discusses how to access data from SAP BW using
ODBO third-party integration with SAP BW.

The next chapter, "SAP BW-Defining Custom InfoCubes," is an

interesting one. You learn data modeling techniques and steps to
create custom InfoCubes.

Team-Fly
Team-Fly
Part III: Designing Custom SAP BW OLAP
Solutions
Chapter List
Chapter 12: SAP BW-Defining Custom InfoCubes

Chapter 13: Enhancing Business Content and Developing Data

Extractors

Chapter 14: Integrating Third-Party ETL Products with SAP BW

Chapter 15: Integrating Third-Party Data Access Products with

SAP BW

Chapter 16: Managing SAP BW-Performance and Sizing Tuning

Chapter 17: The Operational Data Store in SAP BW 2.0

Team-Fly
Team-Fly
Chapter 12: SAP BW-Defining Custom
InfoCubes
In this Chapter
SAP provides a rich business content for analytical applications;
however, it is not expected that it will meet 100 percent of customer
analytical OLAP needs. You either have to extend SAP-provided
business content, as discussed in Chapter 13, "Enhancing Business
Content and Developing Data Extractors," or define custom
InfoCubes and needed data objects to meet your business data
analysis needs. In this chapter, you will learn how to construct
custom InfoCubes to meet your data analysis needs.

Team-Fly
Team-Fly
Data Warehouse Modeling
As with any data warehouse project, data modeling is key to the
success of a high-performance data warehouse implementation.
Data modeling defines how information objects behave in a data
warehouse: logically and physically. Prior to SAP BW 2.0, most data
modeling was focused around a multidimensional paradigm to
support slice-and-dice types of analysis. With the implementation of
Operational Data Store (ODS) in SAP BW 2.0, you now need to think
of SAP BW modeling from an enterprise data modeling perspective
where you model ODS and multidimensional data objects to support
operational, slice-and-dice, and historical data analysis needs, all
under one information framework: SAP BW.

The first question that comes to mind is why you need to think
differently when it comes to modeling a multidimensional or an
enterprise data warehouse. The reason is that multidimensional
database structures are designed to analyze numeric data, such as
measurements, against a given set of variables or characteristics.
On the other hand, the enterprise data warehouse is a logical
collection of all information objects that include multidimensional,
ODS, historical, and unstructured data objects. Therefore, the scope
of enterprise data warehouse modeling is much broader than
multidimensional modeling alone. The following section describes
multidimensional data modeling from an SAP BW perspective.

Figure 12-1 shows several aspects of data warehouse modeling.

Traditionally, data warehouse modeling is limited to the following
models:
 Figure 12-1: Enterprise
Data Warehouse Modeling.

Conceptual

Logical Data

Physical Data

Deployment

The Conceptual model outlines the flow of information across all

business processes. From a data warehousing perspective, it
describes how business decisions are made at all levels in an
organization to drive business processes at an abstract level.

The Logical data model defines grouping and relationships of

logically similar Information Objects in terms of entity relation
models. Then from such entity relationships, you derive several
Logical data models to support enterprise business intelligence
needs. For example, for customer sales analysis, the logical entity
relationship model describes how customer orders are related to
sales organizations and material at a very detailed level, whereas
the multidimensional data model may have only a summary of order
information, such as customers and the products ordered.
The Physical data model describes data structure definitions and
design architecture to meet business intelligence requirements. The
Physical data model heavily depends on the data warehouse
construction technologies best suited for specific data analysis
needs. For example, you might decide to build analytical applications
against pure multidimensional or relational technology and relational
database engines for ODS or the enterprise data warehouse. The
physical design must take into account the necessity to exploit
database specific facilities for high scalability and performance for
analytical applications.

The Deployment model is often considered part of the Physical data

model. However, in today's volatile business environment, the
Deployment model needs special attention. The Deployment model
assures that the Physical data model conforms to the business
Conceptual model, making your enterprise data warehouse flexible
to accommodate new business analytical needs.

The Deployment model is derived primarily from the Physical and

Conceptual models. For example, say a company has a central
enterprise data warehouse where it receives data from all
transaction systems and builds all reporting objects. However, as the
company grows and launches business operations across several
geographic regions and across global boundaries, it is not possible
to build a very rigid central data warehouse for the entire corporation
to support 24-hour operations.

Here the Deployment model describes how an enterprise data

warehouse can be deployed as one central instance, partitioned or
distributed without redesigning the Physical data model. For
example, say you have one central data warehouse. It has an ODS,
the data warehouse, and the OLAP data model. You decide to
separate ODS from the rest of the data warehouse environment and
deploy it on a stand-alone server (hardware, software, and services).
If the Physical model and associated services for ODS are not
defined in an architected fashion, you cannot separate ODS from the
rest of the data warehouse. For this reason, when designing the
Physical data model and associated services, keep in mind that the
business is going to change even before a data warehouse is ready
for deployment. Make sure that the physical design accommodates
the business architecture, today and tomorrow.

The data modeling team consists of business and data analysts and
enterprise data modelers to gather business requirements for
analytical applications. For SAP BW projects, an SAP BW business
content specialist should be a member of the conceptual and logical
modeling phases. Because SAP BW does most of the database
level implementation work, you do not need a database level
programmer to code schemas, store procedures, triggers, or define
indexes. For physical data modeling, however, you should keep one
DBA on the team, especially for database sizing issues. Involve
BASIS operations team members in defining the SAP BW path-to-
production life cycle and in defining the deployment model when
SAP BW goes in production. Make SAP BW support part of the SAP
R/3 support structure. This chapter is designed for SAP BW
developers who define InfoCubes and build analytical applications.

Data warehouse modeling, especially ODS modeling, is discussed in

Chapter 17, "The Operational Data Store in SAP BW 2.0," which
describes the ODS role in a data warehouse and how to implement
ODS in SAP BW 2.0A and 2.0B.

Data Modeling Considerations Specific to SAP BW

Data warehouse modeling for SAP BW is somewhat easier than

traditional data warehousing for companies that deploy SAP
enterprise mission critical applications and have a major portion of
business applications that are SAP-centric. The data modeling task
for data warehouse modelers becomes somewhat easier for the
following two reasons.
 When you implement SAP R/3 applications, the business
workflow, enterprise reference model, data standards,
business rules, and business models have already been well
understood, and such business operational models are
available.

SAP BW business content comes with rich industry-specific

data models. This saves a lot of initial investigative data
modeling work for a data warehouse.

Though the above are good news for data modelers, you will run into
cultural issues associated with the SAP R/3 OLTP and traditional
data warehouse modelers, as discussed in Chapter 2.

The first three modeling areas-Conceptual, Logical, and Physical-

mentioned previously apply to all data warehouse projects. However,
the deployment model is important when modeling the data
warehouse landscape for SAP BW. When modeling SAP BW, you
need to be very careful in analyzing end-user requirements in
modeling queries to define the physical and deployment models to
exploit SAP R/3 BASIS multitiered architecture for optimum
performance. Because SAP BW star schema is implemented in a
relational DBMS, the key point to keep in mind is to model and
implement long, thin fact tables and relatively small, short, and wide
dimension tables.

Note Due to SAP BW's tight integration with the SAP R/3 OLTP
instance, be very careful to model information navigation
schemes directly from SAP BW to SAP R/3 OLTP. SAP BW
2.0B provides this navigation capability, but this does not
mean that you have to implement such direct to OLTP
navigation in every query. Use this capability only when an
analytical activity requires an analyst to investigate
complete transaction-level details that still exist in the SAP
R/3 OLTP. This is another cultural issue. I have seen SAP
R/3-centric SAP BW developers who are more interested in
 jumping to the SAP R/3 OLTP instance rather than focusing
on modeling InfoCubes and ODS objects in SAP BW. My
advice is to limit real-time reporting against SAP.

The next topic describes multidimensional data modeling that is

needed to build custom InfoCubes in SAP BW 1.2B and SAP BW
2.0A.

Team-Fly
Team-Fly
Multidimensional Data Modeling (MDM)
A star schema is the most common form of a multidimensional
model. In the center of a star schema is the fact table connected to
several dimensions that business users use to slice and dice data.

Look at the SAP Sales and Distribution demo InfoCube data model,
as shown in Figure 12-2.

Figure 12-2:
Multidimensional Data Model in SAP BW. The Star Schema
Representation for the Sales and Distribution Demo InfoCube in
SAP BW 2.0A.

On the left is a star schema for the Sales and Distribution InfoCube.
It has nine dimensions and four key measurements. Each dimension
is connected to the fact table via its unique ID. A record in the fact
table is uniquely identified by the keys of the dimension tables and
becomes a multi-part primary key. In this example, to make a unique
fact record there are nine dimension keys, each representing a
dimension. In database terminology, keys of the dimension tables
are foreign keys in the fact table.

The Data Warehouse Toolkit by Ralph Kimball is an excellent source

for SAP BW InfoCube designers to understand common
multidimensional modeling concepts. It provides data modeler
information on multidimensional modeling techniques. However,
multidimensional data models in SAP BW differ from most industry-
accepted reference star schema models. One such difference
between SAP BW and the rest of the industry star schemas is that
master data is shared across all InfoCubes defined in SAP BW.
When modeling in SAP BW this feature-shared master data-alone
plays a major role in modeling information objects that are not too
complex and balanced for navigation to provide overall analytical
applications performance. Because SAP BW is built on top of proven
multitiered architecture, one must understand the deployment
architecture of analytical applications by exploiting SAP distributed
technologies instead of technologies specific to DBMS. The data
models have to accommodate such dynamic distribution of
information objects across the extraprise. Note that Kimball's book
does not discuss ODS design or data warehouse modeling
concepts. It discusses multidimensional modeling at great length,
and I recommend that SAP BW modelers read this book.

Defining Dimensions

In a traditional star schema model, the dimensions contain reference

data to hold business descriptions for analysis; for example,
Customer, Material, and Sales Organization. Dimensions are specific
to a fact table; therefore, reference data such as master data and
hierarchy is not shared across the cubes. In SAP BW, reference data
is stored once and shared across all InfoCubes. This reduces data
redundancy.

An InfoCube can have a total of 16 dimensions. Three are reserved

for Time, Unit of Measure, and Packet ID. The 13 other dimensions
are user definable.

To model dimensions, keep the following points in mind:

Understand how business people want to analyze data.

Understand the possible navigation paths to view data.

Identify the attributes associated with a dimension. For

example, the Customer dimension has attributes such as
 Name, City, State, Zip Code, and so on. You can have up to
248 attributes for a dimension.

Normalize dimensions. Do not mix groups of variables in one

dimension. For example, do not include Customer and
Material attributes in one dimension. Build two separate
dimensions: one for Customer and another for Material.

Note Though dimensions and hierarchies look the same,

they are different entities. Dimensions have no
common levels, and a query may or may not
contain each dimension to fetch dimensions. The
hierarchy must have at least one common level,
and queries can have at most one hierarchy.

Dimensions tend to be time independent. However, it is quite

possible that dimensions also change by passage of time.
For example, organizations or cost center structures may
change from time to time. The terminology used to define
such time dependency is slowly changing dimensions. This
subject is discussed later in this chapter.

Time and Unit of Measure are the most common dimensions

in just about all OLAP cubes. After all, the purpose of
analysis always refers to a specific time period, such as
current year versus past year. For this reason, SAP BW has
a predefined time dimension.

Dimension attributes used for frequent drill-down analysis

must be modeled in the dimension table. This improves
overall data navigation performance.

Defining Facts

Facts contain business measures uniquely associated with a set of

predefined dimensions. The number of entries in a fact table is very
large compared to that of individual dimension tables. The size of the
fact table depends on the dimension attributes in the dimensions. A
fact table can have several millions to billions of entries. For
example, if you want to capture order details up to individual line
item levels, the fact table has several entries based on line items in
an order. Keep the following guidelines in mind when defining a fact
table:

Keep the key figures to atomic level-mostly raw, numeric

items relevant to measures only.

Do not store those computed values that can be derived

easily at runtime. For example, product cost can be derived
at run time by multiplying price per unit times number of units
sold. This saves time loading the data in the fact tables.

Fact tables are accessed through dimensions.

You also can define a factless fact table. This means that
such a fact table contains no measure to query dimension.
For example, to model a manufacturing plant's cost
effectiveness in shipping products, you define dimensions
such as Material, Plant, Time, Unit of Measure, Ship to Zip
Code, and the fact table that has only one dummy measure,
Existence, set to value 1 as a fact. Then by simply slicing
and dicing dimensions, you get counts of the dimension
intersections, as shown in Figure 12-3; for example, you
could obtain the number of products shipped from a
manufacturing plant to customers living in Boston during the
last two years.
 Figure 12-3: Factless Fact Table. It Contains No
Measures.

Team-Fly
Team-Fly
SAP BW Extended Multidimensional Data
Model
In a traditional star schema model, the reference data is modeled in
dimensions and limited to one cube only. In SAP BW, the reference
data is shared across all InfoCubes and ODS objects. This is
managed via an intermediate table, called a Set ID (SID) table. The
SID table connects attributes of a dimension to a corresponding set
of master data, text, and hierarchies, as shown in Figure 12-4.

Figure 12-4: Extended

Star Schema for SAP BW 1.2B InfoCubes.

Data access takes more resources; however, due to additional joins

to access reference data, this model is very flexible and can share
reference data across the entire data warehouse, regardless of
where reporting is done-against an InfoCube, ODS, or other data
objects.

Note In SAP BW 2.0, the SID tables are further decomposed into
two separate SID tables: one for time-dependent and
another for time-independent attributes of reference data
objects. This makes it easier to implement and manage
time-dependent dimensions, known as slowly changing
dimensions. To implement slowly changing dimensions,
master data must be implemented as time dependent.
Then at query run time, use a variable to pass the time
 period of choice for the relevant master data attributes, as
discussed in Chapter 11.

Team-Fly
Team-Fly
Creating a New InfoCube in SAP BW
Constructing a custom InfoCube requires a good amount of analysis
to identify end users' data analysis and reporting needs.

Before implementing an InfoCube, identify and document the

following items:

InfoSources

Characteristics to Define Dimensions

Dimensions Attributes

Key Figures for Fact Tables

Update Plan for Key Figures

Building an InfoCube

To define a new InfoCube, right-click the InfoArea in the InfoCube

tree-in SAP BW 1.2B and BW 2.0A-in which you want to create a
new InfoCube and select the Create InfoCube option. The system
then asks for the type of InfoCube to create. Depending on the
release of SAP BW, you may want to create one or more types of
InfoCubes, as shown in Figure 12-5.
 Figure 12-5: Defining a New
InfoCube in SAP BW. The Top Shows the InfoCube Types
Available in SAP BW 1.2B, the Middle in BW 2.0A, and the
Bottom in BW 2.0B. Note that in SAP W 2.0B, There is No
InfoCube Tree. In SAP BW 2.0B, You Will Find a Data Targets
Tree, InfoAreas, and Either InfoCube or the ODS Object. SAP BW
2.0B is Discussed in Chapter 17; this is Here for Information
Only.

In SAP BW, you can create an InfoCube from scratch or use an

existing InfoCube as a template and then customize it for your
needs. For example, you can take an existing InfoCube model,
Customer or Orders InfoCube, and add or remove a few dimensions
or key figures. This is one way to exploit SAP BW generic InfoCubes
to define additional custom analytical applications.
 Note The ASAP methodology for SAP BW has predefined
information-gathering templates for the building blocks of
InfoCubes. SAP BW methodology guides on data modeling
and implementation are available at SAPNet. I recommend
that SAP BW designers take advantage of these templates
and methodology guides, which are well-suited for SAP
infrastructure.

At the time of this writing, most templates and methodology

guides were written for the SAP BW 1.2B version. With the
implementation of ODS in SAP BW 2.0, the entire data
modeling and analytical application design methodology is
still missing in ASAP for SAP BW methodology documents
and templates. I am sure SAP will update these
methodologies before the SAP BW 2.0B GA release.

In SAP BW 2.0A, you have several options to define a new

InfoCube, as shown in Figure 12-5. The Basic InfoCube is the same
as what was in SAP BW 1.2B. The MultiCube option enables you to
construct a new InfoCube that is based on another set of InfoCubes.
The Remote Cube option enables you to build a virtual InfoCube that
accesses data from an external instance. These new options make
SAP BW a powerful and attractive OLAP engine that extends from a
simple InfoCube-centric OLAP environment to multi-level InfoCube
(data mart) integration.

Constructing an InfoCube consists of two major steps:

1. Defining InfoCube data structures-characteristics, time, and
key figures

2. Assigning characteristics to dimensions

Defining InfoCube Data Structures

For this discussion, I'll define a simple Sales Analysis InfoCube with
three dimensions: Customer, Material, and Distribution Channel with
a key figure called Revenue Amount. Because we are defining a
Basic Cube, the process of creating an InfoCube is the same in SAP
BW 2.0 and BW 1.2B.

After entering the InfoCube name and description, as shown in

Figure 12-5, the system displays the InfoCube Characteristics edit
window, as shown in Figure 12-6.

Figure 12-6: Assigning Characteristics, Dimensions, and

Attributes for a New InfoCube using SAP BW
2.0A.

It is here that you select an InfoSource to associate with an

InfoCube. Click the InfoSource icon on the right of the InfoObject
Catalog option. This displays the available InfoObjects in the window
section on the right titled Template. Now select the characteristics
needed for the InfoCube. Select Characteristics from the right; copy
them in the InfoCube structure to the left by clicking the icon with the
left arrow in the middle of the screen, as shown in Figure 12-6. To
add time and key figures, click tabstrips Time characteristics and Key
figures and select corresponding objects from right to left in the
InfoCube structures.

Assigning Characteristics to Dimensions

Click the Dimensions button to create and assign dimensions, as
shown in Figure 12-7. After completing dimension assignments,
make sure to check the InfoCube structure by clicking the check icon
in the application menu bar, and then save this InfoCube definition.
You must activate an InfoCube before creating the update rules.
After activation, make sure that the InfoCube status in the InfoCube
edit window shows saved, active, and executable. Exit this window.

Figure 12-7: Creating Dimensions and Assigning Attributes to

Them.

At this point, you have the basic structure of an InfoCube. However,

the system does not know how to populate the fact and dimensions
with the incoming data. To enable it to do so, you need to define the
update rules to fill the fact and dimension tables.

Defining Update Rules for an InfoCube

Most often you define update rules for key figures only. Before
creating update rules, you must know the business rules that define
the measurements and key figures. To create update rules for an
InfoCube, right-click the active InfoCube and select Create Update
Rules. First you are prompted for the InfoSource name to use for the
InfoCube, followed by the InfoCube Update Rule: Change window,
as shown in Figure 12-8.

Figure 12-8: Defining Update Rules for an InfoCube in SAP BW

2.0A. This Version Supports a Concept of a Startup Routine that
was Not Available in SAP BW 1.2B.

To get to the Update Rules window, select one key figure and click
the Detail icon on the bottom half of the window. This takes you to
another window where you can define the update rules for
characteristics and key figures.

The startup routine is an important new functionality in SAP BW

2.0A. For example, you can load reference data from a database for
lookup or validation during the update rules. Instead of repeatedly
accessing the database for lookups for each characteristic or key
figure, you can write a routine to load and calculate all needed data
in memory and then do lookups in memory instead of the database
when updating the InfoCube. This improves InfoCube data loading
time significantly. In earlier SAP BW versions, customers defined
their own logic to call function modules in the update rules to develop
a similar startup routine like functionality. This required complex
ABAP programming to create update rules and programming. With
this new functionality, you can simplify update rules.

Figures 12-9 and 12-10 show how to map source values to

characteristics and key figures in an InfoCube. For each key figure,
you have several options to update its value. If Addition mode is
selected, the system looks for a record in which primary keys are the
same. If such a record is found in the InfoCube, the new key figure
value is set to the total of the old and new values.

Figure 12-9: Update Rules Details for Key Figures in an

InfoCube. The Top Section Defines How Key Figures are Saved in
an InfoCube, the Middle Section Describes Mapping of a Key
Figure Value before it is Stored, and the Bottom are the Units for
Reference for the Key Figure.
 Figure 12-10: Defining Update Rules for Characteristics. Five
Methods are Available to Map Characteristics and Assign Values:
Direct InfoSource, Constant Value, From Master Data, Through an
ABAP Routine, or Initial Value.

The update method for a key figure could be a simple move or a very
complex logic to compute values. You can define an update routine
by selecting the ABAP Routine method icon as shown in Figure
12-9. Then click the Create new routine icon on the right of the
Routine method line. You will be asked to enter a routine name. SAP
provides an ABAP routine template that will need its structured
defined. You simply need to add your logic for key figure calculation.

A sample update code is listed in Appendix B, "SAP BW and SAP

R/3 Transactions, Tables, and Code Examples."

Similar methods are applied to characteristics update rules. Here

you map InfoObjects from InfoSource to characteristics, as shown in
Figure 12-10.

There are five sources for characteristic updates, as shown in Figure

12-10. The InfoSource implies a simple move. A constant value
means it is a fixed value. For example, say you are building a data
mart-InfoCube-for a specific region-North America-and you do not
have its value in the incoming InfoSource; here you can assign a
fixed value to sales region characteristics.

The Read master data option allows you to look up values from the
master data tables. For example, say you want to store actual
descriptions of Sales Organization instead of its code, or you want to
standardize product or customer codes based on a predefined
master data lookup table.

The ABAP routine option allows you a complex method to evaluate

characteristic assignment. For example, for data quality assurance,
you can write an ABAP routine that parses the incoming product
code to assure that it conforms to defined product codes. Another
example for writing an ABAP routine is to verify that the ship-to
characteristic-customer-is correct. For example, a customer, say
Digital Equipment Corporation, may be written as Digital, Digital
Equip. Corp., or DEC. From a data quality perspective, you can write
an ABAP routine to assign the ship-to characteristic the correct
name of Digital Equipment Corporation.

The Initial value option simply sets the characteristic value to a

blank.

After defining all update rules, check the update program by clicking
the Check icon on the bottom left of the Update Rule definition
window. If no errors are reported, click the Transfer button that has a
green check mark and exit this window. Save and activate the
update rules.

Note To view any error in generating update rules or to view a

complete ABAP program that updates the InfoCube, select
the Extras menu option and click Display activated
program, as shown in Figure 12-11. This ABAP program
provides you with all the information you may ever want to
know regarding SAP BW populated InfoCubes. A complete
 listing of InfoCube update programs is included in Appendix
B.

Figure 12-11: Accessing Error Logs and Generated

InfoCube Update ABAP Code.

Team-Fly
Team-Fly
Joining InfoCubes
This is a new feature in SAP BW 2.0. The MultiCube is simply a
definition, or view, that is based on multiple InfoCubes. Actual data
remains in the source InfoCubes. Data is fetched at run time from
source InfoCubes in parallel to improve performance.

From the BEX Analyzer, the MultiCube looks as if it is a true

InfoCube. Note that because it represents a view against existing
InfoCubes, there are no update rules for the MultiCube InfoCubes.

InfoCubes are usually subject-centric. However, business decision-

makers often want to pull information together across all
organizations. Under such a scenario, you can define the MultiCube
view against individual InfoCubes. For example, a supply-chain
analyst might want to know details of order, delivery, and billing
statistics in one view. In this case, you can define a MultiCube
against Customer, Deliveries, and Billing InfoCubes and select
characteristics and key figures needed for the analysis from
individual InfoCubes.

Though the MultiCube feature is available in SAP BW 2.0, one has

to be very careful when defining a MultiCube because the
performance of the SAP BW server could be impacted. Remember
that the MultiCube result set is a union of the InfoCubes. Because
you access two or more InfoCubes, and depending on how many
items are selected from each InfoCube, the query result set could be
doubled or tripled, and that could consume a lot of SAP BW system,
network, and client workstation resources.

Moreover, you have to be very aware of the update rules used to

compute key figures in all InfoCubes used to define a MultiCube.
Knowledge of update rules is critical to interpret query results
accurately. For example, say you have one InfoCube for the sales
organization with key figure revenue and another InfoCube for the
marketing organization with the same key figure revenue. To obtain
combined revenue, you can join these InfoCubes to define a
MultiCube. A query against this MultiCube lists sales and marketing
revenues side by side, but are revenues accurate? They may or may
not be for the following reason. The sales organization revenue
figures are calculated based on sales region and product sold, and
the marketing revenues are defined by marketing campaign and
product sold. Though both organizations use the same key figure,
revenue, update rules in each InfoCube are different. When joining
these two InfoCubes to list revenues, you will be comparing apples
and oranges; it does not make sense to make strategic decisions by
looking at these revenue figures.

Therefore, it is very important to understand update rules for all

InfoCubes used to define a MultiCube. Once update rules are
understood, the MultiCubes are a good candidate for building
executive information systems or corporate-wide high-level cross-
organization analytical applications for senior management.

Defining a MultiCube InfoCube in SAP BW 2.0A

Defining a MultiCube InfoCube is relatively simpler than building an

InfoCube. When creating an InfoCube, select the InfoCube type as
MultiCube. The system will display the available InfoCubes for the
join. Select the InfoCubes you need for this new MultiCube definition,
as shown in Figure 12-12. From here on, the process is the same as
when you select characteristics, time, and key figures available in
individual InfoCubes. Define the newly assigned dimensions, select
key figures, save, and activate the MultiCube, as shown in Figure
12-13. No update rules are needed.
 Figure 12-12: Selecting
InfoCubes or MultiCube InfoCubes in SAP BW
2.0A.

Figure 12-13: MultiCube InfoCube Saved and Activated. Looks

and Behaves Exactly Like a Typical InfoCube.
As the size of the InfoCube increases, it slows end-user query
response time. To improve query response time, several aggregate
cubes are defined against one single InfoCube. This is discussed
further in Chapter 16, "Managing SAP BW-Performance and Sizing
Tuning."

Team-Fly
Team-Fly
Summary
In this chapter, you learned about data-warehouse-modeling
techniques primarily focused on multidimensional data modeling for
InfoCubes. You learned how to implement custom InfoCubes in SAP
BW. Moreover, you learned how to join multiple InfoCubes, a new
feature in SAP BW 2.0. The ODS data modeling and implementation
process is discussed in Chapter 17. The next chapter covers how to
enhance business content and develop custom data extractors for
SAP BW.

Team-Fly
Team-Fly
Chapter 13: Enhancing Business Content
and Developing Data Extractors
In this Chapter
Though SAP BW content consists of all objects needed to deliver
ready-to-go analytical applications, it is not expected that it will
satisfy 100 percent of the data needs of all customers. You can add
value to business content either by enhancing existing business
content or by creating your new data objects and extractors in
source SAP R/3 to pull data in SAP BW. In this chapter, you learn
the business content enhancement process and how to extract data
using generic extractors.

Team-Fly
Team-Fly
Enhancing Business Content
Business content in SAP BW 1.2B consists of several objects such
as InfoObjects, InfoCubes, InfoSources, Update Rules (as part of
InfoCubes), Queries, and Channels. To support business content in
SAP BW, one must install SAP BW components in the SAP R/3
OLTP instance. These components consist of data extractors, delta
capture tables, function modules, transactions, and associated
metadata objects for InfoSources. Chapter 8 describes how to load
business content in SAP BW from the SAP R/3 OLTP instance. This
chapter describes how to extend SAP-provided InfoSources content,
how to create new InfoSources, and how to build new data
extractors in SAP R/3 OLTP instances for SAP BW.

The enhancement process starts with creating a project, assigning a

class of enhancements, and defining all changes using user-exits
under the same project.

Use transaction CMOD to create a project. Choose the SAP

enhancement RSAP0001 as an enhancement to the project and
activate the project, as shown in Figure 13-1.

Figure 13-1: Creating a

Project for Enhancements in SAP BW using Transaction
CMOD.
The enhancement RSAP0001 has four components, the function
modules, as shown in Figure 13-1 and as described here:

Note Enhancements, in SAP terminology, have more of a special

meaning than simply making changes to the code or tables.
Enhancement of an SAP object is achieved by use of user-
exits. User-exits keep custom changes transparent from
the SAP maintenance level or release upgrades. User-exits
are function modules that are called when an associated
object is processed during a workflow thread. SAP provides
application-specific user-exits. SAP BW provides user-exits
to extend business content in the SAP R/3 OLTP instance,
SAP BW OLAP level, SAP BW Monitor level, and the
Business Explorer level.

EXIT_SAPLRSAP_001-Transaction Data

This function enables you to populate user-defined,

additional fields attached to an existing InfoSource in the
form of append structures. For example, if you want to collect
additional fields in the Orders InfoSource 2LIS_01_S260,
use this exit to populate new fields with data during the
extraction process.

EXIT_SAPLRSAP_002-Master Data Attributes

This function module acts like transaction data. It fills

additional master data attribute fields the user has defined.
For example, if you want to add plant code as an attribute
associated with material, you use the append structure
technique to enhance the master data structure.

EXIT_SAPLRSAP_003-Master Data Texts

This function module is used to enhance texts associated

with master data attributes. By default, only the short
description is moved from the SAP R/3 OLTP instance to
 SAP BW. This user-exit can be used to populate medium or
long texts from user-defined tables before text data is sent to
SAP BW.

EXIT_SAPLRSAP_004-Hierarchies

This function module can be used to populate transfer tables

generated for hierarchy data requests. For example, if you
want to add additional elements for a hierarchy node for SAP
BW navigation, you call this user-exit to restructure the
hierarchy transfer table before it is sent to SAP BW.

Often, I have been asked when to enhance an existing InfoSource or

to create a new InfoSource. Following are a few guidelines.

Enhance an Existing InfoSource

when you have a few new data elements needed in

conjunction with an existing InfoSource. For
example, say the Order InfoSource 2LIS_01_S260
is missing the customer postal code. In most cases,
you may not need the postal code; however, for
demographic studies or GIS implementations, the
postal code will provide you with detailed information
for product sales analysis. In this case, you would
append the postal code in the 2LIS_01_S260
InfoSource and fill in values during data extraction.

when both the SAP provided InfoSource content and

your additional data elements need to be extracted
simultaneously.

when the record length of an InfoSource does not

exceed 1,000 bytes after appending additional fields
when data associated with the InfoSource is
transferred to SAP BW using IDOCs, or the total
number of fields after new field appends is less than
 255 when the InfoSource is loaded in the ODS using
tRFC.

Create a New InfoSource

when the new data items are not directly associated

with an existing InfoSource and can be extracted
independently. For example, SAP does not provide a
program to extract pricing data. Here, you define a
new InfoSource for pricing information and design a
custom extract program to get all pricing condition
types for sales orders and billing documents.

when the SAP provided InfoSource provides too

much information that is irrelevant to your analysis.
Here, you define a new simplified InfoSource and
extract needed data for the InfoSource.

Team-Fly
Team-Fly
Extending Transaction Data Content
Before deciding on extending business content, extensively analyze
present business content, such as the InfoSources. When you find
that needed data is missing, you should enhance your transaction
InfoSources. This is because the enhancements you make will be
made in the SAP R/3 OLTP environment. For this reason, you need
to stay involved with SAP R/3 OLTP development plans to include
BW-specific development efforts in the SAP R/3 OLTP project life
cycle. Often, your OLTP configuration may not be capturing the
needed data. This can burden existing OLTP configuration projects.

The transaction data enhancement consists of the following steps:

1. Define a project using IMG, as shown in Figure 13-2. When
you right-click Customizing for R/3 extractors, you directly
log on to the source SAP R/3 instance.

Figure 13-2:
Enhancing Data Extractors in SAP
R/3.

2. Edit the InfoSource structure to append new data elements

using transaction program RSAO0007. If you do not know
which structure to update, look at table ROIS-STRUCTURE
for transaction data extracts. Use transaction SE16 or
SE17 to list the InfoSource and respective structure.

Note Any time you change a structure, you must

 activate and adjust the database. Use transaction
SE11 and open the transfer structure. Under the
Utilities menu option, select Database utility. Click
the Edit button. Then select the Save data radio
button and click the Activate and adjust database
button, as shown in Figure 13-3. Go back in SE11
and reactivate the structure.

Figure 13-3: Activating and Adjusting the

Database after Appending a Structure
Definition.

Note You cannot have the same data element multiple

times in a structure definition. Create a new data
element using transaction SE11, and then use
that new element in the structure. Moreover, you
cannot have time elements, such as UZEIT, in the
structures for InfoSources.
3. Assign InfoObjects to the additional fields using program
RSAO0001 in SAP R/3 OLTP.

4. Add new InfoObjects in the SAP R/3 instance. You may

create new InfoObjects that may or may not be master data
dependent or independent.

5. Maintain the Enhancement component and add code to fill

the new data elements in the structure. To do so, you need
to open the project using IMG or transaction CMOD; select
enhancement RSAO0001, and select
EXIT_SAPLRSAP_001, as shown in Figure 13-4.

Figure 13-4: Adding Custom ABAP Code to Fill New

Data Elements in the InfoStructure using
EXIT_SAPLRSAP_001.

6. Write code to populate new fields. The

EXIT_SAPLRSAP_001 function module shows a template
ready for you to write ABAP code to fill new data elements.
Like any function module, it has Import and Export
parameters.
 The Import parameter I_ISOURCE is the name of the
InfoSource, and parameter I_UPDMODE is the transfer
mode as requested by the SAP BW Scheduler, such as
IDOC or tRFC with ODS.

Exporting table parameter I_T_SELECT is selection criteria

set during the SAP BW data request, I_T_FIELDS contains
a list of the transfer structure fields, and parameter
C_T_DATA is a table containing data records received from
the SAP BW data extraction API in the form of the source
system, as defined in the table ROIS in the SAP R/3 OLTP.

7. Add actual code to populate new fields. To do so, double-

click include zxrsau01, as shown in Figure 13-4.

8. Add code to fill new fields in the InfoStructure.

9. After saving the code, you must activate the project before
your enhancement can be used.

10. On the SAP BW side, upload this enhanced InfoStructure,

as shown in Figure 13-5.

Figure 13-5: Updating Metadata for Enhanced

InfoObjects From SAP R/3 OLTP in SAP BW. It is
Suggested that You Enhance Business Content on the
 OLTP Side, and then Pull Metadata in SAP
BW.

Team-Fly
Team-Fly
Extending Master Data InfoSource Content
Enhancing master data is similar to enhancing transaction data. One
simple way to extend master data content in the SAP R/3 OLTP side
is to define a new view and assign that view to the InfoObject
transfer structure using the following steps for SAP BW 1.2B:
1. Copy or change the master data extraction view using
transaction SE11. For example, copy a customer view
BIW_KNA1 to BIW_KNA5. Here you define additional fields
in a new view.

2. Change the structure in table RODCHABAS using

transaction SE16. Select a master data object, such as
0CUSTOMER, and change its default BIW_KNA1 view with
BIW_KNA5.

3. Using transaction SE38, execute program RSAO003 to

assign new fields to the InfoObject.

4. Add this new InfoObject in the InfoSource so the receiving

SAP BW knows the new metadata.

5. Go back to SAP BW and upload new metadata, as shown

in Figure 13-5.

Team-Fly
Team-Fly
Extending Texts InfoSource
For master data text elements, text extractors have a fixed generic
transfer structure for text called RSTEXTTRSF. To fill this structure
with new text elements, you need to use EXIT_SAPLRSAP_003.
One of the export parameters of this function module is C_T_TEXT.
This is an internal table that has formatted text data. You change the
fields in this internal table to add new text.

Team-Fly
Team-Fly
Debugging Data Extractors
Debugging a data extractor is tricky. Because extractors run as
background tasks, users cannot set breakpoints to debug the code.
You need to add an endless loop in the data extractor code. When
SAP BW schedules this job to extract data from SAP R/3 OLTP, the
data extractor code goes in an infinite loop. You log on to the SAP
R/3 instance under the same user name being used to extract data,
usually ALEREMOTE. Here are the steps to debug data extractors:
1. Create an endless loop inside the user-exit as shown here:
DATA: DEBUG_FLAG.
DO.
IF DEBUG_FLAG = 'X'.
EXIT.
ENDIF.
ENDDO.

2. Schedule an InfoPackage to start data extraction from the

SAP BW scheduler.

3. Log on to the SAP R/3 OLTP instance where the extraction

job will be running in an infinite loop. Using transaction
SM50, identify a job running under the user ALEREMOTE.

4. While in the SM50 process monitor window, select the job

and click the Debugging button. This puts you in debugger
mode.

5. Set DEBUG_FLAG to X and continue the typical ABAP

debugging process.

Note that the user who is debugging extractors requires special

development and debugging authorizations in the source system and
not in SAP BW.
Team-Fly
Team-Fly
Summary
In this chapter, you learned the basics of the data extraction process.
To actually code a high-performance data extractor requires good
design strategies and understanding of ABAP programming skills.
However, this chapter provides you with sufficient understanding of
how to enhance transaction business content and use generic data
extractors to extract master data elements from the SAP R/3 OLTP
instance. The next chapters describe how to design data loads from
non-SAP data sources.

Team-Fly
Team-Fly
Chapter 14: Integrating Third-Party ETL
Products with SAP BW
In this Chapter
In earlier chapters, you learned that SAP BW loads data from SAP
R/3 and flat files using IDOCs or tRFCs. In this chapter, you learn
about other methods to load data that resides in SAP R/3 or non-
SAP applications; you learn how to load data directly from data
sources such as Oracle, Microsoft SQL Server, or flat files. You also
learn how to implement a third-party tool to load data in SAP BW.

Team-Fly
Team-Fly
SAP BW Data Load Interfaces
It is a well-known fact that enterprise data warehouses source data
from several corporate transaction systems. This means that an
enterprise data warehouse must provide services that enable
customers to integrate heterogeneous data sources in a seamless
fashion. To make this happen, SAP BW (beginning with release 1.2x)
provides a collection of Business Application Programming
Interfaces (BAPIs) to facilitate integration of non-SAP R/3 data in
SAP BW. Such BAPIs are called Staging BAPIs. The reason for
calling such BAPIs Staging BAPIs is that their scope is limited to the
Staging engine layer of SAP BW, as shown in Figure 14-1.

Figure 14-1: SAP BW

Data Loading and Data Access Interfaces.

Producers of several data warehouse construction tools have

implemented Staging BAPIs to extract data from data sources (SAP
R/3 or non-SAP R/3) and load directly in SAP BW. At the time of this
writing, several vendors have been certified as providers of Staging
BAPIs (refer to Table 3-1 in Chapter 3).

Staging BAPIs make SAP BW open to load data from just about any
data source. SAP also provides BAPIs and the Microsoft OLE DB for
OLAP (ODBO) interface to access data from SAP BW. The data
access BAPIs and ODBO are public APIs, and several data access
vendors have implemented interfaces to SAP BW that complement
SAP BW BEX reporting capabilities. Refer to Table 3-2 in Chapter 3
for a list of vendors that are ODBO certified. Chapter 15, "Integrating
Third-Party Data Access Products with SAP BW," focuses on third-
party data access tools to access data from SAP BW.

Note Built-in data loading interfaces in SAP BW, flat files, and
Staging BAPIs enable you to load master and transaction
data. However, with Staging BAPIs you can also load
metadata of incoming data objects and dynamically
connect to external applications, eliminating the need for
scheduling and preparing flat files.

Staging BAPIs for SAP BW

Before learning how Staging BAPIs work, first look at SAP BAPI
technology. BAPIs were first made available to customers with
release 3.1 of SAP R/3. BAPIs expose SAP R/3 business
functionality through business objects. The SAP Business
Framework provides an open object-oriented component-based
architecture that enables software components from SAP and other
vendors to interact and integrate with each other. Such objects are
called SAP business objects. All SAP business-object types and
their methods are defined and described in the Business Object
Repository (BOR). SAP business objects are accessed through
BAPIs. SAP business objects and their BAPIs provide an object-
oriented view of SAP R/3 business functions.

You need a good understanding of object-oriented programming to

access SAP business objects using BAPIs. You can use Microsoft
Visual Basic, Microsoft C++, Java, or ABAP languages to develop
applications using BAPIs. However, to access BAPIs external to SAP
R/3 instances, you need to program BAPIs using the Remote
Function Call (RFC) protocol. You need a good understanding of
distributed application design and RFC programming skills to call
BAPIs external to SAP R/3.
 Note To learn more about how to access BAPIs or create new
BAPIs, consult the BAPI User Guide and BAPI
programming documents that are part of the standard SAP
help documents. These documents provide you with all the
details, with examples, on how to work with BAPIs.

I also recommend an excellent book on the subject, Prlma

Tech's Java & BAPI Technology for SAP by Ken Kroes and
Anil Thakur.

To implement a data loader, third-party vendors develop an RFC

Server (process) that manages connections between the data
warehouse construction tools and SAP BW. It is important that RFC
Server developers are extremely experienced with the distributed
computing model to implement high-performance data streams
between data sources and BW using the RFC protocol.

In SAP BW 1.2B (Patch 12), eight staging business objects are

registered in BOR as shown in Table 14-1. However, in BW 2.0A, no
new staging business objects are in BOR. Most staging business
objects are either modified or enhanced (new methods and/or
interfaces) to accommodate new functionality due to changes in
metadata, master data structures, and ODS data management.

Table 14-1: Staging Business Objects in SAP BW 1.2B and

2.0A
Object
Business Object
Name in Description
Name
BOR
Properties and
BUS6101 SourceSystem methods of a source
system
Object
Business Object
Name in Description
Name
BOR
Properties of an
BUS6102 InfoSourceTrans InfoSource for
transaction data
General properties of
BUS6103 InfoSourceMaster an InfoSource for
master data
Source-system-specific
properties of an
BUS6104 InfoSourceMasterXfer
InfoSource for master
data
Properties for
BUS6105 InfoSourceHirchyXfer hierarchies of a master
data InfoSource
Source-system-specific
properties of an
BUS6106 InfoSourceTransXfer
InfoSource for
transaction data
Properties and
methods of a data
BUS6107 DataProvider request to a source
system (removed in
BW 2.0A)
Properties and
BUS6108 InfoObject methods of an
InfoObject

Note To list staging business objects in an SAP BW Instance,

execute transaction SWO1. Enter BUS6* in the
 Object/Interface Type field and click the down arrow. This
will list all staging business objects in BOR. To list
interfaces associated with these business objects, execute
transaction SWO1, enter IF*, and click the down arrow.

To list methods for business objects, use the BAPI Browser

(transaction BAPI). This lists all BAPIs and published
methods for individual business objects.

To list function modules associated with individual business

objects, use transaction SE80. Look in function groups
RSAB and RSODS. These function groups contain all
function modules associated with staging BAPIs.

Using Staging BAPIs to Architect Data Loader for SAP

BW

As mentioned earlier, one must have a good understanding of object

technologies and good development skills in distributed service-
centric software design. Typically, the exchange of data with the
source system happens in a two-step process.

The first step is to read metadata of InfoSources defined in SAP BW.

The second step is to use this metadata information to extract data
from the source system and send it to SAP BW.

Metadata Management
Figure 14-2 illustrates the mapping of extracted data against the
transfer structure of an InfoSource defined in SAP BW. Note that this
applies to transaction data as well as master data attribute
InfoSources.
 Figure 14-2: SAP BW Metadata Management Process using
Staging BAPIs.

The source system calls the GetList method of an InfoSource to get

a list of available InfoSources from SAP BW. Depending on how a
third-party application is implemented, it may present this list in a
dialog box and have the user select an InfoSource to map it to the
extract structure of inbound data. This mapping process is based on
the transfer structure definition, which can be retrieved from SAP BW
by calling the GetDetails method associated with the InfoSource.

Extract and Send Data to SAP BW

Once the metadata and transfer structure are captured in the
repository of third-party tools, the next step is to actually extract data
from the data sources, perform mapping and transformation, and
send extracted data to SAP BW, as shown in Figure 14-3.

Figure 14-3: SAP BW Data Loading Process using Staging

BAPIs.

Let's look at the sequence of BAPI methods needed to complete the

data loading process. The data request is initiated by the BW
scheduler to request a list of parameters, such as user name and
password, needed to start the extraction process in the source
system. This is achieved by calling the GetParameterDefinition
method of the Data Provider business object.
The scheduler then sends a data request by calling the
SendRequest method of the Data Provider business object. Part of
the request is the values of the requested parameters, selection
criteria, and request details such as a unique request ID, name of
the corresponding InfoSource, and so on.

It is possible that the InfoSource definition in SAP BW may have

changed, but such changes may not have been updated in the third-
party metadata repository. To make sure that the extract structure
exactly matches the current transfer structure, the source system
has to call the GetDetails method of the requested InfoSource to get
the current transfer structure.

Extracted data can then be sent to SAP BW by calling the SendData

method of the requested InfoSource. The SendData method
supports sending any number of records per call with each call
defining a data packet. However, it is recommended to send about
10,000 to 100,000 records per call.

Note At present, the individual record size is limited to 1,000

bytes regardless of whether data is stored in ODS or
InfoCubes.

Team-Fly
Team-Fly
Implementing Informatica's PowerCenter to Load
Data in SAP BW
As stated previously, SAP has certified data warehouse products from several
data warehouse vendors to load data in SAP BW using Staging BAPIs. I
implemented solutions using products from Acta Technology, Hummingbird,
and Informatica Corporation that extracted data directly from an Oracle (Siebel)
database and a Financial Analysis data mart in Microsoft SQL Server to
populate InfoCubes in SAP BW. Each product that I worked with has its own
strengths and limitations.

Note In this chapter, I use PowerCenter from Informatica Corporation to

demonstrate Staging BAPI implementation. This demonstration is not
to be considered an endorsement or recommendation for Informatica
products or other vendors. Appendix A, "Data Warehouse Industry
References and SAP BW Training," provides information on products
from Acta Technology, Hummingbird, and Informatica.

Informatica Corporation is a leading data warehouse construction tool vendor.

PowerCenter 1.5 is an enterprise data integration hub that enables large
organizations to transform legacy, relational, and ERP data into reliable
information for strategic business analysis. The Integration Server for SAP BW
uses SAP BW Staging BAPIs to load data in SAP BW. Though Informatica
provides several components to support a wide range of data sources and
targets to construct a data warehouse (see details in Appendix A), the following
section describes only how to use PowerCenter 1.5 Integration Server to load
data in SAP BW 1.2A and 1.2B.

Though you can install PowerCenter Designer, Repository, and Integration

Server on UNIX or Windows NT servers, for this example, I've installed all
PowerCenter components on one Microsoft Windows NT 4.0 server. The
repository was based on Microsoft SQL Server 6.5. This NT server had 256 MB
RAM, 266 MHz dual Intel processor, and SAP GUI 4.5 full-development
environment.

Figure 14-4 shows components of Informatica's Integration Server environment

for SAP BW.
 Figure 14-4: Components of
PowerCenter Integration Server for SAP BW.

Implementing data loads in SAP BW is a four-step process, as listed here:

1. Create third-party data source specific definitions for Informatica
PowerCenter in SAP BW.

2. Define RFC connection in SAP BW for Informatica PowerCenter and

create and define data extraction and load scheme.

3. Connect the PowerCenter Integration Server to SAP BW.

4. Load data in SAP BW.

Create Data Source Definitions for PowerCenter in SAP BW

To create a new data source definition in SAP BW, select the Source systems
tab in the Administrator Workbench (see Figure 14-5). Then right-click Source
systems and select Create Source System.

Figure 14-5: Defining Informatica PowerCenter as Data Source Provider in

SAP BW.

From the Select Source System Type option, select Ext.System, data and
metadata transfer-staging. Then enter the source system and its description, as
shown in Figure 14-6. In this example, a source system named PC_SOURCE
is used to get data from PowerCenter. After entering source information, click
the Check button.

Figure 14-6: Creating the Source System in SAP BW.

Defining an RFC Connection in SAP BW for Informatica

PowerCenter

The next step in completing the external data source definition is to set up an
actual RFC connection definition. SAP provides several connection types to
access remote programs; but for SAP BW Staging BAPIs implementations of
Informatica PowerCenter, use connection type T and start an external program
via TCP/IP.

When you click the check mark button, shown in Figure 14-6, the system opens
an RFC destination definition window, transaction SM59. Enter a textual
description for this connection definition. Enter Program ID as PC_SRC. SAP
BW uses this program ID to communicate with the PowerCenter Integration
Server for SAP BW. The RFC destination definition process is the same in both
BW 1.2B and BW 2.0A.

Note Notice that the program ID is case sensitive, and the value you enter
must be the same value you enter in the SAPRFC.INI file used by the
PowerCenter Integration Server.

As of SAP R/3 release 3.0D, an RFC server program, for example,

PowerCenter Integration Server for SAP BW, can be registered with the SAP
gateway and wait for incoming RFC requests.

After entering the program ID PC_SRC, click the Registration button, shown in
Figure 14-7. Registering means telling the SAP RFC gateway that an external
program, PC_SRC, will communicate with SAP BW.
 Figure 14-7: Establishing the RFC Definition for the PowerCenter
Environment for SAP BW.

You can actually verify this remote connection by clicking Test connection, as
shown on the top left of Figure 14-7. However, at this stage it will give you a
connection error because the PowerCenter Integration Server for SAP BW has
not been started. I discuss this process in the next section.

This test connection option is a good way of resolving any connection or

networking-related problems. Results of the Test connection option show how
long SAP BW takes to communicate with the external program, in this case,
PowerCenter Integration Server. If connection time is less than 20 milliseconds
(see Figure 14-8), your data transfer will be acceptable. Otherwise, check with
the networking team to reconfigure the remote server so it has fewer hops to
speed up the network level connection between the SAP BW server and the
PowerCenter Integration Server.
 Figure 14-8: Testing the Connection between SAP BW and the
PowerCenter Integration Server for SAP BW. Connection Time is in
Milliseconds.

After defining this data source in SAP BW, the rest of the process using a data
source is the same as if data were coming from SAP R/3 OLTP. For testing
purposes, create an InfoSource for transaction and master data, assign
PC_SOURCE as a data source, and define transfer and communication
structures. Only the transfer structure for Active InfoSources will be visible in
PowerCenter as one data target per InfoSource.

Connecting the PowerCenter Integration Server to SAP BW

To establish a connection from the PowerCenter Integration Server to SAP BW,

you need to define the SAP BW source definition in the SAPRFC.INI file. This
file usually exists in the Windows NT system directory, C:\WINNT\SYSTEM32.
The SAPRFC.INI file has the following parameters per data source:

DEST: A Destination identifier (or logical name) for a data source/target

that will be used in the PowerCenter repository to connect to a data
source/target.

TYPE: Identifies the connection type. Here set it to R, meaning an RFC

connection. Details on connection types and an example of
SAPRFC.INI are provided in Appendix B, "SAP BW and SAP R/3
Transactions, Tables, and Code Examples."

PROG_ID: The program ID; here you use PC_SRC as the program ID.

ASHOST: Host name or IP address of the SAP BW application server.

 SYSNR: SAP R/3 (BW) system number.

If you need to connect to multiple SAP R/3 or SAP BW data sources, you need
to define additional destinations in the SAPRFC.INI file. For example, the
SAPRFC.INI file to connect the SAP BW instance has the following
parameters:
/*=========================================*/
/* SAPRFC.INI file for Integration Server */
/* The IP addresses are dummy addresses */
/*=========================================*/
/* Type R: Register an RFC server program at an SAP gateway */
/* or connect to an already registered RFC server program */
/* The PowerCenter Integration Server for BW uses */
/* this information */ */
/*============================*/
DEST=BWSERVER
TYPE=R
PROGID=PC_SRC
GWHOST=12.30.0.20
GWSERV=sapgw00

Note After developing SAP BW loading schemes in PowerCenter, you must

make sure that such interfaces work against test BW instances before
going live in production. This is done by simply changing the IP
address of the target SAP BW instance in SAPRFC.INI that points to
the target BW instance (development, test, and production). Never
change the DEST name in the SAPRFC.INI file after defining a data
extraction scheme in PowerCenter for a specific InfoSource. The
PowerCenter repository stores the DEST name in its repository and
not the IP addresses. The DEST name in SAPRFC.INI is similar to
the logical data source name in SAP BW.

Importing the SAP BW InfoSource in PowerCenter

Before importing data in SAP BW using InfoSource TESTPC, you need to
define the data sources and data target in the PowerCenter Designer to define
the mapping and transformation needed before loading in SAP BW.

In this example, a flat file is used as the data source that contained product
royalty data. Using the PowerCenter Warehouse Designer tool, define the
Royalty file structure and import metadata of activated InfoSources, as shown
in Figure 14-9.

Figure 14-9: Importing InfoSource Metadata From SAP BW into a

PowerCenter Repository as the Target Data Source.

When you select Import From SAP BW, you are asked to enter SAP BW logon
information. The connect string is actually the destination value of SAP BW, as
defined in the SAPRFC.INI file-in this case, BWSERVER, as shown in Figure
14-9. After successful logon to SAP BW, you see a list of transfer structures of
active InfoSources. Now you simply drag and drop transfer-structure definitions
into the Targets folder of the ROYALTY project. The dotted line shows the drag-
and-drop path. Repeat the same process to import additional InfoSources, if
any, and save the project.

After defining data sources and targets in PowerCenter, the next step is to
define mapping and transformations. It is here you build field-level relationships
between data sources and targets. To do so, click the Mappings folder in the
project tree and create a new mapping scheme; for example, MappingtoBW.
Then drag and drop sources and targets in the mapping work area.
PowerCenter automatically relates fields between sources and targets using
the field-ordering scheme. If this is not what you need, you can build your own
field mapping by simply linking a source field to a target field of your choice, as
shown in Figure 14-10. Behind each link, you can define several methods to
cleanse, compute, or convert data for your target source.
 Figure 14-10: Defining Source to Target Data Mapping and Transformations
in PowerCenter.

It is important to note that PowerCenter will do needed data type conversions

for the target data sources. For more information on how PowerCenter handles
and converts SAP BW data types, look in the Informatica documents on the
CD-ROM accompanying this book.

Defining an SAP BW Connection in the PowerCenter Server

Manager
Due to the distributed deployment architecture of Informatica products,
individual components were designed to have their own repositories. However,
when all such components share one repository, you still need to redefine the
database connection scheme for individual components. In the future,
individual component management logic may change so that when an entity
has been defined in the repository, it is automatically available to other
components.

The previous section defined the SAP BW connection for the PowerCenter
Warehouse Designer. Now you need to redefine the same SAP BW connection
for the PowerCenter Server Manager. It is here that you define ETL jobs, called
sessions. These sessions are called from the SAP BW Scheduler to do data
extraction/transformation and to ship the transformed data to SAP BW.

From within the PowerCenter Server Manager menu, select the Connect to
Repository option and choose the Server Configuration-Database Connection
option. Then add SAP BW as target database BWSERVER, add the DEST
parameter value in SAPRFC.INI as a data source, and save the definition. Now
PowerCenter Server Manager knows all the registered data sources and
targets. However, to define the data extraction scheme, you need to associate
a session to a specific data transformation or mapping scheme. This is done in
the PowerCenter Server Manager.
First you connect to a repository from the Server Manager main menu and
choose Operations-Add session. There you enter the mapping name, for
example MappingtoBW. Save this session information and remember the
session name; for example, s_S260File_Mapping. You will need this session
name to schedule this job from SAP BW. All defined sessions are listed in the
Organizer window, as shown in Figure 14-11.

Figure 14-11: PowerCenter Server Manager, Used to Define Sessions and

to Monitor and Control Jobs.

Here the Session Wizard asks a few more questions on how and where to
execute this session. Enter the server name on which you want to run this job,
as well as the target data source. For SAP BW, select the data target type as
ERP and select the data processing mode as INSERT rows. This completes
the session definition.

Loading Data in SAP BW

Scheduling and loading data is done from within an SAP BW instance.

PowerCenter Server Manager is capable of starting data extraction jobs, but
when the data target is an SAP BW instance, you cannot start sessions from
the PowerCenter Server Manager. You launch such sessions only from within
SAP BW via the PowerCenter Integration server for SAP BW. You can,
however, stop or monitor active jobs from the PowerCenter Server Manager
when they are in progress.

Loading data in SAP BW is a two-step process, as listed here:

1. Start PowerCenter Integration Server for SAP BW.

2. Schedule data load jobs from SAP BW Scheduler.

Start PowerCenter Integration Server for SAP BW

This integration server is a Staging BAPI Listener. It is started on a Windows
NT 4.0 server. SAP BW Scheduler sends a job startup request to the
PowerCenter Server Manager for a specific saved mapping. Figure 14-13
shows how SAP BW Scheduler and PowerCenter Integration Server exchange
BAPI calls to process external data.

To start the PowerCenter Integration Server, you need to know the SAP BW
destination and the PowerCenter Repository user name and password. Figure
14-12 shows the command line interface to start the PowerCenter Integration
Server on Windows NT 4.0. BWSERVER is the SAP BW destination defined in
SAPRFC.INI; pmrepo is the repository name and password followed by the
TCP/IP port number for this listener. Once started, PowerCenter Integration
Server waits to receive requests from SAP BW.

Figure 14-12: Starting the PowerCenter Integration Server for BW.

Schedule Data Load Jobs From SAP BW Scheduler

To schedule a data load import, first create an InfoPackage request against the
InfoSource. Then schedule the InfoPackage.

The only difference in the SAP BW Scheduler definition is that you will see a
new tabstrip called 3rd Party selections, as shown in Figure 14-13. This shows
only when the InfoSource is based on Staging BAPI implementation of third-
party ETL tools.
 Figure 14-13: Scheduling Data Import Jobs From SAP BW.

Select the 3rd Party selections tabstrip. Enter the session name you have
defined in the PowerCenter Server Manager for specific data mapping and
transformations. Remember that you created a session called
s_S260File_Mapping in an earlier session. Enter this session name in the value
field, as shown in Figure 14-13.

Now schedule this job in SAP BW. The Scheduler connects to the PowerCenter
Integration Server and hands over the session name. The PowerCenter
Integration Server then starts the session, s_S260File_Mapping, on the server
as defined in the PowerCenter Server Manager. After data transformations,
PowerCenter sends data to SAP BW. The data is processed in SAP BW as
methods defined in the transfer rules or as defined data targets-ODS,
InfoCube, or both-during job scheduling in SAP BW.

While this job is in progress, you can monitor the data transformation status
from the PowerCenter Server Manager, as shown in Figure 14-12. To monitor
data load activity in SAP BW, use a typical InfoPackage Scheduler Monitor to
see the number of data load activities.

Other Third-Party Staging BAPI Implementations

In general, all SAP BW-certified vendors work the same-that is, they support
the Staging BAPI Listener; SAP BW triggers data extraction jobs, and the tools
send data back to SAP BW and to an InfoSource. However, they do differ
based on algorithms to process data using proprietary technologies.
Each product has strengths and weaknesses. For example, ActaWorks from
Acta Technology and Genio from Hummingbird provide robust integration with
SAP BW. The Genio engine provides a fast data load technology, and
ActaWorks seems to be very easy to implement and support in production and
has an excellent data extraction environment for SAP R/3. Information on other
products that load data in SAP BW is available on the accompanying CD-ROM.

Team-Fly
Team-Fly
Summary
Third-party data extraction tools play a key role in implementing SAP
BW-based global data warehouses when you need to source data
from SAP R/3 and non-SAP applications. This chapter described
how SAP BW Staging BAPIs load data. PowerCenter integration with
SAP BW gives you sufficient information on steps needed to
implement this tool.

Note that before implementing a third-party tool with SAP BW, a

careful analysis of individual tools must be done. Ask vendors how
they perform data transformation specific to SAP BW, manage
change capture, access SAP R/3 and non-R/3 data sources, capture
and manage metadata, and handle large data volumes. These are
just a few questions to ask. I highly recommend that you do a
conference room pilot to really evaluate if the selected tool is right for
your production environment. Verify that the tool can load large data
volumes in SAP BW in a time that meets your SAP BW production
operations and not just a demo or test environment. While this
chapter focused on third-party data loading tools, the next chapter
describes how third-party tools access data from SAP BW.

Team-Fly
Team-Fly
Chapter 15: Integrating Third-Party Data
Access Products with SAP BW
In this Chapter
In Chapter 14, you learned how third-party tools are integrated with
SAP BW to import data. In this chapter, you learn how third-party
reporting tools access data from SAP BW. You also learn how
Microsoft OLE DB for OLAP, an industry-recognized standard for
multidimensional data access, is used and how it compares with
SAP BW OLAP implementation.

Team-Fly
Team-Fly
Data Access Interfaces for SAP BW
In release 1.2 of BW, SAP provides two native tools to distribute and
access data from SAP BW. These tools, Business Explorer Browser
and Business Explorer Analyzer, work fine when end-users'
analytical needs can be satisfied using the Microsoft Excel
environment. The SAP BW add-in for Microsoft Excel adds data
slicing-and-dicing capability that exploits such SAP R/3 features as
multi-language support, multi-currency conversions, and complex
result-set data structures that are not available in pure Microsoft
Excel. However, when you need to design a sophisticated analytical
application, it takes a lot of time and effort to make a Microsoft Excel
workbook-centric solution to drive analytical processes through
event-driven control objects, such as menus, buttons, list boxes, and
Windows events that third-party OLAP tools provide.

The present release of SAP BW 1.2B does not provide tools to

implement pure Web-based applications. However, a few third-party
tools can use ODBO to build and deploy pure Web-centric analytical
applications against SAP BW and other data sources.

Selecting a third-party data access and reporting tool for SAP BW is

a complex process. Not all users have the same data access and
reporting needs. For example, financial analysts may feel very
comfortable working with BEX Analyzer because it is similar to a
spreadsheet. On the other hand, the manufacturing operations staff
may not feel comfortable working with Excel because they are used
to a screen-centric solution to specify query-selection parameters
using several drop-down list boxes and a printed report with specific
formats and page breakdown. Building such solutions in a Microsoft
Excel environment takes a lot of time. Several third-party data
access and reporting tool vendors provide good alternatives to BEX
Analyzer. The rule of thumb is to first use BEX Analyzer as much as
possible; if your company has already selected standard corporate-
wide data access and reporting tools, make sure that the tools
provider has been certified for ODBO interface for SAP BW.
In version 2.0A of SAP BW, you can publish BEX queries, using SAP
BW Web Publisher Wizard, on a Web server in HTML format. The
published queries are dynamic. You can drill down or refresh data
from the Web browser. In SAP BW 2.0A and 2.0B, you still have to
have BEX Analyzer to compose basic queries and then publish on
the Web. SAP is planning to deliver a pure Web-reporting
development environment for SAP BW starting with the release of
BW 2.0B after its general availability. This Web development
environment for SAP BW will exploit the SAP Internet Transaction
Server (ITS) as the SAP BW Web server. For more information on
SAP BW Web reporting, see Appendix D, "Key Enhancements in
SAP BW 2.0."

Team-Fly
Team-Fly
SAP BW Open Data Access Strategy
To provide open access to third-party reporting and analytical applications, SAP
has adopted Microsoft's standard for multidimensional data access, OLE DB for
OLAP, or ODBO. Though ODBO is a widely accepted standard, when you take a
close look at the specifications, it is very specific to Microsoft Plato OLAP server
technology. Therefore, you will notice later in this chapter that there are some
distinct differences between Microsoft and SAP BW ODBO implementations. The
BW ODBO implementation is based on release 1.0 of Microsoft's OLE DB for
OLAP Programmer's Reference of February 1998. This document is available at
the Microsoft Web site, http://www.microsoft.com/data/.

OLE DB for OLAP Architecture (ODBO)

Unlike Microsoft Open Database Connectivity (ODBC), which was implemented to

access universal relational databases, the ODBO standard is designed to handle
data from multidimensional data sources. The ODBO standard does not, however,
specify how data is physically stored. Data may be stored in a relational database,
such as SAP BW, or in a proprietary multidimensional structure, such as Microsoft
Plato OLAP Server or Oracle Express. Figure 15-1 shows ODBO architecture and
implementation components. ODBO is a set of Microsoft Component Object Model
(COM) objects and interfaces that extend OLE DB, Microsoft's universal data
access framework, for multidimensional data.

Figure 15-1: The ODBO Architecture

and its Implementation in SAP BW.

At the application-server level, when an end-user data request is received, the

OLAP API identifies the request origination type. When BEX Analyzer originates a
request, it is directly handed over to the OLAP processor. However, when a query
is issued over ODBO, the ODBO layer at the application server first parses the
Multidimensional Expression (MDX) statements to SQL statements that are
recognized by the OLAP processor and then hands over the incoming request to
the OLAP processor (the next section describes MDX syntax and grammar).
Because this is an extra step in query processing, ODBO-based queries tend to be
slower than BEX Analyzer queries.

ODBO supports MDX, which is similar to SQL but incorporates multidimensional

grammar, as shown in Figure 15-2.

Figure 15-2: A Multidimensional Statement Syntax, Actual Query, and Results.

Figure 15-2 shows the syntax of a simple MDX statement. To describe this syntax,
the example shows the results of the query. Notice that ODBO lists data in
crosstab format, which is ideal for OLAP operations. Streams of several MDX
statements are used for complex data analysis. For details on ODBO and MDX,
visit the Microsoft Web site at http://www.microsoft.com/data/oledb/olap and
http://msdn.microsoft.com/library/techart/intromdx.htm.

Note Though it is commonly known that MDX means multidimensional

expression, in reality it is called multidimensional extensions. It is called
an extension because MDX extends relational SOL statements to a
multidimensional view of data using statements similar to SQL
statements.

As stated earlier in this chapter, ODBO very much reflects the Microsoft OLAP
server architecture. Therefore, differences between ODBO object definitions and
SAP BW objects are expected. Figure 15-3 shows ODBO equivalent objects in
SAP BW.
 Figure 15-3: SAP BW Objects versus ODBO Schema Objects.

According to ODBO specifications, a schema is composed of a set of cubes. A

collection of schemas constitutes a catalog. A cube is defined as a set of
dimensions, and each dimension has properties. Dimensions can be rolled up and
down along associated hierarchies. The hierarchies have levels that have one or
more members. This simply describes ODBO at a higher level. For additional
details on ODBO specifications, visit the Microsoft Web site at
http://www.microsoft.com/data/doc.htm.

In SAP BW, a query object is equivalent to a cube in ODBO. This is somewhat

inconsistent because a query usually is a subset of an InfoCube. When end users
access SAP BW from third-party tools through ODBO, they see only query
metadata and not the actual InfoCube. This limits the design of the analytical
application against full SAP BW cubes. You can define all dimensions and key
figures in a query against an InfoCube. Then third-party tools access this query,
using ODBO to develop applications. This choice will degrade SAP BW
performance because all ODBO users will have their own copy of the entire
InfoCube at the application server. This is not acceptable.

Moreover, ODBO implementation in SAP BW does not support complex structures

and variables defined in a BEX query. You should also limit data aggregation in the
BEX query because end users might want to slice and dice data differently and
need raw instead of summarized data. For this reason, you must design special
BEX queries that generate raw, flat data for the tool. By doing so, you will have a
large amount of data flowing to the end user; that could cause networking
problems. Therefore, you need to model ODBO queries very carefully, knowing the
limitations of ODBO and how performance impacts query execution and data
delivery.
Not all queries defined in BEX Analyzer are visible to ODBO. To make a query
visible to ODBO, you must check the ODBO option in the Query properties dialog
box, as shown in Figure 15-4.

Figure 15-4: Enabling a BEX Analyzer Query to be Visible to the ODBO

Consumer.

Team-Fly
Team-Fly
Installing ODBO Components at the Client
Workstation
To access SAP BW through ODBO, you need to install the following
components on the desktop computer.

Mdrmsap.dll. The client component of the SAP BW OLE DB

provider.

Sapdialog.dll. Dialog for prompting the user for SAP BW

connection parameters if not specified by the client
application.

Scerrlkp.dll. Error-handling routines.

Mdxpars.dll. Multidimensional Expression (MDX) parser

routines.

Librfc32.dll. SAP RFC library.

Msdadc.dll. A component from Microsoft OLE DB required

by mdrmsap.dll.

Saprfc.ini. RFC connection parameter file.

Prior to SAP BW 1.2B, the OLAP provider needed to be manually

registered on the client workstation: Windows 95198 and Windows
NT 4.0. Today users can select the ODBO provider option during
SAP GUI installation. The installation process registers needed
objects, as shown in Figure 15-5. Note that the SAP BW OLE DB for
OLAP provider is registered under the name mdrmsap. Because you
need to register objects at the client workstation, you must have
administration rights on the workstation.
 Figure 15-5: Installing
ODBO Components at the Client Workstation.

Like Staging BAPIs, the ODBO interface reads the saprfc.ini file to
select the destination, the connection type, and all RFC-specific
parameters needed to connect to the SAP BW server, as shown
here:
SAPRFC.INI
/*================================================*/
/* Type A: A sample saprfc.ini file for inSight software from arcplan
*/
/*================================================*/
DEST=BW
Type=A
ASHOST=12.12.0.12
SYSNR=00
RFC_TRACE=
ABAP_DEBUG=0
RFC_DEBUG=
USE_SAPGUI=0

Team-Fly
Team-Fly
Accessing Data From Third-Party Tools
SAP has certified several data access products that use the ODBO
provider to access data from SAP BW. For demonstration purposes,
I have used inSight version 2.3.5 from arcplan. You will find product
information on the CD-ROM accompanying this book or at
http://www.arcplan.com.

I've used this product to demonstrate the steps needed to use

ODBO from third-party data access tools as well as to construct a
pure Web-centric, ActiveX control-based SAP BW reporting
environment.

Setting up the inSight Development Environment

Figure 15-6 shows the needed components to develop and deploy

inSight applications. On the right side are two data access
workstations: a typical workstation to run the inSight application that
uses RFC, and a light client that uses an Internet browser such as
Microsoft Internet Explorer.

Figure 15-6:
Components of Arcplan inSight Version 2.3.5 to Design Pure
Web-Centric Applications against SAP BW.

The two workstations in the middle represent the inSight application

development workstation and the Web server to use to publish
generated applications. During the inSight development phase, the
development server and Web server could be one Windows NT 4.0
server. However, you should consider a standalone Windows NT 4.0
server to publish inSight applications. You need to install and
configure the inSight Web server component and service as shown
here:

inSight DBweb Connector: c:\Intetpub\Scripts

inSight Service: c:\inSight\Service

ActiveX Control Directory: c:\Inetpub\wwwroot\inSight

The inSight Web server needs this information to route end-user

requests to the requested application and SAP BW server. You set
up these directories during the installation process. However, if you
decide to change this environment, you can always reconfigure
these paths without re-installing the Web server.

Before installing inSight software on the development workstation,

install the SAP BW 1.2B frontend client with ODBO providers, as
shown in Figure 15-5. Then install the inSight development
environment.

Note If you are working with SAP BW 1.2A, you need to copy
ODBO-specific DLLs, most often in the WINNT\SYSTEM32
directory, or as recommended by arcplan. You also need to
register ODBO DLLs manually.

You need to edit the saprfc.ini file on the workstation and the Web
server for the target SAP BW server used by the inSight application.

Building an inSight Application

Before you create an application, you need to connect to a data

source. Here you define the SAP BW application server as a data
source (DEST) in saprfc.ini, as described earlier in this chapter.
After launching inSight, open the Database window and click a new
icon to create a new application data source, as shown in Figure 15-
7. Here you are asked for the type of data source to use. Select SAP
BW for this example.

Figure 15-7: Building an Application using inSight 2.3.5; Defining

a New Connection to the SAP BW Data Source.

Note Note that inSight can access several data sources,

including SAP R/3 and SAP OIW. This enables inSight to
build highly summarized analytical applications, Executive
Information Systems, but with an option to drill down to
transaction systems for the latest detailed information.

When you select the SAP BW data source, Step 1 in Figure 15-7,
you need to provide SAP BW login information, Step 2 in Figure 15-
7. The data source is actually the DESTination parameter value of
TYPE=A from the saprfc.ini file.

After successful logon to SAP BW in Step 3, inSight fetches all query

cubes that have been released for OLE DB for OLAP (see Figure 15-
4), as shown in the bottom right of Figure 15-7. This is done by using
BW OLAP API function calls. As a result of Step 2, a connection
definition file named BW.isc is created.
The name is BW because the DEST used for this connection is BW
in the saprfc.ini file. The name of the connection file will be the DEST
name you decide to use. You need this application connection
definition file to copy and distribute applications to other workstations
or to the Web server. Another file, BW.isr, has the repository
information for this data source. The files bw.ic_ and bw.ir_ are
compressed versions of the connection and repository information
files. These compressed files are good for Web applications.

When you select a cube in the inSight Database window, inSight

displays its cube dimensions and key figures in a tree format, as
shown in Figure 15-8. Now you are ready to create your first
application, product sales analysis by distribution channels.

Figure 15-8: Building a Sales Analysis Analytical Application in

inSight.

To build this simple analytical application, simply drag and drop the
menu, column, row, and table chart object in the new inSight
document. The placement of such objects is shown as numbers 1, 2,
3, 4, and 8 in Figure 15-8.
Next, you need to associate empty objects with cube dimensions
and key figures. Now you drag and drop appropriate dimensions and
key figures in the drawn-up objects, as shown in Figure 15-8 by
numbers 5 through 7; for example, in Step 5, you drag and drop the
Material dimension on the Material column object in the application.
The inSight application will automatically load data from SAP BW.
The distribution channel menu object lists all distribution channels,
and the Material column displays all products. This is not what you
want. You want to show all products and revenues for a selected
distribution channel. To do so, inSight provides a tool that builds
dependency relationships between the objects.

Defining dependency rules is an easy process. You simply draw lines

from and to data objects to describe the parent-child relationship.
You can also define filters or qualifiers for such links. A simple
example in Figure 15-9 shows an arrow pointing to Material from the
distribution channel object.

Figure 15-9: Building an inSight Analytical Application; Defining

Data Dependency Relationships among Selected Data
Objects.

This indicates to show only those products that are ordered by a

selected distribution channel. The table object has two arrows:
Material and Sales revenue. This means to list product revenues for
the corresponding products that are associated with a selected
distribution channel. To draw a chart, simply drag the table object
and drop it on top of the chart object. Because this is your first page
of the application, set its properties to startup document. Save this
application. The application will be saved in files named cust.isd and
cust.is_, where cust is the application name. Files cust.isd and
cust.is_ are the same, but cust.is_ is compressed and is used for
Web implementation. You are now finished building this application.

To run this application from another workstation, install inSight client

software and copy the saprfc.ini, connection, repository, and
application definition files to the workstation. Open the application file
from inSight, and you're done. Running an inSight analytical
application over the Web does not require installation of the inSight
component on the client workstation. The analytical applications are
automatically launched by the Web server, as described in the next
section.

To implement this same application for Internet users, simply copy

these files on the Web server in the application-specific directory.
arcplan provides a template HTML file you can edit using Notepad or
any HTML editor to launch this application. This HTML file has
inSight ActiveX control download and registration information. Edit
this HTML file to change the DEMO.IS_ application file to your
cust.is_ application file. Save this HTML file as cust.htm. Start up the
inSight service on the NT server, and you are ready to launch this
application from anywhere using an Internet browser and the
following URL, as shown in Figure 15-10:
http://dwtech.com/insight/cust/cust.htm.
 Figure 15-10: Launching the inSight Application over the Web by
using ActiveX Control. You Don't Need an inSight Client, SAP
Software, or Microsoft Office on the Client Workstation to Run this
Application.

When the Web server receives this request, the inSight server
determines if the client has ActiveX control on the workstation. If
ActiveX control is not on the client workstation, a new copy of
ActiveX control is downloaded and registered on the client
workstation. If the user already has inSight ActiveX control installed,
the latest version will be downloaded and installed if the previously
installed version is outdated.

After ActiveX control registration, you are asked for SAP BW login
information. This login information is used to connect the Web server
to the SAP BW server. After successful login, your application will
behave just as if you have inSight client on your workstation. All the
communication is via RFC-between SAP BW and the Web server-
and via HTML between the Web server and your workstation, as
shown in Figure 15-6.

Note Because the ActiveX control cab file is close to 1.3 MB,
expect this process to take some time depending on your
networking bandwidth between the Web server and your
workstation. However, this download and installation
happens only once or when a new version is installed on
 the Web site, not every time you access inSight
applications.

This example is very simple and does not implement rich graphics
and multi-layered application models; however, it demonstrates the
steps needed to implement third-party Web-based reporting tools to
build SAP BW reporting solutions. Other vendors, such as Business
Objects, Brio Technology, Cognos, Hummingbird, Information
Builders, and others, provide similar capabilities. Each product has
its own strengths and weaknesses. A careful analysis is needed
before selecting a reporting tool that meets your requirements.
Additional information on these vendors is available on the CD-ROM
accompanying this book.

Though inSight uses SAP logon to access data from a SAP BW

server, when information is pushed out by the Web server, the
connection between end user and the Web server is often based on
HTTP protocol. You have to implement such methods as SSL,
cookies, or digital signatures to manage secure Web connections.
Pure Internet-centric reporting models for SAP BW have just started
under the mySAP.com framework. The SAP Internet Transaction
Server is the Web server of choice. Along with security issues, Web
server load balancing, Web server redundancy, and high availability
are other important areas being evolved in the mySAP.com
framework to support industrial-strength Internet solutions. I
recommend visiting http://www.sap.com and http://www.saplabs.com
to learn mySAP.com marketplace and workplace portals
technologies and how SAP is planning to implement highly scalable
and highly available Web-based solutions.

Team-Fly
Team-Fly
ODBO and BAPIs in SAP BW 2.0
Earlier in this chapter, you learned about ODBO and its SAP BW
implementation limitations. To overcome such limitations, SAP has
enhanced its ODBO interface in BW 2.0. One such enhancement is
the ability to call ABAP routines and to have access to query
variables. The exact details are still sketchy on how the ODBO
interface could be used to access ODS in SAP BW 2.0. The ODS
tables in SAP BW are not multidimensional. They are simple, flat
tables. How ODBO MDX implementation can be used to interact with
tabular data is still being worked out.

The SAP ODBO BAPI is similar to the MDX Query language. Each
set of BAPIs represents ODBO specifications with one exception: the
schema, as shown in Figure 15-11.

Figure 15-11: SAP BW

ODBO BAPIs.

One can develop OLAP applications using BAPI programming in

RFC SDK. These BAPIs prefixed with the OLAP_API_ name have
several function calls. The following lists some of the function
modules in SAP BW 2.0A:
OLAP_API_BROWSE_CATALOGS

OLAP_API_BROWSE_CUBES

OLAP_API_BROWSE_DIMENSIONS
OLAP_API_BROWSE_HIERARCHIES

OLAP_API_BROWSE_LEVELS

OLAP_API_BROWSE_MEASURES

OLAP_API_BROWSE_MEMBERS

OLAP_API_BROWSE_PROPERTIES

OLAP_API_BROWSE_VARIABLES

OLAP_API_CREATE_COMMAND

OLAP_API_DELETE_COMMAND

OLAP_API_EXECUTE_COMMAND

OLAP_API_FS_GET_DATA

OLAP_API_GET_AXIS_DATA

OLAP_API_GET_AXIS_INFO

OLAP_API_GET_BAPIRETURN

OLAP_API_GET_CELL_DATA

OLAP_API_GET_DATASOURCEINFO

OLAP_API_GET_ERROR_MESSAGES

OLAP_API_GET_MESSAGE_HELP

OLAP_API_GET_NAMETAB

OLAP_API_GET_SELECT

OLAP_API_RESOLVE_NAMES

OLAP_API_SET_COMMAND_TEXT
A few vendors have implemented their OLAP applications using this
OLAP API instead of using BAPIs. inSight from arcplan is
implemented by using OLAP API to build powerful analytical
solutions.

Team-Fly
Team-Fly
Summary
The ODBO interface makes SAP BW an open product. Users can
now leverage existing investments in third-party client tools to
access data from SAP and provide a quick Web-based data access
solution. Though the ODBO interface is a powerful interface, it
cannot take advantage of all the services that SAP BW provides,
such as full access to the SAP BW data model and multi-language
and multi-currency features. To exploit all SAP BW capabilities, third-
party-tool providers may program their applications at the ODBO
BAPI level or by direct use of OLAP_API function modules. The
inSight example showed how quickly one could implement and
deploy SAP BW Web-based solutions. SAP BW version 2.0A
provides limited Web reporting capabilities. However, in BW 2.0B
and in future versions, you will see more robust Web implementation
built within the SAP BW software. I also tested the Brio Query 6.0
and the Business Objects 5.1 field beta test versions against SAP
BW 2.0A. Both products seem to be working as expected. At the
time of testing, these products were still undergoing the SAP BW 2.0
ODBO certification process. Check http://www.sap.com for a list of
ODBO-certified third-party data-access products.

Team-Fly
Team-Fly
Chapter 16: Managing SAP BW-Performance
and Sizing Tuning
In this Chapter
After doing all the fun work in developing an SAP BW application,
the tough job of deployment and management begins. You should
expect SAP BW, like any data warehouse, to grow rapidly. This
requires continual monitoring of SAP BW objects and addressing
problems before they interrupt your regular SAP BW operations. This
chapter describes such topics as sizing, performance, monitoring,
and management of SAP BW.

Team-Fly
Team-Fly
SAP BW Performance
Often, the speed at which a query returns data to the end user is equated to data
warehouse performance. To some extent, this is true from the end user's
perspective. However, performance of a data warehouse is based on several
factors, as described in Chapter 1 and as shown in Figure 16-1.

Figure 16-1: Data Warehouse

Performance Characteristics.

The center of the chart in Figure 16-1 is the most desirable situation. The
intersection at all dimensions indicates a practical or "implementable" state. Most
dimensions are time sensitive. The closer you get to the center, the less time it
takes to complete that task. When thinking of SAP BW performance, be creative to
find ways to reduce time for one or more dimensions to optimize the overall
performance.

For example, data extraction takes too much time due to extremely high transaction
volume in SAP R/3. To handle this situation, you may decide to pull data from SAP
R/3 multiple times a day instead of once a day. Keep this data in ODS in SAP BW
and load data InfoCubes only once a day. If this option does not work for you, you
may add additional processors in the SAP R/3 OLTP database server or add a
dedicated application against an SAP R/3 instance to process data extracts quickly.
The last two options could be expensive because they involve purchasing additional
hardware.

Network bandwidth is another key factor in overall data warehouse performance.

End-user queries receive large data volumes compared to OLTP transactions.
Within a corporate Local Area Network (LAN) environment, end users may not feel
much impact on the delivery of query results. However, Wide Area Network (WAN)
and especially Internet users will experience poor information-delivery response
time. To handle this network latency, SAP BW can be architected in data mart
fashion to limit WAN data traffic or define queries that filter data at the SAP BW
server level and return only a limited data set.
Optimizing Data Loads in SAP BW

Reducing data loads in BW is another major factor in improving overall data

warehouse performance. Data loading in SAP BW is a complex process. Several
factors contribute to performance factors; the following guidelines will improve data
load time.

Always load master data first. The SID tables are created at the time of
master data load. When you load data in InfoCubes, all relevant SIDs
needed to link dimensions and master tables are done for you. This reduces
additional time needed to create SIDs during transaction data loads to
populate InfoCubes.

Drop the secondary indexes on the fact tables. Do not drop the primary key.

Load data in ODS first, and then load data from ODS in the InfoCubes. The
ODS here refers to the ODS in SAP BW 1.2B or the PSA in SAP BW 2.0.

Rebuild the indexes on the fact table.

Update the database statistics for cardinality information needed for the
query optimizer to best query the execution path.

Change the buffering of the Number Range Objects.

Adjust IDOC-related parameters.

Sort data to be loaded.

Load data in parallel.

Remember, data warehouse performance is a balancing act. All of the previous

items play a significant role in overall data load performance in SAP BW. Also note
that only some of the data warehouse performance areas are specific to a DBMS
used to implement SAP BW. The rest depends on SAP R/3 infrastructure, data
models for the Information Objects (InfoCubes, ODS, Aggregate Cubes), and the
queries. All such areas have to be regularly tuned for high-performance SAP BW
implementation. Figure 16-2 shows how to set up InfoCube performance
parameters in SAP BW 1.2B and SAP BW 2.0A.
 Figure 16-2: Setting up Data Load Performance Parameters in SAP BW 1.2B
and SAP BW 2.0A.

Index Management

Prior to SAP BW release 1.2B, most index-related performance procedures were

manual. However, in SAP BW 1.2B, these procedures are built into the InfoCube
management options. Figure 16-2 shows how indexes are handled during InfoCube
load time.

In the InfoCube tree, right-click an InfoCube and select the InfoCube Performance
option. Then for SAP BW 1.2B, select InfoCube Performance; select Manage for
SAP BW 2.0A. Check the Index Delete/Create options; the next time you load data,
SAP BW will handle index deleting/re-creation automatically.

Buffering Number Range Objects

A Number Range object is like a Sequence Number in Oracle Database. It tracks

the next available sequence number to assign to an associated object similar to a
counter. Any time a new occurrence of the object is loaded in SAP BW, the system
fetches the next sequence number value from the database, adds 1 to the current
value, and saves it back in the database. When you are loading large amounts of
data, you will do hundreds of extra database accesses to process sequence
numbers, and that can be expensive.

To resolve this problem, you can buffer these sequencing objects in memory and
set a range large enough that during data load, SAP BW simply obtains the next
sequence number from memory instead of the database. This definitely improves
overall data load performance.

Figure 16-3 shows how to set up Sequence Number buffering. To change the buffer
for a Number Range object, run transaction SNRO and select the numbered buffer
object name. Then from the Edit menu, select Set-up buffering and then select Main
memory. Then in the Customizing specifications section, you will see that Main
memory buffering is checked. Here you select your buffer range from 500 to 1,000.

Figure 16-3: Changing Buffering of the Number Range Objects.

Caution Make sure that after you finish loading data, you change buffering back
to the default setting.

InfoCube Aggregates

The size of any data warehouse grows rapidly in time and continues growing. It is
not like an OLTP environment where you purge data to maintain a reasonable,
manageable size for optimum transaction performance. A data warehouse is quite
the opposite. You simply keep pumping data in the data warehouse, which needs
constant monitoring of database growth and frequent database reorganizations.

Figure 16-4 shows the data growth pattern in a data warehouse. The reference data
(master data) does increase, but volumes are often very low. The operational data-
needed for warehouse administration such as sort areas, backup files, and
temporary storage-remains almost the same. On the other hand, the analytical data
such as InfoCubes, ODS, Aggregates, Query Results, and Documents grows
almost exponentially. Note that data growth in a data warehouse is not continuous
but in intervals; for example, toward the end of a quarter or month or at the end of
the week, large transaction data sets are loaded and aggregated in a data
warehouse. Similarly, data warehouse usage patterns vary from time to time and in
intensity. For example, business profitability analysis activity is high just before the
end of a month, quarter, or year, but senior executives want to review the past
week's business operation every Monday morning for product production tactical
planning. A good understanding of growth patterns and Information Objects usage
helps database administrators to plan activities, such as database tuning and
adding data files, before data loads start to fail.

Figure 16-4: A Data Warehouse Data Volume Growth Pattern.

Tip Always plan for plenty of extra disk storage. Typically, the size of a data
warehouse tends to be 4 to 10 percent larger than the actual transaction
data.

As the size of an InfoCube grows, the query response starts to degrade, as shown
in Figure 16-4. However, based on individual queries, one can define an aggregate
cube, a view against an entire InfoCube based on a query definition. Aggregates
are transparent to the end user. When a user or developer plans to design a query,
only the InfoCube is visible to the end user in the BEX Analyzer. When a query is
issued against an InfoCube, the OLAP processor determines which aggregate, if
any, to use to quickly fetch the requested data.

In simple terms, an aggregate is a subset of an InfoCube based on a selected

dimension value(s). For example, you have a sales analysis InfoCube that has four
dimensions: Geography, Customer, Material, and Time. Suppose most of the sales
analysis is done by Sales Regions (North America, Europe, South America, Africa,
and Asia). Here you can build aggregates against the sales analysis InfoCube
based on individual sales region, each having its own fact table and selected
dimensions, containing sales information specific to the sales region.

When you issue a query against the sales analysis InfoCube, the OLAP optimizer
will determine which aggregate to use to quickly retrieve data instead of searching
through the entire sales InfoCube. Under this scenario, the aggregates are similar
to dependent data marts as discussed in Chapter 1. Though aggregates are ideal
for quick data access, they do impact data load times because now you have to
update aggregates along with the InfoCubes. Therefore, do not define aggregates
for all queries and frequently monitor their usage to qualify if you need one. Note
that it is up to the SAP BW administrator to decide when to roll up aggregates after
data loads in the InfoCubes to meet end-user data analysis needs.
The following steps are needed to define aggregates against an InfoCube to meet
specific query data needs:
1. Identify end users' queries and their data navigation schemes

2. Identify fields to include in an aggregate

3. Identify field aggregate values

4. Identify filters to select specific data sets

5. Identify the hierarchy level

6. Define the aggregate

7. Activate the aggregate

8. Fill the aggregate with data (done automatically in BW 2.0)

Assume that the customer InfoCube is very large and queries are timing out. You
may improve query responses by defining a few aggregate cubes. Look at the
query definition. Identify which fields are used in each query. Do queries have built-
in filters or restricted key figures? How do they use hierarchies? Do they start at a
certain hierachy level? With this information, you will define InfoCubes that best
meet end-user query needs.

Defining InfoCube Aggregates

To define aggregates, right-click the InfoCube, as shown in Figure 16-5, and select
Maintain InfoCube aggregates.

Figure 16-5: Defining Aggregates against the Customer InfoCube.

The Aggregate Maintenance window, displayed in Figure 16-6, shows an aggregate
proposal based on queries defined against the Customer (0SD_C01) InfoCube.
Initially, this is a blank screen.

Figure 16-6: Defining Aggregates for an InfoCube in SAP BW 1.2B. Initially,

When an Aggregate is Created, the Entries in the Calls and Last Displayed
Columns are Not Filled in. as Users Use Queries against the InfoCube, SAP BW
Automatically Fills Information About Each Aggregate on How Often and When
an Aggregate was Used. Never-Used Aggregates Should be
Deleted.

If you want to create aggregates based on present queries against the InfoCube,
click the Simulate icon. The system analyzes all queries for the InfoCube and
recommends one or more aggregates, as shown in Figure 16-6. Double-click an
aggregate to edit or view its definition, as shown in Figure 16-7.

Figure 16-7: Defining Aggregates Selection Criteria in SAP BW 1.2B. Here You
Select the Characteristics You Want to Include in the Aggregate. This Shows the
 Characteristics Selected for Aggregate MAX 1 for Customer InfoCube
(0SD_C01).

Next, activate the aggregate and then click the Fill icon to load data from the
aggregate cube from its InfoCube.

If you want to create a new aggregate manually in addition to what the system has
proposed to you, click the New icon. You are then asked to specify the aggregate
criterion. The rest of the process is the same.

The process of defining aggregates is quite similar to what it was in SAP BW 1.2B
(see Figure 16-8). Here, aggregate activation and population of aggregates is done
in one step when you activate the aggregate. Now you have the option of which
type of aggregate proposal you want to use to define aggregates. In SAP BW 2.0,
you have several choices: aggregate proposals from existing queries, from last
navigation steps, BW statistics (from a database), or BW statistics (from an
InfoCube).

Figure 16-8: Defining Aggregates in SAP BW 2.0. In this Scenario, the

Aggregate is Defined for a Specific Product, BIGSCREENTV, because End
Users Want to do Extensive Sales Analysis for Large-Screen
TVs.

After going through all this to define aggregates, you'd like to know how often they
are going to be used. You need to know this to make decisions about which
aggregates to drop. First, let end users run their queries to collect information on
InfoCube and Aggregate usage. To find aggregate usage, simply launch the
aggregate session. SAP BW will display when each aggregate was last used and
the number of times it has been accessed in total. Figure 16-9 shows aggregate
usage statistics for another SD cube I used to perform high-volume testing. The first
aggregate has never been used; therefore, it is a prime target for deletion.
 Figure 16-9: Aggregate Usage Statistics.

Aggregate cubes definitely improve query performance. The downside is that it

takes longer to load data in InfoCubes. You have to be very careful about when to
load data in InfoCubes and when to roll up aggregates to avoid any data
inconsistency. Moreover, if you change master data, hierarchies, or navigational
data, you should refresh (change run) the aggregates that could be time consuming
depending on how many aggregates you have. Keep a close watch on the numbers
in the Entries column (Figures 16-6 and 16-9). If the number of entries for a specific
aggregate cube is less than 10 percent of the fact table, drop that aggregate
because it will take more time and resources to build the aggregate as opposed to
enhancing query performance.

Team-Fly
Team-Fly
SAP BW Query Optimization
In the previous section, I discussed how aggregates help improve
query performance. Remember that aggregates speed up query
response because data requested by the end user (query) is already
available in the summarized/condensed fashion in an aggregate
cube. This saves a lot of database and system resources to find
requested data from a large InfoCube.

The aggregate cubes only help speed up fetching data from the
database, but how SAP BW manages and delivers retrieved data to
the end user is another dimension to consider when improving
overall end-user query response. The SAP BW OLAP process needs
to know when and how much data to read from the fact table and
send to the user based on the query read mode. The read mode
determines how often the OLAP processor reads data from the
database during navigation. The three possible query read modes
are listed below.

Read all data

Read data during navigation

Read data during navigation and when expanding the

hierarchy

Read all Data

In this mode, query reads all data to its lowest granularity from the
fact table and stores data in the user memory space. The OLAP
processor computes all the aggregates and data summaries to meet
end-user query needs in memory. All of the navigational steps are
done in memory. This makes query navigation fast; however, it eats
up tons of OLAP processor memory, and that may cause severe
memory problems with other SAP BW tasks. Because the OLAP
processor reads all possible data from the fact table that a query
may need, the OLAP and database engine may read unnecessary
data that may not be needed for query navigation at that time, and
hence too many resources are consumed that were not needed. The
usage of this mode should be limited to special queries when end
users (data analysts) need to slice and dice data against all
dimensions or perform data mining tasks.

Read Data During Navigation

In this mode, data is retrieved on demand during navigation-for

example, at first when a user launches a query that shows summary
level information. At this time, the OLAP processor simply reads the
required data elements and prepares the data set to satisfy the data
request. Suppose now that the user wants to drill down to next level
detail; the OLAP processor reads the database to generate the next
level of detailed data set for the end user. This is the default read
mode for the queries.

Read Data During Navigation and When Expanding the

Hierarchy

In this mode, the data is read on the hierarchies level from the
database when requested by the user. The OLAP processor does
the data aggregation. If queries do not use hierarchies, there is no
difference between this and the previous read mode, Read data
during navigation.

Now that you know how query read modes work, you may be
wondering how you can set or change query modes. The next
section discusses this subject.

Setting up Query Read Modes

Query modes can be set in two ways. First, set default query mode
for an InfoCube using transaction READMODE, as shown in Figure
16-10. All queries generated against that InfoCube, after setting the
read mode, will have default read mode set for the InfoCube.

Figure 16-10: Setting

Global Query Read Mode for an InfoCube. Changing Read Mode
for an InfoCube Does Not Change Read Mode for all Existing
Queries against the InfoCube. This Mode is Applied to Only New
Queries.

The second method to change the read mode of an individual query

is done via Query Monitor transaction RSRT, as shown in Figure 16-
11.

Figure 16-11: Changing Read Mode for an Existing Query using

Transaction RSRT. Note that this Transaction Can be Used to
Debug the Query.
To check read mode of a query, select a query, and then click the
Technical Info button. It displays technical information of the selected
query, such as when the query was last modified, the ABAP program
name for the query, and the read mode.

To change the read mode, after selecting a query, click the Read
Mode button and select the read mode type as shown in Figure 16-
11.

An interesting feature of the Query Monitor transaction is that you

can debug the selected query. You can debug the actual report
ABAP code for the query. Simply click Debug and step through the
ABAP code. To simply see the query results, without BEX Analyzer,
click Execute System.

Team-Fly
Team-Fly
Sizing SAP BW
As with any traditional data warehouse project, deploying a large-
scale data warehouse solution is a complex and iterative process.
However, when it comes to SAP BW sizing, you must size the
networking resource needed among SAP BW, SAP R/3, and the end
user. You must also account for the additional hardware resources
needed to implement multi-tiered architecture and the impact of SAP
R/3 for SAP BW data extracts.

The Sizing Process

Because SAP BW is a new environment and very few customers use

SAP BW as a global data warehouse in production to date, sizing
information is hard to find from SAP BW customers and hardware
vendors. SAP, however, provides basic sizing guidelines to its
customers for SAP BW configurations. As with the SAP R/3 OLTP
sizing benchmark, SAP has developed a benchmark for SAP BW
1.2B based on a typical sales and distribution data warehouse. Thus
far, only IBM has published official results. On February 15, 2000, at
the SAP BW Congress in San Francisco, California, IBM announced
the first official benchmark for SAP BW for DB2 conducted at IBM
Competency Center in Walldorf, Germany. The full benchmark report
is available at IBM's Web site at
http://www4.ibm.com/software/data/db2/benchmarks/013100.html.
SAP BW benchmarks are under way at Compaq, Hewlett-Packard,
and Sun. Visit their Web sites for SAP BW benchmarks on their
platforms.

SAP BW Benchmark
The SAP BW performance benchmark is a standard software-testing
module from SAP. Functioning as a data generator, user simulator,
and test platform, this module generated a sample Sales and
Distribution (SD) database representing the order-processing activity
of a large-scale business with the following profile:
 50,000 products

10,000 customers

5 divisions

5 distribution channels

40,000 orders per day (almost 15,000,000 orders per year)

In this environment, it is assumed that approximately 70 percent of

the products are sold by 20 percent of the distribution channels and
that 80 percent of the products are sold to 20 percent of the
customers. The average order return rate is 2 percent.

The SAP BW benchmark kit consists of a data generator, a query

simulator, an InfoCube, InfoSources, and an InfoPackage group to
load all generated references and transaction data into SAP BW.
Figure 16-12 shows the SAP BW benchmark configuration.

Figure 16-12: SAP BW

Benchmark Environment.

The data generator generates a series of order data files to load data
in SAP BW. The size of the file is based on the memory of the SAP
BW Database Server, such as 2 GB or 4 GB. Each file represents
one month of activity over a two-year span and totals approximately
800 MB (approximately 2,400,000 rows) in size. For benchmarking
testing purposes, two full years of transaction data (12 files) needs to
be uploaded into SAP BW totaling approximately 20 GB (or
approximately 29,000,000 rows in the fact table).

This benchmark comprises three key measurements: load phase,

realignment run, and user queries. Data is loaded in ODS, then ODS
to InfoCube, and Expected query response time. Visit IBM's or SAP's
Web sites at http://www-
4.ibm.com/software/data/db2/benchmarks/013100.html and
http://www.sap.com/bw, respectively, for details about the IBM SAP
BW benchmark.

Sizing SAP BW Components

The following factors are key in sizing an SAP BW system and
determining the expected processor, memory, and storage
requirements. To estimate hardware size, you should know the
approximate database size, the average number of concurrent
users, and the overall query mix. Note that how you configure these
components and distribute the data across shared storage provides
the basis for ensuring optimal system performance.

System Landscape and Migration Path

SAP recommends the following three-phase rollout strategy that

includes pilot/development, test, and production systems, known
collectively as the SAP BW system landscape:

Pilot/Development System. This system is used to pilot and

develop new components and add-on tools as well as
perform ongoing customization for SAP BW. Only developers
will have access to both the development and test systems.

Test System. The test system is where performance and

verification tests are run against new software prior to rollout
 onto the production system. This system may also be used
to test the behavior of new versions of base components,
such as operating system and device driver updates.

Production System. The production system is the live SAP

BW implementation that contains the operational business
data to which users have access.

SAP R/3 OLTP system. The typical SAP R/3 OLTP system
landscape consists of three system environments, as listed
above-pilot/development, test, and production. However, in
the SAP BW system landscape, you also need to include
dedicated SAP R/3 OLTP instances at each stage of the
SAP BW path to production cycle. I recommend a small SAP
R/3 OLTP instance for a development environment, but
make sure that your TEST SAP R/3 OLTP instance reflects
the current production SAP R/3 OLTP instance. Here you
want to make sure that all SAP BW objects (Queries,
InfoCubes, Aggregates, ODS) can scale to meet end-user
requirements.

The actual system landscape and migration path you choose to

follow depends heavily on the needs of your business as well as the
overall size and complexity of your SAP BW implementation. The
information provided here highlights the areas to consider in sizing
your pilot SAP BW environment.

Database Size

Estimating database size involves calculating the size of incoming

data sources and how that maps into individual data objects in SAP
BW. These data objects are ODS, InfoCubes, IDOCs, and the SAP
BW BASIC environment.

Moreover, you need to size additional storage requirements in the

sourcing SAP R/3 OLTP instances to process and manage data for
SAP BW.
The disk storage requirements for an SAP BW system depend
heavily on the design of the InfoCube as well as the overall
distribution of data. According to the guidelines published by SAP,
the amount of disk storage required is based on the following factors:

Number and size of InfoCubes

Number and size of ODS tables

Volume of data to be loaded

Amount of master data

Number of aggregates

Indexes

Projecting the total amount of storage required involves the

following:

Calculate the total size (in GB) of all InfoCubes. Note that, in
general, InfoCubes should not exceed 100 GB. SAP has
published detailed instructions for estimating the size of an
InfoCube in SAP BW Sizing and Performance ASAP
Accelerator. Exact size of an InfoCube is very hard to
calculate; however, the SAP BW Sizing and Performance
ASAP Accelerator defines a simplified calculation for
estimating the disk space required for an InfoCube as
follows:
f = (nd + 3) x 4 bytes + (22 bytes x nk) = required
disk space in bytes

add
30% per dimension in the fact table
100 % for aggregates
100 % for indexes

InfoCube = f x (nd x 0.30 + 2) x nr x np

 where
f = fact table size in bytes
nd = number of dimensions
nk = number of key figures
nr = number of records
np = number of periods

Suppose you have an InfoCube with four dimensions, two key

figures, and you load 10,000 records every day. The estimated
InfoCube disk space utilization after one month, 30 days, will be:

Disk = [(4 + 3) x 4 + (22 x 2)] x [( 4 x 0.30 + 2 ) ] x

space 10000 x 30
= 69120000 bytes or 69.12 MB

Add 5 GB for BW software (including the SAP BW

Administrator Workbench). Add 150 percent for temporary
table space and storage.

The final total represents the total amount of storage

projected for BW. Note that if you are using a RAID 1 or 0+1
disk array, you should double this estimate.

Note At the time of this writing, all SAP BW ASAP methodology

papers, guidelines, or sizing information is very much
focused on the SAP BW 1.2B environment limited to
InfoCubes. With ODS implementation in SAP BW 2.0 and
new master data architecture, as well as BDS integration,
the size of the SAP BW database and the
database/application server characteristics will require
additional resources. SAP is in the process of updating the
sizing and other methodology papers and hopes they will
be available at the time of SAP BW 2.0B GA.

Processors
The number of processors in an SAP BW server system directly
relates to the time it takes to load data. By default, the SAP BW data
load process is a serial process (with worker threads) that executes
on a single processor. To optimize load times and reduce latency,
each process must be partitioned into a series of sub-processes and
distributed across as many processors as are available. Therefore,
the more available processors you have, the greater number of
parallel sub-processes, resulting in faster data load time.

SAP recommends a minimum of two processors per system,

regardless of the hardware platform. However, for the most efficient
load balancing, SAP suggests a minimum of two to four processors
for each SAP database and application server.

Memory

Most analytical applications are resource intense and consume high

system resources such as memory and CPU cycles. The more data
you can load in memory, the faster the query response will be. Note
in Table 16-1 that both SAP BW database and application servers
require more memory than SAP R/3 OLTP instances.

Table 16-1: Assessing SAP BW Memory Requirements

Server Type Memory
300 MB + 10
Application MB/Concurrent
User
500 MB + 2
Database MB/Concurrent
User
Central Instance (one server with both
2048 MB
Database and Application servers)

Disk I/O Subsystem

Due to large data volumes during data load and query time, the
mass storage I/O subsystem plays a major role in all data
warehouse operations. Due to insufficient bandwidth of I/O
subsystems, you may find that the I/O subsystem is the most
common roadblock to efficient performance. In contrast to the SAP
R/3 OLTP system, it is impossible to tweak memory configurations
adequately to avoid accessing the mass storage entirely. As a result,
tuning efforts are largely focused on making disk I/O bandwidth as
large as possible.

Large bandwidth is achieved by spreading the database across a

large number of array controllers and SCSI buses. Therefore, it is
important to estimate the number of controllers required. The
number of I/O controllers is derived from the estimated bandwidth
required by the workload (typically, 10 MB/s for each CPU). For
example, a system with eight CPUs should have enough I/O
controllers to support 80 MB/s bandwidth.

Network Configuration

SAP BW software is based on the standard R/3 kernel, and, as a

result, similar network requirements apply. However, due to frequent
large data set movements between SAP R/3 OLTP and SAP BW
instances, you must make sure that the SAP R/3 OLTP instances
and SAP BW instances share high-speed network links, usually 100
MB.

Client Workstation

SAP recommends that an SAP BW client workstation for running the

SAPGUI (BEX Explorer) be any Intel-based 350 MHz PC with a
minimum of either 64 MB (for Windows NT 4.0, Windows 2000, or
Windows 98 systems) or 48 MB (for Windows 95 systems).
However, based on experience, at least 128 MB memory on client
workstations with fast graphic adapter cards will provide you with
reasonable performance.
 Note After you make an initial estimate, SAP recommends that
you verify the estimate by loading a small amount of data
and analyzing the actual amount of storage used. Also,
disk space should be checked frequently because usage
changes over time.

Team-Fly
Team-Fly
Summary
Data warehouse performance and management is a very broad
subject. This chapter simply addressed performance-related issues
very specific to SAP BW: data load and data access. In this chapter,
you learned how to optimize data loads in SAP BW and how to build
aggregates to improve query performance.

Sizing any data warehouse is not an easy task. I have never seen
two data warehouses that are alike; sizing is always very specific to
a customer's analytical needs. In this chapter, you also learned how
to size an SAP BW environment and identify areas-such as memory,
processors, and disk I/O requirements for SAP BW-that play a direct
role in overall SAP BW performance. Often, hardware vendors take
advantage of their architectures. For example, the Compaq Alpha
server exploits a very large memory architecture to improve SAP BW
performance. However, I advise you to consult with SAP and partner
hardware vendors to provide the latest SAP BW benchmark results
so you have a good high-performance data warehouse solution. A
few vendor Web sites are listed Appendix A.

Team-Fly
Team-Fly
Chapter 17: The Operational Data Store in SAP
BW 2.0
What is an Operational Data Store (ODS)?
The term ODS is confusing. Is it a data warehouse, part of a data
warehouse, or something else? ODS has several academic definitions in
the data warehouse industry. However, the definition varies based on
usage.

In Building the Operations Data Store, (see Appendix A), William H.

Inmon, Claudia Imhoff, and Greg Battas define ODS as a

subject oriented, integrated, volatile, current valued data store

containing only corporate detailed data

to support tactical decisions. At a conceptual level, just about everyone

agrees with this definition. However, many differ in defining usage
boundaries of ODS and implementation.

History of Operational Data Store

Initially, the ODS was introduced to integrate legacy and transactional

applications to increase customer satisfaction, not to make tactical
decisions. It had a customer focus in mind. For example, in the banking
industry, customers want to see one view of all their accounts, regardless
of the individual systems in which they are stored. Here, the role of ODS
is to keep an up-to-date summary of all such accounts in the ODS to
provide consolidated accounts information to support transactional
applications as well as customers outside the company boundaries.

Here, one can value-add the account information from a partnering

advertising company to promote a product, hence merging corporate and
non-corporate information. Merging company and non-company
information in ODS contradicts the definition previously stated.

There are three classes of ODS layers, most commonly known as Class
I, Class II, and Class II. The ODS Objects in each class have special
characteristics, as listed in Table 17-1.
Table 17-1: Characteristics of Operational Data Store Classes and
Their Usage
Functionality Class I Class II Class III
Asynchronous;
Based on
Asynchronous; analytical
Data refresh Synchronous;
Near real time- application
rate from its almost in real
few minutes to usage and the
data sources time
an hour infrastructure
operational
requirements
Data volume Packets Small-medium Large
Business
Event-Centric-
Very much;
a mix of
Transaction- Subject-centric
Data Content transaction
centric at the atomic
and supporting
level detail
workflow
information
Persistence Low Medium High
Moderate-
compose data Extensive-
Very little just structures by Cleansing,
to conform to combining extraction, and
Data
data transaction transformation
Transformations
interchange and value- to construct
format added atomic level
information for data sets
DSS
Availability High Medium Low
Functionality Class I Class II Class III
High-at the Medium-Low,
Medium-at the
speed of based on
speed of
intra- business value
Performance business work
application and operation
flow rules
interconnect costs
requirement
requirements requirements
Operations
Customer
Customers; management;
facing; Staff;
Customer Data analysis;
Intra-
Intended usage facing and Customer
application
operations problem
interconnect
staff resolution and
services
operations
Fast and
Mostly Mostly batch,
reliable data
application or database, or
interchange
database large data
and data
Technical specific store handling
storage
Infrastructure and forward technologies
technologies-
data to optimize
hardware,
management infrastructure
software-
technologies resources
OLTP-centric
OLTP OLTP OLTP and
Operations operations operations data
Staff staff-highly staff-less warehouse
visible visible staff
Corporate Division or line
Operations
Business senior of business
management
Sponsors business management
team
management team
 Functionality Class I Class II Class III
Airline
Bank accounts Call center;
reservation;
management; Manufacturing
Example Critical care
supply-chain shop floor
medical
management operations
records

The Class I ODS serves mostly as a real-time intra-application

interconnect bus. Classes II and III are mostly to support near-real-time
business operations. Due to specific time-critical ODS object-usage
requirements, use robust flexible technologies to implement ODS objects.
The question is then how one can deploy such a diverse ODS
environment and the data warehouses under one framework to support
e-business and business intelligence. This is where SAP BW technical
framework plays a critical role in constructing, delivering, and managing
all information objects, including ODS, OLAP, data marts, data
warehouse, document warehouse, and extraprise data warehouse to
support CIF under one umbrella.

In BW, 2.0 you can implement an enterprise data warehouse using the
ODS objects. This extended ODS capability in SAP BW completely goes
against the ODS definition. Imhoff, an authority on the Operation Data
Store, states ("Understanding the Role of Operations Data Store, DCI
conference, June 28, 1998") that:

The ODS is not the lowest level of detail in the data warehouse
architecture.

The ODS is not a staging area for the data warehouse.

The ODS is not a department-specific application.

The SAP BW ODS implementation is quite the opposite of these three

points. Most customers will store the lowest level of detail in the ODS
objects, blurring the ODS and data warehouse boundaries. In doing so,
one has to stage data in the ODS objects to construct non-
multidimensional department-specific applications. Though SAP calls this
new functionality the ODS, in reality, it is a framework to build traditional
ODS and data warehouse objects along with its ROLAP implementation
to complete the CIF. For this reason, I call SAP BW ODS eODS-extended
ODS.

Several examples-each providing a different concept of ODS primarily

based on its usage and implementation architecture-can be cited. Today,
due to heavy use of ERP applications and intense focus on customer
satisfaction, the lines between ODS and traditional data warehouse are
blurring. A new vision for ODS is warranted. This bring us to the SAP
view of ODS-how it has evolved and what it really means.

Let's look at ERP packaged applications and the scope of traditional

ODS. The ERP applications provide an integrated suite of business
applications, such as SAP R/3. Here, information is already integrated
among several individual applications. Data from all such applications is
easily available. Because the fundamental role of an ODS in a
corporation is to provide almost real-time data interconnects for an
integrated view of information among business applications, the role of
ODS as previously defined is very limited. For an ERP environment, the
role of ODS still has to be defined where ODS plays an active role in the
corporate information supply chain.

After the release of SAP BW 1.2A, customers found that the ODS
implementation was not what they thought an ODS ought to be. It only
housed the incoming data. American SAP User Group (ASUG) members
worked with SAP to form a subcommittee to define an ODS architecture
in the SAP BW product. This subcommittee consisted of ASUG members
representing a broad range of industries (Dan Spaulding, Halliburton;
Charlene Mathias, Eli Lilly; Naeem Hashmi, Compaq; Ryan Uda, Hewlett-
Packard; Marilyn Jones, Dow Corning; Mary Heaner, Intel; Dave Smith,
Phillips Petroleum; Kay Black, Sabre; and Xuan Pham, Equistar).

After long and intense discussions among team members and Laurie
Nolan and Dr. Heinz Haefner, both of SAP AG, a white paper on SAP BW
ODS was published. This white paper became the foundation of ODS
architecture in SAP BW 2.0. This team focused its analysis of ODS
requirements on the eight key areas: diverse data source, environment
management, extraction-transform-load, metadata management, data
management, archival management, data access, and data requestors.
The proposed ODS functionality is planned for partial implementation in
SAP BW 2.0A for the pilot customers, Hewlett-Packard and Eli Lilly, and
in SAP BW 2.0B for general availability. The ODS pilot was launched
from December 1999 to February 2000. The SAP BW ODS pilot results
were presented at the BW Congress in February 2000 in San Francisco,
California.

Team-Fly
Team-Fly
SAP BW 2.0A ODS Architecture
The ODS architecture in SAP BW 2.0 is quite different from its earlier
versions, as shown in Figure 17-1. Now ODS becomes an active
component of SAP BW, which completes the concept of a full data
warehouse.

Figure 17-1: SAP BW 2.0

ODS Architecture Compared to its Earlier Version, BW
1.2B.

In SAP BW 1.2B, ODS is used to store inbound data as a temporary

holding area before it is loaded in the InfoCubes. After this, data is
simply purged. SAP BW did not provide any services to access data
from the ODS except by writing ABAP code to read such tables.
From an ODS usability perspective, there is another big problem.
The ODS physical table name is system generated and changes
whenever transfer structure is activated or InfoSource structure
changes.

In SAP BW 1.2B, you have few data load options, as shown in

Figure 17-1. You can load directly in ODS, InfoCube, or both in
parallel, or load in ODS and then from ODS to the InfoCube. The
BEX Analyzer is limited to accessing data from the InfoCubes and
not the ODS tables.
Now in SAP BW 2.0, there is one additional data management layer
between InfoSources and the InfoCubes. Under new terminology,
the earlier version of ODS is called Persistent Staging Area, or PSA,
and the new data management layer on top of PSA is called ODS.
The third layer, the InfoCubes, remains unchanged.

Persistent Staging Area

The structure of PSA is defined according to InfoSource and the

source system and has the key request number, packet number, and
record number. Data is stored in transparent database tables in the
format of the transfer structure. As with SAP BW 1.2B, you can
update PSA and InfoCubes sequentially, in parallel, or to the PSA
alone, as shown in Figure 17-1.

ODS Operating Environment

The ODS is an environment to manage all ODS-specific objects in

SAP BW 2.0. The ODS tables can be an identical copy of one PSA
table for reporting, a consolidation of multiple PSA tables, or a
subset of PSA tables. An ODS table, however, can be a
consolidation of several ODS tables for cross-functional operational
reporting. This feature makes it possible to clean, transform, merge,
and sort data and build an ODS table containing document-level
details for end-user reporting. These tables then can be drilled
through from within an InfoCube if detailed information is desired.

You can access data from ODS from within the BEX Browser or via
InfoSet Query, earlier known as SAP Query or ABAP/4 Query. In
SAP BW 2.0, you also can build InfoCubes from an ODS table. With
this capability, you can build staging tables for InfoCubes that will
speed up InfoCube builds.

The philosophy behind an ODS is that it must also provide services

to support intra-application data interconnects. In other words,
several applications share common data sets for business-critical
applications. For example, you have several OLTP applications that
need data from an SAP R/3 OLTP instance as well as among
themselves. Instead of building individual point-to-point interfaces, it
would be much easier if all applications downloaded shareable data
in the ODS. There, it is well managed and shared across all
applications. It is expected that SAP BW 2.0 will also support such a
data sharing data repository, shown as ODS3 in Figure 17-1.

Note You must keep in mind that SAP BW business content was
originally structured for somewhat summary-level analysis.
Now that you have ODS functionality, you may want to
either enhance existing extracts for finer granularity or build
your new data sets for ODS.

Due to lack of ODS functionality in earlier versions, a few

customers have built their InfoCubes to document-level
detail. It takes a lot of time and resources to maintain such
fine-grained InfoCubes. With ODS, you may need to
redesign your InfoCubes to keep only summary-level detail
in the InfoCube and details in the ODS tables.

With ODS implementation in SAP BW 2.0, you need to rethink your

SAP BW modeling philosophy. Earlier, you modeled information
primarily from multidimensional InfoCubes view. Now you need to
decide what information goes in the InfoCube, ODS, Business
Documents, and a data warehouse based on your information usage
model.

The following guidelines will help you decide when to use certain
data objects in SAP BW 2.0.

Store data in InfoCubes when you need to do

pure numerical analysis-slicing and dicing

analysis for fewer than 15 dimensions at a time

 Store data in ODS when you

need to track very detailed information

need to do long-term historical analysis (building

data warehouse objects)

have textual information (non-key characteristics)

descriptive in nature

need an application integration hub to provide data

feeds to other business applications, data marts, or
data warehouses

need to stage and consolidate data from several

sources before building information objects in SAP
BW-implementing a staging area

The primary goal of a data warehouse is to support business

intelligence operations. Do not force-fit one technology to provide all
analytical solutions. Model your data analysis needs and carefully
select what has to go in an InfoCube and an ODS for Operational
Reporting or Enterprise Data Warehouse objects. A combination of
the right technologies will best suit end-user needs.

Team-Fly
Team-Fly
Building ODS Objects
ODS tables are somewhat a hybrid of InfoCube and master data tables. The
information on how to build ODS tables is based on the SAP BW 2.0A ODS pilot
version. Based on feedback, the integration of ODS development and reporting may
look somewhat different in SAP BW 2.0B.

Take the following steps to construct an ODS table:

1. Create Data Structures and Create Update Rules

2. Load Data

3. Create Queries

Creating an ODS Table and Update Rules

1. Creating ODS tables

Creating ODS tables is similar to defining InfoCubes. You first need to do

some modeling and have a model ready to implement. Note that ODS is not
an InfoCube; rather, it is a flat database table. You can design multiple ODS
tables, normalize them the way you want, and then use update rules to
update individual tables. Figure 17-2 shows an ODS table definition for
ZTEST3. Note that you need to provide information about key and non-key
fields. The key fields are those that make a record unique, and non-keys are
not part of a compound key that makes a record unique.

Figure 17-2: Defining ODS

Tables in SAP BW 2.0A. Remember that this Screen Design May Change
in SAP BW 2.0B.

Also note that the combination of key fields defines the grain of your ODS
table. For example, in ZTEST3 ODS, only four key fields make up a unique
ZTEST3 record, as shown in Figure 17-2.

In ODS, you can define key or non-key fields as text, numeric, or any
combination. Unlike a fact in an InfoCube, ODS tables don't always have to
contain numeric fields. In some instances, an ODS table may consist of all
 textual data elements. For example, you may simply want to track contact
name, data, and time when a customer was called, the name of the person
who called, and when to call that customer in the future. Here you have no
such thing as quantity, unit of measure, and so on. But remember, do keep
some time stamp in all ODS records. After all, it's time that you make the
history.

After launching ODS maintenance transaction, simply key in the fields of

your choice that make the record unique and other elements that you want
to track.

2. Creating the update rules for the ODS table

As with InfoCubes, you must create the update rules for the ODS table. This
is the tough job of deciding how individual entities will be updated. Most
often, you need to look up several database tables before you determine
what goes in an individual field in an ODS table. For that reason, SAP BW
now provides a start routine for the InfoCube and ODS update as shown in
Chapter 12. Activate Update, and you are ready to write reports against the
ODS.

Accessing Data From ODS and Setting up a Drill-Down Scheme

To access ODS for direct reporting, you can use BEX Analyzer, InfoSet Query, or any
third-party product that is SAP ODBO-certified. For testing purposes, I composed a
simple query, shown in Figure 17-3, to access data from an ODS table using BEX
Analyzer, InfoSet Query (then SAP Query), and a third-party ODBO-compliant
product. The results were not surprising. As expected, InfoSet Query was the fastest,
followed by BEX Analyzer and the third-party ODBO data access product. Figure 17-4
shows relative resource utilization by each product when the very similar query was
issued against ODS by individual product.

Figure 17-3: SAP BEX Analyzer Query Against ODS and Results.
 Figure 17-4: Comparing Query Response Time to Access Data From SAP BW
ODS.

I executed these queries 10 times in random order to generate balanced resource

consumption statistics. This was a very raw, unscientific test. One must also note that
in the BW 2.0A pilot ODS version, performance was not a key requirement. SAP BW
2.0B offers significant performance improvements for ODS operations.

Team-Fly
Team-Fly
Drill Down to ODS From an InfoCube
The SAP BW 2.0A pilot ODS also supported InfoCube to ODS-level
drill-down capability. This drill-down capability is achieved by SAP's
Report-to-Report Interface technology. A developer, not the end
user, defines a "jump-target" scheme by identifying the sender and
receiver pair information; as shown in Figure 17-5, the receiver is a
BEX Query (Figure 17-3) against an ODS table.

Figure 17-5: Defining

Jump-Target" Scheme to Jump From an InfoCube to an ODS
Query or in Reverse.

After defining a jump-target scheme in SAP BW Administrator

Workbench, you can jump to target report; in sender's BEX Analyzer
session, click the Go To icon, press the Go to Report drill-through
button, and select the target report of your choice. Not very intuitive!
It seems as if you are drilling and scratching all over before you
actually hit the target report to jump on. Finally, BEX Analyzer opens
a new session for the target report and displays query results. From
here, you have two independent BEX Analyzer sessions.

Note The jump-target method is not a true navigational method

in which to stay within one session and drill through data
within that process space with full navigation state
information to navigate backward or forward.
As mentioned earlier, you can also write queries against ODS with
InfoSet Query. An InfoSet query can be a target for a BEX Analyzer
Query. However, note that InfoSet Query requires SAPGUI frontend.
It does not work with BEX Analyzer. The InfoSet Query is easy to
develop, but it has its own interface-SAPGUI.

Team-Fly
Team-Fly
Building ODS in SAP BW 2.0B
In the previous section, you learned how to define ODS objects in
SAP BW 2.0A. The ODS development and management options in
SAP BW 2.0A were not fully integrated in the Administrator
Workbench. In SAP BW 2.0A, you manually invoke an ODS
transaction to launch ODS object design facility. Moreover, in SAP
BW 2.0A, the ODS objects were displayed under the InfoCube tree,
which was confusing if you were dealing with ODS, PSA, or
InfoCube when loading data in ODS objects. It was expected
because then, in SAP BW 2.0A, ODS was introduced to get
feedback from SAP customers on how the ODS environment should
be integrated in SAP BW and the Administrator Workbench. I had
several discussions with the ASUG ODS requirement and SAP BW
ODS development manager, Rainer Hoeltke, and his team on
naming schemes, integration, and its extended capabilities. The
ODS development team was very quick to take feedback to integrate
ODS functionality in the SAP BW 2.0B Administrator Workbench.
Thus far, they have done a great job. Note that there have been
changes in the SAP BW Administrator Workbench, as shown in
Figure 17-6. Now you have the option to create InfoCubes and ODS
objects from within the Administrator Workbench.

Figure 17-6: The

Administrator Workbench in SAP BW 2.0A and SAP BW 2.0B.
The InfoCube Tree Hierarchy No Longer Exists in SAP BW 2.0B.
 Instead, Both InfoCubes and ODS Objects are Listed Under the
Data Targets Tree.

Creating ODS Objects in SAP BW 2.0B

Creating objects in SAP BW 2.0B is similar to what was described

previously. Now instead of executing the ODS transaction, as shown
in Figure 17-2, you go to the Data targets tree, right-click an
InfoArea, and select Create ODS object, as shown in Figure 17-6.
You are then prompted for the ODS object name and taken to the
ODS design window, as shown in Figure 17-7.

Figure 17-7: Defining New DDS Objects in SAP BW 2.0B. Note

that the ODS Design Layout is Very Different From in SAP BW
2.0A, as Shown in Figure 17-2.

Figure 17-7 shows the definition of an ODS object to capture

schedule line item level detailed order information. Note that each
subsection in the right pane is like a tabstrip in Figure 17-2. For
example, Key section in Figure 17-7 is the same as the
Compounding tabstrip in Figure 17-2.

The term key figures has nothing to do with the Key section when
defining the ODS object. In the ODS object definition, as stated
earlier, the Key section is to select a unique set of data elements to
make the ODS record unique. In other words, it is the "grain" of the
ODS object. In Figure 17-7, the ODS record is uniquely identified by
a combination of division, document, order item line number, and
schedule line number. Defining ODS object attributes is a very
simple process. Select the appropriate InfoObject catalog in the left
pane and expand it. Then simply drag and drop the selected
InfoObjects from the left pane in the appropriate ODS object attribute
sections shown in the right pane (see Figure 17-7). Click the Check
icon icon. If no error is reported, click the Activate icon to save
the ODS object definition and create database tables in the SAP BW
database.

Note If the ODS object will be directly accessed by end users,

make sure to check the BEX Reporting option, as shown in
Figure 17-7. This will build SID tables and indexes to speed
data access. You may not want to always check this, such
as when you are building database tables to stage data.

Two types of database tables are created for each ODS object-one
for active usage and the other as a backup or for working copy to
prepare new data. For more information on how ODS objects are
defined in the database, click the menu option Extras and select
Information (Logs/Status), as shown in Figure 17-8.
 Figure 17-8: Getting Detailed Information on ODS Objects in SAP
BW 2.0B.

After activating the ODS objects, define the update rules and load
data. The update rules definition and the data loading process has
not changed. It is the same as if you are working with an InfoCube or
ODS object defined in SAP BW 2.0A. When you load data in the
ODS object, new data will be kept in the New Data table instead of
the Active ODS database table. To view new data or active data,
select an ODS object, right-click, and select Manage, as shown in
Figure 17-9. Click New Data to verify the data that has been loaded
in the ODS object but users do not have access to. To make this
data available for analysis, you must activate new data. To roll over
new data in the active ODS object, select the ODS object, right-click,
and select Activate data in ODS, as shown in Figure 17-9. From
here, the activated ODS object is ready for end users. They can
access it via InfoSet Query, BEX Analyzer, or third-party data-access
tools via ODBO.
 Figure 17-9: Managing Data in ODS Objects.

Team-Fly
Team-Fly
Future Direction of ODS in SAP BW
SAP is in a strong position to shape the industry in defining ODS for
the future corporate information supply-chain networks. SAP BW's
evolution in a short period to a provider of rich business analysis
functionality is amazing. A significant enhancement to the current
implementation will be the provision of a standalone instance of SAP
BW ODS. Benefits of having a stand-alone ODS are many, but the
key benefit will be its manageability-not to be tied down to an
instance of a specific analytical application but to have one
autonomous data source for the entire corporate universe.

Team-Fly
Team-Fly
Summary
The concept of Operational Data Store in SAP BW is new in the ERP
industry. In the SAP world, the role of ODS will be significant to
support other New Dimension products. This chapter defined an
Operational Data Store and how SAP has implemented this concept
in SAP BW 2.0A. SAP BW 2.0B will have a few more enhancements;
for example, the enhanced InfoSet Query and improved ODS data
access performance. You also learned in this chapter how ODS
tables are defined in SAP BW 2.0A and accessed directly as well as
how to implement InfoCube to ODS drill-down scheme.

Team-Fly
Team-Fly
Part IV: Appendixes
Appendix List
Appendix A: Data Warehouse Industry References and SAP BW
Training

Appendix B: SAP BW and SAP R/3 Transactions, Tables, and

Code Examples

Appendix C: Selected SAP BW OSS Notes

Appendix D: Key Enhancements in SAP BW 2.0

Appendix E: What's on the CD-ROM

Team-Fly
Team-Fly
Appendix A: Data Warehouse Industry
References and SAP BW Training
In this Appendix
Though hundreds of books are available on the subject, this
appendix lists only a few key titles for reference that provide a good
foundation on data warehouse technologies. For data warehouse
consultants with no or very little background on SAP R/3
technologies as well for SAP consultants, I list a few books that will
be useful in understanding managing and supporting SAP BW
analytical applications. I also list several references to Web sites for
SAP BW consulting companies as well traditional data warehouse
vendors to introduce readers to the data warehousing and business
intelligence industry. The SAP BW training courses listed are offered
by SAP at this writing.

Team-Fly
Team-Fly
Books on Data Warehousing and SAP
Technologies
Data Warehousing Reference Books

Building the Data Warehouse by William H. Inmon This book

provides an overview of data warehouse architecture.

Building the Operational Data Store by William H. Inmon, Claudia

Imhoff, and Greg Battas This book is known for ODS architecture.
Some basic ODS concepts outlined in this book played a major role
in defining the ODS architecture in SAP BW 2.0.

Corporate Information Factory by William H. Inmon, Claudia Imhoff,

and Ryan Sousa This is a good book on corporate data warehouse
architectures.

Managing the Data Warehouse by William H. Inmon A good

reference book on the issues related to managing data warehouses.
It's interesting to note that most of the data warehouse issues
described in this book are very well implemented in SAP BW.

The Data Warehouse Toolkit: Practical Techniques for Building

Dimensional Data Warehouses by Ralph Kimball An excellent book
on understanding the star schema implementation of an OLAP data
warehouse design. This book is a must for SAP BW InfoCube
schema designers.

The Data Warehouse Lifecycle Toolkit: Expert Methods for

Designing, Developing, and Deploying Data Warehouses by Ralph
Kimball, Laura Reeves, Margy Ross, and Warren Thornthwaite This
is another must-read book for data warehouse designers.

Improving Data Warehouse and Business Information Quality:

Methods for Reducing Costs and Increasing Profits by Larry P.
English Data quality is a major process in the construction and
success of a data warehouse. This is a good reference book that
describes methods to improve the quality of data warehouse content.

The Balanced Scorecard: Translating Strategy into Action by Robert

S. Kaplan and David P. Norton Balance scorecards are much more
than simple KPIs. This is a good reference book for understanding
the philosophy behind balance scorecards and how companies
establish processes to achieve organizational goals such as ROI and
customer satisfaction.

Understanding and Implementing Successful Data Marts by Douglas

Hackney The author shares his experiences on how and when to
build a successful data mart.

Data Warehouse Performance by William H. Inmon, Ken Rudin,

Christopher Buss, and Ryan Sousa A good book on understanding
data warehouse performance issues covering a wide array of topics
such as database technologies for very large databases, hardware
architectures, storage configurations, and large data warehouse
administration.

The Multidimensional Manager, by Richard Connelly, Ph.D., Robin

McNeill, and Ronald Mossimann A good book on understanding
multidimensional concepts and how these concepts are applied in
real-world business scenarios. This book is free. For a copy, contact
Cognos Inc. at www.cognos.com or ask for it at any of their booths at
data warehouse conferences.

SAP Reference Books

BASIS Administration for SAP by Johan Marneweck,Robert

Parkinson,Kay Tailor,Victor Wood

ALE, EDI, & IDoc Technologies for SAP by Arvind Nagpal

 Introduction to ABAP/4 Programming for SAP, Revised and
Expanded Edition by Gareth De Bruyn and Robert Lyfareff

Supporting SAP R/3 by Dennis L. Prince

Administering SAP R/3: The HR-Human Resources Module by

ASAP World Consultancy

Administering SAP R/3: The FI-Finance Accounting and CO-

Control Modules by ASAP World Consultancy

Implementing SAP Sales and Distribution by Glynn Williams

and Simon Yates

Team-Fly
Team-Fly
Data Warehouse Industry Reference Web
Sites
Data Warehouse Magazine and Literature Web Sites

http://www.datawarehousingonline.com

http://www.datawarehousing.com

http://www.dw-institute.com

http://www.dmreview.com

http://datawarehouse.dci.com

http://www.sapfans.com

http://intelligentERP.com

Data Warehouse Consulting Services Web Sites

http://www.ac.com Andersen Consulting

http://www.archer-decision.com
Archer Decision Sciences

www.BraunConsult.com
Braun Consulting

http://www.capgemini.com
Cap Gemini Ernst & Young US LLC

http://www.compendit.com
Compendit Consulting

http://www.dc.com
Deloitte Consulting LLC
http://www.egltd.com
Enterprise Group, LTD.

http://www.infodynamics-llc.com
InfoDynamics, L.L.C.

http://www.kpmgconsulting.com
KPMG Consulting

http://www.origin-it.com
Origin Technology in Business

http://www.panex-usa.com
Panex Consulting, Inc.

http://www.plaut.com
Plaut Consulting, Inc.

http://www.sap.pwcglobal.com/sap
PricewaterhouseCoopers

http://www.syskoplan.com
SyscoPlan Consulting

Data Warehouse Product Vendor Web Sites

http://www.acxiom.com

http://www.ardentsoftware.com

http://www.brio.com

http://www.broadbase.com

http://www.businessobjects.com

http://www.cognos.com

http://www.compaq.com/ActiveAnswers
http://www.corvu.com

http://www.epiphany.com

http://www.gentia.com

http://www.hummingbird.com

http://www.hyperion.com

http://www.software.ibm.com/bi

http://www.informatica.com

http://www.informix.com

http://www.microsoft.com

http://www.oracle.com/products/tools/datawarehouse

http://www.sagenttech.com

http://www.sap.com/bw

http://www.sybase.com

Team-Fly
Team-Fly
SAP BW Training Courses
SAP offers four SAP BW training courses at its training centers
worldwide.

Note that additional courses may be added in the near future. Check
http://www.sap.com/bw for the latest schedule.

SAP offers three levels of SAP BW training sessions, as shown in

Figure A-1. Level 1 is an introductory SAP BW training session.
Level 2 is for subject-matter experts to learn SAP R/3 application
modules. Level 2 sessions are SAP standards training courses on
application modules in SAP R/3 and required for business content
experts and SAP BW data extractor developers. Level 3 courses are
specific to SAP BW application developers, support, and
administration staff.

Figure A-1: SAP BW

Training Sessions Listed at the SAP Web Site.

Following are the SAP BW course descriptions, as published on the

SAP Web site.
BW200: Business Information Warehouse (BW)-
Overview

Course Description
Length 1 Day
Project managers working in Controlling; IT
Target
managers; anybody interested in data
Audience
warehousing
Prerequisites None
Participants get a technical and functional
overview of the SAP Business
Course InformationWarehouse.
Goals They gain a first impression of the way the
SAP Business Information Warehouse works,
its functions, and its use.
Course Description
SAP's data warehousing strategy in the
Business Information Warehouse The
Business Information Warehouse as a
dedicated component in the SAP Business
Framework Metadata administration in a
heterogeneous landscape
The SAP Business Information Warehouse
data model
Course
Transferring and homogenizing application
Content
data in the SAP Business Information
Warehouse Organizing and monitoring data
transfer
Online analytical processing with the Business
Explorer
Organization of Decision Support using
InfoCatalogs, user groups, and new browser
techniques

BW 205: Business Information Warehouse (BW)-Analysis

Course Description
Length 2 Days
Target Project team members with basic knowledge
Audience of data warehousing and SAP R/3 experience
Prerequisites None
Participants gain BW knowledge to ensure the
Course
successful implementation use of the BW
Goals
analysis tools.
Course Description
Introduction to working with the SAP BW
analysis tools: Overview of the basic data
warehousing concepts and the SAP BW
Course architecture; Overview of the basic query
Content navigation functions; Creating reports with the
Query Builder of the Business Explorer
Analyzer. Organizing queries in InfoCatalogs
using the Business Explorer Browser
This course is a prerequisite for the course
Notes BW210 Business InformationWarehouse-
System Configuration.

BW 210: Business Information Warehouse (BW)-System

Configuration

Course Description
Length 3 Days
Target Project team members with basic knowledge
Audience of data warehousing and SAP R/3 experience
Essential:
Basic knowledge of data warehousing
Recommended:
Prerequisites
Experience of the subject matter covered by
Level 2 and Level 3 courses for at least one
SAP R/3 application
Participants gain the detailed BW knowledge
Course they need to be able to implement and
Goals administer successfully a heterogeneous BW
landscape.
Course Description
Overview of the basic concepts and
architecture of the SAP Business Information
Warehouse Hands-on experience of working
Course
with the SAP BW tools, focusing on BW data
Content
modeling and ETL (Extraction,
Transformation, Loading of Data) Introduction
to the functions of the BW Metadata repository
BW210 (Business Information Warehouse
(BW)-System Configuration) is the first in a
whole series of BW courses that should
enable the participants to understand the
complex of themes behind SAP BW.
Notes
If they are primarily interested in the analysis
functions of the SAP BW, they may wish to
start by attending the one-day course BW200
(Business Information Warehouse [BW]-
Overview), and then attend the course

BW220: Business Info. Warehouse (BW)-SAP OLTP

Extraction

Course Description
Length 2 Days
Target
SAP BW application developers
Audience
Course Description
Essential:
Basic knowledge and experience of the
subject matter covered by Level 2 and Level 3
training courses for at least one SAP R/3
Prerequisites application Knowledge of the subject matter
covered by BW210 dealing with the BW
Administrator Workbench Recommended:
Knowledge of R/3 Basis: Data Dictionary and
ABAP/4 Programming
Participants gain detailed knowledge of the
Course
various possibilities for extracting data in an
Goals
R/3 OLTP system.
Participants gain a better understanding of
various extraction mechanisms within the SAP
R/3 OLTP
Overview of the basic concepts of OLTP
extraction
Course Implementing individual extraction techniques
Content using function enhancements Hands-on
experience of working with the SAP BW tools,
focusing on BW data modeling and ETL
(Extraction, Transformation, Loading of Data)
Transferring CO-PA data from SAP R/3 into
SAP
Examples from other applications

D20BW: Business Information Warehouse (BW)-Delta

with Release 2.0

Course Description
Length 3 Days
Course Description
Project team members with extensive
Target
knowledge of BW Release 1.2B and
Audience
appropriate SAP R/3 experience
This course explains the changes made for
BW Release 2.0 only, and is therefore
Prerequisites
completely unsuitable for people who are not
familiar with the SAP BW.
Course Participants gain detailed knowledge of the
Goals changes made for BW Release 2.0.
An explanation of changes made in the
following areas: General-Geographical
Information Systems; InfoCube download;
Transport Wizard SAP BW Business Explorer-
Web Reporting; Exception Reporting; Multi
Course
Cube query SAP BW OLAP-Authorization
Content
check during drilldown; Drilldown to OLTP-
OLAP API Business Content-Role-based
Business Content; Business Content of New
Dimension partners; Industry-specific
Business Content
The same version of this course is offered to
Notes
SAP customers and partners alike.

Team-Fly
Team-Fly
SAP BW ODBO-Certified Products

Figure A-2: ODBO-

Certified Products to Access Data in SAP BW as Listed on the
SAP Web Site.

Team-Fly
Team-Fly
SAP BW Staging BAPI-Certified Products

Figure A-3: Staging

BAPl-Certified Products to Load Data in SAP BW as Listed on the
SAP Web Site.

Team-Fly
Team-Fly
Appendix B: SAP BW and SAP R/3
Transactions, Tables, and Code Examples
In this Appendix
This appendix contains a few often-used programs, transactions,
function modules, and database tables in the SAP R/3 OLTP and
SAP BW instance. It also lists a sample InfoCube Update program
that was generated by SAP BW 1.2B when a simple update rule was
defined for the sales analysis InfoCube that was designed in Chapter
12.

Team-Fly
Team-Fly
SAP BW 1.2B Programs in the SAP R/3 OLTP
Instance
Data Extractors

Program Description
RMCSBIWC SAP BW connection for LIS InfoStructure
CO/PA -> SAP BW metadata maintenance
RKEBW100
utility
RKEBW200 Display CO/PA -> SAP BW: tool functions
RGUCBIW0 GL Table
TL InfoSource: GO, LO, and LR (i.e.,
RGUCBIW1
3FI_SL_LR)
RSAO0001 InfoSource maintenance for customer appends
RSAO0002 InfoSource maintenance for all InfoSources
RSAO0003 InfoObject assignment for attributes
RSAO0004 List of application areas with InfoSource
Test of the existing InfoObject - Display not
RSAO0005
used InfoObjects
Create and maintain customer appends
RSAO0007
(Transaction Data)
Create and maintain customer appends
RSAO0008
(Attributes)
RSAO0009 Delete InfoObjects

LIS Setup
Program Description
RMCVNEUA Statistical setup of InfoStructure: order
RMCVNEUL Statistical setup of InfoStructure: delivery
RMCVNEUF Statistical setup of InfoStructure: invoice
Statistical setup of InfoStructure: material
RMCBNEUA
movements
RMCBNEUB Statistical setup of InfoStructure: stocks
Statistical setup of InfoStructure: purchasing
RMCENEUA
movements
Reorganization of Quality Maintenance
RMCQNEUA
information structures
Statistical setup of InfoStructure: purchasing
RMCENEUA
documents
RMCSBIWX Settings for SD-InfoStructures
RMCSBIW0 Activation of InfoStructure

Team-Fly
Team-Fly
SAP BW Tables
Key Tables in SAP R/3 OLTP

SAP BW Key Tables in SAP R/3 in OLTP

RSSGTPDIR BW programs for each LIS/BW table
Keeps status of active LIS Change Log
TMCBIW
table SxxxBIW1 or SxxxBIW2
Keys for LIS Change Log LIS tables
TMCBIWU
SxxxBIW or SxxxBIW2 for TMCBIW
TMC4 Global Control Elements: LIS InfoStructure
InfoObject and InfoSource characteristics
RODCHA
mapping
RODCHABAS InfoObject basic characteristics
RODIOBJCMP Compounded InfoObjects
RODCHABGEN Display InfoObject with hierarchy
RODIR Released object directory
RODKYF Key figures
RODTIM Time characteristics
RODUNI Unit of measure characteristics
RODCHA InfoObjects mapping
ROHIEBAS Hierarchy for basic characteristic
ROIDOCPRMS IDOC Parameter Source System (SM30)
ROISIOBJ InfoSource/InfoObject relationship
ROIS InfoSources
 SAP BW Key Tables in SAP R/3 in OLTP
ROISGEN InfoSource Transfer Structure IDOC

Function Modules on SAP R/3 OLTP for LIS Extracts

MCS_BIW_LIS_API

MCS_BIW_UPDATE_SWITCH

MCS_BIW_CHANGE_KEY_ORDER

MCS_BIW_CODING_GENER

MCS_BIW_DBTABLE_DOUBLER

MCS_BIW_DB_DATA_COLLECT

MCS_BIW_DROP_CREATE_TABLE

MCS_BIW_DTEL_GENER

MCS_BIW_FULL_UPDATE_PREPARE

MCS_BIW_LIS_CONVERT_SELECT

MCS_BIW_STRUCTURE_CREATE

Programs to Update LIS BW Tables

Program Description
RMCSS260 Statistical program to update LIS table S260
RMCSS261 Statistical program to update LIS table S261
RMCSS262 Statistical program to update LIS table S262

BW Function Modules On SAP R/3 OLTP

Function module name
MASTER_IDOC_DISTRIBUTE_BIW
FBIW_DATA_TRANSFER_AP_1
FBIW_DATA_TRANSFER_AP_2
FBIW_DATA_TRANSFER_AR_1
FBIW_DATA_TRANSFER_AR_2
FBIW_DATA_TRANSFER_GL_1
FBIW_DATA_TRANSFER_GL_2
FBIW_SELECT_FIELD_TABLE_FILL
FBIW_SELECT_RANGES_FILL
G_BIW_GET_TRANSACTION_DATA
G_BIW_INFOSOURCE_ASSIGN
G_BIW_INFOSTRUCTURE_GENERATE
HR_BIW_GET_DATA
HR_BIW_GET_MASTER_DATA
HR_BIW_GET_TEXTS
RKE_BIW_CHECK_CLIENT
RKE_BIW_CHECK_ERKRS
RKE_BIW_ISOURCE_STATUS_GET
RKE_BIW_ISOURCE_STATUS_SET
RKE_BIW_READ_ISRC_FROM_DB
RKE_BIW_TKEBWLG_BUFFER_INVALID
RKE_BIW_TKEBWLG_INTERFACE
Function module name
RKE_BIW_TKEBWL_BUFFER_INVALID
RKE_BIW_TKEBWL_INTERFACE
RKE_BIW_F4_COPA_ISOURCE
RKE_BIW_FULL_GENERATE
RKE_BIW_GET_DATA_API
RKE_BIW_GET_FNAM_FOR_IOBJ
RKE_BIW_GET_NC_STATUS
RKE_BIW_GET_PERIV
RKE_BIW_MASTERDATA_EXIM
RKE_BIW_MASTER_DATA_GET
RKE_BIW_TRECS_AVAIL
RKE_BIW_TRECS_BUILD_SELTAB
RKE_BIW_USE_MESSAGE_HANDLER
RKE_BIW_USE_OPTIMIZED_TRANSFER
KKB_CO_DATA_TO_BIW
MCB_BIW_LIS_API
MCS_BIW_CHANGE_KEY_ORDER
MCS_BIW_CODING_GENER
MCS_BIW_DBTABLE_DOUBLER
MCS_BIW_DB_DATA_COLLECT
MCS_BIW_DROP_CREATE_TABLE
MCS_BIW_DTEL_GENER
Function module name
MCS_BIW_FULL_UPDATE_PREPARE
MCS_BIW_LIS_API
MCS_BIW_LIS_CONVERT_SELECT
MCS_BIW_STRUCTURE_CREATE
MCS_BIW_UPDATE_SWITCH
HR_BIW_EXTRACT_IO_OCCUPANCY
HR_BIW_EXTRACT_IS_ACTION
ECPCA_BIW_GET_ACCT
ECPCA_BIW_GET_ACCT_TEXT
ECPCA_BIW_GET_DATA
PS_BIW_GET_ACTIVITY
PS_BIW_GET_WBS_ELEMENT
REOM_OM_GET_BIW_PARTNER
RSAP_BIW_CONNECT
RSAP_BIW_CONNECT_30
RSAP_BIW_DISCONNECT
RSAP_BIW_DISCONNECT_30
RSAP_IDOC_EINBUCHEN_VOM_BIW
RSAP_IDOC_FIND_ALL_FROM_BIW
RSAP_IDOC_MONITOR_FROM_BIW
GET_BIW_SYSTEM
RSAP_SOURCESYSTEM_BIW_CONNECT
Function module name
RSA_LOGICAL_SYSTEM_BIW_GET
RS_BIW_ACTIVE
RSAX_BIW_GET_DATA
RSAX_BIW_GET_MASTER_DATA
RSAX_BIW_GET_TEXTS

Tables in SAP BW 1.2B

Table Description
RSIS InfoSource
RSISFIELD InfoSource/InfoObjects relationship
RSISFIELDSH Shadow table: InfoSourceFields
RSISODS ODS
RSMDDELTA Master Data Delta Handling
InfoSourceFields-provider structure of a
RSISOFIELD
source system
InfoSource (transaction data) in source
RSISOLTP
system
RSISOLUDEL InfoSource hidden by user in OLTP
InfoSource Selection Fields of a source
RSISOSELFD
system
RSISSELFDSH Shadow table: InfoSourceFields
RSISSH Shadow table: InfoSource
RSIST InfoSource Texts
Table Description
RSISTSH Shadow table: InfoSource texts
RSISUDEL InfoSource hidden by user

Transactions in SAP BW

Transaction
Description
Code
ALE Inbound IDOC - ALE manual
BALE
processing
CMOD SAP Enhancements: Project Management
ListCube InfoCube table content
List of InfoCube dimensions and
ListSchema
characteristics
RSA1 Administrator Workbench
RSD1 Edit InfoObject
RSDCube System Settings-Edit InfoCube
RSDCubem Edit InfoObject
RSDIOBCM Edit InfoObject Catalog
RSDDV Aggregate Maintenance
RSIS InfoSource (Transaction Data)
RSRT Report Monitor
RSU2 Update Change Rules
SNUM Number Ranges Object Maintenance
SPAM SAP Patch Manager
Transaction
Description
Code
SCC4 Display View "Clients": Overview
SE38 ABAP Editor Programs
SALE ALE Configuration
SE37 ABAP Editor Function Modules
SE01 Transport Organizer
SE10 Customizing Organizer
SE11 Dictionary
SE16 Data Browser
SE91 Check error messages
SM04 Overview of users
SM12 Select lock entries
SM30 Maintain Table Views: Initial Screen
SM31 Table maintain
SM37 Job overview
SM38 Define job
SM59 Display and maintain RFC Destinations
SM62 Display/edit events
SU01 Create user profile
SWU3 Check error message
SAPBWNEWS Documentation
WE07 IDOC-Statistics
WE20 Partner profiles
Transaction
Description
Code
WE21 WF-EDI port definition
DB02 Table space monitoring
RSB1 Check program for InfoSource/InfoCube

Team-Fly
Team-Fly
InfoCube Update Code Examples
In Chapter 12, you defined a simple Sales Analysis InfoCube,
IC_CUBE02, with characteristics Customer number, Distribution
channel, and Material number; and one key figure, Amount, as
shown in Figure B-1. As a result of the update rules definition to
populate the InfoCube, SAP BW 1.2B will generate the following
program. The SAP BW scheduler will use this program to populate
the InfoCube.

Figure B-1: SAP BW Model for the IC_CUBE02 InfoCube as

Described in Chapter 12.

**************************************************
**********************

*
* Generated report for update: Business
Information Warehouse *

* Template......: RSTMPLUR

* InfoCube......: IC_CUBE02

* InfoSource....: IS_SALES_DATA *
Author........: BWADMIN

* Date..........: 09.08.1999 11:11:06

* Do not change this report !

**************************************************
**********************
REPORT GPDKBVHM89E97PCFLJYLCF434T5 MESSAGE-ID
RSAU.

TYPE-POOLS:

RSAU, RSAA, RSARR, RSA, RS, RSSM.

INCLUDE RSAUIDOCSTAT.

TYPES:

BEGIN OF G_S_HASHED_CUBE.

INCLUDE STRUCTURE /BIC/VIC_CUBE02T.

TYPES:
 F0AMOUNT0001 TYPE RS_BOOL, END OF
G_S_HASHED_CUBE,

G_T_HASHED_CUBE TYPE HASHED TABLE OF

G_S_HASHED_CUBE

WITH UNIQUE KEY

CUSTOMER

DISTR_CHAN

MATERIAL

CALYEAR

CURRENCY

G_T_COMSTRU LIKE /BIC/CSIS_SALES_DATA OCCURS 0.

DATA:

G TYPE G_S_HASHED_CUBE,
G_S_KBTBX TYPE G_S_HASHED_CUBE, G_S_KB
TYPE G_S_HASHED_CUBE, G_T_KB TYPE
G_T_HASHED_CUBE, G_S_IS LIKE
/BIC/CSIS_SALES_DATA, * name convention violated
in the following variables COMM_STRUCTURE LIKE
/BIC/CSIS_SALES_DATA, I_RECORD_NO LIKE SY-
TABIX, RECORD_NO LIKE SY-TABIX, I_RECORD_ALL
LIKE SY-TABIX, RECORD_ALL LIKE SY-TABIX,
I_LOGSYS LIKE RSUPDSIMULH-LOGSYS,
SOURCE_SYSTEM LIKE RSUPDSIMULH-LOGSYS, I_DATAP
TYPE RSARR_S_RECEIVE_HEADER3-DATAPAKID, I_IDOCNUM
TYPE RSARR_IDOC_DOCNUM, I_REQUNR TYPE
RSARR_S_RECEIVE_HEADER3- REQUEST, I_INFOCUBE
TYPE RSAU_S_UPDINFO-INFOCUBE, MONITOR LIKE
RSMONITOR OCCURS 0 WITH HEADER LINE, ABORT
LIKE SY-SUBRC,
RSMONINC5M,

RSMONINC5C,
 RSMONINC5W,

RSMONINC5G.

**************************************************
**********************

* fill infocube with infosource data

**************************************************
**********************

FORM UPDATE_INFOCUBE

TABLES I_T_ISOURCE TYPE G_T_COMSTRU

 USING I_S_MINFO TYPE RSSM_S_MINFO

I_DATAP_INIT TYPE
RSARR_S_RECEIVE_HEADER3-DATAPAKID

I_IDOCNUM_INIT TYPE RSARR_IDOC_DOCNUM

CHANGING C_T_IDOCSTATE TYPE RSARR_T_IDOCSTATE

C_SUBRC LIKE SY-SUBRC.

DATA:

L_S_IC TYPE G_S_HASHED_CUBE, L_T_IC

TYPE G_T_HASHED_CUBE, L_WA_NEW TYPE
RS_BOOL, L_VAL_SET TYPE RS_BOOL,
L_FSCVTSRC TYPE RSAU_S_UPDINFO-FSCVTSRC,
L_T_RSMONDATA LIKE RSMONVIEW OCCURS 0 WITH
HEADER LINE.
 ERROR_CATCH.

* init global vars

I_INFOCUBE = 'IC_CUBE02'.

I_REQUNR = I_S_MINFO-REQUNR.

* i_record_no

* i_record_all

SOURCE_SYSTEM = I_S_MINFO-LOGSYS.

I_LOGSYS = I_S_MINFO-LOGSYS.
 I_DATAP = I_DATAP_INIT.

I_IDOCNUM = I_IDOCNUM_INIT.

REFRESH: MONITOR.
* check, if source of fiscvarnt has changed CALL
FUNCTION 'RSAU_FISCVARNT_INFO_GET'

EXPORTING

I_INFOCUBE = 'IC_CUBE02'

I_ISOURCE = 'IS_SALES_DATA'

IMPORTING

E_FSCVTSRC = L_FSCVTSRC

EXCEPTIONS
 ISOURCE_NOT_FOUND = 1

UNSPECIFIED_ERROR = 2

OTHERS = 3.

IF SY-SUBRC <> 0 OR

L_FSCVTSRC <> 'NO'.

SIMPLE_ERROR C_T_IDOCSTATE 'UPDATE_INFOCUBE'

'497'

'NO' L_FSCVTSRC RSMONINC5G.

C_SUBRC = 1.

EXIT.

ENDIF.
* log 'start update'-event

INCLUDE RSMONINC55.

DESCRIBE TABLE I_T_ISOURCE LINES I_RECORD_ALL.

RECORD_ALL = I_RECORD_ALL.

LOOP AT I_T_ISOURCE INTO G_S_IS.

I_RECORD_NO = SY-TABIX.

RECORD_NO = I_RECORD_NO.
 L_WA_NEW = RS_C_FALSE.

L_VAL_SET = RS_C_FALSE.

CLEAR G_S_KB.

REFRESH G_T_KB.

CLEAR G_S_KBTBX.

*
**************************************************
******************

* * update rule no...: 0001

* * update infoobject: 0AMOUNT

*
**************************************************
******************

PERFORM R0001_0AMOUNT

CHANGING L_WA_NEW L_VAL_SET C_T_IDOCSTATE

C_SUBRC.
IF C_SUBRC <> 0.

EXIT

ENDIF.

*
**************************************************
******************

* * save last key figure to key figure buffer

table *
**************************************************
******************

IF L_VAL_SET = RS_C_TRUE.
 IF L_WA_NEW = RS_C_FALSE. "read from
table !!!

DELETE TABLE G_T_KB FROM G_S_KBTBX.

ENDIF.

* INSERT G_S_KB INTO TABLE G_T_KB.

L_VAL_SET = RS_C_FALSE.

CLEAR G_S_KB.

ENDIF.

* insert records from the keyfigure buffer table

into the local cube LOOP AT G_T_KB INTO G_S_KB.

READ TABLE L_T_IC INTO L_S_IC WITH TABLE KEY

 CUSTOMER = G_S_KB-CUSTOMER

DISTR_CHAN = G_S KB-DISTR_CHAN

MATERIAL = G_S_KB-MATERIAL

CALYEAR = G_S_KB-CALYEAR

CURRENCY = G_S_KB-CURRENCY

IF SY-SUBRC = 0. "heureka
IF G_S_KB-F0AMOUNT0001 = RS_C_TRUE.

L_S_IC-F0AMOUNT0001 = RS_C_TRUE.

L_S_IC-AMOUNT = L_S_IC-AMOUNT +
 G_S_KB-AMOUNT.

ENDIF.

MODIFY TABLE L_T_IC FROM L_S_IC.

ELSE.

INSERT G_S_KB INTO TABLE L_T_IC.

ENDIF.

ENDLOOP.

ENDLOOP.

PERFORM USER_MESSAGE CHANGING C_T_IDOCSTATE.

IF C_SUBRC <> 0.
 EXIT.
ENDIF.

* fill the InfoObject 0REQUID

IF I_S_MINFO-CANCELLATION = RS_C_TRUE.

L_S_IC-REQUID = I_S_MINFO-CANCELLATIONREQUNR.

ELSE.

L_S_IC-REQUID = I_S_MINFO-REQUNR.

ENDIF.

MODIFY L_T_IC FROM L_S_IC

 TRANSPORTING REQUID

WHERE REQUID IS INITIAL OR

NOT REQUID IS INITIAL.

* log 'stop update'-event

DESCRIBE TABLE L_T_IC LINES SY-TFILL.

INCLUDE RSMONINC59.
IF I_S_MINFO-CANCELLATION = RS_C_TRUE.

PERFORM CANCELLATION_CONVERT

CHANGING L_T_IC C_T_IDOCSTATE C_SUBRC.

IF C_SUBRC <> 0.

EXIT.

ENDIF.

ENDIF.
 PERFORM WRITEIC(GPDMGLMY6URMYDHLS4691XYERYX)
USING L_T_IC

I_S_MINFO

I_DATAP

I_IDOCNUM

CHANGING C_T_IDOCSTATE

C_SUBRC.

ERROR_ENDCATCH C_T_IDOCSTATE 'UPDATE_INFOCUBE'

I_RECORD_NO.
ENDFORM.
FORM USER_MESSAGE

CHANGING C_T_IDOCSTATE TYPE

RSARR_T_IDOCSTATE.

DATA:

L_S_MONITOR LIKE RSMONITOR, L_S_IDOCSTATE

TYPE RSARR_S_IDOCSTATE, L_S_RSMONDATA LIKE
RSMONVIEW, L_T_RSMONDATA LIKE RSMONVIEW OCCURS 0.

LOOP AT MONITOR INTO L_S_MONITOR.

* user messages
 IF L_S_MONITOR-MSGTY = RS_C_ERROR.

* make idoc entry

MOVE-CORRESPONDING L_S_MONITOR TO
L_S_IDOCSTATE.

L_S_IDOCSTATE-STATUS =
RSARR_C_IDOCSTATE_ERROR.

L_S_IDOCSTATE-UNAME = SY-UNAME.

L_S_IDOCSTATE-REPID = SY-REPID.

L_S_IDOCSTATE-ROUTID = 'USER_DEFINED'.

APPEND L_S_IDOCSTATE TO C_T_IDOCSTATE.

ENDIF.
* monitor entry

MOVE-CORRESPONDING L_S_MONITOR TO
L_S_RSMONDATA.

L_S_RSMONDATA-RNR = I_REQUNR.

L_S_RSMONDATA-DATAPAKID = I_DATAP.

L_S_RSMONDATA-IDOCNUM = I_IDOCNUM.

L_S_RSMONDATA-AUFRUFER = '57'.

IF L_S_IDOCSTATE-MSGTY = RS_C_ERROR.

L_S_RSMONDATA-ERROR = RS_C_TRUE.

ELSE.
 L_S_RSMONDATA-ERROR = RS_C_FALSE.

ENDIF.

APPEND L_S_RSMONDATA TO L_T_RSMONDATA.

ENDLOOP.

* user defined messages monitor entries

CALL FUNCTION 'RSSM_MON_WRITE_MONITOR_IC'

EXPORTING

AGGREGATE = 'N'

TABLES

DATA = L_T_RSMONDATA.
ENDFORM.

**************************************************
**********************

* routine to convert InfoCube data for

cancellation mode
**************************************************
**********************

FORM CANCELLATION_CONVERT

CHANGING C_T_IC TYPE G_T_HASHED_CUBE

 C_T_IDOCSTATE TYPE RSARR_T_IDOCSTATE

C_SUBRC LIKE SY-SUBRC.

DATA:

L_S_IC TYPE G_S_HASHED_CUBE,

L_RECORD_NO LIKE SY-SUBRC, L_MODIFIED TYPE
RS_BOOL, L_T_RSMONDATA LIKE RSMONVIEW OCCURS 0
WITH HEADER LINE.

ERROR_CATCH.

LOOP AT C_T_IC INTO L_S_IC.

 L_RECORD_NO = SY-TABIX.

L_MODIFIED = RS_C_FALSE.

IF L_S_IC-F0AMOUNT0001 = RS_C_TRUE.

L_S_IC-AMOUNT = -1 * L_S_IC-AMOUNT.

L_MODIFIED = RS_C_TRUE.

ENDIF.

IF L_MODIFIED = RS_C_TRUE.

MODIFY TABLE C_T_IC FROM L_S_IC.

ENDIF.

ENDLOOP.
 ERROR_ENDCATCH C_T_IDOCSTATE
'CANCELLATION_CONVERT' L_RECORD_NO.
ENDFORM.

**************************************************
**********************

* cha_calculation
**************************************************
**********************

FORM CHA_CALCULATION

CHANGING L_RETURNCODE LIKE SY-SUBRC

C_T_IDOCSTATE TYPE RSARR_T_IDOCSTATE

C_SUBRC LIKE SY-SUBRC.

DATA:

L_T_RSMONDATA LIKE RSMONVIEW OCCURS 0 WITH

HEADER LINE, L_FSCVTVAL TYPE RSAU_S_UPDINFO-
FSCVTVAL.
 G-CUSTOMER = G_S_IS-CUSTOMER.

G-DISTR_CHAN = G_S_IS-DISTR_CHAN.

G-MATERIAL = G_S_IS-MATERIAL.

G-CALYEAR = G_S_IS-CALYEAR.

G-CURRENCY = G_S_IS-CURRENCY.

ENDFORM.

**************************************************
**********************
* update rule no...: 0001

* update infoobject: 0AMOUNT

* update field.....: AMOUNT

**************************************************
**********************

FORM R0001_0AMOUNT

CHANGING C_WA_NEW TYPE RS_BOOL

C_VAL_SET TYPE RS_BOOL

C_T_IDOCSTATE TYPE RSARR_T_IDOCSTATE

C_SUBRC LIKE SY-SUBRC.

DATA:
 L_KYF TYPE G_S_HASHED_CUBE-AMOUNT,
L_FSCVTVAL TYPE RSAU_S_UPDINFO-FSCVTVAL,
L_SUBRC LIKE SY-SUBRC, L_RETURNCODE LIKE
SY-SUBRC, L_T_RSMONDATA LIKE RSMONVIEW OCCURS 0
WITH HEADER LINE.

ERROR_CATCH.

CLEAR G.

* common characteristics calculation PERFORM

CHA_CALCULATION

CHANGING L_RETURNCODE C_T_IDOCSTATE C_SUBRC.

IF L_RETURNCODE <> 0 OR C_SUBRC <> 0.

EXIT.
ENDIF.

L_KYF = G_S_IS-AMOUNT.

G_S_KB-CUSTOMER = G-CUSTOMER.

G_S_KB-DISTR_CHAN = G-DISTR_CHAN.

G_S_KB-MATERIAL = G-MATERIAL.

G_S_KB-CALYEAR = G-CALYEAR.

G_S_KB-CURRENCY = G-CURRENCY.
 C_WA_NEW = RS_C_TRUE.

g_s_kb-AMOUNT = g_s_kb-AMOUNT + 1_kyf.

G_S_KB-F0AMOUNT0001 = RS_C_TRUE.

C_VAL_SET = RS_C_TRUE.

G_S_KB-CURRENCY = G-CURRENCY.

ERROR_ENDCATCH C_T_IDOCSTATE 'R0001_0AMOUNT'

I_RECORD_NO.

ENDFORM.
Team-Fly
Team-Fly
Appendix C: Selected SAP BW OSS Notes
In this Appendix
Caution This appendix lists SAP BW OSS notes. Remember
that the content of OSS notes changes frequently.
Therefore, these OSS notes may become obsolete at
any time with the new release or a new patch or
workaround.

Team-Fly
Team-Fly
Basis Notes

Description OSS Note

An Overview on SAP R/3 Add-On Components 0108103
Collective Notes on Source System
0184971
Connections
Converting Logical System Names 0121163
Installing SAP BW Statistics Cube 0145304
Installation of PA-99 for SAP R/3 0181474
Parameter Setting of SAP BW Systems - 0180605;
Oracle 109779
Patch Level of Basis in SAP BW System 0162842
Post SAP BW Add-On Imports 0141650
Release Strategy - SAP BW Business Content
0099907
and Extractors
Release Strategy - SAP BW Software 0153967
SAP BW Front-End Patch Installations 0120632
SAP BW Landscape - Path to Production 0184447
SAP Query Enhancements for SAP BW 0158847

Team-Fly
Team-Fly
Business Content

Description OSS Note

BW Master Data Delta Extraction 0141436
Deleting Data from Fact Tables 0158550
Delta Support for Master and Transaction Data 0190124
Generic Data Extractor 0144746
Transfer SAP BW Business Content 0120685

Team-Fly
Team-Fly
General Purpose

OSS
Description
Note
BW Infrastructure 0137285
BW Statistics 0176616
Collective Note - BW Tips and Tricks 0130691
Collective Note Performance BW 1.2B 0156319
Large BW-Systems and Performance of
0175534
Aggregate Build

Team-Fly
Team-Fly
Reporting and Analysis

Description OSS Note

Authorization in SAP BW Reporting 0121514
Calculations with Restricted Key Figures 0138441
Hierarchy - Filter and Display 0146793
How to Display Variables in BEX Analyzer 0116246
Percent Function in SAP BW 0119280
Required Authorizations for Use of ODBO 0164214
Use of Variables in Query - Tips and Tricks 0121291

Team-Fly
Team-Fly
Warehouse Management

OSS
Description
Note
Aggregates and Exceptions Aggregation 0125681
Buffering Master Data 0152683
Collective Notes of BW Authorizations 0130561
CTS for BW Objects 0127326
Deleting Master Data and Texts in SAP BW 1.2B 0146752
Loading Data and User-Exits 0144959
Loading Hierarchies - Non SAP via Flat File 0157628
Loading Large Amounts of Data 0115407
Options to Find Aggregates 0166433
Performance When Loading Large Amounts of
0124532
Data
Upload of Transaction Data into SAP BW 0130253
SAP BW Performance 184905

Team-Fly
Team-Fly
Appendix D: Key Enhancements in SAP BW
2.0
In this Appendix
After working with SAP BW since its conception, one thing I can say
for sure is that its functionality is rapidly changing. Every patch is
loaded with fixes or feature enhancements, making SAP BW a viable
data warehousing solution. Now, SAP BW 2.0B general availability is
around the corner, and, as expected, it offers significant
enhancements that make SAP BW Internet ready and supports
Operational Data Store and Business Document Services that puts
SAP BW right in the middle of the corporate extraprise information
supply-chain network. This appendix describes a few of the
enhancements in SAP BW 2.0A and SAP BW 2.0B.

Team-Fly
Team-Fly
SAP BW 2.0B Architecture
This release has several architectural changes to overcome
InfoCube management. Following are only a few topics that have the
most significant impact on SAP BW architecture.

The ROLAP Implementation-Star Schema Model

In its earlier versions, the star schema and its dimension tables,
associated with a fact table, were connected to master data via SID
tables. To optimize the slowly changing dimensional implementation
in the SAP BW 2.0 OLAP model, SAP has changed its master data
management architecture to separate time-independent and time-
dependent master attributes. This separation of time-dependent data
is represented in the star schema, which now has two SID tables
associated with master data characteristics. An example of schemas
in SAP BW 1.2B and 2.0A is shown in Figure D-1 as well as on the
accompanying CD. You can list schemas using the LISTSCHEMA
transaction. A Lotus ScreenCam movie on the accompanying CD
shows how to list schema models in SAP BW 2.0A for a Basic
InfoCube, an ODS object, and the MultiCube using the
LISTSCHEMA transaction.
 Figure D-1: InfoCube
Schemas in SAP BW 1.2B, on the Top, and BW 2.0A, on the
Bottom. Notice How the New Star Schema Accounts for Several
New SID Tables, Where Each Dimension Characteristic Has
Time-Dependent Master Data.

Note Prior to the BW 2.0A release, InfoObject names were

limited to a maximum of 32 characters. Now you can have
an InfoObject name with up to 60 characters.

InfoSources and Data Sources in SAP BW

In SAP BW 2.0, the traditional InfoSource has been divided into two
entities: the InfoSource and the DataSource. The reason for this split
is to make metadata management simpler. For example, in SAP BW
1.2B, the InfoSources were very specific to individual Source OLTP
systems, and that required installation, field mappings, and
management of InfoObjects in both places: SAP R/3 OLTP and SAP
BW. This situation gets complicated when you have multiple SAP
R/3 OLTP instances for SAP BW. When you update metadata in
SAP BW from the source system, the SAP R/3 that gets connected
first wants to send metadata to SAP BW. This may cause problems if
some source systems have different InfoObject definitions than the
one that sent the metadata to SAP BW.

In SAP BW 2.0, InfoSources on OLTP are called DataSources. The

metadata is simply replicated from the source instance to SAP BW,
where necessary mapping and transformation takes place instead of
in an OLTP instance. This method is simple and has very little impact
on the SAP R/3 OLTP instance.

The Administrator Workbench

The SAP BW user interface has gone through several major

changes in the last 12 months. The SAP BW 1.2B Administrator
Workbench is shown in Figure D-2.

Figure D-2: Administrator Workbench in SAP BW 1.2B. The

 InfoCubes Tabstrip Lists all Available InfoCubes in a Tree Format
Under the InfoCubes Tree Node.

In SAP BW 1.2B, under the InfoCubes tree node, you are able to
create and manage an InfoArea or an InfoCube but not ODS. The
ODS is generated automatically when you select tRFC with ODS
transfer method, as shown in Figure 9-8, when defining transfer rules
for the communication structure.

The Administrator Workbench in SAP BW 2.0A has changed

significantly. Instead of SAP BW data object tabstrips on the top,
now you have to select a task from the Goto drop-down menu and
select an activity and the data object to from another list box, as
shown in Figure D-3.

Figure D-3: Administrator Workbench in SAP BW 2.0A and SAP

BW 2.0B.

Notice that the Administrator Workbench for SAP BW 2.0A looks

somewhat different than its earlier version in SAP BW 1.2B. In SAP
BW 2.0A, you still have the InfoCube tree node on the left, the
InfoAreas, and the generated InfoCubes. In SAP BW 2.0A, ODS
management is not fully integrated in the Administrator Workbench,
as discussed in Chapter 17. The philosophy behind Administrator
Workbench design was to present information objects in a tree
fashion that makes it easier to navigate data objects and exploit
drag-and-drop capabilities while modeling information objects.

In SAP BW 2.0B, the Administrator Workbench has gone through

significant changes, as shown in Figure D-3. The most significant
change is that there is no InfoCube tree as in SAP BW 1.2B and SP
BW 2.0A. Instead, you see a new Data targets object, as shown in
Figure D-3. The reason for this change is the fact that starting from
SAP BW 2.0B, there are two types of data targets, InfoCubes and
ODS objects. Notice that now when you select an InfoArea and right-
click, the create object context menu lists two options-Create
InfoCube and Create ODS object. Remember that the ODS object
you create here is very different than what it was in SAP BW 1.2A,
as discussed in Chapter 17.

Overall, the new Administrator Workbench is much easier to work

with, especially when creating new InfoCubes or ODS objects
because you can simply drag and drop objects from source to target
instead of switching the screens.

Another significant feature in SAP BW 2.0B Administrator

Workbench is that when you define a new InfoCube or copy an
existing InfoCube, all relevant transfer rules, dimension assignments,
update rules, as well as defined queries in the source data object are
also propagated to the new data object. This feature alone will save
hours of developers' time in SAP BW data object maintenance.

Within a year, SAP BW has gone through significant architectural

changes that change the user interface. When installing SAP BW
2.0B GA or future versions, make sure that your Basis team applies
the latest OSS notes.

The Operational Data Store (ODS)

The ODS implementation is another major architectural change in

the SAP BW 2.0 architecture. The ODS architecture has changed
the data warehouse design philosophy in 2.0; now you need to
model objects differently than when you have only InfoCubes.
Chapter 17 is dedicated to the ODS subject.

Business Document Services (BDS)

Most data warehouses are very much database- and data-centric

and not much integrated with the business processes. On the
average, about 80 percent of business information needs are based
on unstructured documents. Documenting business processes and
metadata associated with the information objects is key to making
effective business decisions. These documents may come in any
shape, size, or type and range from a simple text note from a
customer to a project proposal for salespeople in Microsoft Word, a
marketing PowerPoint presentation, or simply a fax image. In SAP
BW 2.0, SAP provides a new concept to manage documents in the
data warehouse using Business Document Services (BDS). The
BDS consists of an easy-to-integrate document management
component in the R/3 Basis System. This powerful Basis technology
extends the data warehouse scope into the knowledge and
document management boundary. You can link documents with
InfoCatalog, InfoSource, InfoObjects, InfoCubes, Reports, Queries,
or even calculated key figures in a query or report. Moreover, you
can save InfoCube star schema data models and user guides in
BDS to manage the SAP BW data warehouse development process
and its implementation.

For example, say you want to document metadata for a key figure
ZAMOUNT that you created earlier and used in the queries in
Chapter 11. Often, end users want to know what this amount means
or how it is computed in the queries. You can attach a document in
Microsoft Word or any text editor and associate with the ZAMOUNT
key figure, as shown in Figure D-4.
 Figure D-4: The BDS Document Management Environment.
Assigning a Document to Key Figure
ZAMOUNT.

To assign a new document to ZAMOUNT key figure, edit the

InfoObject and launch BDS navigator by clicking on the Document
icon as shown in the top right of Figure D-4-Edit Key figure
window marked with dotted lines. The BDS navigator allows you to
select a wide array of document types to import in the BDS
repository. In this example, you select a text document of Microsoft
Word type, copy the document content in the window on the right to
attach to ZAMOUNT key figure, and import it in the BDS. These
documents are then available to end users through the Business
Document Navigator, or by the Shift+F8 or Document commands
when available.

In addition to supporting documents about SAP BW objects, the BDS

is used to save Web Report templates to support the SAP BW Web
reporting environment.

Team-Fly
Team-Fly
Web Reporting
Prior to SAP BW 2.0, there were two methods to publish reports over
the Internet. In the first method, you use BEX Analyzer, execute
Query, and save the Microsoft workbook, with the results, on a Web
server. This workbook is then launched from an Internet browser.
Because this spreadsheet had data when it was last stored, the
Internet browser displays the results. Now if the user wants to
refresh the query, the spreadsheet will pull new query results from
SAP BW only if the user has SAP BW frontend installed at the
workstation. From here, the BEX Analyzer connection will be a
straight RFC-instead of HTTP-communication back to the SAP BW
server for data manipulation.

The second method is to use third-party products, such as inSight

from arcplan, as discussed in Chapter 15, to build dynamic analytical
applications against SAP BW using the ODBO interface.

With SAP BW 2.0, SAP has implemented methods to integrate its

Internet Transaction Server (ITS) to enable users to launch and
navigate reports over the Internet. In SAP BW 2.0B, SAP plans to
provide an ActiveX control that will enable users to dynamically
define and execute queries. Because it is an ActiveX control object
that, via RFC, communicates with the SAP BW server, you must
have Internet Explorer as your browser and not Netscape Navigator.
Check the latest SAP BW 2.0B functionality list to see if such query
generation over the Web is included in SAP BW 2.0B GA or when it
will be released.

This is the first offering of an SAP BW Web development and end-

user environment, and SAP is promising robust Web-reporting
capability when SAP BW GA is released.

SAP Web Reporting Architecture

The core of SAP BW reporting is the SAP Internet Transaction
Server (ITS), as shown in Figure D-5. The ITS transaction-centric
technology is now being extended to handle data warehouse
information delivery challenges, such as large data volumes and
non-uniform end-user data requests, and support data slicing-and-
dicing capabilities.

Figure D-5: SAP BW

Web Data Access Architecture using SAP Internet Transaction
Server (ITS) and an Internet Server.

The ITS has two gateways, WGate and AGate, as shown in Figure
D-5. These gateways and the Internet server can be run on one
Microsoft NT server, each on its own server, or in any combination.
The configuration of gateway services depends on the scalability and
performance required to meet end-user data-access needs. For
discussion purposes, I assume that all three components, AGate,
WGate, and Internet server, are configured to run on one Microsoft
NT server.

The WGate receives/sends requests from/to an Internet server in the

form of HTML. The WGate sends user requests to the AGate and
receives HTML pages (Reports). The AGate server is the place
where most of the work is done. The AGate sends RFC requests to
the SAP BW server and gets raw data back from the SAP BW
server. It is here that the AGate server pulls the metadata of the
saved query views and rendering services merge the raw data with
the report view templates and constructs HTML pages. These HTML
pages are then sent back to the Wgate, where WGate services take
care of Internet server-specific processing needed to send a final
report to the end user in HTML format.

Basic requirements for SAP BW Web reporting are the following:

A Web server with CGI support

Internet Transaction Server, Release 4.6B (from build

4620.0.0.306)

Read OSS notes to get latest list of patches for SAP BW

Web reporting

Using IMG, release the function module WEBQUERY in SAP

BW for Internet. Moreover, release the following function
modules for the BEX Browser for the Internet.

RSBB_WWW_BROWSER_GATE

RSBB_WWW_BROWSER_TREE

RSBB_WWW_BROWSER_NODE_READ

RSBB_WWW_BROWSER_NODE_SEARCH

RSBB_WWW_BROWSER_TITLEBAR

Note Due to ever-increasing emphasis on Internet technologies,

the Basis team needs to be trained on configuring and
managing the Web servers, which exceeds the typical
Basis role of managing SAP BW or SAP R/3 instances.
Most often, the Web servers may be on a totally different
platform than your SAP R/3 or SAP BW instances.
Similarly, end-user support teams need to be re-skilled for
Internet-centric end-user support functions, such as Web
browser configuration and Web temporary file management
and security.
The following section describes the SAP BW Web-reporting
environment.

Publishing Dynamic SAP BW Reports over the Internet

Figure D-6 shows SAP BW 2.0 components used to publish dynamic

reports and analytical solutions over the Web. This is a five-step
process, as shown in Figure D-6 and here:

Figure D-6: SAP BW 2.0 Web-Reporting Architecture and Five-

Step Web Reports Publishing Process.

1. Create a query using the BEX Analyzer. Save this query in

SAP BW by clicking the save icon as shown in Figure
D-7.
 Figure D-7: The SAP BW BEX Query to Publish on the
Web.

2. While in the BEX Analyzer, publish the Query View that you
want to see by default when a user opens the query.
Include your common query layout; for example, a sales
analyst may always want to see sales breakdowns by
product family (material) as a default view of sales reports.
Further analysis can be done later, such as sales by
calendar year or customer, as shown in Figure D-8. The
purpose of saving the Query view is to have a basic query
result layout posted in the SAP BW database server. The
query view in terms of SAP BW Web reporting constitutes a
data provider.
 Figure D-8: Publishing a Query View. The a Step is to
Save the Basic Query in SAP BW. The B Step is to Save
the View Query as Default View for Publishing over the
Web. Here, Sales Revenues (Amount) are Shown by
Product (Material). Step C is to Format the Layout of the
Result Set using SAP BW Web
Publisher.

3. The BW Web Publisher is a wizard that guides you through

the process of embedding one or more query views to
compose Web pages. You can use any Web page
authoring tool, such as FrontPage, Microsoft Word, or a
good old notepad, to build your pages. The BW Web
Publisher uses special HTML tags to associate query views
and hyperlinks to the objects in other pages.

4. After composing Web pages for your queries, publish the

templates in the SAP BW server. Actually, the documents
are stored in the Business Document Server (BDS), which
is now part of SAP Basis 4.6 release. To publish these
templates, click the Check In icon as shown in Figure D-
9.
 Figure D-9: The SAP BW Web Publisher Defines SAP
BW Web Report Elements Associated with the Query
View. The HTML Wizard is Used to Determine How
Items are Displayed in the Reports and Associated
Navigation Schemes. You Can Have Several Query
Views in One HTML Page. After Finalizing the HTML
Template, Click Check in to Save the HTML Template in
the SAP BW Server (BDS). To Review the Web Report,
Click the HTML Browser.

5. To view the generated Web report from within the SAP BW

Web Publisher, once the templates have been defined,
stored in the BDS, and actual query navigation views saved
in the SAP BW database server as components of an
analytical application, click the Launch Browser icon .
After SAP logon information, the current Web report is
displayed as shown in Figure D-10.
 Figure D-10: Viewing an SAP BW Analytical Application
over the Web. Note How the Original SAP BEX Query,
Shown in Figure D-7, Has been Transformed to
Dynamically Perform Data Navigation over the
Web.

Later you can call these analytical applications through any

Web server that supports CGI methods. Using WebRFC,
the ITS server connects to the SAP BW server.

The typical URL to launch SAP BW Web report is http://its-

server/scripts/wgate.dll/WebRFC/!?
_function=WEBQUERY&CMD=LDOC
&WBID=1234&PAGEID=Template_Name, where LDOC is
the document location, =WBID is the workbook ID for the
BEX Analyzer Query used to build the Web report
template, and PAGEID is the Web Report template name.
You can also add some filter tags in the URL to filter data
for specific characteristics.

When you issue the URL, you are prompted for SAP BW logon
information. After SAP logon, the BW Web service fetches the report
template from BDS, pulls data from the SAP BW database server,
and fills in the tagged values to compose the HTML page. This page
is sent back to the ITS server, and the HTML formatted reports are
shipped via the Web server to the end user.

Note At present, you cannot compose queries directly from the

Web interface. You have to create queries using BEX
Analyzer. In SAP BW 2.0B, SAP will bundle an ActiveX
control to build new queries directly over the Web. You will
be able to define new queries, but you are restricted to
using Microsoft Internet Explorer 5.0 and must have all the
SAP GUI components (RFC clients) needed to make a
direct RFC connection to the SAP BW server (not through
the Web server!). Again, check with SAP if this capability
will be available in its SAP BW 2.0B GA release.

Consult the OSS notes and apply special patches for SAP BW Web
reporting using ITS. At a higher level, you must know that the Web
server you want to use with SAP ITS must support Common
Gateway Interface (CGI) methods. Depending on the release of SAP
BW, you may need to release a few programs in SAP BW as well.
Read the installation directions very carefully before configuring the
ITS server.

Current implementation of Web reporting is somewhat limiting;

however, due to heavy focus on mySAP.com Internet strategy (for
example, workplace, marketplace, and other business critical
applications), SAP will deliver a powerful Web-centric solution to
support a wide array of analytical and business application
environments, including a robust Web-centric application
development facility to construct scalable and secure Internet-centric
solutions.

Team-Fly
Team-Fly
Business Explorer Browser
The concept of Channels in SAP BW 1.2B has been replaced with
Activity Groups. Instead of maintaining Channels and reports
assignments in InfoCatalog manager, SAP has replaced the
InfoCatalog manager with an Activity Group Maintenance program,
transaction PFCG. SAP also provides conversion utilities to migrate
InfoCatalog, Channels, and favorite entries to the new format.

Team-Fly
Team-Fly
Reference
With the release of SAP BW 2.0, just about every area in the SAP
BW development process has been enhanced. Visit SAPNet at
http://service.sap.com for the documents "Release-Infos, Business
Information Warehouse, Release 2.0A" and "BW 2.0B features." All
known enhancements are well documented in these documents.

Team-Fly
Team-Fly
Summary
SAP BW is going through a rapid development cycle, and it will take
some time for it to become a mature and stable product. The future
release will have the additional functionality to implement a stand-
alone Operational Data Store and the Business Document Server.
The next challenge facing SAP is to focus on Internet frontends and
performance improvements in all processes needed to construct,
deploy, and operate a global data warehouse. In my opinion, SAP
will meet that challenge.

Team-Fly
Team-Fly
Appendix E: What's on the CD-ROM
The CD that accompanies this book contains example projects from
the book and ScreenCam movies that show you how to execute
various processes.
Running the CD
To make the CD more user-friendly and take up less of your disk
space, no installation is required. This means that the only files
transferred to your hard disk are the ones you choose to copy or
install.

Caution This CD has been designed to run under Windows

95/98 and Windows NT 4, Neither the CD itself nor the
programs on the CD will run under earlier versions of
Windows.

Windows 95/98/NT4

Because there is no install routine, running the CD in Windows

95/98/NT4 is a breeze, especially if you have autorun enabled.
Simply insert the CD in the CD-ROM drive, close the tray, and wait
for the CD to load.

If you have disabled autorun, place the CD in the CD-ROM drive and
follow these steps:
1. From the Start menu, select Run.

2. Type D:\CDInstaller.exe (where D:\ is the CD-ROM drive).

3. Select OK.

Team-Fly
Team-Fly
The Prima License
The first window you will see is the Prima License Agreement. Take
a moment to read the agreement, and click the "I Agree" button to
accept the license and proceed to the user interface. If you do not
agree with the license, click the "I Decline" button to close the user
interface and end the session.

Team-Fly
Team-Fly
The Prima User Interface
Prima's user interface is designed to make viewing and using the CD
contents quick and easy. The opening screen contains a two-panel
window with three buttons across the bottom. The left panel contains
the structure of the programs on the disc. The right panel displays a
description page for the selected entry in the left panel. The three
buttons across the bottom of the user interface make it possible to
install programs, view the contents of the disc using Windows
Explorer, and view the contents of a help file for the selected entry. If
any of the buttons are "grayed out" it means that button is
unavailable. For example, because there are no help files for any of
the items on this CD, the Help button is always grayed out.

Resizing and Closing the User Interface

As with any window, you can resize the user interface. To do so,
position the mouse over any edge or corner, hold down the left
mouse button, and drag the edge or corner to a new position.

To close and exit the user interface, either double-click on the small
button in the upper left corner of the window or click on the exit
button (marked with a small "x") in the upper right corner of the
window.

Using the Left Panel

The left panel of the Prima user interface works very much like
Windows Explorer. To view the description of an entry in the left
panel, simply click the entry. For example, to view the general
information about Prima Publishing, Inc., click the entry Prima-Tech.

Some items have subitems that are nested below them. Such parent
items have a small plus (+) sign next to them. To view the nested
subitems, simply click on the plus sign. When you do, the list
expands and the subitems are listed below the parent item. In
addition, the plus (+) sign becomes a minus (-) sign. To hide the
subitems, click the minus sign to collapse the listing.

Note You can control the position of the line between the left and
right panels. To change the position of the dividing line,
move the mouse over the line, hold down the left mouse
button (the mouse becomes a two-headed arrow) and drag
the line to a new position.

Using the Right Panel

The right panel displays a page that describes the entry you chose in
the left panel. Use the information provided to provide details about
your selection, such as what is shown in a ScreenCam movie.

Command Buttons

Install. Use this button to install the program corresponding to your

selection onto your hard drive.

Read File. If the item you are viewing in the left panel includes an
Adobe Acrobat file (*.pdf), the Install button becomes the Read File
button. Clicking the Read File button opens the file in Adobe
Acrobat, providing you have Adobe Acrobat installed on your
computer.

Explore. Use this button to view the contents of the CD using the
Windows Explorer.

Help. This button is not active on this CD.

Pop-Up Menu Options

Install. If the selected title contains an install routine, choosing this

option begins the installation process.
Explore. Selecting this option allows you to view the folder
containing the program files using Windows Explorer.

View Help. Use this menu item to display the contents of the Help
file provided with the program.

Team-Fly
Team-Fly
Index

Symbols
000 client, 116-117
2LIS_01_S260, 282
066 client, 117

Team-Fly
Team-Fly
Index

A
ABAP (Advanced Business Application Programming), 27, 30,
292
ABAP developer, 98
ABAP Query, 30
ABAP Routine method, 272
ABAP routines, 274
ABAP routine template, 272
ABAP Workbench, 27
accessing data from third-party tools, 317-324
ActaWorks for SAP, 43, 66-67
Activate demo cube icon, 185
activate icon, 180
active client, 117-118
active dictionary, 27
Active icon, 141, 155
active LIS tables, 193
ActiveX Control Directory, 318
Activity Groups, 57, 251-252
adaptation of new technologies, 14
Administrator Workbench, 54, 128-133, 155, 410-412
changing startup view, 131
Content Delivery menu, 129-130
Content Management menu, 129-130
InfoCubes tabstrip, 131, 158-159
InfoCube view, 131
 InfoObjects tabstrip, 131, 139
InfoSources tabstrip, 131, 220
InfoSource view, 131
managing data warehouse content, 130
Monitor icon, 210
ODS tabstrip, 131
Refresh icon, 152
SAP BW content delivery functions, 129-133
Source Systems tabstrip, 131, 134, 219, 298
Source Systems view, 131
Tools menu, 176
tree format layout, 128-129
where to run, 124
Administrator Workbench menu, 139
Agate, 415
aggregate cube. See aggregates
aggregates, 54, 334
based on present queries, 336
BW statistics, 337
defining, 335-338
from existing queries, 337
last navigation steps, 337
loading data in InfoCube, 336
manual creation, 336
Aggregates Maintenance window, 335
ALE (Application Link Enabling), 36
IDOC setting, 123
messages, 123
parameters, 97
users, 123
ALEREMOTE, 288
ALEREMOTE user, 123, 136, 189
ALE user, 124, 189
analytical applications, 232
Analytical Applications Integration service, 10
Application Logic layer, 27-28
applications
analytical, 232
Web frontends, 21
application server and data files, 226
application-specific user-exits, 281
APPL_LOG_A sub-profile, 189
arcplan Web site, 317
ASAP (Accelerated SAP)
accelerators, 88
how-to guides, 88
methodology, 42
methodology and SAP BW implementation team templates, 95
templates, 88
ASC (ASCII) files, 218
aspect, 33
Audit and Controls service, 11
availability, 15
AVERS table, 124, 167

Team-Fly
Team-Fly
Index

B
B2B (business to business), 36
B2C (business to customer), 36
background data loads, 226
backup and restore of OLTP database, 37
B_ALE_ALL sub-profile, 189
BAOV transaction, 124
BAPI (Business API), 290
ETL (Extraction, Transformation and Load) tools, 43
function, 292
history of, 291
programming documents, 292
SAP BW 2.0, 324-326
BAPI Browser, 293
BAPI transaction, 293
BAPI User Guide, 292
Basic InfoCube, 269
Basis Administration for SAP, 106
Basis notes, 404
Basis team, 416
Basis technology, 27
batch printing, 130
BDS (Business Document Server), 419
BDS (Business Document Services), 413
Begin_FY variable, 130
BEX (Business Explorer), 49-51, 77, 116, 421
 architecture, 232
BEX Analyzer, 44, 50, 55, 72, 77, 130, 232-234, 310-311, 417
analyzing data, 243-246
customizing report data presentation, 238
as developer workbench, 82
drilling down data, 244-245
exiting, 79
functions, 234
logging on to, 81-82
menu bar, 234
MultiCube, 275
Query View, 417
refreshing query, 248
sessions, 254
variables in queries, 247-250
BEX (Business Explorer) Analyzer, 115
BEX Browser, 49, 57, 77, 232, 252-254, 310
applications and reports, 232
continuing data analysis, 81
displaying all valid channels, 79
EXECUTE option, 254
launching application from, 58
logging on to, 78-84
sessions, 254
URLs, 253
Web-centric interface, 232
BEX Explorer, 55
bitmapped indexes, 53
BIW_KNA1 view, 287
BIW_KNA5 view, 287
BOR (Business Object Repository), 292
bottom-up approach, 87
buffering number range objects, 332
Building the Data Warehouse, 4
Building the Operations Data Store, 350
business content, 174, 280
activating in SAP BW, 173-174
channels, 47, 280
data extractors, 45
enabling in SAP BW, 176-177
enhancing, 280-283
InfoCubes, 46, 280
InfoObjects, 45, 280
InfoSource, 46, 280
KPI (Key Performance Indicators), 47
loading InfoCube queries, 182-183
logical system names, 168
more information about, 186
notes, 405
objects and metadata, 171
order of object activation, 174
OSS notes, 168
preparing SAP BW instance, 175
queries, 47, 280
SAP BW, 261
transports to load, 167
update rules, 280
workbooks, 47
Business Content command, 176
Business Content menu, 177-178
Business Explorer menu, 115
Business Framework, 292
Business Information Warehouse, 37, 78
business intelligence, 6, 36
business objects, 67, 292
business partners, 96
business process integration, 62
business reports, 29-34
business requirements and SAP BW projects, 99-100
business rules, 27
BW 200: Business Information Warehouse (BW)-Overview, 376
BW 205: Business Information Warehouse (BW)-Analysis, 377
BW 210: Business Information Warehouse (BW)-System
Configuration, 378
BW 220: Business Info. Warehouse (BW)-SAP OLTPExtraction,
379
BW AddOn, 115
BW-BCT add-on, 124
BW-centric customizations, 119
BW Customizing Implementation Guide, 119
bw.ic_file, 320
bw.ir_file, 320
BW.isc file, 319-320
BW.isr file, 320
BWSERVER target database, 305
BW Web Publisher, 418-419

Team-Fly
Team-Fly
Index

C
calling data extractors, 169
catalog, 314
CEDBBW.SH script, 112
CGI (Common Gateway Interface), 421
change capture method, 19
Change InfoCube command, 161
Change window InfoCube Update Rule, 271
channels, 47, 57, 280
activating, 184-186
assigning to users, 184
clusters, 57
defining, 251
displaying valid, 79
listing available, 184
users, 252
Channels command, 184
characteristics
assigning to dimensions, 270-271
update rules, 271-272, 273-274
charts
attaching to queries, 239-240
changing type, 240
check icon, 155, 180
CKF (Calculated Key Figures), 182-183
client configurations, 103
Client Profile service, 11
clients, 33
client-specific reports, 33
client workstation, 348
ActiveX control, 323
data files, 224-226
installing ODBO clients, 316-317
login information, 323-324
registering objects, 317
Close (Alt+F4) key combination, 81
clusters, 57
cluster tables, 41
CMOD transaction, 280, 285
Cognos, 67
Communication Structure, 49
COM (Component Object Model) objects and interfaces, 312
comparing reporting systems, 33-34
components, 343
compounding InfoObjects, 147
Conceptual data model, 262
Conceptual model, 259
constant value, 273
consulting services Web sites, 373-374
content delivery functions, 129-133
continual improvements, 15
CO-OM (Controlling Overhead Management), 33
CO-PA (Controlling-Profitability Analysis), 32-33
corporate data warehouse team, 96
corporate information architects, 99
Create InfoArea command, 152
Create InfoCube command, 267
Create InfoObject Catalog command, 154
Create InfoObject Catalog window, 154
Create InfoPackage command, 203
Create new routine icon, 272
Create Source System command, 135, 298
Create Update Rules command, 271
CRM (Customer Relationship Management), 36
cross-InfoCube queries, 57
Crystal Info product version 7, 69
CSV (Comma Separated) files, 134, 218
type data files missing field values, 229
C_T_DATA table, 285
CTO (Correction and Transport Organizer), 109
CTS (Correction and Transport System), 109
C_T_TEXT export parameters, 287
Cube_Que-e.pdf file, 186
cubes, 51, 314
currency
characteristic, 150
conversion calculations, 175-176
cust.htm file, 322
cust.isd file, 322
cust.is_ file, 322
custom
InfoCubes, 191
InfoObjects, 139
 LIS structures, 191
Customer channel, 57
customer created objects naming scheme, 151
customer evaluations, 32
Customizing for R/3 extractors command, 283
customizing query display layout, 238

Team-Fly
Team-Fly
Index

D
D20BW: Business Information Warehouse (BW)-Delta with
Release 2.0, 380
data, 241
quality, 195
refresh, 15
replication services, 93
replication tools, 93
scrubbing, 19
transfer methods in SAP BW, 200-202
data access
BW (Business Information Warehouse), 49-50
interfaces, 310-311
database
activating and adjusting, 283
objects managing data flow and storage, 51-54
size, 344-346
database-centric data warehouses, 37-39
Database Utility command, 283
Data Cleansing service, 10
Data Consolidation service, 10
data conversions, 11
data dictionary, 142
Data Dictionary service, 12
data distribution, 16
Data Distribution service, 10
data extraction, 18, 328-329
techniques, 41
Data Extraction service, 10
data extractors, 45, 97, 384-385
calling, 169
debugging, 287-288
data files
application server, 226
client workstation, 224-226
field values, 229
header lines, 223
location, 224-225
data flow between SAP R/3, 166
data load, 203-210
ALE IDOCs mechanism, 206
background, 226
breaking into smaller jobs, 208
data providers, 216-217
defining scheme, 205
delta, 209-210
exceeding time limit, 211
fatal errors, 211
flat files, 216, 217-229
initial, 208-209
in-limbo state, 211
master data attributes, 224-226
method, 205
monitoring, 210-213, 227
monitoring utility, 210-213
non-SAP R/3 data source, 216-217
optimizing, 330
periodic, 205
platform-independent technologies, 217
pre- and post-load activities, 204-205
in progress, 211
reducing time for, 19
 resolving problems, 212, 227
Staging Business API (BAPI), 216-217
successful, 211
text and hierarchy data, 226-227
tRFC with ODS transfer method, 207-208
data loader, building with staging BAPIs, 294-296
data loads, 203-210
pre-and post-load activities, 204-205
Data Management layer, 27-28
Data Manager, 51-54
data marts, 7
data modeling, 258-259
data modeling team, 261
data objects
classes, 199
loading data, 203-210
managing, 11-12
managing and distributing, 10
Data Partitioning service, 10
Data Profiling, 10
Data Provider layer, 10
data providers, 216-217
data puddles, 6
data sets statistical update, 192
DataSource, 48
Data Source object, 157
data sources, 216
definitions, 298-299
extracting data, 295-296
gateway, 10
 naming, 135
sending extracted data to SAP BW, 295-296
Data Staging service, 10
Data Storage service, 10
Data Transformation service, 10
Data Transport service, 10
(The) Data Warehouse Lifecycle Toolkit, 95, 99
Data Warehouse Management layer, 11-12
data warehouses, 6
24-7 mode, 12
adaptation of new technologies, 14
ALE-centric, 39-40
architecture, 8
availability, 15
baseline data, 192
bottom-up approach, 87
bulk-load utilities, 217
business intelligence, 6, 260
categories, 6-8
components, 9-12
Conceptual model, 259
construction steps, 4
consulting services Web sites, 373-374
continual improvements, 15
database-centric, 37-39
data distribution, 16
data extraction techniques, 41
data growth pattern, 333
data marts, 7
Data Provider layer, 10
Data Warehouse Management layer, 11-12
Deployment model, 260
dimensions, 17
enterprise business intelligence needs, 260
extraprise, 5, 8
flat files, 216
Global catalog, 13
Global Information Delivery services, 13
high-performance, 17
hybrid approach, 87-88
implementation methodologies, 86
industry, 65
industry analysts and consulting services providers, 63
Information Consumer layer, 11
integrated enterprise, 133
loading large data volumes, 19
Logical data model, 260
magazines and literature Web sites, 372-373
manageability, 13-14
managing content, 130
metadata management, 13
modeling, 258-262
modeling in SAP BW, 261-262
network bandwidth, 16, 329
number of users, 17
ODS (operational data store), 7
performance metrics, 16-20
Physical data model, 260
poor performance, 16-17
product vendor Web sites, 374
purpose, 99
reliability, 15
SAP approach, 87-88
SAP R/3-centric environments, 37-42
scalability, 16
security, 14-15
Service Provider layer, 10
technical issues in constructing, 12-16
third-party-tool-centric, 41-42
 top-down approach, 87
traditional, 5
upgradability, 15
usage patterns, 333
(The) Data Warehouse Toolkit, 263
data warehousing
books, 370-372
data quality, 195
definition of, 4
evolution, 22
tight integration with OLTP, 22
time, 149-150
DB2, 53
DEBUG_FLAG, 288
debugging data extractors, 287-288
defining
active client, 117-118
dimensions, 264-265
facts, 265
Delta Change table, 210
delta data loads, 209-210
DELTA logs, 192
DEMO.IS_application file, 322
dependent data marts, 7, 16
dependent InfoObjects, 178
Deployment model, 260
Development Management service, 12
dimensions, 180, 314
assigning characteristics, 270-271
attributes, 264-265
defining, 264-265
 InfoCubes, 264
normalizing, 264
slicing and dicing, 265
star schema model, 264
time independent, 264
user-definable, 264
dimension tables, 51, 52
keys, 263
size, 265
disk I/O subsystem, 347
disk storage requirement, 345-346
Display InfoCube Data Model command, 181
Dresner, Howard, 6
drill-down analysis, 236, 265
drill down data, 241
D-versioned objects, 173
DynaSite, 67

Team-Fly
Team-Fly
Index

E
ECO-PCA (Enterprise Controlling-Profit Center Accounting), 32,
33
ECP (Early Customer Program), 42
EDA (Enterprise Data Access) server, 68
Edit InfoCatalog window, 154
Edit InfoCube window, 161
Edit InfoObject window, 177
Edit Query window, 248
EIS (Executive Information System), 30, 33
Employee channel, 57
End_FY variable, 130
End-user Data Synchronization service, 11
end users installing frontend components for reporting and
analysis, 115-116
enhancements, 280-282
Enterprise Applications, 22
enterprise data warehouses
accommodating new business analytical needs, 260-261
data modeling, 258-259
sourcing data, 290
Enterprise Miner, 69
enterprise-wide reporting, 92-93
entity relation models, 260
ERP (Enterprise Resource Planning), 22
data target type, 305
 evolution of, 20-22
extracting information from applications, 23
infrastructure characteristics, 23-24
ERP data warehousing, 20-24
cultural impact, 62-63
initiatives, 23
IT (Information Technology) changes, 63
OLTP team changes, 63
Error in the source system message, 212
/etc/sysconigtab file, 111
ETI (Evolutionary Technology Inc), 67
ETL jobs, 305
Excel add-in, 115
exiting, 79
EXIT_SAPLRSAP_001 function module, 281, 285
EXIT_SAPLRSAP_002 function module, 281-282
EXIT_SAPLRSAP_003 function module, 282, 287
EXIT_SAPLRSAP_004 function module, 282
extended multidimensional data model, 266
extended star-schema model, 46
extending
master data InfoSource content, 287
texts InfoSource, 287
transaction data content, 283-286
ExternData tabstrip, 224
extractors, installing, 124-126
Extract Structure, 48
extraprise data warehouses, 5, 8
Team-Fly
Team-Fly
Index

F
fact-based systems, 6
factless fact tables, 265
facts defining, 265
fact tables, 51-52, 180, 262
accessing, 265
computed values, 265
defining tablespaces for, 111
factless, 265
foreign keys, 263
key figures, 265
number of entries in, 265
size, 265
field-level relationships between data sources and targets, 303-
304
FI-GL (Financial General Ledger), 33
FI-LC (Financial Consolidation), 33
filtering data for queries, 183, 241-242
Financials module, 29
FIS (Financial Information System), 30, 32
FI-SL (Financial Special Purpose Ledger), 33
Fixed Length files, 134
flat files, 216, 224
1,000 bytes record limit, 224
ASCII data, 223
data loads, 217-229
data type, 223-224
dates, 224
 defining data source, 219-220
defining metadata, 220-223
hierarchies, 218
InfoSources, 205
master data, 218, 220-222
metadata, 218
missing values, 229
processing, 123
sorting, 224
source system type, 219-220
text, 218
time, 224
transaction data, 218, 227
frontend components, 73
FrontPage, 72
function module, 287
function modules for LIS extracts, 387-390

Team-Fly
Team-Fly
Index

G
gateway data sources, 10
gateways, 415
General Purpose Channel, 57
general purpose notes, 405
Genio, 43, 67-68
Genio MetaLink for SAP, 68
Genio Suite 4.0, 68
GetDetail method, 295
GetDetails method, 296
GetList method, 295
GetParameterDefinition method, 296
Global catalog, 13
Global Catalogs service, 11
Global Information Delivery services, 13
Governing Services service, 11
grouping InfoObjects, 139

Team-Fly
Team-Fly
Index

H
Hackney, Doug, 9
Hardware/Software service, 12
hierarchies, 264, 314
flat files, 218
loading data, 226-227
transfer table, 282
hierarchy intervals, 145-146
high-performance data warehouses, 17
HIS (Human Resources Information System), 30
HTML, 73
human resources module, 29
hybrid approach, 87-88

Team-Fly
Team-Fly
Index

I
IBI (Information Builders, Inc.), 68
IBM Web site, 342
IDOCs (Intermediate Documents), 39, 217
processing, 103
saving data, 206
IMG, 283, 285
independent data marts, 7
index management, 331
industry analysts and consulting services providers, 63
Industry specific module, 29
InfoAreas, 139, 152, 159
InfoCatalogs, 49, 251
Channel InfoCat tabstrip, 184
User channel assignment tabstrip, 184
InfoCube Characteristics edit window, 269-270
InfoCube content window, 163
InfoCube Edit window, 163
InfoCubes, 46, 51, 54, 158-164, 280, 334
activating, 178-181, 270-271
activating InfoObjects, 177
activating query objects, 183
aggregates, 333-338
assigning characteristics to dimensions, 270-271
associating InfoSource, 270
based on another set of InfoCubes, 269
building, 267-271
building from template, 162
characteristics, 158
checking structure, 270
CKF (Calculated Key Figures), 183
creation of, 267-274
custom, 191
database-specific options, 164
data loading strategies, 199-202
data model, 159, 161
data subset, 47
defining, or viewing dimensions, 162
defining data structures, 269-270
defining update rules, 271-274
dimension assignments, 162
dimensions, 159, 180, 264
document-level detail, 356
drilling-down to ODS, 360-361
fact table, 180
fetching data from, 54
improving data loading time, 272
improving query response time, 278
joining, 275-278
key figures, 158
listing objects, 163
loading queries from business content, 182-183
managing data flow and storage, 51-54
mapping source values to characteristics and key figures, 272
modeling, 98
multidimensional data view, 54
multidimensional modeling, 159
optimizing data access, 53
populating, 130, 158
query response, 334
selecting, 81
shared attributes, 146
shared hierarchies, 146
sharing master data, 263
 sharing reference data, 266
status, 271
subject-centric, 275
subset of, 56
summarized information, 200
summary-level detail, 356
as template, 267-268
time dimensions, 149-150
transactional data, 199
types, 267
update code examples, 392-402
update rules, 181, 276
viewing content, 163-164
viewing structure, 161-163
virtual, 269
InfoCube tree, 159
InfoArea, 267
InfoObject catalog, 139
activating, 178
creation of, 154-156
InfoObject structure, 154
saving, 155
InfoObject display screen, 177
InfoObject Edit window, 141
InfoObject icon, 139, 141
InfoObject Maintenance window, 139-141
General tabstrip, 142
Master data/text tabstrip, 142-144
InfoObjects, 45, 280
A:Active version, 139
activating, 141, 174, 177
assigning in InfoCatalog, 154
assigning to additional fields, 285
 attributes, 138, 146-147
characteristics, 140-142
classes, 138
collection of, 46
compounding, 147
creation of, 139
custom, 139
dependent InfoObjects, 178
D:SAP Delivered version, 139
editing, 139
grouping, 139
hierarchies, 145-146
language data objects, 142-144
metadata definition, 142
M:Revised version, 139
narrowing list of, 155
properties, 142
status, 141
as templates, 154-155
tree structure, 139
verifying definitions, 155
viewing attributes, 156
InfoObjects command, 177
InfoObject tree, 152
InfoObject catalog line, 152
InfoObject tree folder, 139
InfoPackages, 203, 224
data flow, 205
naming, 203
InfoPackage scheduler, 203-205, 224
Data Target folder tab, 205
Select Data tab, 208
Update Parameter folder tab, 209
Informatica, 68
Information Access APIs service, 11
Information Authoring service, 10
Information Consumer layer, 11
Information Consumer Profiling service, 11
Information Delivery service, 11
information objects, 11
Information Presentation service, 11
information structures, 31
information systems, 29-30
Informix, 53
InfoSet Query, 234
InfoSource object, 157
InfoSources, 46, 48, 156-157, 280
activating, 178
assigning source system, 220
based on flat files, 205
creation of, 157
Data Source object, 157
editing structure to append elements, 283-284
enhancing, 282
GetDetail method, 295
GetList method, 295
independent date items, 283
InfoSource object, 157
irrelevant information, 283
LIS-based, 210
listing, 295
master data flat file 220, 222
master data/text/hierarchies, 157
populating user-defined, additional fields, 281
reading metadata, 294
record length, 282
 scope, 156
transaction data, 157
transaction type, 222-223
tRFC with ODS transfer method, 207-208
when to create, 283
initial data loads, 208-209
preparation strategies, 194-199
Inmon, William H., 4, 9, 350
INSERT rows data processing mode, 305
inSight, 44, 67, 317, 326, 414
associating empty objects with cube dimensions and key figures,
320-321
building application, 319-324
cube dimensions and key figures, 320
data sources, 319
defining dependency rules, 321
defining filters or qualifiers, 321
drawing chart, 321-322
implementing application for Internet, 322
light client, 318
query cubes, 319
running application, 322
SAP BW data source, 319
setting up development environments, 328-319
typical workstation, 318
inSight DBweb Connector, 318
inSight Service, 318
inSight Web server, 318
Installation of 32-bit SAP BW Frontend Software under Microsoft
Windows NT and Windows 95/98, 111
Installation of SAP Business Information Warehouse on UNIX/Oracle
Database, 112
Installation of the SAP Business Information Warehouse on UNIX,
111
Installation of the SAP Business Information Warehouse on
UNIX/Oracle Database Release 1.2B, 111, 112, 113
Installation of the SAP Business Information Warehouse on UNIX-
OS Dependencies, 111, 112
instances
defined as data source, 176
deleting queries, 130
preparing for business content, 175-176
integrated enterprise data warehouse, 133
Integration Server for SAP BW, 297
INVCO (Inventory Controlling), 31
ISOURCE Import parameter, 285
I_T_FIELDS parameter, 285
ITS (Internet Transaction Server), 44, 72, 311, 324, 414-415
I_T_SELECT exporting table parameter, 285
I_UPMODE parameter, 285

Team-Fly
Team-Fly
Index

J
Java, 292
Java & BAPI Technology for SAP, 292
joining InfoCubes, 275-278

Team-Fly
Team-Fly
Index

K
key figures, 45
defining, 148
units of measure, 156
update method, 272
update rules, 271
Key Figures maintenance window, 148-149
key tables and SAP R/3 OLTP, 386
Kimball, Ralph, 9, 263
KPI (Key Performance Indicators), 5, 47
BW (Business Information Warehouse), 100
calculation of, 15

Team-Fly
Team-Fly
Index

L
language data objects, 142-144
Librfc32.dll file, 316
LIS (Logisitics Information System), 97
LIS (Logistics Information System), 30, 31-32
LIS-based
data sets statistical update, 192
InfoSources, 210
LIS information structures
defining synchronization scheme, 32
updating, 31
LIS Setup, 385
LIS structures
custom, 191
deactivating, 197
delta updates, 198
preparing and loading initial statistical data, 197-198
update mode enabled, 212
updating, 198, 209
LIS tables
active, 193
populating, 192
tables associated with, 192-193
LISTCUBE transaction, 163
loading
large data volumes, 19
text and hierarchy data, 226-227
logging on
 to BEX Analyzer, 81-82
to BEX Browser, 78-84
Logical data model, 260, 262
logical system definition, 117-118
logical system names, 168
associating SAP BW client, 189
Logistics module, 29

Team-Fly
Team-Fly
Index

M
magazines and literature Web sites, 372-373
Maintain InfoCube aggregates command, 335
major application modules, 29
manageability, 13-14
MappingBW mapping scheme, 304
master data, 144, 169
attribute data loads, 224-226
Attributes file, 222
deleting, 195
elements, 170-171
enhancing text, 282
extending InfoSource content, 287
flat files, 218, 220-222
function modules, 170
grouping, 196
InfoCube population process, 194
invalid records, 195
loading, 194, 208
ODS, 199
populating attributes, 281-282
quality, 195
records failing, 195
sharing across all defined InfoCubes, 263
SID tables, 194
slowly changing dimensions, 144
structure, 222
text elements, 287
time-dependent, 222
timestamping, 144
MCS_BIW_LIS_API function module, 169
MCS_BIW_UPDATE_SWITCH function module, 199
MDM (multidimensional data modeling), 262-266
defining dimensions, 264-265
defining facts, 265
star schema, 262
Mdrmsap.dll file, 316
MDS (Multidimensional Expression), 55
MDX (Multidimensional Expression), 313
Mdxpars.dll file, 316
memory, 56, 347
metadata, 10, 13
business content objects, 171
defining for flat files, 220-223
defining inbound data structures manually, 171
flat file, 218
importing from SAP R/3, 171
loading in SAP BW, 171-173
management, 13, 294-295
management in SAP BW, 170-171
non-SAP R/3 data sources, 173
refreshing, 172
table storage of, 168-169
updating, 172-173, 175
metadata repository, 138
Metadata service, 12
methodology guides on data modeling and implementation, 269
Microsoft C++, 292
Microsoft Excel, 116, 311
BEX icons in spreadsheets, 81
data analysis, 79
 SAP BW add-in, 310
VBA and ODBO programming developer, 98
Microsoft Frontpage, 72
Microsoft Office 97, 73
Microsoft Plato OLAP Server, 312
Microsoft SQL Server 7, 51
Microsoft Visual Basic, 292
Microsoft Web site, 311, 313, 314
migration path, 344
MMC (Microsoft Management Console), 126
modeling InfoCubes, 98
Monitor Assistant window, 211
monitoring data loads, 210-213
Gantt Chart format, 211
overview list format, 211
statistics in tree format, 211
MRP (manufacturing resource planning) systems, 20-21
MSA (Mobile Sales Automation) server, 13-14
Msdadc.dll file, 316
MS SQL Server, 53
MultiCube, 275-276
defining in SAP BW 2.0A, 276-278
defining view, 275
result set, 276
multidimensional data warehouses and data modeling, 258-259
multi-tiered architecture, 26
Multi-Tiered Models service, 11
mySAP.com initiative, 36
Team-Fly
Team-Fly
Index

N
navigating data, 241
networks
bandwidth, 16
configuration, 347
topology, 19-20
New Dimension products, 42
non-SAP BW information objects, managing, 253
non-SAP R/3 data sources
data loads, 216-217
metadata, 173
normalizing dimensions, 264

Team-Fly
Team-Fly
Index

O
OBASE_UOM characteristics, 150
object names, 99
objects, versions of, 173
OCITY InfoObject, 178
OCOUNTRY InfoObject, 178
OCUSTOMER characteristic, 247
OCUSTOMER InfoObject, 178
ODBC (Open Database Connectivity), 14, 312
ODBO (OLE DB for OLAP Architecture), 44, 290, 312-315, 322
crosstab format data, 313
equivalent objects in SAP BW, 314
implementation in SAP BW, 315
installing components at client workstation, 316-317
making queries visible, 315
MDX (Multidimensional Expression), 313
modeling queries, 315
SAP BW 2.0, 324-326
saprfc.ini file, 317
ODBO (OLE DB for OLAP Architecture), 14
ODBO-certified products, 381
ODBC-certified vendors, 44
ODS (Operational Data Store), 54, 258, 350, 412
accessing data, 358-360
architecture, 354-356
detailed data, 200
drill down from InfoCube, 360-361
future direction, 365-366
 history of, 350-353
limited access to SAP R/3, 200
loading transaction data, 202
managing data flow and storage, 51-54
master data, 199
object creation, 362-365
one InfoSource populating multiple InfoCubes, 200
operating environment, 355
resolving data quality problems, 200
saving data in, 202
setting up drill-down scheme, 358-360
storing transaction data, 200
transactional data, 199
ODS objects, 202, 266
ODS tables, 54, 200, 357-358
OIW (Open Information Warehouse), 29-30
OLAP (On-Line Analytical Processing) after-the-fact reporting
requirement, 5
OLE DB for OLAP Programmer's Reference, 311
OLE DB for OLAP Provider, 115
OLI7/OLI8 transaction, 197
OLI7 transaction, 197
OLI8 transaction, 197
OLI9 transaction, 197
OLTP (Online Transaction Processing), 4-5
database backup and restore of, 37
data extraction, 18
performance impact by reports, 35
reporting requirements, 34
tight integration with data warehousing, 22
OM01 transaction, 197
OMATERIAL InfoObject, 151
attributes, 146
master data tables, 152
properties, 142
structure, 140
OMO1 transaction, 209, 213
OMO2 transaction, 209, 213
open data access strategy, 311-315
operational reporting, 91
optimizing data loads, 330
Oracle, 68-69
Oracle8, 51, 53
Oracle Data Mart Designer, 69
Oracle Designer/Developer 2000, 69
Oracle Express, 69, 312
Oracle Tool Kit for SAP R/3, 68
Order InfoSource, 282
order processing transactional data flow, 191
OREGION InfoObject, 178
OSS (Online Service System)
notes and business content, 168
OSS (Online Service System) account, 88-89

Team-Fly
Team-Fly
Index

P
passwords and BW (Business Information Warehouse), 75
PC_SOURCE data source, 301
PC_SOURCE source system, 299
PC-SRC program, 300
PC_SRC program ID, 299
Physical data model, 260-261
pilot/development system, 108, 344
PIS (Purchasing Information System), 31
planning for SAP BW projects, 88-94
platform-independent data movement technologies, 217
Plugin for SAP BW, 189
PMIS (Plant Maintenance Information System), 31
pool tables, 41
PowerCenter, 43, 68
data source definitions, 298-299
data type conversions, 304
defining RFC connection for, 299-301
loading data in SAP BW, 296-308
PowerCenter Designer, 303-304
PowerCenter Integration Server, 299
command line interface, 306
connecting to SAP BW, 301-305
launching sessions, 306-308
SAPRFC.INI file, 299
starting, 306
PowerCenter Server Manager
 Connect to Repository option, 305
defining SAP BW connection, 304-305
Operations-Add session, 305
predefined
information-gathering templates, 269
reports, 35
Presentation layer, 27-28
previewing reports, 252-253
processors, 346
PROD_MD.CSV file, 226
production system, 109, 344
product vendor Web sites, 374
profitability analysis, 32
programs in SAP R/3 OLTP instance, 384-385
projects
creation of, 280
enhancements, 280-282
PSA (Persistent Staging Area), 355
PSA objects, 202
publishing
BEX queries, 311
dynamic reports on Internet, 417-421
pull model, 166
pure Internet-centric reporting models, 324
push model, 166

Team-Fly
Team-Fly
Index

Q
QMIS (Quality Management Information System), 31
queries, 47, 280
analytical functions, 182
analyzing, 54
analyzing data, 243-246
attaching chart, 239-240
characteristics display attribute, 238-239
CKF (Calculated Key Figures), 182-183
Columns area, 236
composing, 421
computing values for new data elements, 183
cross-InfoCube, 57
customizing display layout, 238
defining, 233, 236-239
defining dimensions and key figures, 314
defining new key figure, 182-183
deleting from instances, 130
drill-down analysis, 236
drilling down data, 244-245
edit mode, 248
executing, 233, 237
executing without BEX Browser, 50
Filter area, 237
filtering data for, 183
filtering results, 236-237
filters, 241-242
Free characteristics area, 236-237
improving performance, 338
improving response time, 278
on InfoCube and aggregate usage, 338
InfoCube data source, 237
 key figures, 236
limiting scope of result set, 241
Lines area, 236
loading from business content, 182-183
navigational attributes, 243
navigational drill-down values, 243
optimization, 339-348
publishing BEX, 311
publishing on Web, 44
query cube, 55-56
reading all data, 339
reading data during navigation, 339-340
refreshing, 248
restricted key figures, 241-242
restricting data characteristics, 237
result characteristics, 236
saving current view, 237
selecting, 81
setting up query read modes, 340-341
star-joined optimization, 53
storing, 251
suppressing repeated key values and row totals, 245-246
target, 232
templates, 182
type, 237
variables, 130, 247-250
Web pages, 419
Query Builder, 234
query cubes, 55-56
memory, 56
relating to InfoCube, 57
uniqueness of, 56
query definition window, 237
query object, 314
Query Properties dialog box, 246, 248, 315
Query properties dialog box, 250
Query Properties icon, 248
Query property and variables, 250
Query View, 417

Team-Fly
Team-Fly
Index

R
R/2, 26
R/3, 26
R3SETUP, 112
range numbers buffering objects, 332
READMODE transaction, 340
real-time, 26
record size, 296
reducing data load time, 19
reference data, 194-197, 203
disk space, 194
order of loading, 194
SAP BW version 1.2B, 194
sharing, 266
reliability, 15
remote logon and ALE user, 189
repeated key values, suppressing, 245-246
replicating tables, 93
reporting and analysis notes, 405
reporting environment, 29-34
Reporting Server, 42
reporting systems, comparing, 33-34
Report Navigator, 29, 35
Report Painter, 33
reports, 29-34, 232
assigning to favorites, 252
 client-specific, 33
displaying, 35
EIS (Executive Information System), 33
executing, 254
FIS (Financial Information System), 32
initial assessment, 90
limitations, 35-37
limited OLAP functionality, 35
LIS (Logistics Information System), 31-32
list oriented, 35
missing or unclear information, 35
OLTP performance impact, 35
predefined, 35
previewing, 252-253
problems and causes of problems, 90
publishing on Web, 44
storing, 251
Report Tree tool, 29
Report Writer/Report Painter, 30
REP-type queries, 182
restricted key figures, 241-242
RFC (Remote Function Calls), 109, 292
RFC destination definition process, 299
RFC/Logical destinations, 134
RFC Server, 292
RIOS table, 169
RIS (Retail Information System), 31
RMCSBIWC report, 197
RMCVNEUA report, 197
RMCVNEUL report, 197
RO (Reporting Server component), 171
RODCHABAS table, 170, 287
RODCHA table, 169
RODIOBJCMP table, 169
RODIOBJ table, 169
RODKYF table, 169
RODTIM table, 169
RODUNI table, 169
ROIDOCPRMS table, 123
ROISGEN table, 169
ROISGN table, 169
ROIS-STRUCTURE table, 284
ROIS table, 170
ROLAP implementation, 408-410
ROLAP (Relational OLAP) model, 51
roles, 14-15
ROOT.SH shell script, 113
row totals, suppressing, 245-246
ROYALTY project, 303
RS (Reporting Server), 171
RS00 transaction, 128
RSA1 transaction, 121, 124, 131
RSAB function group, 293
RSADMIN table, 121-124
RSAO0001 enhancement, 285
RSAO0001 program, 285
RSAO0007 transaction program, 283
RSAP0003 program, 287
RSIMG transaction, 119
RSMIG transaction, 121
RSODS function group, 293
RSRT transaction, 341
RSSGTPDIR table, 199
RSTEXTTRSF function module, 287
RSZV transaction, 247

Team-Fly
Team-Fly
Index

S
S001BIWS extract structure, 169
S001 LIS structure, 191
S001 through S499 database tables, 32
S260 LIS structure, 191
S261BIW1 table, 192-193
S261BIW2 table, 192-193
S261 LIS structure, 191
S261 table, 192-193
Sales Analysis InfoCube, 269
Sales and Distribution InfoCube star schema, 262
SALE transaction, 117
SAP (Systems, Applications and Products in Data Processing),
26
approach, 87-88
CRM (Customer Relationship Management) initiative, 13
multilanguage environment, 194
reference books, 372
SAP_ALL profile, 117
SAPBEXO.XLA add-in, 234
SAPBEX.XLA file, 50, 81, 115, 116
SAP Business Framework, 292
SAP Business Framework Architecture, 36-37
SAP Business Information Warehouse Business Content and
Extractor installation guide, 124
SAP business objects, 292
SAP BW (Business Information Warehouse), 8, 24, 134
acceptable characters, 195
accounting area, 47-48
activating business content, 173-174
activating channel, 184-186
active client, 117-118
administration environment log-on, 73-76
Administration transaction, 128
analyzing transaction data, 197
architecture, 9, 43-45
basic configuration, 108
batch printing, 130
benchmarks, 102-103
BEX (Business Explorer), 77
BEX Analyzer, 77
BEX Browser, 77
business content, 45-48, 261
BW OLAP processor, 54-55
certified products, 64
channels, 57
checking installation, 116
client configurations, 103
collecting and grouping data set information, 196
configuring, 107
configuring administrators workstation, 113-114
content delivery functions, 129-133
Copyrights window, 76
customizing instance configuration, 119-121
data access, 49-50
data access environment log-on, 77-82
data access interfaces, 310-311
database size, 110
data consistency, 75
data flow, 55-57
data flow between SAP R/3 and, 166-173
data load interfaces, 290-296
Data Manager, 51-54
data objects client independent, 75
data sources, 410
data transfer methods, 200-202
data warehouse modeling, 261-262
defining RFC connection for PowerCenter, 299-301
defining source system, 172
defining tablespaces for fact tables, 111
dependent objects activation, 174
enabling business content, 176-186
evolution, 42-55
extended multidimensional data model, 266
extracting and sending data to, 295-296
fast disk I/O subsystem requirement, 110
frontends, 114
global settings, 121
hardware and database engine, 108
hardware requirements, 101-102
human resources area, 48
IDOC processing, 103
implementation landscape, 108-109
implementing data loads, 297-308
implementing without SAP R/3 as data source, 107
InfoObjects, 138-152
information provider layer, 44
InfoSources, 410
initializing global settings, 116-124
installing extractors, 124-126
installing frontend components for end-user reporting and analysis,
115-116
installing objects, 188
instance, 43
KPIs (Key Performance Indicators), 100
leveraging business rules, 175
life cycle, 97
loading data, 134, 306-308
loading languages, 116
loading metadata, 171-173
loading text and hierarchy data, 226-227
logging off, 76
logical system name, 189
logistics area, 47
Log Off dialog box, 76
logon process, 73
management layer, 44-45
metadata management, 170-171
metadata repository, 138
methodology guides on data modeling and implementation, 269
Microsoft Windows NT, 126
model information navigation schemes, 262
multiple clients, 75
naming data sources, 135
network requirements, 103
new SAP R/3 data source, 134-138
ODBO-certified products, 381
ODS (Operational Data Store), 54
open data access strategy, 311-315
OSS notes, 111
partners and consulting organizations, 89
passwords, 75
performance, 328-338
performance benchmark, 342-343
pilot/development system, 108
platform and database support, 108
preparing information for, 31-32
preparing instances for business content, 175-176
preparing SAP R/3 for, 188-193
production system, 109
pull model, 166
pure Internet-centric reporting models, 324
quality of master data, 195
reference data, 194-197
 RFC destination, 189
ROLAP (Relational OLAP) model, 51
sample report, 57-58
SD business content, 190
service provider layer, 44
session logon window, 73-74
setting parameters in RSADMIN table, 121-124
SID (Set ID), 52
sizing, 101, 341-348
slowly changing dimensions, 53
software installation preparations, 106-110
source system, 157
source systems, 133-138
Staging BAPI-certified products, 382
Staging engine, 48-49
Staging engine layer, 290
staging process, 102
star schema, 262
star-schema model, 52-53
startup screen, 73
System Landscape, 109
technical requirements, 100-103
test system, 108-109
third-party data warehouse solutions, 64-69
training courses, 375-380
transaction data loads, 197
transaction data paths, 200
transactions, 391
transferring exchange rates to, 175
VBA callable functions, 250
Web Publisher Wizard, 311
Windows NT 4.0, 51
workflow basic setting, 189-190
SAP BW 1.2A
copying ODBO-specific DLLs, 319
 data load paths, 201
SAP BW 1.2B
data load paths, 201
programs in SAP R/3 OLTP instance, 384-385
reference data, 194
tables, 390
Web reporting, 233
SAP BW 1.2B ODS
reference data, 196
SAP BW 2.0
accessing data from ODS, 234
BAPIs, 324-326
ODBO, 324-326
publishing and executing pure Web queries, 234
SAP BW 2.0A
defining MultiCube InfoCube, 276-278
function modules, 325-326
ODS architecture, 354-356
startup routine, 271
SAP BW 2.0B
architecture, 408-413
building ODS, 361-365
building queries on Intranet, 234
SAP BW business content specialist, 98
SAP BW client, 115, 234
SAP BW experts, 98-99
SAP BW Installation Guide, 134
SAP BW/Oracle8 database default parameters, 112
SAP BW projects
balancing benefit and feasibility, 94
business requirements, 99-100
business sponsor, 90-91
 data analysis and reporting, 91-93
documenting scope, 94
enterprise-wide reporting, 92-93
iterative-phased implementation, 94
limiting scope, 90
management reporting and analysis, 91-92
management sign-off, 94
near real-time operational reporting, 93
operational reporting, 91
planning for, 88-94
scope, 91-94
single subject area, 94
TCO (total cost of ownership perspective), 90
SAP BW project team, 94-99
ABAP developer, 98
business partners, 96
corporate data warehouse team, 96
corporate information architects, 99
Microsoft Excel VBA and ODBO programming developer, 98
SAP BW business content specialist, 98
SAP BW experts, 98-99
SAP R/3 program office, 96-98
steering committee members, 94
SAP BW Scheduler
3rd Party selections tab, 307
scheduling data load jobs, 307-308
sessions, 305
SAP BW servers
installing and configuring, 110-113
UNIX base system, 110-113
Sapdialog.dll file, 316
SAPGUI, 72, 73, 77, 113-115, 233
SAPGUI_BW20_vs_BW12B.SCM file, 129
saplicense command, 113
SAPLMCSBW function module, 199
SAP Logon server window, 73
SAPNET Web site, 88-89
SAPNet Web site, 421
SAP New Dimension, 37
SAP R/2, 26
SAP R/3, 26
ALE (Application Link Enabling), 36
architecture and technologies, 26-28
Basis Administration transaction, 128
Basis tasks, 129
business applications active dictionary, 27
custom LIS infostructure names, 192
data capture schemes for analytical applications, 5
data flow between SAP BW and, 166-273
data source information collection process, 190-193
delta change capture, 192-193
EIS (Executive Information System), 33
FIS (Financial Information System), 32
high transaction rate, 34
information systems, 29-30
life cycle, 97
LIS (Logistics Information System), 31-32
Logon Screen, 78
major application modules, 29
multiple clients within one instance, 75
multi-tiered architecture, 27
newest application release used, 123-124
OIW (Open Information Warehouse), 29-30
OLTP configuration, 5
operation team, 96-98
order processing, 191
 preparing for SAP BW, 188-193
program office, 96-98
reporting environment, 29-34
reporting limitations, 35-37
reporting tools, 29
S000-S499 SAP standard LIS infostrucutres, 192
SD (Sales and Distribution) module, 190
transports to load business content, 167
SAP R/3-centric data warehouse environments, 37-42
SAP R/3 OLTP, 344
Basis administration, 129
function modules for LIS extracts, 387-390
installing SAP BW objects, 188
key tables, 386
metadata management, 168-170
remote logon connection, 189
source instance configuration information, 175
SAPRFC.INI file, 299, 316, 317, 319
changing IP address of target SAP BW instance, 302
defining additional destinations, 302
DEST (data source), 319
destination value of SAP BW, 303
DEST name, 302
DEST parameter value, 305
parameters, 301
SAP BW source definition, 301
transfer-structure definitions, 303
SAP Sales and Distribution demo InfoCube data model, 262
SAP simplicity Web site, 29
SAP technologies books, 370-372
SAP Web site, 64
SAS Institute, 69
save icon, 417
saving
data in IDOCs, 206
data in ODS, 202
InfoObject catalog, 155
S_BI-WX_RFC profile, 189
S_BI-WX_RFC SM 30 transaction profile, 124
scalability, 16
SCCL transaction, 117
Scerrlkp.dll file, 316
Scheduling service, 11
schema, 314
ScreenCam movie, 129
SD Customer InfoCube, 178-180
SD Demo InfoCube, 185
SD InfoCubes, 197-199
SD-SIS (Sales and Distribution Sales Information System), 33
SE06 transaction, 116
SE11 transaction, 285, 287
SE16 transaction, 167, 169, 284, 287
SE17 transaction, 284
SE38 transaction, 287
SE80 function group, 293
Seagate, 69
Seagate Holos OLAP, 69
Search Engines service, 11
security, 14-15
Security service, 12
SendData method, 296
SendRequest method, 296
Sequence Number buffering, 332
Service Provider layer, 10
sessions, 305
Session Wizard, 305
SFIS (Shop Floor Information System), 31
SID (Set ID), 52
S_IDOC_ALL sub-profile, 189
SID (Set ID) tables, 266
master data, 194
time-dependent attributes, 266
time-independent attributes of, 266
Simplification Group, 29
SIS (Sales Information System), 31
sizing, 343
slicing and dicing data, 241
slowly changing dimensions, 144, 264
SM21 transaction, 116
SM28 transaction, 116
SM30 transaction, 189
SM31 transaction, 117-118
SM50 transaction, 288
SM59 transaction, 124, 135-136, 168, 189, 299
SMO30 transaction, 124
Source/Target Management service, 11
SQL and Windows GUI interface, 54
S_RS_ALL sub-profile, 189
s_S250File_Mapping session, 307
s_S260_Mapping session, 305
SS_FF_PROD source system, 220
Staging BAPI-certified products, 382
Staging BAPIs (Business APIs), 43, 67, 98, 134, 216-217, 290-
291, 297
building data loader, 294-296
third-party implementations, 308
staging business objects, 292-293
star-joined query optimization methods, 53
star-schema model, 408-410
dimensions, 264
dimension tables, 51-52
fact table, 51-52
statistical update, 192
STMS transaction, 116
stovepipe culture, 62
STR query template, 182
structures
changes to, 283
new elements, 285
SU01 transaction, 189
Subject Models service, 10
SWO1 transaction, 293
SWU3 transaction, 189
system landscape, 344

Team-Fly
Team-Fly
Index

T
T000 table, 117, 124
Tab Delimited files, 134
tables, replicating, 93
target queries, 232
TBATG table, 124
TCO (total cost of ownership) perspective, 90
teams, building, 94-99
technologies, adaptation of, 14
templates
ABAP routine, 272
building InfoCubes, 162
InfoCubes, 267-268
InfoObjects as, 154-155
predefined information-gathering, 269
publishing, 419
test system, 108-109
text
extractors, 287
flat files, 218
loading, 226-227
Texts master data file, 222
text system, 344
third-party data
access tools, 317-324
extraction, 41
third-party data warehouse solutions to BW (Business
Information Warehouse), 64-69
third-party Staging BAPI implementations, 308
third-party-tool-centric data warehouses, 41-42
three-tiered application model, 28
three-tiered architecture, 26-27
time characteristics, 149-150
time dependencies, 144
time-dependent hierarchy name, 145
time-dependent hierarchy structure, 145
time-dependent master data, 222
Time dimension, 265
TIS (Transportation Information System), 31
TIS (Treasury Information System), 32
TMCBIW table, 193, 198
Tools, Business Engineer, BW Customizing command, 119
top-down approach, 87
Track Resource Utilization service, 11
traditional data warehouses, 5
training courses, 375-380
transaction data, 169
analyzing, 197
extending content, 283-286
file name, 227
flat files, 218, 227
InfoSource definition, 170
InfoSources, 157
loading, 208
physical storage, 191
 populating with, 281
storing in ODS, 200
transaction InfoSource, 220
transaction OMO1, 31-32
transaction systems and ODS (operational data store), 7
transaction tables, updating, 31
transfer structure, 48, 287
transformations, 19
tRFC, 197, 217
tRFC with ODS data transfer mode, 200, 202
two-tiered application model, 28
two-tiered architecture, 26
type T connection, 299

Team-Fly
Team-Fly
Index

U
uninstalling SAPGUI, 113-114
unit of measure characteristics, 150-151
Unit of Measure dimension, 265
UNIX base system
installing and configuring, 110-111
SAP BW servers, 110-113
Update InfoSource metadata function, 172
update routine, defining, 272
update rules, 280
ODS tables, 357-358
Update Rules Definition window, 274
Update Rules icon, 181
Update Rules window, 271
updating
LIS information structures, 31
metadata, 172-173, 175
transaction tables, 31
upgradability, 15
URLs and BEX Browser, 253
user-definable dimensions, 264
user-exits, 281
users
Activity Groups, 252
assigning channels to, 184
channel assignment, 252
channels, 252
Team-Fly
Team-Fly
Index

V
VAR (Variables), 182-183
variables, 130
existing queries, 248
queries, 247-250
Query property names, 250
slowly changing dimensions, 248
special authorizations, 247
VBA function modules, 50
VBA programming, 250
version-dependent hierarchy, 145
virtual InfoCubes, 269
Visual Basic, 292
V_TBDLS table, 189

Team-Fly
Team-Fly
Index

W
warehouse management notes, 406
Warehouse Operations service, 11
Web reporting, 414-421
architecture, 415-416
SAP BW 1.2B, 233
WebRFC, 420
WGate, 415-416
Windows NT
BW (Business Information Warehouse), 51
SAP BW, 126
Windows registry and SAPGUI entries, 114
WINNTdirectory, 319
WMIS (Warehouse Management Information System), 31
workbooks, 47
worksheets, 250

Team-Fly
Team-Fly
Index

X
XDWCLNT050, 135-136
XLS files, 134

Team-Fly
Team-Fly
Index

Z
ZCUSTMR variable, 247
ZTIMPRD variable, 248, 250
&ZTIMPRD& variable, 250

Team-Fly
Team-Fly
List of Figures
Chapter 1: Constructing a Data Warehouse
Figure 1-1: Independent and Dependent Data Marts.

Figure 1-2: The Architectural Layers of a Data Warehouse.

Figure 1-3: The Technical Aspects of a Data Warehouse.

Figure 1-4: Data Warehouse Performance Characteristics.

Figure 1-5: Evolution of ERP Applications and Data Warehousing.

Chapter 2: Evolution of SAP Business
Information Warehouse
Figure 2-1: SAP R/3 Business Applications.

Figure 2-2: SAP R/3 Deployment Architecture.

Figure 2-3: SAP R/3 Reporting Environment.

Figure 2-4: SAP Business Framework Architecture.

Figure 2-5: R/3 Database-Centric Reporting Environment.

Figure 2-6: SAP ALE-Centric R/3 Reporting Environment.

Figure 2-7: Functionality Comparison of R/3 Data Warehouse

Models.

Figure 2-8: Architecture of Business Information Warehouse.

Figure 2-9: Business Content in SAP BW 1.2B and BW 2.0A

Figure 2-10: SAP BW Staging Process in SAP BW 1.2B and SAP

BW 2.0A.

Figure 2-11: Business Explorer Browser and Analyzer.

Figure 2-12: Business Explorer Analyzer.

Figure 2-13: A Typical Star-Schema Model for Multidimensional

Data Analysis.

Figure 2-14: Star-Schema Model in SAP BW 1.2B.

Figure 2-15: Data Flow Within SAP BW 1.2B.

Figure 2-16: SAP BW Business Explorer Browser with Sample

Reports.
Figure 2-17: SAP BW Business Explorer Browser-Starting Data
Analysis Tasks.

Figure 2-18: SAP BW 1.2B Business Explorer Analyzer.

Figure 2-19: SAP BW 1.2B Business Explorer Analyzer Drill-Down

by Product Hierarchy.
Chapter 3: Comparing SAP BW with Data
Warehouse Solutions Provided by Other
Vendors
Figure 3-1: SAP BW and Third-Party Vendors' Data Warehouse
Products.
Chapter 4: Getting Started with SAP BW
Figure 4-1: The SAP BW Logon Icon.

Figure 4-2: The SAP BW Logon Server Selection Screen.

Figure 4-3: SAP BW Client Session Starts.

Figure 4-4: SAP BW Session Startup Screen.

Figure 4-5: SAP BW User Logon Information Screen.

Figure 4-6: SAP BW Main Screen for SAP BW 1.2B (SAPGUI

4.5A Frontend) and SAP BW 2.0A (SAPGUI 4.6A Frontend).

Figure 4-7: Exiting From SAP BW.

Figure 4-8: SAP BW Session Log Off Confirmation Dialog Box.

Figure 4-9: SAP BW Logon Paths in SAP BW 1.2B and SAP BW

2.0.

Figure 4-10: The Business Explorer Browser.

Figure 4-11: The SAP Business Warehouse Logo Window.

Figure 4-12: The SAP BW Server Selection Window.

Figure 4-13: The SAP BW Logon User Information Window.

Figure 4-14: SAP Business Warehouse Copyright Window for

SAP BW 1.2B.

Figure 4-15: The SAP BW Browser is a Corporate Information

Repository that Contains Information Objects Such as Reports,
Analytical Applications, or Web Sites.

Figure 4-16: Simple Sales by Employee Data Analysis Report via

BEX Analyzer.
Figure 4-17: The SAP Business Explorer Analyzer.

Figure 4-18: SAP BEX Analyzer Microsoft Excel Add-In.

Figure 4-19: Starting Connection to SAP BW From the SAP BEX

Analyzer.

Figure 4-20: SAP BEX Information Catalog to List the Defined

Query in SAP BW 1.2B.
Chapter 5: Planning for SAP BW
Implementation
Figure 5-1: ASAP Methodology Road Map for Business
Information Warehouse.

Figure 5-2: ASAP Methodology Templates and Accelerators for

Business Information Warehouse.

Figure 5-3: Reporting and Data Analysis Categories and

Boundaries of an SAP BW Project.

Figure 5-4: SAP BW Project Team Members.

Chapter 6: Setting Up SAP BW
Figure 6-1: SAP BW Installation Steps-Backend and Frontend.
The Shaded Area Represents the SAP BW Specific Component
Installation.

Figure 6-2: SAP BW System Landscape-Path to Production.

Figure 6-3: SAP BW Frontend Installation on the Administrator

Workstation.

Figure 6-4: Installing SAP BW Components for End Users and

Developers.

Figure 6-5: Launching the SAP Business Explorer Analyzer.

Figure 6-6: SAP BW Explorer.

Figure 6-7: SAP BW Installation Checkup.

Figure 6-8: Defining the SAP BW Active Client.

Figure 6-9: Copying the 000 Client to the SAP BW Active Client.

Figure 6-10: Basic SAP BW Setting. The Left Shows the Setting
Menu for SAP BW 1.2B, and the Right Shows the Same Setting
Menu in SAP BW 2.0A.

Figure 6-11: Customizing SAP BW Operational Parameters.

Figure 6-12: SAP BW Customizing Implementation Guide.

Figure 6-13: SAP BW Instance and Applications Specific

Customization and Configuration Parameter Settings.

Figure 6-14: SAP BW Customization and Configuration Global

Parameter Settings.

Figure 6-15: Setting Global Data Administration Parameters.

Figure 6-16: Modifying the SAP BW Operation Configuration
Table RSADMIN.

Figure 6-17: Defining RFC Destination for Remote Data Source

SAP R/3 Instance.

Figure 6-18: Testing RFC Destination for a Remote SAP R/3 Data
Source.

Figure 6-19: SAP BW Operations on Microsoft Windows NT 4.0.

On the Left is the Service Manager to Start and Stop the SAP BW
1.2B Instance. On the Right is the Service Manager Integration
with Microsoft Management Console to Manage SAP BW 2.0
Services and Associated Processes.
Chapter 7: SAP BW-The Administrator
Workbench
Figure 7-1: SAP BW Main Menu. The Menu on the Left is for SAP
BW1.2B, and the Menu on the Right is for SAP BW 2.0A.

Figure 7-2: SAP BW 1.2B Administrator Workbench.

Figure 7-3: SAP BW Administrator Workbench (Transaction

RSA1). The Top Section Shows the SAP BW 1.2 Administrator
Workbench with Tabstrips to Manage Object Types. The Bottom
Shows the SAP BW 2.0A Administrator Workbench. The Only
Major Difference is that in BW 2.0A, You Select the Object Type
From a Drop-Down Menu.

Figure 7-4: SAP BW Administrator Workbench-Changing the

Startup View.

Figure 7-5: SAP BW Administrator Workbench-Selecting Display

Options.

Figure 7-6: SAP BW Administrator Workbench-Operations and

Development Environment and its Relationship with the SAP BW
1.2B Staging Process.

Figure 7-7: Classes of Data Sources for SAP BW.

Figure 7-8: Creating a Source System in SAP BW. The Source

System is the Logical Name Assigned for a Remote Connection.

Figure 7-9: Defining an RFC Definition in SAP BW for SAP R/3 as

a Data Source.

Figure 7-10: RFC Destination Connection Verification.

Figure 7-11: Source Systems Tree in the Administrator

Workbench to Show Data Sources Connected to SAP BW.
Figure 7-12: Maintaining Data Sources in SAP BW, Such as
Updating InfoSource Metadata from Source R/3 to SAP BW or
Enhancing SAP-Provided Data Extractors.

Figure 7-13: Managing InfoObjects in the Administrator

Workbench.

Figure 7-14: Maintaining InfoObjects in SAP BW 1.2B.

Figure 7-15: Characteristics in SAP BW 1.2B.

Figure 7-16: Maintaining Individual InfoObjects in SAP BW 1.2B.

Figure 7-17: Assigning Master Data and Text Elements to an

InfoObject.

Figure 7-18: Maintaining an InfoObject and Assigning Hierarchies.

Figure 7-19: Assigning Attributes to an InfoObject.

Figure 7-20: Navigational Attributes of an InfoObject.

Figure 7-21: Building Compounding Functionality for an

InfoObject.

Figure 7-22: Defining Basic Data Types for a Key Figure.

Figure 7-23: Defining an Aggregation Scheme for a Key Figure.

Figure 7-24: Definition of Calendar Year (0CALYEAR) Time

Characteristics.

Figure 7-25: Definition of Unit of Measure, 0BASE-UOM

InfoObject.

Figure 7-26: Managing InfoObjects in SAP BW 1.2B.

Figure 7-27: Creating an InfoArea, Demo Info Area, to Group

Analytical Applications for Product Demonstration.
Figure 7-28: Creating a New InfoObject Catalog.

Figure 7-29: Defining Characteristics for an InfoObject Catalog.

Figure 7-30: Editing an InfoObject Catalog for Characteristics.

Figure 7-31: Editing an InfoObject Catalog for Key Figures.

Figure 7-32: Viewing InfoObject Details of an InfoObject Catalog.

Figure 7-33: Importing InfoSource Metadata in SAP BW From an

SAP R/3 Data Source.

Figure 7-34: Creating New Application Components to Set up an

InfoSource.

Figure 7-35: Sales and Distribution InfoArea and Associated

InfoCubes.

Figure 7-36: SAP's Customer InfoCube Data Model.

Figure 7-37: Definition of SAP's Customer InfoCube Data Model.

Figure 7-38: Defining Dimensions for an InfoCube and Assigning

Characteristics to the Dimensions.

Figure 7-39: Graphical View of Dimension Assignments for an

InfoCube.

Figure 7-40: Viewing InfoCube Content.

Chapter 8: SAP BW-Loading Business
Content
Figure 8-1: Information Flow between SAP BW and its Data
Sources.

Figure 8-2: Verification of an SAP BW Add-On in an SAP R/3

OLTP Instance.

Figure 8-3: SAP BW 1.2B Metadata Management in SAP R/3

OLTP Instance. Tables that Manage SAP BW Specific Metadata.

Figure 8-4: Metadata Tables in SAP BW 1.2B.

Figure 8-5: Loading InfoSources Metadata From an SAP R/3 Data

Source.

Figure 8-6: Importing Exchange Rates From an SAP R/3 OLTP

Instance.

Figure 8-7: Importing Global Settings From SAP R/3.

Figure 8-8: Activating Business Content in SAP BW 1.2B.

Figure 8-9: Activating an InfoCube in SAP BW.

Figure 8-10: Transferring InfoCube Definition From SAP BW

Business Content to Local Implementation.

Figure 8-11: Maintaining an InfoCube Schema in SAP BW.

Figure 8-12: Maintaining InfoCube Update Rules.

Figure 8-13: Visual View of the InfoCube Model for the Customer
InfoCube in SAP BW.

Figure 8-14: Loading Queries From Business Content for

Customer InfoCubes.
Figure 8-15: Activating SAP Delivered Channels.

Figure 8-16: Adding Channels in the InfoCatalog.

Figure 8-17: Assigning Users to Channels.

Figure 8-18: Activating the SAP Demo Cube.

Chapter 9: Preparing R/3 Data Sources for
SAP BW Initial Data Loads
Figure 9-1: SAP R/3 OLTP Verification of the Workflow Runtime
Environment for SAP BW.

Figure 9-2: A Typical Order Processing Transaction Data Flow in

SAP R/3 and Associated Data Sets for InfoCubes in SAP BW
1.2B.

Figure 9-3: Statistical Update to Prepare Initial Data Loads and

Process of Incremental Data Capture in SAP R/3 for SAP BW.

Figure 9-4: Identifying Permitted Characters in SAP BW Beyond

Standard Text and Numeric Characters in SAP BW 1.2B. A
Similar Method Exists in SAP BW 2.0A.

Figure 9-5: Setting Statistical Update for SAP BW LIS Structures

in SAP R/3 OLTP Data Source.

Figure 9-6: Data Load Paths in SAP BW 1.2B.

Figure 9-7: Data Load Paths in SAP BW 2.0A. The Early

Customer Release is SAP BW2.0B, But it May Change.

Figure 9-8: Editing Transfer Rules for an InfoSource to Define

InfoSource Data Transfer Method.

Figure 9-9: Creating an InfoPackage to Load Data in SAP BW

1.2B.

Figure 9-10: InfoPackage Scheduling for SAP R/3 Transactional

InfoSources Based on SAP BW Version 1.2B.

Figure 9-11: InfoPackage Scheduling for SAP R/3 Transactional

InfoSources Based on SAP BW Version 2.0A.
Figure 9-12: InfoPackage Scheduling Options for Flat File
InfoSources.

Figure 9-13: InfoPackage Scheduling for Third-Party Data

Loading Tools that Use SAP BW Staging BAPIs.

Figure 9-14: Defining Data Load Flow in SAP BW When the Data
Transfer Method is ALE IDOC.

Figure 9-15: Defining Data Load Flow in SAP BW When the Data
Transfer Method is tRFC with ODS. In SAP BW Version 2.0A,
ODS Means PSA.

Figure 9-16: Loading a Large Amount of Data in SAP BW by

Splitting One Huge Task into Multiple Data Load Sessions. Each
Session is Limited to a Given Range of Material Values.

Figure 9-17: Loading Incremental Changes in SAP BW.

Figure 9-18: SAP BW Data Load Monitoring Environment in SAP

BW 2.0A.

Figure 9-19: Data Load Job Statistics Summary. The Lights

(Green, Red, and Yellow) Show the Current State of Individual
Jobs.

Figure 9-20: Monitor Assistant (Renamed Wizard in BW 2.0)

Displays the State of Individual Data Load Tasks.

Figure 9-21: Data Load Detailed Analysis to Identify and Resolve

Update Problems.
Chapter 10: Loading Data via Flat Files
Figure 10-1: Defining a Flat File Data Source.

Figure 10-2: Creating a Source System for Flat File Data Sources.

Figure 10-3: Defining InfoSource Type for Flat File Data Sources.

Figure 10-4: Assigning a Flat File Source System to a Master

Data InfoSource.

Figure 10-5: Attributes Definitions for Master Data.

Figure 10-6: Texts Definitions for Master Data.

Figure 10-7: Hierarchies Definitions for Master Data.

Figure 10-8: Metadata Definition for Transaction Data Flat Files.

Figure 10-9: Scheduling an InfoPackage to Load Data in SAP BW.

Figure 10-10: Scheduling Data Load in SAP BW.

Figure 10-11: Loading Hierarchy Data in SAP BW

Figure 10-12: Loading Transaction Data via Flat Files.

Figure 10-13: Selecting InfoCubes to Load Data into From

External Data Flat Files.
Chapter 11: Analyzing SAP BW Data
Figure 11-1: SAP BW Business Explorer Browser and Analyzer
Architecture in BW 1.2B and BW 2.0A.

Figure 11-2: SAP BW Business Explorer (BEX) Analyzer Add-In

and BEX Analyzer Menu Bars for BW 1.2B and BW 2.0B.

Figure 11-3: InfoCube Model to Demonstrate BEX Analyzer for

Reporting and Analysis.

Figure 11-4: Defining a New Query in the BEX Analyzer.

Figure 11-5: Selecting Data Elements of a BEX Query.

Figure 11-6: The Default Query Results Based on the Global

Query Setting. You Can Change the Look and Feel of the Query
by Changing its Properties.

Figure 11-7: Selecting Characteristic Display Options.

Figure 11-8: Creating Charts and Graphs in the BEX Query.

Figure 11-9: Selecting Chart Display Options.

Figure 11-10: Creating Restricted Key Figures in the BEX

Analyzer Query.

Figure 11-11: Using Restricted Key Figures in the BEX Analyzer

Query.

Figure 11-12: Displaying Current and Past Year Revenues by

using Restricted Key Figures.

Figure 11-13: SAP BEX Analyzer Query Navigation and Result

Areas.

Figure 11-14: Drill-Down Methods to Navigate Data in SAP BW

BEX Analyzer.
Figure 11-15: Swapping Dimensions. Revenues are Broken Down
by Material and Customer on the Left and Revenue by Customer
and Material on the Right.

Figure 11-16: The BEX Analyzer Default Displays Data with

Repeated Characteristic Values. Setting the Query Property to
Suppress Repeated Values Makes the Same Data Display Much
Clearer and the Data More Presentable.

Figure 11-17: Displaying Subtotal Values Against a Given

Characteristic During Drill-Down Navigation.

Figure 11-18: Defining Variable ZCUSTMR in SAP BW using

Transaction RSZV that Will be Used to Dynamically Set Values for
a Customer to Select.

Figure 11-19: Customizing the BEX Analyzer Query to Select

Customer Data Based on User Input using a Variable. At the
Query Runtime, the User is Prompted for Variable Value. This
Variable Value is Used to Select Data at the Database Level.

Figure 11-20: Setting up the Query Global Properties for Time-

Dependent (Slowly Changing Dimensions) Data Objects.

Figure 11-21: Enterprise InfoCatalog. A Collection of Enterprise-

Wide Reports and Other Information Objects. Use Simple Drag-
And-Drop Techniques to Move Objects.

Figure 11-22: Channel InfoCatalog. Common Repository of

Channels. Here You Create New Channels and Manage and
Assign Reporting Objects to the Channels. Note that You Assign
Only Reports or Other Information Objects to a Specific Channel
and Not to an End User.

Figure 11-23: User Channel Assignment. All Users in SAP BW are

Listed Alphabetically on the Left. All Defined Channels are Listed
on the Right. Select a User, and Drag and Drop it in a Channel to
Make an Assignment.
Figure 11-24: Assigning Reports to Individual Favorites. The
InfoCatalog Administrator Can Manage an Individual's Entries in
His or Her Favorite Folders. You Can Organize Entries Simply by
Dragging Them From One Folder and Dropping Them into
Another Folder.

Figure 11-25: The BEX Browser Lists Only Assigned Channels to

User BWADMIN. These Assignments were Made in the
InfoCatalog as Shown in Figure 11-24.

Figure 11-26: Viewing Query Properties From the BEX Browser.

Figure 11-27: Including Non-SAP BW Information Objects in the

BEX Browser.
Chapter 12: SAP BW-Defining Custom
InfoCubes
Figure 12-1: Enterprise Data Warehouse Modeling.

Figure 12-2: Multidimensional Data Model in SAP BW. The Star

Schema Representation for the Sales and Distribution Demo
InfoCube in SAP BW 2.0A.

Figure 12-3: Factless Fact Table. It Contains No Measures.

Figure 12-4: Extended Star Schema for SAP BW 1.2B InfoCubes.

Figure 12-5: Defining a New InfoCube in SAP BW. The Top

Shows the InfoCube Types Available in SAP BW 1.2B, the Middle
in BW 2.0A, and the Bottom in BW 2.0B. Note that in SAP W
2.0B, There is No InfoCube Tree. In SAP BW 2.0B, You Will Find
a Data Targets Tree, InfoAreas, and Either InfoCube or the ODS
Object. SAP BW 2.0B is Discussed in Chapter 17; this is Here for
Information Only.

Figure 12-6: Assigning Characteristics, Dimensions, and

Attributes for a New InfoCube using SAP BW 2.0A.

Figure 12-7: Creating Dimensions and Assigning Attributes to

Them.

Figure 12-8: Defining Update Rules for an InfoCube in SAP BW

2.0A. This Version Supports a Concept of a Startup Routine that
was Not Available in SAP BW 1.2B.

Figure 12-9: Update Rules Details for Key Figures in an InfoCube.

The Top Section Defines How Key Figures are Saved in an
InfoCube, the Middle Section Describes Mapping of a Key Figure
Value before it is Stored, and the Bottom are the Units for
Reference for the Key Figure.
Figure 12-10: Defining Update Rules for Characteristics. Five
Methods are Available to Map Characteristics and Assign Values:
Direct InfoSource, Constant Value, From Master Data, Through an
ABAP Routine, or Initial Value.

Figure 12-11: Accessing Error Logs and Generated InfoCube

Update ABAP Code.

Figure 12-12: Selecting InfoCubes or MultiCube InfoCubes in SAP

BW 2.0A.

Figure 12-13: MultiCube InfoCube Saved and Activated. Looks

and Behaves Exactly Like a Typical InfoCube.
Chapter 13: Enhancing Business Content
and Developing Data Extractors
Figure 13-1: Creating a Project for Enhancements in SAP BW
using Transaction CMOD.

Figure 13-2: Enhancing Data Extractors in SAP R/3.

Figure 13-3: Activating and Adjusting the Database after

Appending a Structure Definition.

Figure 13-4: Adding Custom ABAP Code to Fill New Data

Elements in the InfoStructure using EXIT_SAPLRSAP_001.

Figure 13-5: Updating Metadata for Enhanced InfoObjects From

SAP R/3 OLTP in SAP BW. It is Suggested that You Enhance
Business Content on the OLTP Side, and then Pull Metadata in
SAP BW.
Chapter 14: Integrating Third-Party ETL
Products with SAP BW
Figure 14-1: SAP BW Data Loading and Data Access Interfaces.

Figure 14-2: SAP BW Metadata Management Process using

Staging BAPIs.

Figure 14-3: SAP BW Data Loading Process using Staging

BAPIs.

Figure 14-4: Components of PowerCenter Integration Server for

SAP BW.

Figure 14-5: Defining Informatica PowerCenter as Data Source

Provider in SAP BW.

Figure 14-6: Creating the Source System in SAP BW.

Figure 14-7: Establishing the RFC Definition for the PowerCenter

Environment for SAP BW.

Figure 14-8: Testing the Connection between SAP BW and the

PowerCenter Integration Server for SAP BW. Connection Time is
in Milliseconds.

Figure 14-9: Importing InfoSource Metadata From SAP BW into a

PowerCenter Repository as the Target Data Source.

Figure 14-10: Defining Source to Target Data Mapping and

Transformations in PowerCenter.

Figure 14-11: PowerCenter Server Manager, Used to Define

Sessions and to Monitor and Control Jobs.

Figure 14-12: Starting the PowerCenter Integration Server for BW.

Figure 14-13: Scheduling Data Import Jobs From SAP BW.

Chapter 15: Integrating Third-Party Data
Access Products with SAP BW
Figure 15-1: The ODBO Architecture and its Implementation in
SAP BW.

Figure 15-2: A Multidimensional Statement Syntax, Actual Query,

and Results.

Figure 15-3: SAP BW Objects versus ODBO Schema Objects.

Figure 15-4: Enabling a BEX Analyzer Query to be Visible to the

ODBO Consumer.

Figure 15-5: Installing ODBO Components at the Client

Workstation.

Figure 15-6: Components of Arcplan inSight Version 2.3.5 to

Design Pure Web-Centric Applications against SAP BW.

Figure 15-7: Building an Application using inSight 2.3.5; Defining

a New Connection to the SAP BW Data Source.

Figure 15-8: Building a Sales Analysis Analytical Application in

inSight.

Figure 15-9: Building an inSight Analytical Application; Defining

Data Dependency Relationships among Selected Data Objects.

Figure 15-10: Launching the inSight Application over the Web by

using ActiveX Control. You Don't Need an inSight Client, SAP
Software, or Microsoft Office on the Client Workstation to Run this
Application.

Figure 15-11: SAP BW ODBO BAPIs.

Chapter 16: Managing SAP BW-Performance
and Sizing Tuning
Figure 16-1: Data Warehouse Performance Characteristics.

Figure 16-2: Setting up Data Load Performance Parameters in

SAP BW 1.2B and SAP BW 2.0A.

Figure 16-3: Changing Buffering of the Number Range Objects.

Figure 16-4: A Data Warehouse Data Volume Growth Pattern.

Figure 16-5: Defining Aggregates against the Customer InfoCube.

Figure 16-6: Defining Aggregates for an InfoCube in SAP BW

1.2B. Initially, When an Aggregate is Created, the Entries in the
Calls and Last Displayed Columns are Not Filled in. as Users Use
Queries against the InfoCube, SAP BW Automatically Fills
Information About Each Aggregate on How Often and When an
Aggregate was Used. Never-Used Aggregates Should be
Deleted.

Figure 16-7: Defining Aggregates Selection Criteria in SAP BW

1.2B. Here You Select the Characteristics You Want to Include in
the Aggregate. This Shows the Characteristics Selected for
Aggregate MAX 1 for Customer InfoCube (0SD_C01).

Figure 16-8: Defining Aggregates in SAP BW 2.0. In this

Scenario, the Aggregate is Defined for a Specific Product,
BIGSCREENTV, because End Users Want to do Extensive Sales
Analysis for Large-Screen TVs.

Figure 16-9: Aggregate Usage Statistics.

Figure 16-10: Setting Global Query Read Mode for an InfoCube.

Changing Read Mode for an InfoCube Does Not Change Read
Mode for all Existing Queries against the InfoCube. This Mode is
Applied to Only New Queries.

Figure 16-11: Changing Read Mode for an Existing Query using

Transaction RSRT. Note that this Transaction Can be Used to
Debug the Query.

Figure 16-12: SAP BW Benchmark Environment.

Chapter 17: The Operational Data Store in
SAP BW 2.0
Figure 17-1: SAP BW 2.0 ODS Architecture Compared to its
Earlier Version, BW 1.2B.

Figure 17-2: Defining ODS Tables in SAP BW 2.0A. Remember

that this Screen Design May Change in SAP BW 2.0B.

Figure 17-3: SAP BEX Analyzer Query Against ODS and Results.

Figure 17-4: Comparing Query Response Time to Access Data

From SAP BW ODS.

Figure 17-5: Defining Jump-Target" Scheme to Jump From an

InfoCube to an ODS Query or in Reverse.

Figure 17-6: The Administrator Workbench in SAP BW 2.0A and

SAP BW 2.0B. The InfoCube Tree Hierarchy No Longer Exists in
SAP BW 2.0B. Instead, Both InfoCubes and ODS Objects are
Listed Under the Data Targets Tree.

Figure 17-7: Defining New DDS Objects in SAP BW 2.0B. Note

that the ODS Design Layout is Very Different From in SAP BW
2.0A, as Shown in Figure 17-2.

Figure 17-8: Getting Detailed Information on ODS Objects in SAP

BW 2.0B.

Figure 17-9: Managing Data in ODS Objects.

Appendix A: Data Warehouse Industry
References and SAP BW Training
Figure A-1: SAP BW Training Sessions Listed at the SAP Web
Site.

Figure A-2: ODBO-Certified Products to Access Data in SAP BW

as Listed on the SAP Web Site.

Figure A-3: Staging BAPl-Certified Products to Load Data in SAP

BW as Listed on the SAP Web Site.
Appendix B: SAP BW and SAP R/3
Transactions, Tables, and Code Examples
Figure B-1: SAP BW Model for the IC_CUBE02 InfoCube as
Described in Chapter 12.
Appendix D: Key Enhancements in SAP BW
2.0
Figure D-1: InfoCube Schemas in SAP BW 1.2B, on the Top, and
BW 2.0A, on the Bottom. Notice How the New Star Schema
Accounts for Several New SID Tables, Where Each Dimension
Characteristic Has Time-Dependent Master Data.

Figure D-2: Administrator Workbench in SAP BW 1.2B. The

InfoCubes Tabstrip Lists all Available InfoCubes in a Tree Format
Under the InfoCubes Tree Node.

Figure D-3: Administrator Workbench in SAP BW 2.0A and SAP

BW 2.0B.

Figure D-4: The BDS Document Management Environment.

Assigning a Document to Key Figure ZAMOUNT.

Figure D-5: SAP BW Web Data Access Architecture using SAP

Internet Transaction Server (ITS) and an Internet Server.

Figure D-6: SAP BW 2.0 Web-Reporting Architecture and Five-

Step Web Reports Publishing Process.

Figure D-7: The SAP BW BEX Query to Publish on the Web.

Figure D-8: Publishing a Query View. The a Step is to Save the

Basic Query in SAP BW. The B Step is to Save the View Query as
Default View for Publishing over the Web. Here, Sales Revenues
(Amount) are Shown by Product (Material). Step C is to Format
the Layout of the Result Set using SAP BW Web Publisher.

Figure D-9: The SAP BW Web Publisher Defines SAP BW Web

Report Elements Associated with the Query View. The HTML
Wizard is Used to Determine How Items are Displayed in the
Reports and Associated Navigation Schemes. You Can Have
 Several Query Views in One HTML Page. After Finalizing the
HTML Template, Click Check in to Save the HTML Template in
the SAP BW Server (BDS). To Review the Web Report, Click the
HTML Browser.

Figure D-10: Viewing an SAP BW Analytical Application over the

Web. Note How the Original SAP BEX Query, Shown in Figure D-
7, Has been Transformed to Dynamically Perform Data Navigation
over the Web.

Team-Fly
Team-Fly
List of Tables
Chapter 2: Evolution of SAP Business
Information Warehouse
Table 2-1: Comparison of Operational and Reporting/OLAP
Environments
Chapter 3: Comparing SAP BW with Data
Warehouse Solutions Provided by Other
Vendors
Table 3-1: Products to Load Data in SAP BW 1.2B

Table 3-2: Products to Access Data From SAP BW 1.2B

Chapter 5: Planning for SAP BW
Implementation
Table 5-1: SAP BW Hardware Configuration Model (Source: SAP)
Chapter 7: SAP BW-The Administrator
Workbench
Table 7-1: Master Data Tables for 0MATERIAL InfoObject in SAP
BW 1.2B
Chapter 11: Analyzing SAP BW Data
Table 11-1: VBA Routines in SAPBEX.XLA to Customize
Workbooks
Chapter 14: Integrating Third-Party ETL
Products with SAP BW
Table 14-1: Staging Business Objects in SAP BW 1.2B and 2.0A
Chapter 16: Managing SAP BW-Performance
and Sizing Tuning
Table 16-1: Assessing SAP BW Memory Requirements
Chapter 17: The Operational Data Store in
SAP BW 2.0
Table 17-1: Characteristics of Operational Data Store Classes and
Their Usage
Appendix B: SAP BW and SAP R/3
Transactions, Tables, and Code Examples
Programs to Update LIS BW Tables

BW Function Modules On SAP R/3 OLTP

Team-Fly