Download pdf - 011000358700001524642002 ODS Objects in BW 30.ppt

8/11/2019 011000358700001524642002 ODS Objects in BW 30.ppt

1/34

Lothar SchubertBI RIG, SAP AG

ODS Objectsin BW 3.0


2/34

SAP AG 2001, Title of Presentation, Speaker Name 2

SAP Portals 2002, BI RIG, LS

Agenda

ODS Objects in BW 3.0Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)

02


3/34



Agenda






03


4/34



BW Architecture: Layers & Accessiblity 04

Data Warehouse

Non volatile

Granular

Historical foundation

Integrated

Built via ODS Objects

Multidimensional Model

Multidimensional analysis Aggregated view

Integrated

Built via InfoCubes

Operational Data Store

Operational Reporting

Near Real-Time / Volatile

Granular

Built via ODS Objects


5/34



Motivation for Implementation

Physical store for integrated, granular data from the staging

process (as a historical foundation of the data warehouse)

Means to transform, merge, hold and export data

Framework to handle volatile and most recent reporting

scenarios

SoHow do ODS Objects help ME?

05


6/34



ODS Object Design

Key Fields

Data Fields

Settings

06


7/34 SAP AG 2001, Title of Presentation, Speaker Name 7 SAP Portals 2002, BI RIG, LS

Comparison PSA / ODS Object / InfoCube

Object/Property PSA ODS Object InfoCube

Method, Usage Buffer/Maintenance Harmonization

Consolidation /EnterpriseData Model (EDM)

Query optimization,

Aggregation

Data retention Buffer (approx. 30 days)

for transactional data and

master data; it might be

of longer duration if no

ODS Objects are used

Memory for transactional

data/permanent

Memory for aggregated

data/permanent

Data origin DataSource / source-

system-dependent

InfoSource-dependent InfoSource-dependent

Manipulation Add Change/add/delete Add

Data structure Relational databasetables; request-oriented

key

Relational database tablesNormalized, semantic key

w/o request

Star schema, de-normalized

Reporting Typically no reporting,

possible via InfoSetQuery

for detailed Reporting

Reporting at a high level of

granularity, mainly flat

reporting

Multi-dimensional

Reporting at a low level

of granularity

07



Flexible Update into any Data Target

Transfer-Structure Transfer-Structure

Attributes Texts

InfoSource

ODS

Object

08



Update Rules

MasterData ODS

Master Data InfoSource

Flexible Master Data Staging - Example

Additional master data layer

(optional)

Cleansing

Consolidation

Populate master data tables from

consistent ODS objects

Refresh and recalculate, e.g. for

status attributes or transitive

(dependent) attributes

Benefit: Flexibility

Business Partners

MasterDataCustomers

Master

DataVendors

09



Characteristics: New Settings (ODS Object relevant)

Direct

update

Flexible

update

ODS Object

for checking

10



Check of Referential Integrity - Example

Communication Structure Enable check (optional)

1000

Bus. Partner

Look Up

Error Handler

InfoObject Bus. Partner 9000 doesnt

meet the referential Integrity => the

record is marked as erroneous

9000 not allowed

ODS-Object defined in InfoObject as check table

11



Check of Referential Integrity - Details

Selective check of the value of a single InfoObject in transfer

rules against

Master Data table or

ODS Objects

Available for all InfoObjects

Find errors as soon as possible

Integrated in Error handling

Optional split of not allowed records into a second Request

Difference to Master Data check of InfoPackage-Level:

Check of Referential Integrity MD check of InfoPackage-Level

All Data targets All Data targets

One check in transfer rules Check after updatre rules for each data target

Only for selected InfoObjects All InfoObjects

Error-handling Aborts after first erroneous record

Works for all ODS objects BW 2.0 SP18: ODS only if BEx-Reporting is active

Check against MD-table or ODS Object is possible Check only against MD-table

12



Lookup of Master Data Attributes in Update Rules

In 3.0 it is possible to fill a data field of an ODS-Object or anattribute of an InfoObject by reading the attribute from the MD-

table of the InfoObject

Example:

Document # Customer GroupCustomer #... ...ODS Record

Customer GroupCustomer # ...Master Data Record

Lookup

13



InfoSet - Joining ODS Objects and Master Data

related

objects

ON condition

14



InfoSets Benefits for ODS Object Access

Fully integrated in Business Explorer

BEx as reporting frontend (all reporting and web reporting features available)

Accessed via OLAP engine (full range of OLAP features is utilized) Same functionsno specific user training necessary

Integrated into Administrator Workbench

InfoProvider-Tree

InfoSets can join all flat BW Objects ODS Objects

Attributes

Texts

You can setup a consistent and normalized data warehouse layerusing ODS-objects, which is very flexible from an operationalreporting point of view.

15



ODS Objects: New BAPI/API

External System

Read API

Write API

Customer program

BW system

ODS

Object

Read BAPI

Write API

APIs support additional openness

Read BAPI Internal: Look up for data targets

External: Provide ODS Objectinformation for external application

Write API Limited to transactional ODS Objects

Additional flexibility

Update from external system

16



Selection Criteria for Data Marts 17


18/34

SAP AG 2001, Title of Presentation, Speaker Name 18 SAP Portals 2002, BI RIG, LS

Delta Update to ODS Objects

Serialization required due to overwrite capabilities

New methods with PI-2003.1:

A - Direct delta:

Direct transfer or records to delta queue.

Every record becomes LUW.

No need for V3.

B - Queued delta:

Data collection in Extraction Queue.

CNon-serialized V3 Update

Same feature as before.

Sequence of data records not guaranteed.

See OSS note 500426 for additional details

18


19/34


Distribute ODS Object Data - Open Hub Service 19

Controlled distribution

of consistent data

Target: file or DB table

Central monitoring

Select filter criteria and

columns

Scheduling

Full or delta mode

InfoCubes

ODS Objects

BW

Server

External

DataMart

. . .

. . .

RelationalTable

Flat

File

Master Data


20/34


Agenda






20


21/34


New Technical Architecture

Enabling of parallel upload and parallel activation

Transactional ODS Objects

21


22/34


New Technical Architecture Parallel upload

Parallel upload supported

On data package and request

level

Reduced upload times

No table for new and modified

data (M-table)

Faster availability for reporting

Benefit: Performance

File File

ODS

Object

22


23/34


New Technical Architecture - Compare 2.0B to 3.0

active data

Staging Engine

change log

New/modified

data

Req1

Req2

Req3

Activation Activation

Req2

Req3

Req1

Activation

queue

ReqID, PackID, RecNo

ReqID, PackID, RecNoDoc-No.

Doc-No.

23

New Technical Architecture Update Example BW 3 0


24/34


New Technical Architecture, Update Example BW 3.0

Active data

Staging Engine

Req2

Req3

Req1

Activationqueue

Req.ID I Pack.ID I Rec.No

Change log

Doc.No I Value

ODSRx I P 1 I Rec.1I4711I 104711 I 10

Activation

Activation

During activation the data is sorted by the

logical key of active data plus change log

key.This guarantees the correct sequence of the

records and allows inserts instead of table

locks .

REQU1 I P 1 I Rec.1I4711I 10

REQU2 I P 1 I Rec.1I4711I 30

Upload to Activation queue

Data from different requests are uploaded inparallel

to the activation queue

ODSRy I P 1 I Rec.1I4711I-10

ODSRy I P 1 I Rec.2I4711I+304711 I 30

Before- and After Image

Request ID in activation queue and change

log differ from each other.

After update, the data in the activation queue

24


25/34


ODS Object

New Technical Architecture - ODS Object Type

Standard type

Used for staging

- this is the 2.0B ODS Object Track changes with change log

Available for staging (in and out)

Future enhancements: Standard type

without change log

Transactional type (new in 3.0)

Used as data storage for applications,

e.g. SAP SEM, external application

Direct update via APIsno staging

Real-time visibility of updates No change log availableno delta

support for connected data targets

Only queries via InfoSets supported

ODS

Object

changelog

activedata

API

Staging

Activation

queue

25


26/34


Agenda

BW ODS 3.0Concept and Application




Upgrade considerations (2.0 > 3.0)

26

I d Ad i i t ti S d I d


27/34


Improved Administration - Secondary Indexes

Primary indexes are generated automatically

Secondary indexes creation in ODS Object maintenance

Secondary index must differ from primary index

Maximum 16 secondary indexes

Benefit: Improved administration

27

M i t f S d I di


28/34


You are now able to:

Maintenance of Secondary Indices

Flag: Trans.ODS Object

Index

Maintenance

28

Additi l Ad i t ti F t


29/34


Additional Adminstration Features

Selective deletion of requests (backout)

Selective deletion of active ODS Object records

Deletion of entries in the change log

Simulation of update from the ODS Object into data targets

Integration in Open Hub Service

Display data via Data Browser (Listcube)

Popup for field selection

Benefit: Improved administration

29

A d


30/34


Agenda






30

A hi i M ti ti


31/34


Archiving - Motivation

Customer requirements:

Data objects relevant for archiving InfoCubes

ODS Objects

PSA

Master data

Functionality

Both Archiving and Data Deletion (without archiving)

Select data based on any criteria

Automatically scheduled on a periodic base

Restoring of archived data

Data retention time

3 to 5 years in InfoCube and ODS Objects

Consistent archiving processes

31

A d


32/34


Agenda






32

Upgrade Considerations


33/34


Upgrade Considerations

Upgrade from BW 2.0B to BW 3.0A

Data in M-tables need to be activated first

OldM-table will be dropped during the upgrade

Upgrade cannot proceed, if inactive data exist

Customer routines on M-table need to be adapted

Classic InfoSets on merged Mand A-table

33


34/34

Lothar SchubertBI RIG, SAP Portals America

ODS Objects

in BW 3.0