SAP Online Training for ALL Technical & Functional Modules

SAP BW Architecture

2011-08-04T17:47:00.000+05:30

Theoretically, SAP BW Architecture can be divided into 3 layers: Sources System, SAP BW Server and SAP BW OLAP.

SAP BW Architecture

Source system:
Source system is a reference system that functions as data provider for SAP BW.
There four type source system than can be SAP BW provider:
mySAP.com components: SAP BW is fully integrated into mySAP.com component. Currently, predefined extraction structures and program from mySAP.com component are delivered by SAP. Therefore, we can upload data source from mySAP.com component directly into SAP BW.
Non-SAP systems: SAP BW is an open architecture that can interface vis-à-vis tp external OLTP or legacy system. Based on information or data collected from heterogeneous system, SAP BW has possibility to be a consolidated data basis reporting to support management in decision making.
Data Providers: Market research result from, for example, AC Nielsen USDun & Bradstreet can be loaded into SAP BW. The uploaded information can be used as benchmarking and measurement again our operative data.
External databases: Data from external relational database can be loaded to SAP BW too.
SAP BW Server
SAP BW Server has several features:
Administration Service: The administration service is responsible for organization within SAP BW. Administration service is available through the Administrator Workbench (AWB), a single point of entry for data warehouse development, administration and maintenance tasks in SAP BW.
Metadata Service: SAP BW metadata services component provide both an integrated metadata repository where all metadata is stored and a Metadata Manager that handles all requests for retrieving, adding, changing, or deleting meta data.
Extraction, Transformation, and Loading (ETL) Services: Depending on the source systems and type of data basis, the process of loading data into the SAP BW is technically supported in different ways.
Storage Services: the storage service (known as SAP BW Data Manager) manages and provides access to different data target available in SAP BW, as well as aggregates stored in relational or multidimensional database management system.
SAP BW OLAP
The Online Analytical Processing (OLAP) layer allows us to carry out multi-dimensional analysis of SAP BW data sets. In principle, the OLAP layer can be divided into three components:
BEx Analyzer (Microsoft Excel Based)
BEx Web Application
BEx Mobile Intelligence.
What I wrote above (Sources System, SAP BW Server and SAP BW OLAP) are the architecture of SAP BW (Business Information Warehouse) in global explanation.

Enterprise Data Warehousing with SAP BW – An Overview

2011-08-04T17:46:00.001+05:30

When we talk about enterprise data warehousing it is first necessary to ask what we understand by this term:
Enterprise data warehousing is the sum of all the decisions that have to be taken at corporate level in order to obtain a durable solution that adheres to business-wide, specified guidelines, and fulfills all requirements for integrated, consistent and structured information.

These decisions are mirrored in the enterprise data warehouse architecture.

In this chapter we will consider the aspects of such an architecture so that we can then look more closely at how BW supports an architecturally-based, consistent, corporate data warehouse solution.

As well as a BW architecture that ensures consistency, we want to consider in what ways the BW offers support in generating consistent application solutions.

Please download the detailed book from the following link:

SAP BI 7.0 Enterprise Reporting, Query and Analysis

2011-08-04T17:45:00.000+05:30

The reporting, analysis, and interpretation of business data is of central importance to a company in guaranteeing its competitive edge, optimizing processes, and enabling it to react quickly and in line with the market.

As a core component of SAP NetWeaver, the SAP Business Information Warehouse (SAP BW) provides data warehousing functionality, a business intelligence platform, and a suite of business intelligence tools that enable businesses to attain these goals.

Relevant business information from productive SAP applications and all external data sources can be integrated, transformed, and consolidated in SAP BW with the toolset provided. SAP BW provides flexible reporting and analysis tools to support you in evaluating and interpreting data, as well as facilitating its distribution. Businesses are able to make well-founded decisions and determine target-orientated activities on the basis of this analysis.

The following graphic shows how the SAP BW concept is structured. Data Warehousing, BI Platform and BI Suite represent the core areas of SAP BW.

Integration

The following graphic shows where SAP BW is positioned within SAP NetWeaver. Furthermore, those subareas that incorporate SAP BW are listed. These are described in detail below.

Please download the Detailed book for the SAP BI Reporting from the following link:

SAP BW Data Extraction

2011-08-04T17:44:00.000+05:30

n Extraction programs that read data from extract structures and send it, in the required format, to the Business Information Warehouse also belong to the data staging mechanisms in the SAP R/3 system as well as the SAP Strategic Initiative products such as APO , CRM and SEM.

n The IDOC structures or TRFC data record structures (if you choose to use the PSA - Persistent Staging Area) that are generated from the transfer structures for the Business Information Warehouse on the source system side are used for this.

n These extraction tools are implemented on the source system side during implementation and support various releases.

n In non-SAP applications, similar extraction programs can be implemented with the help of third party providers. These then collect the requested data and send it in the required transfer format using BAPIs to the SAP Business Information Warehouse.

n The OLTP extraction tables form the basis of a DataSource on an R/3 OLTP system. The structure is written in the OLTP using the data elements that describe the available data, usually from a table view.

n For an R/3 OLTP source system, the ‘DataSource Replication’ step is provided to duplicate the DataSource is replicated with its relevant properties in BW. Once there you can assign it to an InfoSource.

n You can request the Metadata for a DataSource, the Metadata for an application component, or all the Metadata of a source system:

Ÿ To replicate the Metadata of a DataSource, choose Source System Tree ® Your Source System à DataSource Overview à Your Application Components àYour DataSource à Context Menu (right mouse click) à Replicate DataSources in the BW Administrator Workbench

Ÿ To replicate the Metadata from a source system into BW for an application component, choose Source System Tree ® Your Source System ® DataSource Overview ® Your Application Components ® Context Menu (right mouse click) à Replicate DataSources in the BW Administrator Workbench

Ÿ To update all the Metadata of a source system, choose Source System Tree à Your Source System à Context Menu (right mouse click) à Replicate DataSources in the BW Administrator Workbench

n All application data must be described in SAP BW using meta data. The InfoObjects used for this are not just transaction and master data but also relationship sets such as attributes or hierarchies for master data.

n Further detailed information, such as exchange rates, comes from the operative applications.

n For reasons of performance, delta update mechanisms are also supported in most application areas on the OLTP side. With a periodic data transfer into BW, only those data records and objects that have changed or been added since the last data transfer need to be considered.

The mechanisms used are explained in detail later

n The transfer structures are oriented to the data formats of the source system.

n The transfer rules are processed with the transfer of the data from the source system oriented transfer structure to the BW oriented communication structure and, for the most part, have the objective of the homogenization of data from different source systems.

If data is being loaded from flat files,it must be able to be described with SAP BW InfoObjects. You can also create new InfoObjects for this purpose easily in the SAP BW

n Updating is controlled separately for each key figure. The characteristic values for updating can be established separately for each key figure.

n Different updating methods can be chosen interactively, and you can also formulate as many algorithms in ABAP as you like via the function extensions. Requirement handling is also supported.

n You proceed in a similar way with the transfer of data from non-SAP systems into the Business Information Warehouse: You define transfer and communication structures and then create transfer and update rules for them that fine tune the data flow. You describe the structures using InfoObjects that can be created individually where necessary.

n Using third party tools you can implement the necessary infrastructure for data staging for the SAP Business Information Warehouse in the non-SAP systems. Therefore, InfoSources, InfoObjects, extract structures and extract programs are available that communicate with the Business Information Warehouse using BAPIs.

n Meta data such as InfoObjects and InfoSources can then also be loaded from the external (non-SAP) OLTP into the Business Information Warehouse.

In the simplest case you use the Business Information Warehouse file interface in order to import MS-Excel files in CSV format, for example. You store the record description for the data file in the Business Information Warehouse as a transfer structure

n The SAP BW extractors carry out a number of functions in the SAP OLTP, in order to guarantee smooth communication between SAP OLTP and SAP BW.

n These tasks must be carried out by external software in non-SAP Systems, that are set up in the BAPI interfaces of the SAP BW.

Various businesses have already been certified as official third party providers in this field. A complete list can be found on the SAPnet BW homepage.

Virtually any source of data can be extracted for use in the Business Information Warehouse

n Two options for data transfer are possible

Ÿ TRFC (chosen by selecting PSA in the transfer structure)

TRFCs are faster than ALE but there is a 255 field and a 1962 byte limit imposed. The transfer is asynchronous and runs in the background.

Ÿ ALE (IDOC)

Here there is a 1000 byte limit imposed. The load process takes place in two steps and tracing of the status of each step is provided.

n Benefits of TRFC

Ÿ Improved performance when loading data.

Ÿ Overcoming the 1000 byte limit (now a maximum of 255 fields and 1962 bytes).

Ÿ Possibility to synchronize InfoSources.

API to access the data stored in the ODS (read and update).

Please download the full document from the following link:

Data Extraction from SAP to BW using Generic Extractors

Data Extraction from SAP to BW using LO Extractors

Master Data Loading in SAP BI 7.0

2011-08-04T17:40:00.001+05:30

Please download the Document for the Master Data Loading into SAP BI 7.0:

Data Upload from Flat File to Business Intelligence 7.0 System

2011-08-04T17:40:00.000+05:30

Introduction:

This article describes about the basic steps from the beginning that if the user is given a flat file (.CSV file),
then what steps he need to follow to upload the whole data in the BI 7.0 system using all the rules present in
the BI system. Here I am going to explain the whole process with the help of screenshots.

Please download the document for step by step guide with the screenshots:

What is an Infocube in SAP BW?

2011-08-04T17:35:00.000+05:30

In SAP business Intelligence, InfoProviders are the basis of most of the reporting you will be doing in the real time. They are the objects that serve your reports with data. Hence the name InfoProviders.

There are two types of InfoProviders, these are listed below

InfoCube, this type of InfoProvider stores the data in the system and makes it available for reporting.
Virtual providers for example a Multiprovider, this will be covered in a later lesson but basically, this is a type of InfoProvider that does not store the data physically but combines the data from multiple InfoCubes into one view.As far as reporting is concerned, it does not know how the data is stored. Physically or not, the data is being presented to the reporting query in the same way.

A standard installation of SAP BI comes with a lot of default InfoCubes that models many business processes from Financials to Sales and distribution. As a SAP BI consultant, most of the time you will not need to create your own InfoCube but rather use one out of the box or customize the existing one to suit your needs.

An InfoCube is modelled after the extended star schema shown in the picture above. The fact table in the center of the cube contains the key figures. The fact table is surrounded by dimensions which contain characteristics.

These are some statistics that are important if you plan to take the certification exam or during interviews.

An InfoCube consists of one fact table that is used to store key figures.
The maximum number of key figures that the fact table can store is 233
The same fact table can have a minimum of 4 and a maximum 16 dimension tables.
3 of these dimension tables are supplied by SAP. They are the Unit, data package, and time dimensions.
The customer can create 13 dimensions.
Each of the 13 dimensions can have a maximum of 248 InfoObjects.
Each InfoObject can also contain master data in the form of Text, Attributes and Hierarchies.

So you can see how advanced modelling is done in SAP business intelligence. This allows for efficient reporting at the later stages.

Infocube Creation using SAP BI 7.0

2011-08-04T17:34:00.000+05:30

Please download thd Pdf from the following pdf download link for the step by step guide to create Infocube in SAP BI 7.0.

What is ODS/DSO Object in SAP BI ?

2011-08-04T17:33:00.000+05:30

A DataStore object serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level.

This data can be evaluated using a BEx query.

A DataStore object contains key fields (such as document number, document item) and data fields that, in addition to key figures, can also contain character fields (such as order status, customer). The data from a DataStore object can be updated with a delta update into InfoCubes (standard) and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.

Unlike multidimensional data storage using InfoCubes, the data in DataStore objects is stored in transparent, flat database tables. The system does not create fact tables or dimension tables.

DataStore object types:

1.Standard DataStore object

Data provided using a data transfer process
SID values can be generated
Data records with the same key are aggregated during activation
Data is available for reporting after activation

2.Write-optimized DataStore object

Data provided using a data transfer process
SID values cannot be generated
Records with the same key are not aggregated
Data is available for reporting immediately after it is loaded

3.DataStore object for direct update

Data provided using APIs
SIDs cannot be generated
Records with the same key are not aggregated

Please download the documents for the detailed information of each type of the DSO from the following link:

DSO Creation in SAP BI 7.1

2011-08-04T17:32:00.000+05:30

Please download the step by step guide for the DSO Creation in SAP BI 7.0 from the following link:

Difference between ODS and DSO objects

2011-08-04T17:31:00.000+05:30

Since SAP BW version 7.x there is a new term introduced for former ODS (Operational Data Store) object. DSO stands for Data Store Object.

Some general information about ODS/DSO: In principle from data warehousing point of view such an objects are serving for storing of data from multiple sources to make analyses of data and simplifying reporting. Since data is coming from different sources data needs to be cleansed (e.g. redundancy) and consolidated (e.g. from business point of view).

ODS/DSO objects store data in detailed level (atomic). In addition pure “data warehouse theory definition” would be that data to ODS/DSO is captured in “real time” or “near real time” mode and there is bigger portion of data available as opposite to data warehouse’s cubes.

ODS/DSO is combining key field (e.g. business document or its item) with data field (e.g. business document status and other properties) as a key figures. There is nothing multidimensional (no dimension neither fact tables) with ODS/DSO as with cubes. Data in ODS/DSO is stored in transparent (flat) database tables. ODS/DSO objects are reportable.

In BW 3.x following types of ODS are used:

1. Standard ODS:

i. Inbound ODS object – or Inflow ODS where the data is stored in the same form as it is when delivered from the source system.

ii. Consistent ODS object - Data is stored here in granular form and consolidated.

iii. Application-related ODS object – data is combined according to the business process rules and serves as a basis for operative reporting.

2. Transactional ODS object – data is immediately available here for reporting no data is stored in different versions (active, delta, modified).

In BW 7.x following types of ODS were introduced:

1. STANDARD DSO OBJECT – AS STANDARD 3.X ODS; 3 TABLES WITH DIFFERENT DATA VERSION (NEW/ACTIVE/DELTA) DATA.

2. DSO OBJECT FOR DIRECT UPDATE - AS TRANSACTIONAL 3.X ODS; DATA IN A SINGLE VERSION.

3. WRITE OPTIMIZED DSO - CONTAINS ONLY ONE TABLE OF ACTIVE DATA; DATA IS LOADED USING THE DATA TRANSFER PROCESS.

7.x DSO types differences:

Difference between ODS vs CUBE

2011-08-04T17:30:00.000+05:30

ODS vs CUBE:

The main difference between the ODS Object and the PSA and InfoCube is that the ODS Object allows existing data to be changed. Whereas an InfoCube principally allows inserts, and only allows deletion on the basis of requests, data in an ODS Object can be changed during the staging process. This enables an ODS Object to be used as a consolidation Object in a Data Warehouse. PSA data change is only supported by manual change or by customer programs and not by the staging mechanism.

Unlike ODS Objects; InfoCubes have a mandatory time-dimension that allows you to look at particular relationships in relation to time-periods. For example, you can look at how relationships have changed over a certain time-period.

An ODS Object is principally used for analyzing the status of data at a certain point in time. This allows you to see what relationships are currently like. Exceptionally you can also track history in ODS Objects by adding a date to the key fields of the ODS Object.

It is generally true to say that it is not always necessary to implement ODS Objects in every scenario. Rather, it depends on the requirements of each scenario. You should only use ODS if the requirements of your scenario fit one of the three usage possibilities outlined above (Inbound ODS, Consistent ODS, Application-related ODS). An ODS Object placed in the data flow

to an InfoCube without having a function does nothing except hinder loading performance.

What is InfoObjects in SAP BI 7.0 ?

2011-08-04T17:29:00.000+05:30

InfoObject

Definition

Business evaluation objects are known in BW as InfoObjects. They are divide into characteristics (for example, customers), key figures (for example, revenue), units (for example, currency, amount unit), time characteristics (for example, fiscal year) and technical characteristics (for example, request number).

Use

InfoObjects are the smallest information units in BW. They structure the information needed to create data targets.

InfoObjects with attributes or texts can be either a pure data target or an InfoProvider (if it is being reported).

Structure

Characteristics are sorting keys, such as company code, product, customer group, fiscal year, period, or region. They specify classification options for the dataset and are therefore reference objects for the key figures. In the InfoCube, for example, characteristics are stored in dimensions. These dimensions are linked by dimension IDs to the key figures in the fact table. The characteristics determine the granularity (the degree of detail) at which the key figures are kept in the InfoCube. In general, a data target contains only a sub-quantity of the characteristic values from the master data table. The master data includes the permitted values for a characteristic. These are known as the characteristic values.

The key figures provide the values that are reported on in a query. Key figures can be quantity, amount, or number of items. They form the data part of a data target.

Units are also required so that the values for the key figures have meanings. Key figures of type amount are always assigned a currency key and key figures of type quantity also receive a unit of measurement.

Time characteristics are characteristics such as date, fiscal year, and so on.

Technical characteristics are used for administrative purposes only within BW. An example of a technical characteristic is the request number in the InfoCube. This is generated when you load a request as an ID and helps you locate the request at a later date.

Special features of characteristics:

If characteristics have attributes, texts, or hierarchies at their disposal then they are referred to as master data-bearing characteristics. Master data is data that remains unchanged over a long period of time. Master data contains information that is always needed in the same way. References to this master data can be made in all data targets. You also have the option of creating characteristics with references. A reference characteristic provides the attributes, master data, texts, hierarchies, data type, length, number and type of compounded characteristics, lower case letters and conversion routines for new characteristics.

A hierarchy is always created for a characteristic. This characteristic is the basic characteristic for the hierarchy (basic characteristics are characteristics that do not reference other characteristics). Like attributes, hierarchies provide a structure for the values of a characteristic. Company location is an example of an attribute forCustomer. You use this, for example, to form customer groups for a specific region. You can also define a hierarchy to make the structure of the Customer characteristic clearer.

Special features of key figures:

A key figure is assigned additional properties that influence the way that data is loaded and how the query is displayed. This includes the assignment of a currency or unit of measure, setting aggregation and exception aggregation, and specifying the number of decimal places in the query.

Mater Data Loding in Info Objects in BI 7.0

2011-08-04T17:27:00.000+05:30

Please download the pdf from the following link for the Complete stey by step navigation to Load Master Data in Info Objects.

What is InfoSets in SAP BI 7.0 ?

2011-08-04T17:26:00.000+05:30

InfoSet

Definition

Description of a specific kind of InfoProvider: InfoSet describes data sources that are defined as a rule as joins of DataStore objects, standard InfoCubes and/or InfoObjects(characteristics with master data). A time-dependent join or temporal join is a join that contains an InfoObject that is a time-dependent characteristic.

An InfoSet is a semantic layer over the data sources.

Unlike the classic InfoSet, an InfoSet is a BI-specific view of data.

For more information see the following documentation: InfoProviders, Classic InfoSets.

Use

With activated InfoSets you can define queries in the BI suite.

InfoSets allow you to report on several InfoProviders by using combinations of master data-bearing characteristics, InfoCubes and DataStore objects. The information is collected from the tables of the relevant InfoProviders. When an InfoSet is made up of several characteristics, you are able to map transitive attributes and report on this master data.

You create an InfoSet using the characteristics Business Partner (0BPARTNER) – Vendor (0VENDOR) – Business Name (0DBBUSNAME), and can then use the master data for reporting.

You can create time runs with an InfoSet by means of a temporal join (for this, see Temporal Joins). With all other types of BI object, the data is determined for the query key date, but with a temporal join in an InfoSet, you can specify a particular point in time at which you want the data to be evaluated. The key date of the query is not taken into consideration in the InfoSet.

Structure

You can include every DataStore object, every InfoCube and every InfoObject of the type Characteristic with Master Data in a join. A join can contain objects of the same object type, or objects of different object types. The individual objects can appear in a join any number of times. Join conditions connect the objects in a join to one another (equal join-condition). A join condition determines the combination of records from the individual objects that are included in the resulting set.

InfoSet Creation in SAP BI 7.0

2011-08-04T17:25:00.000+05:30

What is Multi Providers in BI 7.0

2011-08-04T17:21:00.000+05:30

Definition
A MultiProvider is a special InfoProvider that combines data from a number of InfoProviders and makes them available as a whole to reporting. The MultiProvider itself does not contain any data; its data comes exclusively from the InfoProviders it is based on.

InfoProviders and MultiProviders are the objects or views that are relevant for reporting.

Use
A MultiProvider allows reporting using several InfoProviders.

InfoCube and InfoCube: You have an InfoProvider with actual data for a logically closed business area and an equivalent InfoProvider with plan data. You can combine the two InfoProviders into one MultiProvider so that you can compare the actual data with the planned data of a query. In BW release 2.0B/2.1C, this combination of two InfoCubes was still called a MultiCube.

InfoCube and InfoObject: You have an InfoCube with your products and sales. You combine InfoObject 0PRODUCT. In this way you can display the "slow-moving items" since products that do not result in sales are also displayed. This is made possible because a union operation is used to combine the tables (see below).Structure

A MultiProvider can consist of different combinations of the following InfoProviders: InfoCube, ODS object, InfoObject and InfoSet. The data from these objects can be combined in the MultiProvider with a union operation.

The union operation creates a union of the featured tables. That is, all values in these tables are combined. As a comparison: InfoSets are created using joins. These only combine values that appear in both tables. In contrast to a union, joins build the intersection of the featured tables

Multi Providers Creation in BI 7.0

2011-08-04T17:20:00.000+05:30

Step by step procedure to create a multi provider.

MultiProvider is a special InfoProvider which combine data from several InfoProviders for its own reporting, without actually holding any physical data itself (i.e. its data comes exclusively from the InfoProviders on which it is based), then, it can only use an InfoProvider that is ready and available for reporting, in which case, the Transactional ODS object is not one of them.

Therefore, to include a Transactional ODS object in a MultiProvider, you would have to first define an Infoset for the Transactional ODS object.

You can include Master data table in the Multiprovider but for that you should convert the InfoObject as the data target then only it is possible.

Note : We go for Multiprovider when we want to do reporting on two or more data targets.

A MultiProvider can be made of of various combinations of the following InfoProviders:

1. InfoCubes
2. ODS Objects (Standard only)
3. InfoObjects
4. InfoSets

Creation steps :

1. Go to the info area where you want the multi provider; right click and chose create multi provider.

2. Chose a technical name and also choose the info providers that you make part of this multi provider.

3. When you confirm your entries, you will get a infocube maintenance screen; on the right side, you will see the characteristics available in al the basic cubes that you choose in the first step.

4. Select the chars that you wish to be in the multiprovider and similarly for time chars, key figs, and nav attributes ( if any).

5. Choose to create dimension and you will get a system msg whether to create from any of the basic cubes.

6. Either select to create your own dimension and insert all the chars in to the approprate dimensions.

7. Go back to chars tab and there will be tab for "idendification" click that and here is where you specify which are the chars form each cube you want into the multiprovider. And likewise for the key figure.

8. Activate the multiprovider.

If you have data in the basic cube, you can view the data in the multiprovider from LISTCUBE transaction.

What is Virtual Providers, Types of Virtual Providers & Creation of Virtual Providers in BI 7.0

2011-08-04T17:19:00.000+05:30

Summary:
Virtual Info Cubes are Info Providers with transaction data. It is not stored in the objects themselves, but is
read directly for analysis and reporting purposes. Virtual Providers using DTP is used for Up-to-date
information from SAP Source system provided very small quantity of data exists.

In this article, we'll deal withsuch a situation as a demo example, wherein data is loaded by using DTP. There are also other ways, likeusing BAPI. In case of VPs based on BAPIs, the transaction data is read from a different source which iscalled BAPI (Business Application Program Interface) and not specifically from an SAP source. Similarly, wehave VPs using FM also, incase data needs to be loaded from non-BI Data Sources in BI without having tocopy the dataset into the BI structures.

Introduction
Virtual info provider with direct access is really slow, and must be threaded wisely. If we have a lot of records
transmitting between the remote function calls. There might be a situation where data for the Info provider
need not be stored physically. One such model is an Virtual Info provider. This acts very similar to an Info
cube, but is not physical data storage, with dimensions, characteristics and key figures like normal Info
cubes. But the actual generation of data for this cube, depends on one's making.

We can choose to create a virtual provider with a 'Direct access' to R/3. This means that upon viewing the
data in this virtual provider, a remote function call is called direct to R/3 to get the values on the fly.
Creating a Virtual Info cube

In SAP BI 7.0, just right click on any info area, and choose create 'virtual provider'. For direct access, you
choose Virtual Provider with 'direct access'. There is one more method by using the old R/3 info source.

Direct Access:
Direct Access is suitable only for data sources with especially small data volume and for a small number of
accesses. Direct Access is relevant for both transactional data and for master data, and is mapped by Virtual
Info Providers, that are defined like regular Cubes & regular IOs. But exist only in the meta data of the BI
system.

3 types of Virtual Providers:

 VPs with Staging Connect (Simple DTP)
 VPs using BAPI (for transactional data only)
 VPs using Function Module

Virtual Providers with Staging Connect
VPs with Staging Connect offer an option to access the data of a source system through Data Sources of the
Source system & use transformation procedure for the supply.
VPs for transactional data are modeled as Info Cubes, but we must choose the type which only selects Meta
data. Virtual Providers for transactional data access the data source in the source system for characteristics
& key figure. However, it always reads master data of characteristics from the existing master data tables in
BI system.

Note: Attributes like IOs can be defined only as display & not as navigational data.

Each Virtual Provider can access a random number of Data Sources. The precondition is the ability of
respective data source to provide data to BI system via direct access. The connection between data sources
& a virtual provider is defined with regular staging by a transformation & DTP.

How many Data sources supply data to a virtual provider depends on the defined transformations & DTP.
With definition of DTP, we must select the option 'Do not extract from PSA but Access Data Source' and the
adapter for synchronous extraction. The data sources which are actually to be read with direct access need
to be redefined explicitly. This is done in the context menu of the respective target structure (master data
attributes or texts or cube) and is activated via 'Activate Direct Access'

Virtual Providers with BAPI:
There are also other ways, like using BAPI. In case of VPs based on BAPIs, the transaction data is read froma different source which is called BAPI (Business Application Program Interface) and not specifically from an SAP source.

Using VPs with BAPI, the systems from the third party suppliers can be used to retrieve data from these
systems. The principle is similar to the virtual provider with staging connect, but the obtained data is not even
processed in a transformation.

Data requirement is not directed to the data sources of the source system, but requires a specifically
prepared 3rd party source system that provides a corresponding BAPI to exchange data.
It needs to be already supplied in the form required for analysis.

The creation of a VP with BAPI is similar to creation of VP with staging connect, where the type based on a
BAPI is selected and the RFC destination to respective 3rd party source system is indicated.
Virtual providers with BAPI are used in special cases if data is to be obtained from a market data supplier.
Up to release of 3.X of BW, BAPI was referred as general Remote Cube.

Virtual Providers using Function Module:
In comparison to other Virtual Providers, this one is more generic. It offers more flexibility, but also requires a
higher implementation effort. The data can be local or remote. We can also use your own logic to change
data before it is passed to OLAP processor.

We use this incase data needs to be loaded from non-BI Data Sources in BI without having to copy the
dataset into the BI structures.

Step-by-Step Guide

What is Star Schema & Extended Star Schema in BI 7.0 ?

2011-08-04T17:18:00.001+05:30

SAP BW Star Schema

SAP BW Star schema is based on the extended of the classic star schema (aka “snowflake” schema). The enhancement comes from the fact that the dimension table does not contain master data information. This master data information is stored in separate tables, called master data tables. In SAP BW Star Schema, the distinction is made between two self-contained areas: infocube and surrogate ID (SID) tables

Infocube

Infocubes are the central objects on which reports and analysis are based in SAP BW. It describes a self-contained data set within a business area, for which we can define queries.

Infocube consist of a central fact table and several surrounding dimension tables. In SAP BW star schema, the facts in a fact table refers to key figure and the dimension attributes refer to characteristics.

In contrast to classic star schema, characteristics are not component the dimension tables since the characteristic values are not stored in the dimension tables. They are stored in master data tables. There are foreign keys that replace the characteristics as the component of dimension table, i.e.: SID stand for Surrogate ID. In picture above, these keys are given the prefix SID_.

Each Dimension table has a generated primary key, called the dimension key. (In Picture above, the keys are given the prefix DIM_ID_..). As the classic star schema, the primary key of the fact table is made up of dimension keys.

Master data Table or Surrogate ID (SID) Table

In SAP BW, additional information about characteristic is referred to as master data.Master data information is stored in separate tables called master data tables. There are 3 types of master data, i.e.: Attributes, Text and Hierarchies.

Here, SID tables play an important role in linking the data warehouse information structured to the subject-oriented infocubes. The master data tables, text tables, and hierarchy tables are not directly linked to the associated dimension tables. These tables are infocube independent and joined with the dimension tables using SID table. The SID therefore provides the link to the dimension tables.

The connection between Infocube and Master Data Tables

Picture above illustrates the connection between master data table and infocube. Master data tables are connected to an infocube by way of the SID tables. The picture above also explains that in SAP BW star schema, the master data is independent infocube and can be used by several infocubes at the same time.

Extended Star Schema:

Many of the problems associated with the basic star schema are resolved with the BW extended star schema. With the extended star schema, attributes are removed from the dimensions and placed outside the InfoCube in master data tables.

The BW extended star schema differs from the basic star schema. It is divided by a solution dependent part (InfoCube) and a solution independent part (attribute, text and hierarchy tables) which is shared among other InfoCubes.In BW, attributes located in the dimensions are called characteristics. In BW, attributes located in a master data table of a characteristic are called attributes of the characteristic.

When designing a solution, it is a great challenge to decide whether an attribute should reside in a dimension table and thus in the InfoCube or in a master table or even both. Data is loaded separately into the master data (attributes), text and hierarchy tables. The SID table provides the link between the master data and the dimension tables.

The fact table and the relevant dimension tables of an InfoCube are connected with one another relationally using the dimension keys. The dimension key is provided by the system per characteristic combination in a dimension table.

With the execution of a query the OLAP processor checks the dimension tables of the InfoCube to be evaluated for the characteristic combinations required in the selection.

The dimension keys determined in this way point the way to the information in the fact table. Dimension tables consist of a maximum of 248 characteristics. The Time dimension holds the time characteristics needed for analysis.

The Unit dimension contains the unit of measure and currency characteristics needed to describe the key figures properly. The Data Packet dimension is used to identify discrete packets of information loaded into the InfoCube. In this way, packets can be deleted, reloaded or maintained individually.

Multidimensional Modeling in SAP BW/BI

2011-08-04T17:17:00.000+05:30

Please Download the Document for the Multidimensional Modeling in SAP BW/BI from the following link:

Difference Between BW 3.5 to BI 7.0

2011-08-04T17:16:00.000+05:30

1. In Infosets now you can include Infocubes as well.

2. The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only for info cube.

3. The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 - 100. This BI accl is a separate box and would cost more. Vendors for these would be HP or IBM.

4. The monitoring has been imprvoed with a new portal based cockpit. Which means you would need to have an EP guy in ur project for implementing the portal ! :)

5. Search functionality hass improved!! You can search any object. Not like 3.5

6. Transformations are in and routines are passe! Yess, you can always revert to the old transactions too.

7. The Data Warehousing Workbench replaces the Administrator Workbench.

8. Functional enhancements have been made for the DataStore object:
New type of DataStore object
Enhanced settings for performance optimization of DataStore objects.

9. The transformation replaces the transfer and update rules.

10. New authorization objects have been added

11. Remodeling of InfoProviders supports you in Information
Lifecycle Management.

12. The Data Source:
There is a new object concept for the Data Source.
Options for direct access to data have been enhanced.
From BI, remote activation of Data Sources is possible in SAP source systems.

13.There are functional changes to the Persistent Staging Area (PSA).

14.BI supports real-time data acquisition.

15. SAP BW is now known formally as BI (part of NetWeaver 2004s). It implements the Enterprise Data Warehousing (EDW).

The new features/ Major differences include:

a) Renamed ODS as DataStore.
b) Inclusion of Write-optmized DataStore which does not have any change log and the requests do need any activation
c) Unification of Transfer and Update rules
d) Introduction of "end routine" and "Expert Routine"
e) Push of XML data into BI system (into PSA) without Service API or Delta Queue
f) Intoduction of BI accelerator that significantly improves the performance.
g) Load through PSA has become a must. I am not too sure about this. It looks like we would not have the option to bypass the PSA Yes,

16. Load through PSA has become a mandatory. You can't skip this, and also there is no IDoc transfer method in BI 7.0. DTP (Data Transfer Process) replaced the Transfer and Update rules. Also in the Transformation now we can do "Start Routine, Expert Routine and End Routine". during data load.

New features in BI 7 compared to earlier versions:

i. New data flow capabilities such as Data Transfer Process (DTP), Real time data Acquisition (RDA).

ii. Enhanced and Graphical transformation capabilities such as Drag and Relate options.

iii. One level of Transformation. This replaces the Transfer Rules and Update Rules

iv. Performance optimization includes new BI Accelerator feature.

v. User management (includes new concept for analysis authorizations) for more flexible BI end user authorizations.

Please click on the following link for the presentation:

Open Hub Destination in BI 7.0

2011-08-04T17:15:00.000+05:30

Definition

The open hub destination is the object that allows you to distribute data from a BI system to non-SAP data marts, analytical applications, and other applications. It ensures controlled distribution across multiple systems.

The open hub destination defines the target to which the data is transferred.

In earlier releases, the open hub destination was part of the InfoSpoke. It is now an independent object that provides more options as a result of its integration into the data flow.

The open hub service previously provided with the InfoSpoke can still be used. We recommend, however, that you use the new technology to define new objects.

The following figure outlines how the open hub destination is integrated into the data flow:

Use

Database tables (in the database for the BI system) and flat files can act as open hub destinations. You can extract the data from a database to non-SAP systems using APIs and a third-party tool.

Structure

The open hub destination contains all the information about a data target: the type of destination, the name of the flat file or database table and its properties, and the field list and its properties.

BI objects such as InfoCubes, DataStore objects, InfoObjects (attributes or texts), and InfoSets can function as open hub data sources. Note that DataSources may not be used as the source.

Integration

You can use the data transfer process to update data to the open hub destination. This involves transforming the data. Not all rule types are available in the transformation for an open hub destination: Reading master data, time conversion, currency translation, and unit conversion are not available.

Please download the PDF for the complete scenario from the following link:

Routines in SAP BI 7.0

2011-08-04T17:13:00.000+05:30

Introduction:
Routines are used to define complex transformation rules. In most of the cases data won’t be coming directly
in desired form before sending to the target. In some cases output needs to be derived on some incoming
data. In such cases we need to go for writing of routines at the transformation level.

There are four types of Routines available

• Characteristic or Field Routine
• Start Routine
• End Routine
• Expert Routine

The routine which we need to go for depends on when it needs to be executed. Suppose if some logic needs
to be implemented before transformation then the start routine needs to be implemented.

Please download the document for the detail about each of the above Routine from the following link:

Performance Tuning in SAP BI 7.0

2011-08-04T17:12:00.001+05:30

Performance Tuning in BI 7.0:

Scenario for the Performance Tuning in SAP BI 7.0

30 Tips for the SAP BI Performance:

Watch the Following Videos for the More Information on Performance Tuning in BI 7.0

SAP BW Query Performance Tuning with Aggregates
SAP BW Data Load Performance Analysis and Tuning

What is Analysis Process Designer ?- Step by Step Process to Extract Data to a File and Rearranging the Columns Using Transformations

2011-08-04T17:11:00.000+05:30

Introduction:

The Analysis Process Designer (APD) is a workbench with an intuitive graphical user interface for creating,executing, and monitoring analysis processes. The analysis process is primarily based on data that wasconsolidated in the Data Warehouse and that exists in InfoProviders.

Analysis processes (APD) can be created on a graphical user interface using drag and drop. Data fromdifferent data sources in the BI system can be combined, transformed, and prepared for analysis in several individual steps. This allows it to be resaved in data targets in the BI system (DataStore objects for directupdate or InfoObjects with attributes) or in CRM system

Step by Step Process to Extract Data to a File and Rearranging the Columns Using Transformations

Scenario 1: Analysis Process Designer

Scenario 1I: Analysis Process Designer

SAP BW Process Chains - automation and job scheduling

2011-08-04T17:10:00.001+05:30

Would you like to automate repetitive BW tasks like loading transaction data? Create Process Chains!

Let's begin with basic definitions:

Process chain (PC) is a sequence of processes linked together.
Each Process have a type (BW activity, e.g., activate ODS) and a variant (contains parameters).
Start process describes when the process will start (immediately, scheduled job, metaprocess, API).
Connector is linking processes; you can choose 1 of 3 options of starting next process: when previous finishes with success (green arrow), failure (red) or always start the next process (black).
Variant is a set of parameters passed to the process, such as the name of the InfoPackage to use for loading, the name of the InfoObject to perform a change run for.

Selected icon bar buttons:

Planning view enables to create and modify processes.
Checking view checks consistency of a process chain selected in plan view.
Log view shows log of the execution of a process chain selected in plan view.

Selected left panel buttons:

Process Chains displays process chains.
Process Types displays process types, enable to drag and drop process into main panel.

The picture below shows simple PC (loading transaction data into ODS and than into InfoCube).

Loading Hierarchy using Process Chain

Now, we will describe how to load a hierarchy into an InfoObject. The process will start every day at 1PM. The process chain will have the following processes:

Start > Load Hierarchy > Save Hierarchy > Attr. Change Run

1. Start transaction RSPC and choose Process Chain > Create. Enter a name of the chain and description. You will be asked to insert a name of start process - choose New, enter a variant name and description.

2. Select Direct Scheduling option and click Change Selection. Click Date/Time, enter schedule start date and hour (current date, 01:00:00). Click Period values > Daily > Save > Save > Save> Back.

3. Click Process Types button on the left panel. Expand Load process and click twice Execute InfoPackage. Choose the InfoPackage for the Hierarchy you would like to load and confirm the choice. To connect the Start process with the load process: right click on the Start, chooseprocess > Connect with > Load Data > created process.

4. Add processes to save hierarchy and attributes change run (commits changes in the InfoObject).

5. Save the process. Click Checking View button. If the chain is OK, activate and schedule the chain by clicking Activate and then Schedule buttons.

Additional information

To work with PC, you need authorization for authorization object S_RS_PC.
To monitor selected processes create a list of PCs using TCode RSPCM. This tool will enable you to see statuses of selected PCs and provide a link to process chains' log.
To have a PC that can be scheduled and maintained only in specified client - pressProcess Chain > Attributes > Editing Client, and enter the name of the selected client.
To transport client dependant PC with complete starting options, enter required background user data in the target system using TCode RSTPRFC.
If you transport PC with scheduling option: immediately the PC will start immediatelyafter the transport.
To "stop" scheduled PC click Execution > Remove from Schedule.
To see overall PCs status - start BWCCMS tool.
PC can send e-mail message when process failed. To create e-mail alert right click on the process and choose Maintain Message option.
To see technical names and additional information about processes: click View > Detail View.

Examples of BW PCExample of processes sequence when deleting overlapping requests form a InfoCube:
Start > Del. indexes > Load InfoCube > Delete Overlapping request > Gen. Indexes
Loading hierarchy, attributes and texts into InfoObjects:
Start > Load Attr. > Load Hierarchy > Save Hierarchy > Attr. Change Run > Load Texts

Process Chain Creation in SAP BI 7.0

2011-08-04T17:10:00.000+05:30

I want to continue my series for beginners new to SAP BI. In this blog I write down the necessary steps how to create a process chain loading data with an infopackage and with a DTP, activation and scheduling of this chain.

1.) Call transaction RSPC

RSPC is the central transaction for all your process chain maintenance. Here you find on the left existing process chains sorted by “application components”. The default mode is planning view. There are two other views available: Check view and protocol view.

2.) Create a new process chain

To create a new process chain, press “Create” icon in planning view.

In the following pop-Up window you have to enter a technical name and a description of your new process chain.

The technical name can be as long as up to 20 characters. Usually it starts with a Z or Y. See your project internal naming conventions for it.

3.) Define a start process

After entering a process chain name and description, a new window pop-ups. You are asked to define a start variant.

That’s the first step in your process chain! Every process chain does have one and only one starting step. A new step of type “Start process” will be added. To be able to define unique start processes for your chain you have to create a start variant. These steps you have to do for any other of the subsequent steps. First drag a process type on the design window. Then define a variant for this type and you have to create a process step. The formula is:

Process Type + Process Variant = Process Step!

If you save your chain, process chain name will be saved into table RSPCCHAIN. The process chain definition with its steps is stored into table RSPCPROCESSCHAIN as a modified version.So press on the “create” button, a new pop-up appears:

Here you define a technical name for the start variant and a description. In the n ext step you define when the process chain will start. You can choose from direct scheduling or start using meta chain or API. With direct scheduling you can define either to start immediately upon activating and scheduling or to a defined point in time like you know it from the job scheduling in any SAP system. With “start using meta chain or API” you are able to start this chain as a subchain or from an external application via a function module “RSPC_API_CHAIN_START”. Press enter and choose an existing transport request or create a new one and you have successfully created the first step of your chain.

4.) Add a loading step

If you have defined the starting point for your chain you can add now a loading step for loading master data or transaction data. For all of this data choose “Execute infopackage” from all available process types. See picture below:

You can easily move this step with drag & drop from the left on the right side into your design window.A new pop-up window appears. Here you can choose which infopackage you want to use. You can’t create a new one here. Press F4 help and a new window will pop-up with all available infoapckages sorted by use. At the top are infopackages used in this process chain, followed by all other available infopackages not used in the process chain. Choose one and confirm. This step will now be added to your process chain. Your chain should look now like this:

How do you connect these both steps? One way is with right mouse click on the first step and choose Connect with -> Load Data and then the infopackage you want to be the successor.

Another possibility is to select the starting point and keep left mouse button pressed. Then move mouse down to your target step. An arrow should follow your movement. Stop pressing the mouse button and a new connection is created. From the Start process to every second step it’s a black line.

5.) Add a DTP process

In BI 7.0 systems you can also add a DTP to your chain. From the process type window ( see above.) you can choose “Data Transfer Process”. Drag & Drop it on the design window. You will be asked for a variant for this step. Again as in infopackages press F4 help and choose from the list of available DTPs the one you want to execute. Confirm your choice and a new step for the DTP is added to your chain. Now you have to connect this step again with one of its possible predecessors. As described above choose context menu and connect with -> Data transfer process. But now a new pop-up window appears.

Here you can choose if this successor step shall be executed only if the predecessor was successful, ended with errors or anyhow if successful or not always execute. With this connection type you can control the behaviour of your chain in case of errors. If a step ends successful or with errors is defined in the process step itself. To see the settings for each step you can go to Settings -> Maintain Process Types in the menu. In this window you see all defined (standard and custom ) process types. Choose Data transfer process and display details in the menu. In the new window you can see:

DTP can have the possible event “Process ends “successful” or “incorrect”, has ID @VK@, which actually means the icon and appears under category 10, which is “Load process and post-processing”. Your process chain can now look like this:

You can now add all other steps necessary. By default the process chain itself suggests successors and predecessors for each step. For loading transaction data with an infopackage it usually adds steps for deleting and creating indexes on a cube. You can switch off this behaviour in the menu under “Settings -> Default Chains". In the pop-up choose “Do not suggest Process” and confirm.

Then you have to add all necessary steps yourself.

6.) Check chain

Now you can check your chain with menu “Goto -> Checking View” or press the button “Check”. Your chain will now be checked if all steps are connected, have at least one predecessor. Logical errors are not detected. That’s your responsibility. If the chain checking returns with warnings or is ok you can activate it. If check carries out errors you have to remove the errors first.

7.) Activate chain

After successful checking you can activate your process chain. In this step the entries in table RSPCPROCCESSCHAIN will be converted into an active version. You can activate your chain with menu “Process chain -> Activate” or press on the activation button in the symbol bar. You will find your new chain under application component "Not assigned". To assign it to another application component you have to change it. Choose "application component" button in change mode of the chain, save and reactivate it. Then refresh the application component hierarchy. Your process chain will now appear under new application component.

8.) Schedule chain

After successful activation you can now schedule your chain. Press button “Schedule” or menu “Execution -> schedule”. The chain will be scheduled as background job. You can see it in SM37. You will find a job named “BI_PROCESS_TRIGGER”. Unfortunately every process chain is scheduled with a job with this name. In the job variant you will find which process chain will be executed. During execution the steps defined in RSPCPROCESSCHAIN will be executed one after each other. The execution of the next event is triggered by events defined in the table. You can watch SM37 for new executed jobs starting with “BI_” or look at the protocol view of the chain.

9.) Check protocol for errors

You can check chain execution for errors in the protocol or process chain log. Choose in the menu “Go to -> Log View”. You will be asked for the time interval for which you want to check chain execution. Possible options are today, yesterday and today, one week ago, this month and last month or free date. For us option “today” is sufficient.

Here is an example of another chain that ended incorrect:

On the left side you see when the chain was executed and how it ended. On the right side you see for every step if it ended successfully or not. As you can see the two first steps were successfull and step “Load Data” of an infopackage failed. You can now check the reason with context menu “display messages” or “Process monitor”. “Display messages” displays the job log of the background job and messages created by the request monitor. With “Process monitor” you get to the request monitor and see detailed information why the loading failed. THe logs are stored in tables RSPCLOGCHAIN and RSPCPROCESSLOG. Examining request monitor will be a topic of one of my next upcoming blogs.

Please download Step by Step guides for the Process from the following links:

What is Authorizations in SAP BI

2011-08-04T17:09:00.000+05:30

To ensure that your data warehousing solution represents the structure of your company and fulfills the requirements of your company, you have to define who has access to which data.

An authorization allows a user to perform a certain activity on a certain object in the BI system. There are two different concepts for this depending on the role and tasks of the user: standard authorizations and analysis authorizations.

An authorization concept must always have been taken into account in the modeling phase. Otherwise there could be functional or security restrictions.

Standard Authorizations:

These authorizations are required by all users who are working in the Data Warehousing Workbench to model or load data, and also by users who work in the planning workbench or the Analysis Process Designer, and those that work with the Reporting Agent or the BEx Broadcaster or define queries.

Each authorization refers to an authorization object and defines one or more values for each field that is contained in the authorization object. Individual authorizations are grouped into roles by system administration. You can copy the roles delivered by SAP and adjust them as needed. These authorizations are then entered into individual users’ master records in the form of profiles.

More information: Standard Authorizations

These authorizations are based on SAP's standard authorization concept.

More detailed documentation on SAP's standard authorization concept: SAP Authorization Concept

The following figure illustrates the structure of the authorizations:

Analysis Authorizations:

All users who want to display transaction data from authorization-relevant characteristics in a query require analysis authorizations for these characteristics.

This type of authorization is not based on SAP's standard authorization concept. Instead, the authorizations use their own concept that takes the features of reporting and analysis in BI into consideration. As a result of the distribution of queries using the BEx Broadcaster and the publication of queries to the portal, more and more users can access query data. Using the special authorization concept of BI for the display of query data, you can protect especially critical data in a much better way.

More information: Analysis Authorizations

Before SAP NetWeaver 7.0, the SAP standard authorization concept was also used for analysis authorizations, which were then still called reporting authorizations. If you have upgraded to SAP NetWeaver 7.0, you can decide whether you want to use the new, more user-friendly concept or switch back to the previous reporting authorization concept. If you decide to use the new concept, the old reporting authorization objects are no longer taken into account (access is denied). However, SAP recommends using the new concept because it is better suited to the requirements of BI and because the previous concept will no longer be supported.

More information about the previous concept for reporting authorizations: Previous Concept for Reporting Authorizations

Functions of Authorizations:

Authorization checks can be used to protect any functions, objects, or values in the system. During an authorization check, when you perform a certain action the system compares the values for the individual fields of an authorization object or an authorization that are assigned to the user with the values that are predefined for the execution of an action in the program. A user is only authorized to perform an action if the authorization check is successful for every field in an authorization object or authorization. Complex checks of the user authorization can be carried out in this way.

Integration

The system checks the special authorization objects that SEM-BPS defines and, if necessary, also those authorization objects that are defined for reporting in the SAP Business Information Warehouse environment. In this case, the SEM-BPS users must have both the SEM-BPS application-specific authorizations and the general SAP BW reporting authorizations.

You manage the SEM-BPS authorizations using the system administration tools (see Users and Roles) and the BW reporting authorizations using the relevant functions under Business Explorer ® Authorizations ® Reporting - Authorization Objects.

To assign authorizations for changing and displaying plan data separately, you must include the ACTVT (activity) field in the reporting authorization object. In this field the value 02 represents the authorization to change and 03 the authorization to display plan data. If you do not include the field, then this corresponds to an authorization to change plan data.

In addition to that, because of internal dependencies, you need authorization for the following authorization objects for data entry using planning layouts:

· S_BDS_DS: This authorization object controls access to documents, which belong to a document set of the Business Document Service (BDS).

· S_TRANSLAT: This authorization object controls access to the translation functions of the SAP System.

Features

The following authorization objects exist for the SEM Business Planning and Simulation component:

· R_AREA: You use this authorization object to control access to planning areas and all subordinate objects. You must set up read access to planning areas for people who will work with the SEM-BPS component. Otherwise, they will not be able to access any of the subordinate planning elements.

· R_PLEVEL: You use this authorization object to control access to planning levels and all subordinate objects. This authorization object is also relevant to access documents of the SEM-BIC component.

· R_PACKAGE: You use this authorization object to control access to planning packages (including ad hoc packages).

· R_METHOD: You use this authorization object to control access to planning functions and the appropriate parameter groups.

· R_PARAM: You use this authorization group to control access to individual parameter groups of a certain planning function.

· R_BUNDLE: You use this authorization object to control access to global planning sequences (you control authorizations for planning sequences, which you create for a planning level, with the authorization objects R_METHOD, R_PLEVEL, or R_AREA).

No separate authorization for execution is defined for this authorization object. Whether a global planning sequence can be executed or not, depends on the authorization objects for the planning functions contained in it.

· R_PROFILE: You use this authorization object to control access to planning profiles. A planning profile restricts the objects that can be viewed. If you wish to view the planning objects, you must have at least display authorization for the appropriate planning profile.

· R_PM_NAME: You use this authorization object to control access to planning folders. In order to be able to work with planning folders, you also require the necessary authorizations for the planning objects combined in the folder.

· R_WEBITF: You use this authorization object to control access to Web interfaces that you create and edit with the Web Interface Builder, and from which you can generate Web-enabled BSP applications.

· R_STS_PT: You use this authorization object to control access to the Status and Tracking System. The object enables a check to be carried out whether a user is allowed access to a certain subplan or a version of it with the Status and Tracking System.

· R_STS_CUST: You use this authorization object to control access to Customizing for the Status and Tracking System. The object enables or forbids a user to execute Customizing.

· R_STS_SUP: This authorization object provides the assigned users with the status of a superuser in relation to the Status and Tracking System. The object enables changing access to all plan data, independent of whether and where a user of the cost center hierarchy it is based on is assigned. The authorization object is intended for members of a staff controller group, who are not part of the line organization of the company, but who nevertheless must be able to intervene in the planning process.

In accordance with the hierarchical relationships that exist between the various types of planning objects, authorizations that are assigned to an object on a higher level are passed on to its subordinate objects. An authorization that has been passed on can be enhanced but not restricted on a lower level. The following table presents the combination possibilities using the example of a change authorization for planning area and level:

Change Planning Area	Change Planning Level	Authorization Available for Level
yes	no	yes
yes	yes	yes
no	no	no
no	yes	yes

In practice this behavior means that you can proceed according to two different strategies when setting up authorizations:

· Minimization of Customizing Effort: You assign authorizations for planning objects on as high a level as possible, and thereby enable access to the planning objects without further authorization assignment on lower levels.

· Optimization of Delimitation of Access Rights: You assign authorizations for planning objects on as low a level as possible, and therefore make sure that access to a planning object is only possible for the person responsible for this.

Activities

Create the user profiles you require and then assign authorization objects to these profiles. Then assign the newly created user profiles to possible users.

You can find further information on the activities associated with the different authorization objects in the online documentation on the authorization objects themselves. You can call this up in the maintenance transaction "Role maintenance" (PFCG).

SAP BI 7.0 Authorization - Part 1: InfoObjects level authorization

2011-08-04T17:08:00.000+05:30

New SAP BI 7.0 Authorization concept (analysis authorization) change a lot in accessing, analyzing and displaying BI information. The approach allow to restrict data access on Key figure, Characteristic, Characteristic value, Hierarchy node, and InfoCube levels. It enables more flexible data access management.

Analysis authorization is active by default in SAP BI 7.0 systems and I think it is worth to spend some time to look closer at the new concepts and the features. In part one of this two-article series, I will show you how you can restrict access to SAP BW reports onInfoObjects level.

Initial settings

At the beginning activate business content objects (TCode RSORBCT) related to authorizations:

InfoObjects 0TCA*
InfoCubes 0TCA*

and set the following InfoObjects as Authorization-Relevant:

0TCAACTVT (activity such as Display)
0TCAIPROV (InfoProvider authorization)
0TCAVALID (validity period of authorization)
0TCAKYFNM (if you want to restrict access to key figure)

Characteristics authorization

Use TCode RSA1, go to Modelling -> InfoObjects. Display properties of the characteristic to which you want to restrict access and set it as Authorization-Relevant.

Characteristics values authorization

To authorize characteristics values you need to create new authorization object through TCode RSECADMIN. The following pictures show how allow users to access to specific sale organization (e.g., New York, San Francisco, Dallas).
1. Create new authorization object (e.g., Z_SORG_B).

2. Choose characteristic and press Details button.

3. Select sales organization (e.g., 1612 - New York, 1614 - San Francisco, 1615 - Dallas). Available operators: EQ - single value, BT - range of values, CP - pattern ending with (*) (e.g., abc*). You have also option to Include (I) or Exclude (E) values.

Attributes authorization

To authorize navigational attributes, set them as Authorization-Relevant.

Hierarchies authorization

To grant authorization on hierarchy level edit or create authorization object (e.g., Z_SORG_B), add hierarchy and nodes, and choose type of authorization.

Key figure authorization

To grant authorization to particular key figure, add special object 0TCAKYFNM to authorization object (e.g., Z_SORG_B), and choose the key figure to be authorized.

Summary

InfoObject level authorization gives you a great flexibility, but keep in mind system limitations. Avoid setting too many characteristics as authorization relevant (more than 10 in a query). All marked characteristics are checked for existing authorization if they are in a query or in an InfoProvider that is being used. Too much authorization objects may slow query execution. Exception are characteristics with all (*) authorization. If you want to check which InfoObjects are authorization relevant in your BI system, use TCode RSECADMIN -> Authorization Maintenance and display 0BI_ALL authorization. More about 0BI_ALL you will find in the article on creating and assigning authorization.

Remember that authorization do not work as a filters do. It means that the user who is executing the query, where characteristics are authorization relevant, must have sufficient authorization to the characteristics ("all-or-nothing" rule). Exceptions are hierarchies in the drill down and variables which are dependent on authorization.

SAP BI 7.0 Authorization - Part 2: Creating and assigning authorization

2011-08-04T17:07:00.000+05:30

Creating authorization:

To create analysis authorization perform the following steps:
1. Use TCode RSECADMIN, go to the Authorizations tab.
2. Press Maint. button and enter a name (e.g., Z_USR_A1) and press Create.
3. Fill required Short Text field.
4. Insert special characteristics: 0TCAACTVT, 0TCAIPROV, and 0TCAVALID by pressing Insert Special Characteristics button.

5. Insert authorization-relevant characteristics and navigational attributes (Insert Row -> press F4 -> choose item). I described how to set InfoObjects as authorization-relevant in previous articles.
6. Press Details button to restrict values and hierarchy authorization of inserted items.
7. Save the authorization.

You must include special characteristics: 0TCAACTVT (activity), 0TCAIPROV (InfoProvider), and 0TCAVALID (validity) in at least one authorization for a user. They are used for:

0TCAACTVT - to restrict the authorization to activities, default value: Display;
0TCAIPROV - to restrict the authorization to InfoProviders, default value: all (*);
0TCAVALID - to restrict the validity of the authorization, default value: always valid (*).

If you want to authorize access to key figures, add 0TCAKYFNM characteristic to the authorization. It is important to know that if this characteristic is authorization-relevant, it will be always checked during query execution.

0BI_ALL authorization

The 0BI_ALL authorization includes all authorization-relevant characteristics. It is automatically updated when you restrict a BI InfoObject. Use this authorization if you have users that are allowed to execute all queries.

Assigning authorization to a user

You may assign authorization directly to a user or to a role. To assign authorization directly use TCode RSECADMIN, go to the User tab and press Assign. Now enter the user name, press Change and select the authorization. To assign authorization to the role use TCode PFCG, enter the role name and press Change. Using Authorization tab change authorization data by adding S_RS_AUTH entry. The entry includes analysis authorization in roles. Enter here authorization that you previously created.

Summary

I encourage you to collect all requirements related to BI security, structure of the organization and authorization needs before starting authorization preparation. I have learned that it can save a lot of time. Organization's hierarchy can facilitate your work by providing structures and levels of authorization. Indirect authorization assignment can also save your time because it is more flexible and easier to maintain.

Transporting SAP BI 7.0 Objects

2011-08-04T17:06:00.000+05:30

Use

Development projects for Business Intelligence (BI) are generally not performed in a productive system. They are normally carried out in one or more development systems depending on their scope.

If you carry out your development projects in a development system, you have to transport the development to a target system (a test or productive system).

To do this, the standard transport system has been enhanced in BI to provide the BI transport connection. Using the transport connection in your BI development system, you can collect a consistent amount of new or changed BI objects and then transport them using the Change and Transport Organizer (CTO).

Procedure

...

1. In the Data Warehousing Workbench, choose the Transport Connection functional area (transaction RSOR) by choosing the pushbutton in the left navigation window or by choosing the menu option Goto ® Transport Connection.

You can display or hide the left navigation window in the Data Warehousing Workbench by choosing Navigation Window On/Off.

2. Collect objects that you want to transport and check the settings.

More information: Collecting Objects

Objects Being Transported for the First Time (Package $TMP)

3. To transport the selected objects, choose Transport Objects. The Change Object Directory Entry dialog box appears.

4. Under Attributes, in the Package field, enter a transportable customer package (beginning with Y or Z).

This prompt only appears once for all collected objects. If you want to transport objects in different packages, you must collect the objects more than once.

You can change the package assignment subsequently.

More information: Changing Package Assignments

5. Save your entries. A dialog box appears where you are prompted for a transport request.

6. In the Request field, enter a transportable request or create a new request first.

7. Choose Continue.

8. Choose CTO Transport Organizer: Overview. The Workbench Organizer:Requests screen appears.

9. Release the individual tasks first and then the complete request.

Ensure that you release any requests with locked objects beforehand.

In the Collected Objects screen area, the system displays the corresponding information for individual objects in the following columns:

● Last Changed by

● Last changed by

● Transport Request

● Transport Request Holder

● Package

10. In the log display in the lower screen area of Collected Objects, check the status of the transport.

Objects That Have Already Been Transported

From this point on, BI objects are subject to automatic change recording since they were assigned to a transportable package when transported for the first time. This means that all changed objects are written automatically to a request, and can be transported.

Note the following for automatic change recording: If you create new InfoObjects for an InfoCube that is subject to automatic change recording, these are not automatically written to the InfoCube request. Instead, they are assigned the $TMP package. You must use the BI transport connection to collect and transport these objects or the InfoCube.

Only refrain from collecting objects using the BI transport connection if the changes do not produce any new objects.

If you really want to list newly created objects in the standard transport system that belong to objects that have already been transported make sure that the objects are listed in the correct transport request. In the object maintenance screen, you can use the menu functions for the object catalog entry or Transport Organizer (if available) to assign the relevant package to the object and to write the object to the correct transport request.

More Information

Technology of the SAP Change and Transport System (CTS):

● Transport Organizerlink_0002_0003_0010

● Transport Strategy in the CTSnk_0002_0004_0010

Transport Landscape in BI

Recording Time for Transports

Defining Object Changeability

Changing Package Assignments

Special Features of Individual Object Types

Troubleshooting (Transport)

Transport Sequence in SAP BW

2011-08-04T17:05:00.000+05:30

Transporting objects in SAP BW is not same like in other SAP or non-SAP systems, handling transportation in SAP BW is some what different. Here below listed all the BW objects in sequence to follow while transporting with in the landscape.

1. R/3 - R/3 objects must be transported first before BW transports cab begin

2. Development Class - for backend objects

3. Developer Security Roles - End user roles for projects can be transported later

4. Application Component - including InfoAreas

5. Custom Tablespace / Custom Data Class - DBA creates custom tablespaces and Basis data class entries must be transported

6. InfoObject & InfoObject Catalogs - only object definition, no InfoSource or Rules

7. DataSources - replicate DataSources prior to importing objects listed below

8. InfoSources - master data and text

9. Data Targets for Transactional data - InfoCubes and ODSs (this can be grouped with the two following items

10. InfoSource - Transaction Data ODS - includes Update Rules, Communication Structure, Transfer Rules, Transfer Structures, InfoPackages

11. InfoSource - Transaction Data InfoCubes - includes Update Rules, Communication Structure, Transfer Rules, Transfer Structures, InfoPackages

12. MultiCubes

13. Development Class - for frontend objects

14. InfoSet Queries

15. End user security roles

16. Variables Customer Exit code

17. Workbooks / Queries/ Structures / Calculated Key Figure / Restricted Key Figure

18. Workbook Folders - needs to be transported whenever new workbooks are created

19. Jump Targets

20. Process Chains

Lo Extraction in BI 7.0

2011-08-04T17:03:00.000+05:30

Please download the LO Extraction documents from the following links:

Extraction Part -1

Extraction Part -II

Extraction Part - III

Extraction Part - IV

Extraction Part - V

Extraction Part - VI

Extraction Part - VII

Extraction Part - VIII

Enhancing LO Data Sources in BI 7.0 - Step by Step Guide

2011-08-04T17:02:00.001+05:30

Download the step by step guide for the Enhancing LO Data Sources in BI 7.0 from the following link:

Generic Extraction In BI 7.0

2011-08-04T17:02:00.000+05:30

Please Download the File for the Generic Extraction from the following link:

CO-PA Extraction in BI 7.0

2011-08-04T17:01:00.000+05:30

Please download the CO PA Extraction document from the following link:

Delta Mechanism in SAP BI 7.0

2011-08-04T16:59:00.000+05:30

For extracting logistic transactional data from R/3, a new generation of datasources and extractors, no longer based on LIS (Logistic Information System) information structures, was developed starting from BW Release 2.0B and PI 2000.1 or PI-A 2000.1 (valid from R/3-Release 4.0B ).

The tools for the logistics extract structures can be found in the IMG for BW (transaction SBIW): access into your OLTP system, choose Customer-Defined DataSources -> Logistics -> Managing Extract Structures.

The Logistics Extract Structures Customizing Cockpit (you can directly see it by transaction LBWE) represents the central tool for the administration of extract structures.

Ok...but, in other words, what is this the Logistic Cockpit (LC)?
We can say that it’s a new technique to extract logistics information and consists of a series of a standard extract structures (that is, from a more BW perspective, standard datasources), delivered in the business content thanks to a given plug-in.

But, what is the logic behind these datasources that allows to manage the logistic flows towards BW in delta mode after an initial load of the historical data (done with update mode ‘Delta Initialization’, by retrieving data from the setup tables, which are assigned to each extract structure, and are filled using special setup transactions in OLTP) ?

Following from many questions posted until now in SDN BW Forums, in this weblog we will focus only on the delta mechanism of the LC and not on the other tasks we can manage inside it, like the necessary steps for activating and carrying out successful data extraction or the maintenance of extract structures and datasources (but, don’t worry, it will arrive also a summary weblog dedicated to these important procedures in the next days !).

The V3 Update

Unlike the LIS update (well, I know that you are asking ‘but how does this old LIS update work ???’...my dear, another weblog will arrive very soon also for this topic...sorry for the waiting, but I have a lot of things to do !), data is transferred from the LIS communication structure, using extract structures (e.g. MC02M_0HDR for the header purchase documents), into a central delta management area.

This transfer takes place thanks to the V3 update with a specific (scheduled) job and is therefore temporally detached from the daily application operations; the main consideration is that the delta management acts as a buffer (not depending from the application business) containing data that can be requested from BW via infopackage with update mode ‘delta’.

The following picture shows (with an high-level view) the interaction between the LIS communication structure and the V3 extraction technology.

We said that for updating the extraction of transactional data from the different logistics applications (MM, PP, SD and so on), the technology for collective updates (‘V3 updates’) is used (until PI 2003.1).

This means that the data is collected in the R/3 update tables before the transfer to the interface: the data is retrieved there by means of a periodic update process that needs to be started in order to transfer delta records to the the BW system delta queue.

During this V3 collective run (that you can start and schedule from LBWE for each application component), the data is transferred to the BW delta queue (that you can see from RSA7 (see the picture below) or LBWQ transactions), from which they are retrieved by means of (delta) requests from the BW system.

V1, V2, V3...
When scheduling what

Normally in R/3 there are three types of update available:

Synchronous update (V1 update)

Statistics update is carried out at the same time (synchronous) as the document update (in the application tables).

Asynchronous update (V2 update)

Document update and the statistics update take place in different tasks.

So, V1 and V2 updates don’t require any scheduling activity.

Collective update (V3 update)

As for the previous point (V2), document update is managed in a separate moment from the statistics update one, but, unlike the V2 update, the V3 collective update must be scheduled as a job (via LBWE).

Remember that the V3 update only processes the update data that is successfully processed with the V2 update.

This is a key task in order to properly manage the right working of the BW logistic flows.
In fact, scheduling timing process is very important and it should be based on the basis of
1) the amount of activities on a particular OLTP system and on

2) the particular requirements related to the updating needs of data displayed in BW reports.

For example (relating to the first point), a development system with a relatively low/medium of new/modified/deleted documents may only need to run the V3 update on a weekly/daily basis.

Instead, a full production environment, with really many thousands of transactions everyday, may have to be updated hourly, otherwise postings will queue and can affect performance heavily.

About the second point: if, for example, the reporting timing refers to a monthly periodic view, successfully monthly scheduling the V3 update will ensure that all the necessary information structures are properly updated when new or existing documents are processed in the meanwhile.

Finally, the right choice will be the result of all these considerations; by doing so, the information structures in BW will be current and overall performance will be improved.
It’s possible to verify that all V3 updates are successfully completed via transaction SM13.

SM13 transaction will take you to the Update Records: Main Menu screen:

On this screen, enter asterisk as your user (for all users), flag the radio button ‘V2 executed’, select a range date and hit enter.
Any outstanding V3 updates will be listed.

At this point, it’s clear that, considering the V3 update mechanism, the main requirement is that the delta info have to be transferred in the same sequence to the BW system as it occurred in the OLTP system.
Just a consideration...if we had to load our delta records only in a cube, there would be no problem: everything goes in append and, in the end, we’ll find the final situation right displayed thanks to the OLAP processor!

But since updating in ODS objects is permitted in the logistics extraction for almost all DataSources, we have to consider any effects that can derive from the ‘overwrite’ update mode (specific of the ODS object).

For example, the consistent storage of a status field (e.g. delivery status) in ODS objects can only be ensured only with a right (serialized) delta sequence: if the record with ‘open delivery’ status (created as first record in R/3) arrives later than the record with ‘closed delivery’ one (created as second one in R/3), we would have a false representation of the reality.

Considering that, the sequence of the existing data records is recognized by and taken into account when reading and processing the update data (step A of the picture), as well as when transferring data to the BW system (step B).

Since the normal existing update methods actually does not recognize the serialized processing of update data, the Serialized V3 Update function was created (also thanks to subsequent several corrections in SAP Basis) in order to be able to serialize step A.

Different Types of Delta Updates

2011-08-04T16:58:00.000+05:30

What is the different delta updates and when to use which updates?

Delta loads will bring any new or changed records after the last upload. This method is used for better loading in less time. Most of the std SAP datasources come as delta enabled, but some are not. In this case you can do a full load to the ODS and then do a delta from the ODS to the cube. If you create generic datasources, then you have the option of creating a delta on Calday, timestamp or numeric pointer fields (this can be doc number, etc).

You'll be able to see the delta changes coming in the delta queue through RSA7 on the R3 side.

To do a delta, you first have to initialize the delta on the BW side and then set up the delta. The delta mechanism is the same for both Master data and Transaction data loads.

There are three deltas:

Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.

Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.

Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.

Enterprise Reporting, Query and Analysis

2011-08-04T16:50:00.000+05:30

Please download the following books for the Entire Reporting Concepts :

How to Create High Impact BW Reports ?

2011-08-03T13:15:00.001+05:30

Checklist: Creating high impact BW workbooks:

So you've purchased and installed SAP BW at your company and you've created some basic reports. You're happy that you've been able to retrieve data into the BW BEx Analyzer, but you're not sure how to increase the usability for your users. Should you learn how to change the look and feel of the reports? Should you eliminate some functionality to 'protect your users from the system'? Should you find a way of putting all your reports into one printable package?

This checklist provides you with proven project strategies that quite simply increase the use of your BW reporting. The following scenarios will illustrate ways you can achieve a successful implementation of BW by increasing the number of users and the frequency that these users access data.

CREATING HIGH IMPACT BW WORKBOOKS

Home: Introduction
Scenario 1: I need to create a customized template with my company's logo
Scenario 2: I need to create a template without gridlines
Scenario 3: I need my users to have the latest data available
Scenario 4: I need to publish reports where users can't modify the layout of the report
Scenario 5: I have a requirement to put all my reports into a single package
Scenario 6: I want to lock the data values found in my BW reports
Review: Conclusion and more resources

Scenario 1: I need to create a customized template with my company's logo

Solution:

1. Launch the BEx Analyzer.
2. Open a NEW workbook using the Excel toolbar.
3. Follow the Excel menu path and choose Insert > Picture > Clip Art...
4. Navigate to your corporate logo and double-click to choose it.
5. Use the handles to resize the picture so that it sits in the upper left corner.
6. Using the BW BEx toolbar, select the Save icon > Save as new workbook.
7. Using the BW BEx toolbar, select the Settings icon > Permanent workbook template.
8. A pop-up window will allow you to choose your workbook template. Navigate to the one you saved earlier and select it. Click Ok.
9. Next go back to the BW BEx toolbar and select the Settings icon > New workbook on embed > is based on permanent template.
10. Open a BW Query into the BEx Analyzer and your corporate logo will appear.

Scenario 2: I need to create a template without gridlines

Solution:

1. Launch the BEx Analyzer.
2. Using the Excel toolbar, open your previously saved template.
3. Follow the Excel menu path and choose Tools > Options > View. Remove the checkbox for Gridlines.
4. Using the BW BEx toolbar, select the Save icon > Save Existing workbook.
5. Open a BW Query into the BEx Analyzer and your template will appear without gridlines.

Scenario 3: I need my users to have the latest data available

In this scenario, it is critical for your business that only one - the latest - version of a report gets circulated.

Solution:
1. Launch the BEx Analyzer.
2. Using the Excel toolbar, open a previously saved workbook.
3. In order to have the most relevant data appear you want to make your workbook "auto-refresh".
4. In the results section of your report, right-click on any field and choose Properties.
5. Navigate to the Interaction tab.
6. Check 'Refresh query when opening workbook'. Click ok.
7. Using the BW BEx toolbar, select the Save icon > Save Existing workbook.
8. The next user to open this report will automatically receive the latest data from the BW database.

Scenario 4: I need to publish reports where users can't modify the layout of the report

Solution:

Publishing reports that have no BW functionality and no update capabilities allow you to distribute data across your company without changes to the numbers or content. This also allows you to distribute reports to non-BW users.
1. Launch the BEx Analyzer.
2. Using the Excel toolbar, open a previously saved workbook.
3. Execute the report by clicking the Refresh icon if it does not automatically get refreshed.
4. Using the BW BEx toolbar, select the Tools icon > All queries in workbook > Detach.
5. A warning message will prompt you to accept the detachment.
6. The workbook is now severed from the BW system and OLAP functions are no longer applicable.
7. Using the Excel menu path, choose File > Save As...
8. Save the Excel Workbook to a local drive.
9. The report can now be distributed as an Excel attachment with no requirement for BW access.

Scenario 5: I have a requirement to put all my reports into a single package

Solution:

The ability to create and share a reporting package allows simpler distribution and access to data.
1. Launch the BEx Analyzer.
2. Using the Excel toolbar, open a previously saved workbook.
3. Execute the report by clicking the Refresh icon if it does not automatically get refreshed.
4. Using the Excel menu path, choose Insert > Worksheet .
5. Click on the new worksheet to make it active.
6. Using the BW BEx toolbar, select the Tools icon > Insert query.
7. From the pop-up window, select a second query to embed into the new worksheet.
8. This second report will now be displayed on its own worksheet.
9. Repeat steps 4 through 8 to add additional queries to your workbook.
10. When finished, follow the steps outlined in Scenario 3 to ensure consistency.

Scenario 6: I want to lock the data values found in my BW reports

Solution:

1. Launch the BEx Analyzer.
2. Using the Excel toolbar, open a previously saved workbook.
3. Execute the report by clicking the Refresh icon if it does not automatically get refreshed.
4. Using the BW BEx toolbar, select the Tools icon > SAP Protection.
5. From the pop-up window, input a password into both boxes.
6. Using the BW BEx toolbar, select the Save icon > Save Existing workbook.
7. Open the Workbook again and try to adjust individual cell values. Not possible!

Conclusion and more resources

Conclusion:
Extending the BW functionality inherent within the BEx Analyzer allows you to accommodate many traditional reporting requirements, while maximizing distribution and usability of the reports. Removing the tie-in to OLAP functionality opens up your ability to disseminate data to non-BW users in a familiar Excel format. The real balance is finding a way to keep financial data integrity without limiting the scope of who is able to access the data.

What is SAP Business Objects ?

2011-08-02T17:43:00.000+05:30

SAP BI and SAP BO

2011-08-02T17:21:00.000+05:30

SAP Business Intelligence and SAP Business Objects

What is Business Intelligence (BI)? In a word, Business Intelligence is compounded of all the IT solutions responsible for extracting, transforming, and loading data, as well as different types of information operating, reporting and analysis. Along that, Business Objects (BO) is one of the market leaders in Business Intelligence area.

Business Objects company was settled in 1990, in Paris. Even the very first years of its activity were full of successes and quite profitable, what resulted in company's debut in NASDAQ market. Along market existence, came the cooperation with the largest and the most meaningful enterprises from all over the World.

WHAT BUSINESS OBJECTS HAS TO OFFER TO ITS CUSTOMERS?

Mainly, Business Objects is a company concentrated about vending databases and applications supporting data management. Furthermore, BO offerings include solutions for enterprise performance management, as well as diverse Business Intelligence solutions designed especially for tiny and medium-size companies.

Flagship products of Business Objects have been included in the scheme below:

Business Objects XI Enterprise

Among a few main products, one might be described as a factor determining Business Objects market success. Business Objects XI Enterprise is a rightful, independent BI platform ideal for usage in the largest enterprises. The widest-known and - simultaneously - the most successful product in Business Objects' portfolio was designed for supporting data quality management, data integration, ad-hoc information analysis, reporting (including print-oriented formatting), and data visualization cockpits for managers. Finally, facilitated data sharing and compatibility with Microsoft Office suite, coupled with multiple functionality and high performance, make Business Objects XI Enterprise a really efficient solution.

BO Enterprise Performance Management

Second large, meaningful product of Business Objects is BO Enterprise Performance Management - the wide range of applications and solutions designed especially for the largest companies. The aim of the whole tools packet is supporting all the processes necessary for Performance Management (Enterprise Performance Management - EPM). What features are provided by Business Objects Enterprise Performance Management?
Diverse types of results cards, manager cockpits, systems supporting planning, budgeting and prognosis. Furthermore, Business Objects EPM suite guarantees innovative solutions for consolidating an enterprise and financial evaluating demanded periods for active-based costing (ABC). The same as financial and risk analysis, predicting profitability and financial modeling. Finally, all the tools offer indispensable security, supporting Financial Governance.

Both solutions presented above refer to the largest enterprises. That doesn't mean Business Objects creates solutions only for customers from that segment. There are also a lot of offerings for large- and medium-sized companies and the two most-known of them - Business Objects Edge and Crystal products family.

Business Objects Edge includes Business Intelligence solutions for customers from medium- and tiny-sized companies segment. Basing on proven standards - Crystal Enterprise and Crystal Xcelsius, they efficiently support managing.

Crystal Reports

Finally, the last two products of Business Objects are a bit different. They're usually being described together, as they're almost similar. The main difference between them applies to their destination - Crystal Reports Server are designed to function as a standalone reporting server, while Crystal Reports demands integrating into .Net application. All in all, both solutions are dedicated for usage in small- and medium-sized companies. According to applications' specific, both solutions are wanted by companies keen only on reporting aspect. From the whole range of Business Intelligence applications, Crystal Server and Crystal Reports refer exclusively to reporting, offering its multidimensional functionality. While both solutions' specific doesn't allow self-dependent functioning, they're usually - as a proven environment for reporting and analysis - developed with other vendors' offerings.

ACQUISITION OF BO BY SAP AG AND ITS CONSEQUENCES

Twenty years of BO's market presence cannot be boiled down to a matter of case. Successive technological advance, growing data dependence, and information importance were the favorable factors that led BO to a due place in "great four of business intelligence vendors". Even though BO as an independent company lived its bests, year 2008 brought a completion of its acquisition by SAP AG.

Finally, the whole acquisition process engendered significant revolution in Business Intelligence market, as it has to lead to the full integration of SAP and BO BI offerings, and both sides' partnerships joint.

Despite the fact of company acquisition and increasing compatibility of solutions, both vendors' offerings remain separate. Thereupon, comes the questions about Business Objects BI and SAP Business Intelligence. Which one is better? Which one to choose? The answer isn't obvious and depends on a customer.

SAP BI AND BUSINESS OBJECTS FEATURES COMPARISON

While comparing two similar solutions, it's important to call attention to three aspects: solutions' architecture, data access, and profits.

As long as extracting, transforming, and loading data (ETL) make up the essence of business intelligence, grows the importance of data management system. In this case, both solutions - Business Objects BI and SAP Business Intelligence - are extremely different. SAP BI is a singular data warehouse, itself supporting all the ETL processes, as well as data management, and providing reporting tools. The architectural model assimilated by Business Objects BI is slightly different, as it provides the broad range of tools separate for every process. Even though there are a lot of diverse tools, all of them cooperate well thank to open standards (CORBA, Web services, etc.). Both models are different, but it cannot be undoubtedly stated which one is better.

Second aspect, data access method, also differs. With SAP Business Intelligence, data from diverse sources is being extracted, loaded into a data warehouse. Next, data stored in OLAP cubes is being reported. This model of data accessing is commonly described as "business interface", enabling all types of the access without involving into a complex physical data structure. Once again, the solution used by Business Objects BI is slightly diverse. With BO, data isn't stored regardless to reports in OLAP cubes. Instead of this, high efficiency is being reached through concrete reports. Even though both models are different, each of them might be replaced by the other one. To reach that, using remote cubes becomes a necessity (SAP Business Warehouse) or using the data integrator (Business Objects BI).

Thirdly, features. Both solutions have their strengths, among which a few deserve pointing out.
Business Objects Business Intelligence:
- wins with more intuitive reporting (creating and sharing) interface,
- couples its main goal with wide range of tools extending its functionality.

SAP Business Intelligence:
- praises for its more advanced data store module,
- enables significantly faster access to data.

These features listed above are only chosen from much longer list, commonly similar for both solutions. All in all, the most meaningful features of both vendors' solutions supply themselves mutually, what was an additional factor favoring the acquisition.

BUSINESS OBJECTS BI OR SAP BUSINESS INTELLIGENCE - MAKING THE RIGHT CHOICE

Choice between Business Objects BI and SAP Business Intelligence had always been difficult, but has become even worse since the acquisition. However, earlier and recently, it depends on the customer, especially the size of an enterprise, which is of the most meaningful factors. The second factor that should be considered, are all the former implementations of any SAP solutions. Along that, enterprises might be divided into five specific groups, being simultaneously a base for future solution choice.

Large enterprises with no earlier implementations of SAP solutions - This is a kind of customers, which generally Business Objects XI is suggested for. The factor determining this choice is multitude and diversification of systems already reporting with direct access to databases. Why BO? Mainly because of its simplicity of cooperation with multiple databases and data sources. Also user-friendly interface and no necessity of moving already existing data to the new data warehouses argue for using Business Objects XI. Eventually, additional functionalities of BO XI might also be useful. On the other hand, large enterprises might prefer SAP Business Intelligence. Especially while attention is attached to reporting of large data volumes and data access efficiency. SAP BI guarantees the highest performance with possibilities of data extracting to off-line data warehouses and reporting with OLAP data structures.

Large enterprises, which earlier implemented SAP solutions are important element of BI system in - Already existing systems (especially with SAP ERP) heterogeneity, might be a factor arguing for implementing typically hybrid solution. Already mentioned SAP ERP contains data that might be easily reported with SAP Business Intelligence, while any other data sources and more advanced BI appliances might demand Business Objects XI.

Large and medium-sized enterprises, which earlier implemented SAP solutions play dominant role. Generally, regardless to a company's size, main role of SAP ERP determines future SAP Business Intelligence usage. Logically, the best integration might be reached when using tools from the same vendor's portfolio. Along that, ETL tools provided with SAP BI might work with currently stored data in the most efficient way. However, more advanced Business Intelligence appliances might demand implementing Business Objects BI.

Medium-sized companies with no or only marginal earlier implemented SAP solutions - While considering this type customers, the choice depends on real company's needs. Generally, for most of their uses, Business Objects Edge is ordered, due to its simplicity (in oppose to Business Objects XI and SAP BI), but - simultaneously - even more functional.

Medium-sized and tiny companies with no or only marginal earlier implemented SAP solutions - Finally, the tiniest and medium-sized companies as well should accurately consider their real needs. If they're keen exclusively on reporting, then Business Objects Crystal Reports would suit them best. It's a solution designed strictly for reporting (excluding most of other Business Intelligence appliances) and its main strength is price. Crystal Reports is relationally the cheapest solution, designed especially for customers who don't want to pay for functionalities they're never going to use.

Even though SAP AG do its best to calm down former BO customers, the most meaningful acquisition of recent years became a fact, and - as a consequence - a lot of changes are unstoppable.

What does it mean especially for Business Objects customers?
While the acquisition's results are more and more visible, SAP states to keep each BO BI and SAP BI separate. Despite all the promises, some specific relation among both solutions must have evolved. Along that, the basic, fundamental BI role has been confided to SAP Business Intelligence. According to proven SAP Business Warehouse, SAP BI might function as a base for diverse solutions. On the other hand, Business Objects BI saved its independence and - as well - might function completely alone, but also using SAP BW's foundation. The benefits of such cooperation may be meaningful - multiplied functionality, improved Enterprise Performance Management, etc.

FUTURE OF SAP BUSINESS INTELLIGENCE SOFTWARE

Even though the acquisition process has been announced to be completed, integration has to last much longer. First forecasts state the two-year period for integration, but no one can be sure of its success - there's still so much to be done that even two years might eventually turn out insufficient. What exactly changes are being prepared?

To begin with data extracting, both solutions Business Objects Quality Management and SAP Master Data Management are going to become fully integrated. Data management is announced to stay unmodified and still provide two separate, differentiated models of access. Reporting solutions are going to be intercepted from Business Objects.

The point is to rely formatted reporting on Crystal Reports (to be significantly extended), and make Pionieer (the effect of current Voyager BO and SAP BEx Analyzer consolidation) solution responsible for ad hoc reporting. Furthermore, former Xcelsius and Web Application Designer solutions are going to be integrated in one, called Xcelsius+, responsible for cockpit creating and managing. In the matter of reports availability, portals of SAP and Business Objects are said to become integrated.

Was the acquisition a profitable move? For SAP AG - certainly. And for the market? There are two sides to every story. At once, the integration made SAP's offering much more attractive for customers, making it one of the best - if not the very best - solutions ever. On the other hand, the acquisition was a move against competition and its long-term results are difficult to be predicted.

SAP ABAP Certification Book Download

2011-08-01T13:30:00.000+05:30

SAP ABAP Certification Book Download

Data Declaration in SAP ABAP Programming

2011-08-01T00:30:00.000+05:30

Declare single value variable:Variable can be declared by two ways, first by declaring based on data type, second by declared it refer to table field.

Data d_data1 TYPE type. " berdasarkan type data
Data d_data2 LIKE customer-customerno. " refer ke field tertentu

Data types:
C (character)
N (numeric)
D (date)
T (Time)
X (byte / hexadecimal)
I (integer)
P (packed number)
F (floating point number)

Internal TableInternal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays.

DATA: BEGIN OF t_report OCCURS 10,
field1 LIKE customer-customerno,
field2 TYPE I,
field3(20) TYPE C,
END OF t_report.

In above example, we define internal table contatin 3 fields, field-1 refer to field customer-customerno, field-2 type Integer, field-3 type character with field length 10 character. OCCURS 10 means that it reserve 10 line of memory at initialization, in run time memory will expand automatically when data exceed the limit.

My First SAP ABAP Programme

2011-08-01T00:26:00.000+05:30

my first ABAP program

No, it's not a "hello world" program ;p

One of main job of an ABAPer is create ABAP report.
Report content 4 basic component.
1. Data declaration.
2. Selection screen.
3. Select Data.
4. Write Report.

I assume you already familiar with data dictionary. For an example, we have a table "SFLIGHT", with following fields:
1. CARRID (Airline carrier ID)
2. CONNID (Flight connection Id)
3. FLDATE (Flight date).
4.SEATSMAX (Maximum capacity).
We wan to create a report that can be filtered based on Airline carrier ID and Flight connection Id.
Go to transaction code SE38 (SAP Menu->Tools>ABAP Workbench->Development->ABAP Editor), enter program name with prefix Z, for example ZTEST0001, then choose "Create" button.

Then, enter title for program, and choose 1 "Executable Program" for program type. If screen input for development class appear, click "Local Object".
Then, go to following steps.

1. Data declaration

TABLES: sflight.

DATA: BEGIN OF t_report OCCURS 3,
carrid LIKE sflight-carrid,
connid LIKE sflight-connid,
fldate LIKE sflight-fldate,
seatsmax LIKE sflight-seatsmax,
END OF t_report.

2. Selection screen

SELECT-OPTIONS s_carrid FOR sflight-carrid.
SELECT-OPTIONS s_connid FOR sflight-connid.

It will generate selection screen like picture below.

3. Select data

SELECT * FROM sflight
WHERE carrid IN s_carrid AND
connid IN s_connid.
t_report-carrid = sflight-carrid.
t_report-connid = sflight-connid.
t_report-fldate = sflight-fldate.
t_report-seatsmax = sflight-seatsmax.
APPEND t_report.
ENDSELECT.
IF sy-subrc NE 0. "sy-subrc = return code
WRITE 'Data not found'.
ENDIF.

4. Write data

LOOP AT t_report.
skip. "comment:Go to next line
WRITE t_report-carrid.
WRITE t_report-connid.
WRITE t_report-fldate.
WRITE t_report-seatsmax.
ENDLOOP.

The result :

Here is the complete program:

REPORT ZTEST0001 .
*Data Declaration
tables: sflight.

DATA: BEGIN OF t_report OCCURS 3,
carrid LIKE sflight-carrid,
connid LIKE sflight-connid,
fldate LIKE sflight-fldate,
seatsmax LIKE sflight-seatsmax,
END OF t_report.

*Selection Screen
SELECT-OPTIONS s_carrid FOR sflight-carrid.
SELECT-OPTIONS s_connid FOR sflight-connid.

*Get Data
SELECT * FROM sflight
WHERE carrid IN s_carrid AND
connid IN s_connid.
t_report-carrid = sflight-carrid.
t_report-connid = sflight-connid.
t_report-fldate = sflight-fldate.
t_report-seatsmax = sflight-seatsmax.
APPEND t_report.
ENDSELECT.
IF sy-subrc NE 0.
WRITE 'Data not found'.
ENDIF.

*Write Data
LOOP AT t_report.
skip. "comment:Go to next line
WRITE t_report-carrid.
WRITE t_report-connid.
WRITE t_report-fldate.
WRITE t_report-seatsmax.
ENDLOOP.

SAP ABAP Data Dictionary Tutorial

2011-08-01T00:15:00.001+05:30

Digg Digg

A data dictionary is a central source of information for the data in a information management system. Its main function is to support the creation and management of data definitions (or “metadata”).

What is Data dictionary used for ?

Management of data definitions
Provision of information for evaluations
Support for software development
Support for documentation
Ensuring that data definitions are flexible and up-to-date

Objects in the ABAP Dictionary resided on three levels that support their re-usability. These levels are:

Tables and structures
Data elements
Domains

Lets look into them in detail -

Domains

Describes the technical characteristics of a table field
Specifies a value range which describes allowed data values for the fields
Fields referring to the same domain (via the data elements assigned to them) are changed when a change is made to the domain
Ensures consistency

Ex. Purchasing document number (EBELN)

Data Elements

Describes the role played by a field in a technical context
Fields of same semantic meaning can refer to the same data element
Contains the field information

Ex. Purchasing document number (EBELN)

Tables

Represent the Database Tables where data actually resides.
Tables can be defined independently of the database in the ABAP Dictionary.
The fields of the table are defined with their (database-independent) SAP ABAP data types and lengths.

Structures

Are record declarations that do NOT correspond to a Database Table.
Just like user-defined data type.
Defined like a table and can then be addressed from ABAP programs.
Structures contain data only during the runtime of a program.

Aggregated Objects of ABAP Dictionary

Aggregated means consisting of several components. In the ABAP Dictionary, aggregated objects are objects which come from several different transparent tables.

Views
Search Help
Lock Objects

Lets look into them in detail

Views

Views in SAP _ ABAP are used to summarize data which is distributed among several tables
The data of a view is not actually physically stored. The data of a view is instead derived from one or more other tables
It is tailored to the needs of a specific application

Search Help

A Search help is a tool to help you search for data records in the system
An efficient and user-friendly search assists users where the key of a record is unknown

Lock Objects

Simultaneous accessing of the same data record by two users in the SAP system is synchronized by a lock mechanism.
Locks are set and released by calling certain function modules. These function modules are generated automatically from the definition of so-called lock objects in the ABAP/4 Dictionary

Function modules :

Enqueue_<obj name> – to lock the table

dequeue_<obj name> – to release the lock

Important Transactions
SE11 : Data Dictionary Initial Screen (SE12 Display only)
SE13 : ABAP Dictionary : Technical Settings
SE14 : Database Utility
SE15 : Repository Information System
SE16 : Data Browser
SE17 : General table Display
SE55 : Table View Maintenance
SM30 : Table Maintenance