Lothar Schubert

BI RIG, SAP AG
ODS Objects
in BW 3.0
SAP AG 2001, Title of Presentation, Speaker Name 2
SAP Portals 2002, BI RIG, LS
Agenda

ODS Objects in BW 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)



02
SAP AG 2001, Title of Presentation, Speaker Name 3
SAP Portals 2002, BI RIG, LS
Agenda

ODS Objects in BW 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)



03
SAP AG 2001, Title of Presentation, Speaker Name 4
SAP Portals 2002, BI RIG, LS
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
SAP AG 2001, Title of Presentation, Speaker Name 5
SAP Portals 2002, BI RIG, LS
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
SAP AG 2001, Title of Presentation, Speaker Name 6
SAP Portals 2002, BI RIG, LS
ODS Object Design
Key Fields
Data Fields
Settings

06
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 /Enterprise
Data 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 database
tables; request-oriented
key


Relational database tables
Normalized, 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
SAP AG 2001, Title of Presentation, Speaker Name 8
SAP Portals 2002, BI RIG, LS
Flexible Update into any Data Target
Transfer-Structure Transfer-Structure
Attributes Texts
InfoSource
ODS
Object
08
SAP AG 2001, Title of Presentation, Speaker Name 9
SAP Portals 2002, BI RIG, LS








Update Rules
Master
Data 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
Master
Data
Customers
Master
Data
Vendors
09
SAP AG 2001, Title of Presentation, Speaker Name 10
SAP Portals 2002, BI RIG, LS
Characteristics: New Settings (ODS Object relevant)
Direct
update
Flexible
update
ODS Object
for checking
10
SAP AG 2001, Title of Presentation, Speaker Name 11
SAP Portals 2002, BI RIG, LS
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
SAP AG 2001, Title of Presentation, Speaker Name 12
SAP Portals 2002, BI RIG, LS
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
SAP AG 2001, Title of Presentation, Speaker Name 13
SAP Portals 2002, BI RIG, LS
Lookup of Master Data Attributes in Update Rules

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


Example:



Document # Customer Group Customer # ... ...
ODS Record
Customer Group Customer # ...
Master Data Record
Lookup
13
SAP AG 2001, Title of Presentation, Speaker Name 14
SAP Portals 2002, BI RIG, LS
InfoSet - Joining ODS Objects and Master Data
related
objects
ON condition
14
SAP AG 2001, Title of Presentation, Speaker Name 15
SAP Portals 2002, BI RIG, LS







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 functions no 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 layer
using ODS-objects, which is very flexible from an operational
reporting point of view.
15
SAP AG 2001, Title of Presentation, Speaker Name 16
SAP Portals 2002, BI RIG, LS







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 Object
information for external application

Write API
Limited to transactional ODS Objects

Additional flexibility

Update from external system


16
SAP AG 2001, Title of Presentation, Speaker Name 17
SAP Portals 2002, BI RIG, LS
Selection Criteria for Data Marts
17
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.
C Non-serialized V3 Update
Same feature as before.
Sequence of data records not guaranteed.
See OSS note 500426 for additional details
18
SAP AG 2001, Title of Presentation, Speaker Name 19
SAP Portals 2002, BI RIG, LS
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
. . .
. . .
Relational
Table
Flat
File
Master Data
SAP AG 2001, Title of Presentation, Speaker Name 20
SAP Portals 2002, BI RIG, LS
Agenda

ODS Objects in BW 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)



20
SAP AG 2001, Title of Presentation, Speaker Name 21
SAP Portals 2002, BI RIG, LS
New Technical Architecture
Enabling of parallel upload and parallel activation

Transactional ODS Objects

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







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
SAP AG 2001, Title of Presentation, Speaker Name 23
SAP Portals 2002, BI RIG, LS
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, RecNo
Doc-No.
Doc-No.
23
SAP AG 2001, Title of Presentation, Speaker Name 24
SAP Portals 2002, BI RIG, LS
New Technical Architecture, Update Example BW 3.0
Active data
Staging Engine
Req2
Req3
Req1







Activation queue
Req.ID I Pack.ID I Rec.No
Change log
Doc.No I Value
ODSRx I P 1 I Rec.1I4711I 10
4711 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 in
parallel
to the activation queue
ODSRy I P 1 I Rec.1I4711I-10
ODSRy I P 1 I Rec.2I4711I+30
4711 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
is deleted.
24
SAP AG 2001, Title of Presentation, Speaker Name 25
SAP Portals 2002, BI RIG, LS







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 APIs no staging
Real-time visibility of updates
No change log available no delta
support for connected data targets
Only queries via InfoSets supported

ODS
Object
change
log
active
data
API
Staging
Activation
queue
25
SAP AG 2001, Title of Presentation, Speaker Name 26
SAP Portals 2002, BI RIG, LS
Agenda

BW ODS 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (2.0 > 3.0)



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







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
SAP AG 2001, Title of Presentation, Speaker Name 28
SAP Portals 2002, BI RIG, LS
You are now able to:
Maintenance of Secondary Indices
<>
Flag: Trans.ODS Object
Index
Maintenance
28
SAP AG 2001, Title of Presentation, Speaker Name 29
SAP Portals 2002, BI RIG, LS







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
SAP AG 2001, Title of Presentation, Speaker Name 30
SAP Portals 2002, BI RIG, LS
Agenda

ODS Objects in BW 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)



30
SAP AG 2001, Title of Presentation, Speaker Name 31
SAP Portals 2002, BI RIG, LS
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
SAP AG 2001, Title of Presentation, Speaker Name 32
SAP Portals 2002, BI RIG, LS
Agenda

ODS Objects in BW 3.0 Concept and Application

Technical Architecture

Administration Features

ODS Object Archiving

Upgrade considerations (from 2.0 to 3.0)



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







Upgrade Considerations
Upgrade from BW 2.0B to BW 3.0A

Data in M-tables need to be activated first

Old M-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 M and A-table


33
Lothar Schubert
BI RIG, SAP Portals America
ODS Objects
in BW 3.0