What is the significance of ODS in BIW?

What is the significance of ODS in BIW?

An ODS Object serves to store consolidated and debugged transaction data on a document level (atomic level). It describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or InfoSet Query. The data of an ODS Object can be updated with a delta update into InfoCubes and/or other ODS Objects in the same system or across systems. In contrast to multi-dimensional data storage with InfoCubes, the data in ODS Objects is stored in transparent, flat database tables.

 Mail this post

What is Bex?

Bex stands for Business Explorer. Bex enables end user to locate reports, view reports, analyze information and can execute queries. The queries in workbook can be saved to there respective roles in the Bex browser. Bex has the following components: Bex Browser, Bex analyzer, Bex Map, Bex Web

 Mail this post

Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System

 Mail this post

Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type ‘Repeat’. If you need to repeat the last load for certain reasons, set the request in the monitor to red manually. For the contents of the repeat see Question 14. Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat, if they have not been deleted from the data targets concerned before.

 Mail this post

Relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?

The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix ‘BW, the client and the short name of the DataSource. For DataSources whose name is 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN.

In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.

 Mail this post

What is the purpose of function ‘Delete data and meta data in a queue’ in RSA7?

You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization.

When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.

The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.

 Mail this post

Transport Strategy

 

Transport strategy is developed to answer the questions as below:

 

·         What is my system landscape?

·         How many different projects are working on that system?

·         How complex are my scenarios?

·         Who is responsible for transports / development classes (central,

·         decentral)?

·         Which kind of system (development, consolidation, production)?

·         How can the transport of BEx objects be organized?

In a standard three system landscape one development class may be sufficient, transport using object collector. In a complex landscape different objects might have to be transported to different system (different development classes, transport layers). There are typically some common objects that need to be transported to all systems and some specific ones.

 

Number of Projects in a system

 

Basically the system landscape considerations also apply for projects. You have to distinguish between common objects and project specific ones. You may want to be prepared to split up into different systems later on (e.g.for performance reasons).

 

Complexity of Scenarios

 

In very complex scenarios dependencies of objects can also be complex. Activating automatic transport connection ensures that no objects are forgotten but the order of the imports is then very important. The object collector helps you find the dependent objects but transport requests may contain many objects. In case of problems split up transports (into parts of the data flow).

 

Responsibility

 

If you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue. Central management may be necessary to decide. Which object is assigned to which development class, which objects are collected in one transport request, in which order and when do the transports take place.

 

Type of Systems

 

The above considerations are focussed mainly on development systems, you may want to create some objects in the consolidation system in exceptional cases. Activation of automatic transport connection for keeping track of all such objects / changes may be a good approach

In the productive system you typically don‘t create objects to be transported but e.g. queries (ad hoc reporting). Using default BW setting (no automatic transport connection) is usually the best option (independent of settings in development or consolidation systems).

 

Transport of BEx Objects

 

Since BEx Objects (once they are assigned to a transportable development

class) are transported in a special way there are special considerations:

 

• All changes of BEx objects (in one development class) in a certain period are transported together (unless standard transport system is activated)
• Granularity of development classes for BEx objects is important for flexibility in transports, e.g.
  • On project level
  • On data target level
  • Several ones for each data target
  • One for each query
• Transport management of BEx requests
  • Agreement on when transport request is released
  • Creation of a new one immediately after (or before) releasing the old one

 

The only way of grouping BEx objects in a transport (after first transport) is by development class. So you have to determine the granularity you need for transporting BEx objects and set up development classes accordingly.

 

• No changes to BEx objects are possible if:
  • No BEx request exists
  • The old BEx request is released and no new one is created
  • A new BEx request is already assigned but the old one has not been released.

 

 Mail this post

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BI 7 – New features

 

 

 

New features in BI 7

 

- Flexibility

-Transformation Concept

- DataStore object

- Data Transfer Process

- Real-Time Data Acquisition

- Administration Cockpit

- High Performance Analytics

- Near-line Storage

- Enterprise Reporting, Query, and Analysis

Query, Reporting & Analysis – Designing a Query

Query, Reporting & Analysis – Designing a Report

Query, Reporting & Analysis – Designing a Web Application

- BEx Web Printing

- Information Broadcasting – Enhancements

- Business Planning and Analytical Services

- Further Enhancements

- The Administrator Workbench is now called Data Warehousing Workbench.

- The ODS object is now called DataStore object.

- The transaction ODS object is now called as direct update DataStore

- The transactional InfoCube is now called real-time InfoCube.

- The RemoteCube, SAP RemoteCube and virtual InfoCube with services are now referred

to as VirtualProviders.

- The monitor is now called the extraction monitor, to distinguish it from the other monitors.

 

New terminology in BI 7

 

BI 7 provides additional flexibility for implementing new data models and changing

existing ones :

Remodeling Toolbox

Changing InfoCubes without rebuilding them from scratch – improved flexibility. As of

now applicable only for infocube. To access re-modeling option select InfoCube->right

click Additional function->Remodelling

Note: During (dictionary-based) conversion process it is not possible to get data in

queries, aggregates will be automatically deactivated and need to be rebuilt.

Transporting remodeling is not possible

Enhanced DataStore objects

 

 

(formerly: ODS objects)

Improved performance and flexibility. New DataStore type: Write-optimised (without

change-log, no activation queue)

Enhanced Info Sets

Improved flexibility

Integrate InfoCubes into join condition, can have join between infocube and master data

(outer join between master data and InfoCube).

 

Modeling the EDW – Flexibility

Remodelling

 

InfoSet with master data and InfoCube

 

BI 7 significantly improves transformation capabilities.

Improved performance, flexibility and usability

Graphical UI

Unification of transfer and update rules

Grouping (Ex. Sales agent and his manager)

New rule type: end routine – Data after transformation

New rule type: expert routine (pure coding of transformation)

Transformation directly links from source Infoprovider

(Datasource) to target Infoprovider (Infosource usually not

required)

 

 

 

Data transfer process

BI 7 improves and streamlines the data flow definition and process chain set-up. In addition,

it provides new real-time data acquisition capabilities that facilitate operational reporting:

Data transfer process (DTP)

Data distribution within SAP BI (from PSA or Info Providers to Info Providers)

Improved transparency of staging processes across data warehouse layers

(PSA, DWH layer, ODS layer, Architected Data Marts)

Improved performance

Separation of delta mechanism for different data targets (Ex: Daily/Weekly load)

Enhanced filtering in dataflow

 

 

 

Data Transfer process (Filter option)

 

 

 

Enhanced real-time data acquisition capabilities

XML Web service

Direct push into PSA (instead of Service API/Delta Queue)

Near-real-time InfoPackage & DTP

Daemon-based update from delta queue (BW Service API)

Daemon-based update of DataStore objects

(ODS layer) – including lean staging (with minimized logging)

 

Real time data acquisition

 

- Enhanced real-time data acquisition capabilities

 

 

 

High performance Analytics

 

BI 7 provides various tools to increase the data load and query performance

Significantly – among them the innovative high performance analytics approach.

Thus, the implementation of large enterprise data warehouses is facilitated.

High performance analytics (HPA) / BI Accelerator (BIA)

A new paradigm for high performance data access.

- Query performance is improved by factor 10 – 100

- HPA is used in connection with KM search engine TREX

- TREX indexes – Vertical indexes in which stored data in column wise not row wise

- No need of change run in aggregates

Near-line storage

Administrator cockpit

 

Enterprise Reporting, Query and Analysis

 

Query , Reporting and Analysis.

Query design takes place in the Business Explorer (BEx) Query Designer,

a Visual Basic .NET-based Unicode-compliant tool.

 

 

State-of-the-art UI concept, providing for example:

 

 

 

Available tasks for a selected object presented via a

task pane

 

 

 

Message panel shows warnings and error messages in context 

helps to avoid or

correct errors

 

 

 

Enhanced application menus, toolbars and context menus

 

 

 

Extended visualization of status and user actions

 

 

Support of multi-selected objects – drag&drop, properties

 

 

Options for BI-integrated Planning

26

Report designer

Designing a Report

Report design takes place in the Business Explorer (BEx) Report Designer – a new,

VB .Net-based tool that allows to create formatted, print-optimized reports.

 

 

Standard formatting: Font styles (e.g. bold, italic) and colors, etc.

 

 

Group level changes with individual formattings

 

 

Layout options, for example

 

 

 

Height of rows, width of columns

 

 

 

Multiline column headers

 

 

 

Flexible positioning of fields

 

 

 

Merger of cells

 

 

Support of hierarchies

 

 

Integration of texts, pictures, and charts

 

 

Header and footer for reports and pages

 

Web application designer

 

Model-driven BI application building

 

 

 

Wizards for charts, maps, command editing

 

 

 

Wizard for layout elements (e.g. buttons)

 

 

 

Intellisense“ support for Web API developers

 

 

 

Easy integration of native HTML commands

 

 

New layout elements (Tab strips etc.)

 

 

New Web items

 

 

New chart types, e.g. GANTT chart, MTA (Milestone trend analysis) chart

 

 

Design of planning aware business applications

Web printing

Comfortable PDF based BEx Web printing

 

 

Any type of BEx Web query, Report or Web Application can be converted to PDF and printed

 

 

Leveraging the SAP NetWeaver AS integration with Adobe Document Service

 

 

Adobe Acrobat Reader required, no plug-ins necessary

 

 

Printing options can be maintained globally or individually by an end-user

 

Business planning and analytics services (BI integrated planning)

 

 

Open and flexible planning framework for all SAP applications

 

 

Fully integrated with BI and analytics services

 

 

One user interface, one design environment, one engine

 

 

Shared services and persistency and integrated meta data

 

Further enhancement

 

Modeling the EDW

Data Warehousing Workbench

New infocube maintanence UI like ODS

Contains process chain maintanence,monitor, delta queue etc.

Display complete dataflow from source to target

PSA mandatory

Running the EDW

Process Chains

Display-only mode, copying of process chain

Additional functionality(interupt process,workflow, and process types (condition),

choosing background user for execution process

New Analysis Authorization concept

Higher flexibility and simplified modeling

32

Process chain enhancement

33

Data warehouse workbench

34

InfoCube maintenance

35

Distinction between 3.X and BI 7 objects

36

BI 7 vs. 3.x DataSource

37

Migration

38

DataSource Migration

 Mail this post