Guide to SAP Beginners

Navigating in SAP

Toolbar

Screen Icons

SAP Log on

BI - Business Intelligence (Reporting and Analysis)

OLAP: Online Analytical Process (SAP BI) OLTP: Online Transaction Process (SAP SD, MM, FICO, ABAP, HR) Basics: BI is a data warehousing tool ETL: Extraction > Transformation > Loading BI is used by middle level and high level management

PSA (Persistent Storage Area): Used to correct errors.Chapter 2: Info Objects (SDN)

Info objects are the fields in BI system. These are divided into two types:1. Characteristics: Used to refer key figureEx: Material, Customer

The characteristics are divided into three types. They are:a. Time Characteristicsb. Unit Characteristicsc. Technical Characteristics

a. Time Characteristics include day, month, year, and half-yearly, quarterly. They are generated by the system.Note: Info objects are of two types,i. System generated (0)ii. Customer generated (Z)

b. Unit Characteristics include currency, unit. (0Currency, 0Unit)MaterialAmount0CurrencyQuantity0Unit

E620400Rs10

E621500$12

They are always assigned to key figures type amount and quantity (as shown in the above example). c. Technical Characteristics include 0requestID, 0changeID, 0recordID.

2. Key Figures: Used for calculation purposeEx: Amount, Quantity

The key figures are divided into two types. They are:a. Cumulative key figuresb. Non-cumulative key figures

a. Cumulative key figures are used when the data in the key figure field need to be added.MaterialAmount

E621100

E622200

E623300

Total: 600

b. Non-cumulative key figures are used in MM and HR related reportsPlantMaterialStock ValueDate

4002Pencil50028/04/2012

4002Pencil60029/04/2012

Records in the 'Stock Value' field are not added.

Steps to create info objects of type characteristics and key figures: Part 1:1. Go to RSA12. Go to 'Info Object' selection3. Right click on the context menu > Select 'Create Info Area'4. Give the technical name (Always unique)5. Give description6. Click on Continue

Part 2:1. Right click on Info Area > Select create 'Info Object Catalog'2. Give technical name3. Give description4. Select Info object type 'Character'5. Click on Activate button

Part 3:1. Right click on Info area > Select create 'Info Object Catalog'2. Give technical name and description3. Select info object type 'Key Figure'4. Click on Activate button

Part 4:1. Right click on Info Object Catalog for characteristics2. Select create Info Object3. Give technical name (length between 3 to 8)4. Give description5. Click on Continue6. Give mandatory options in the 'General' tab page (like Data type, length .. )7. Click on Activate button

Part 5:1. Right click on the Info Object Catalog for key figures2. Select create Info Object3. Give technical name (length between 3 to 8)4. Give description5. Click on Continue6. For key figure of type 'Amount' and 'Quantity' we have to give 'Unit Characteristic' (0Currency/ 0Unit)7. Click on Activate button)There are two types of data in SAP (ERP). They are:1. Master Data2. Transaction Data

1. Master Data:It is always assigned to characteristic. From SAP BI point of view, master data doesn't change frequently

Note:Master Data is always assigned to a characteristic. A characteristic is called master data characteristic if it has attributes, text and hierarchies.

i. Attributes:These are info objects which explain a characteristic in detail. These are divided into two types: a. Navigational attributes b. Display attributes

Steps to create Attributes (type characteristic): Part 1:1. Go to Info object of type characteristic2. Go to 'Display/Change'3. In the 'Master data text' tab page, check the 'With Master Data' checkbox4. Go to the Attribute tab page5. Give technical name of attribute6. Click Enter7. Give description8. Give data type, length9. Click on continue10. Activate the info object

Part 2:1. If the info object is already in the system, copy the technical name of the info object2. Go to attribute tab page of char3. Paste the technical name of the info object4. Click on Activate button

Note:Key Figure can be an attribute to a characteristic and it can only be a display attribute

Steps to enable Texts:1. Right click on the info object, select change, go to Master Data Text tab page, select the check box Text

Company CodeAmount

India2000

USA2500

Company CodeSales OrgAmount

IndiaHyderabad2000

Bangalore2000

USANew York2500

Washington D.C2500

Company CodeSales OrgDivisionAmount

IndiaHyderabadAmeerpet1000

Begumpet1000

BangaloreElectronic City1000

Silk Board1000

USANew York7thStreet1250

9thlane1250

Washington D.C8thstreet1250

10thstreet1250

Navigational Attribute:We can drill down using navigational attribute. It acts as characteristic in the report. Display Attribute:We cannot drill down using display attribute

Note:1. Attribute Only: If you mark the characteristic as exclusive attribute, it can only be used as display attribute but not as navigational attribute.2. The characteristic cannot be transferred into info cube directly.

Steps to change attributes from navigational to display:

1. Go to 'Attribute' tab page, in column 'Navigation On/Off', select the pencil like structure.2. When changing display to navigation, give a description, click on activate button.

Steps to create attribute (type Key Figure):1. Go to info object, go to 'Attribute' tab page2. Give technical name3. Click on Enter, Select radio button 'Create attribute as key figure'4. Click on Continue5. Give description and data type6. Click on continue7. Click on activate button

Tab Pages of Characteristic:1. General tab page:2. Data Element: Naming convention of data element (technical name of info object). It is like a field on database level3. Data Type: Here we have Char (1-60), string, Numeric (1-60), Date (8), Time (6)4. Lower Case Letters: If the characteristic is having lower case letters, select lower case allowed option5. SID Tables: Surrogate ID or Master Data ID6. Business Explorer: The selections which are in the Business Explorer tab page are by default displayed at report level7. Master Data/Text tab page: Info object has the following tablesP -> Time Independent display attributesQ -> Time dependent display attributesX -> Time Independent navigational attributesY -> Time dependent navigational attributesText: If we select this option, we can have text for the characteristicHierarchy: To enable hierarchies, we have to select the hierarchiesAttribute: In this, we give the attributes for a characteristic ii.Text: The same report can be selected in different language in different country. This is because of the 'Text' functionality iii. Hierarchy

Chapter 3: Extended Star Schema (SCN)

Fact table consists of DIM ID and key figures. Every Info cube has two types of tablesa. Fact tableb. Dimension tables Info cube consists of one fact table (E and F), surrounded by multiple dimension tables. Maximum number of dimension tables in an info cube is 16 and the minimum number is 4. There are 3 system generated tablesa. Data Package dimension table (Technical dimension)b. Time dimensionc. Unit dimension Maximum number of key figures in an info cube are 233 Maximum number of characteristics in an info cube are 248

Advantages of Extended Star Schema: Faster loading of data/ faster access to reports Sharing of master data Easy loading of time dependent objects

Classical Star Schema:

In classical star schema, the characteristic record is directly stored in DIM tables. For every Dimension table, a DIM ID is generated and it is stored in the fact table.

Differences between Classical Star Schema and Extended Star Schema: In Classic star schema, dimension and master data table are same. But in Extend star schema, dimension and master data table are different. (Master data resides outside the Info cube and dimension table, inside Info cube). In Classic star schema we can analyze only 16 angles (perspectives) whereas in extended star schema we can analyze in 16*248 angles. Plus the performance is faster to that extent.

Create an InfoCube

Create an InfoCube

Creating an InfoCube In BW,Customer ID,Material Number, Sales Representative ID,Unit of Measure, and Transaction Date are called characteristics. Customer Name and Customer Address are attributes of Customer ID,although they are characteristics as well. Per Unit Sales Price, Quantity Sold, and Sales Revenue are referred to as key figures. Characteristics and key figures are collectively termed Info Objects.

A key figure can be an attribute of a characteristic. For instance, Per Unit Sales Price can be an attribute of Material Number. In our examples, Per Unit Sales Price is a fact table key figure. In the real world, such decisions are made during the data warehouse design phase. InfoCube Design provides some guidelines for making such decisions.

InfoObjects are analogous to bricks. We use these objects to build InfoCubes. An InfoCube comprises the fact table and its associated dimension tables in a star schema.

In this chapter,we will demonstrate how to create an InfoCube that implements the star schema from figure. We start from creating an InfoArea. An InfoArea is analogous to a construction site,on which we build InfoCubes.

Creating an InfoArea

In BW,InfoAreas are the branches and nodes of a tree structure. InfoCubes are listed under the branches and nodes. The relationship of InfoAreas to InfoCubes in BW resembles the relationship of directories to files in an operating system. Let's create an InfoArea first,before constructing the InfoCube.

Work InstructionsStep 1. After logging on to the BW system,run transaction RSA1,or double-click Administrator Workbench.

Step 2. In the new window,click Data targets under Modelling in the left panel. In the right panel,right-click InfoObjects and select Create InfoArea.

NoteIn BW,InfoCubes and ODS Objects are collectively called data targets.Step 3. Enter a name and a description for the InfoArea,and thenmark to continue.

ResultThe InfoArea has been created.Creating InfoObject CatalogsBefore we can create an InfoCube,we must have InfoObjects. Before we can create InfoObjects,however,we must have InfoObject Catalogs. Because characteristics and key figures are different types of objects,we organize them within their own separate folders,which are called InfoObject Catalogs. Like InfoCubes,InfoObject Catalogs are listed under InfoAreas.

Having created an InfoArea,let's now create InfoObject Catalogs to hold characteristics and key figures.

Work InstructionsStep 1. Click InfoObjects under Modelling in the left panel. In the right panel,right-click InfoAreademo,and select Create InfoObject catalog.Step 2. Enter a name and a description for the InfoObject Catalog,select the option Char.,and then clickto create the InfoObject Catalog.Step 3. In the new window,clickto check the Info Object Catalog. If it is valid,clickto activate the InfoObject Catalog. Once the activation process is finished,the status message InfoObject catalog IOC_DEMO_CH activated appears at the bottom of the screen.

ResultClickto return to the previous screen. The newly created InfoObject Catalog will be displayed,as shown in Screen

Following the same procedure,we create an InfoObject Catalog to hold key figures. This time,make sure that the option Key figure is selected Screen.

Creating InfoObjects-Characteristics

Now we are ready to create characteristics.

Work InstructionsStep 1. Right-click InfoObject Catalogdemo: characteristics,and then select Create InfoObject.Step 2. Enter a name and a description,and then clickto continue.Step 3. Select CHAR as the DataType,enter 15 for the field Length,and then click the tab Attributes.Step 4. Enter an attribute name IO_MATNM,and then clickto create the attribute.

Note: Notice that IO_MATNM is underlined. In BW,the underline works like a hyperlink. After IO_MATNM is created,when you click IO_MATNM,the hyperlink will lead you to IO_MATNM's detail definition window.Step 5. Select the option Create attribute as characteristic,and then clickto continue.

Step 6. Select CHAR as the DataType,and then enter 30 for the field Length. Notice that the option Exclusively attribute is selected by default. Clickto continue.

Note: If Exclusively attribute is selected,the attribute IO_MATNM can be used only as adisplay attribute,not as a navigational attribute. "InfoCube Design Alternative I Time Dependent Navigational Attributes," discusses an example of the navigation attributes.

Selecting Exclusively attribute allows you to select Lowercase letters. If the option Lowercase letters is selected,the attribute can accept lowercase letters in data to be loaded.

If the option Lowercase letters is selected,no master data tables,text tables,or another level of attributes underneath are allowed. "BW Star Schema," describes master data tables and text tables,and explains how they relate to a characteristic.Step 7. Clickto check the characteristic. If it is valid,clickto activate the characteristic.

Step 8. A window is displayed asking whether you want to activate dependent InfoObjects. In our example,the dependent InfoObject is IO_MATNM.

Clickto activate IO_MAT and IO_MATNM.

ResultYou have now created the characteristic IO_MAT and its attribute IO_MATNM.

Note: Saving an InfoObject means saving its properties,or meta-data. You have not yet created its physical database objects,such as tables.

Activating an InfoObject will create the relevant database objects. After activating IO_MAT,the names of the newly created master data table and text table are displayed under the Master data/texts tab. The name of the master data table is /BIC/PIO_MAT,and the name of the text table is /BIC/TIO_MAT.

Notice the prefix /BIC/ in the database object names. BW prefixes /BI0/ to the names of database objects of Business Content objects,and it prefixes /BIC/ to the names of database objects of customer-created BW objects.

Repeat the preceding steps to create the other characteristics listed.CHARACTERISTICS

The column "Assigned to" specifies the characteristic to which an attribute is assigned. For example,IO_MATNM is an attribute of IO_MAT.

The Material Description in Table will be treated as IO_MAT's text,as shown in Table,"Creating InfoPackages to Load Characteristic Data." We do not need to create a characteristic for it.

IO_SREG and IO_SOFF are created as independent characteristics,instead of IO_SREP's attributes. Section 3.6,"Entering the Master Data,Text,and Hierarchy Manually," explains how to link IO_SOFF and IO_SREG to IO_SREP via a sales organization hierarchy. "InfoCube Design Alternative ITime-Dependent Navigational Attributes," discusses a new InfoCube design in which IO_SOFF and IO_SREG are IO_SREP's attributes.

BW provides characteristics for units of measure and time. We do not need to create them.From Administrator Workbench,we can verify that the characteristics in Table have been created by clicking InfoAreademo,and then clicking InfoObject Catalogdemo: characteristics.

Creating Info Objects-Key Figures

Next,we start to create the keys.

Work InstructionsStep 1. Right-click InfoObject Catalogdemo: key figures,and then select Create InfoObject.Step 2. Enter a name and a description,and then clickto continue.Step 3. Select Amount in the block Type/data type,select USD as the Fixed currency in the block Currency/unit of measure,and then clickto check the key figure. If it is valid,clickto activate the key figure.

ResultYou have created the key figure IO_PRC. A status message All InfoObject(s) activated will appear at the bottom of Screen.

Repeat the preceding steps to create other key figures listed.KEY FIGURES

From Administrator Workbench,we can verify that the key figures in Table have been created (Screen) by clicking InfoAreademo,and then clicking InfoObject Catalogdemo: key figures.

Having created the necessary InfoObjects,we now continue to create the InfoCube.

Creating an InfoCube

The following steps demonstrate how to create an InfoCube,the fact table and associated dimension tables,for the sales data shown in Table

Work InstructionsStep 1. Select Data targets under Modelling in the left panel. In the right panel,right-click InfoAreademo and then select Create InfoCube.

Step 2. Enter a name and a description,select the option Basic Cube in block InfoCube type,and then clickto create the InfoCube.

Note: An InfoCube can be a basic cube,a multi-cube,an SAP remote cube,or a general remote cube.A basic cube has a fact table and associated dimension tables,and it contains data. We are building a basic cube.

A multi-cube is a union of multiple basic cubes and/or remote cubes to allow cross-subject analysis. It does not contain data. See,Aggregates and Multi-Cubes,for an example.

A remote cube does not contain data;instead,the data reside in the source system. A remote cube is analogous to a channel,allowing users to access the data using BEx. As a consequence,querying the data leads to poor performance.

If the source system is an SAP system,we need to select the option SAP RemoteCube. Otherwise,we need to select the option Gen. Remote Cube. This book will not discuss remote cubes.

Step 3. Select IO_CUST,IO_MAT,and IO_SREP from the Template table,and move them to the Structure table by clicking

Next,click the Dimensions button to create dimensions and assign these characteristics to the dimensions.

Step 4. Click,and then enter a description for the dimension.

Note: BW automatically assigns technical names to each dimension with the format .

Fixed dimension is reserved for Data Packet,Time,and Unit. Section,"Data Load Requests," discusses the Data Packet dimension.

A dimension uses a key column in the fact table. In most databases,a table can have a maximum of 16 key columns. Therefore,BW mandates that an InfoCube can have a maximum of 16 dimensions: three are reserved for Data Packet,Time,and Unit; the remaining 13 are left for us to use.

Repeat the same procedure to create two other dimensions. Next,click the Assign tab to assign the characteristics to the dimensions.

Step 5. Select a characteristic in the Characteristics and assigned dimension block,select a dimension to which the characteristic will be assigned in the Dimensions block,and then clickto assign the characteristic to the dimension.Step 6. After assigning all three characteristics to their dimensions,clickto continue.Step 7. Select the Time characteristics tab,select 0CALDAY from the Template table,and move it to the Structure table by clickingStep 8. Select the Key figures tab,select IO_PRC,IO_QUAN,and IO_REV from the Template table and move them to the Structure table by clicking.Next,clickto check the InfoCube. If it is valid,clickto activate the InfoCube.

Result:You have created the InfoCube IC_DEMOBC. A status message InfoCube IC_DEMOBC activated will appear at the bottom of Screen.

Summary

In this chapter,we created an InfoCube. To display its data model,you can right-click InfoCubedemo: Basic Cube,then select Display data model.

The data model appears in the right panel of Screen .

Note:IO_SREG and IO_SOFF are not listed under IO_SREP as attributes; rather,they have been created as independent characteristics. "Entering the Master Data,Text,and Hierarchy Manually," describes how to link IO_SOFF and IO_SREG to IO_SREP via a sales organization hierarchy. "InfoCube Design Alternative I Time-Dependent Navigational Attributes,"discusses a new InfoCube design in which IO_SOFF and IO_SREG are IO_SREP's attributes.

InfoCube

Info Cubeis structured as Star Schema(extended) where a fact table is surrounded by different dim table that are linked with DIM'ids. And the data wise, you will have aggregated data in the cubes.Infocube contains maximum 16(3 are sap defines and 13 are customer defined) dimensions and minimum 4(3 Sap defined and 1 customer defined) dimensions with maximum 233 key figures and 248 characteristic.The following InfoCube types exist in BI:. InfoCubes. VirtualProvidersThere are two subtypes of InfoCubes: Standard, and Real-Time. Although bothhave an extended star schema design, Real-Time InfoCubes (previously calledTransactional InfoCubes) are optimized for direct update, and do not need to use the ETL process. Real-Time InfoCubes are almost exclusively used in the BI Integrated Planning tool set. All BI InfoCubes consists of a quantity of relational tables arranged together in a star schema.

Star SchemaIn Star Schema model, Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains millions to billions of records. On the other hand dimensional tables are very small. Hence they contain a few thousands to few million records. In practice, Fact table holds transactional data and dimensional table holds master data.The dimensional tables are specific to a fact table. This means that dimensional tables are not shared to across other fact tables. When other fact table such as a product needs the same product dimension data another dimension table that is specific to a new fact table is needed.This situation creates data management problems such as master data redundancy because the very same product is duplicated in several dimensional tables instead of sharing from one single master data table. This problem can be solved in extended star schema.

Extended star schemaIn Extended Star Schema, under the BW star schema model, the dimension table does not contain master data. But it is stored externally in the master data tables (texts, attributes, hierarchies).The characteristic in the dimensional table points to the relevant master data by the use of SID table. The SID table points to characteristics attribute texts and hierarchies.This multistep navigational task adds extra overhead when executing a query. However the benefit of this model is that all fact tables (info cubes) share common master data tables between several info cubes.Moreover the SID table concept allows users to implement multi languages and multi hierarchy OLAP environments. And also it supports slowly changing dimension.

Info Area

InfoAreaIn BW, InfoArea are the branches and nodes of a tree structure. InfoProviders are listed under the branches and nodes. The relationship of InfoArea to InfoProviders in BW is similar to the relationship of directories to files in an operation system.

Steps to create an InfoArea:Step 1:After logging in to BW system, run transaction RSA1.Step 2:In the new window, click InfoProvider tab under Modeling in the left panel. In the right panel, right click on InfoProvider and selectCreate InfoArea.

Step 3:Enter a name and a description for the InfoArea, and then click to continue.

nfoObjects

InfoObjects are the smallest pieces in SAP BW puzzle. They are used to describe business information and processes. Typical examples of InfoObjects are: Customer Name, Region, Currency, Revenue, Fiscal year.

There are five types of SAP BW InfoObjects: Key figures, Characteristics, Unit characteristics, Time characteristics, and Technical characteristics.The following picture illustrates the different InfoObject types and their examples.

Key figuresKey figures describe numeric information that are reported on in a query. The most popular types of key figures are: Quantity - numeric values with associated unit of measure; Amount - numeric values with associated currency; Date - enable date computation; Time - enable time computations; Number; Integer.CharacteristicsCharacteristics describe business objects in BW like products, customers, employee, and attributes like color, material, company code. They enable us to set select criteria during which we display required data.Unit characteristicsUnit characteristics provide a meaning of key figures values, stores currencies or units of measure (e.g.,CURRENCYunit, value unit).Time characteristicsTime characteristics describe time reference of business events. They build the time dimension - obligatory part of InfoCube. The complete time characteristics (clearly assigned to a point in time) provided by SAP: calendar day (0CALDAY), calendar week (0CALWEEK), calendar month (0CALMONTH), calendar quarter (0CALQUARTER), calendar year (0CALYEAR), fiscal year (0FISCYEAR), and fiscal period (0FISCPER). Incomplete time characteristics: CALMONTH2, 0CALQUART1, 0HALFYEAR1, 0WEEKDAY1, 0FISCPER3.Technical characteristicsTechnical characteristics have administrative purposes (e.g., stores request ID, change ID).InfoObjects catalogsSAP BW InfoObjects are stored in InfoObjects catalogs, separately Key figures and Characteristics (all types). Usually there are two InfoObjects catalogs (for Key figures and Characteristics) defined for every business context in SAP BW implementation.

Detailed information on particular InfoObject you can find in the Modeling area of the Data Warehousing Workbench (TCode: RSA1 -> Modeling -> InfoObjects).

Data Store Objects

Since aDataStore objectis designed like a table, it contains key fields (document number and item, for example) and data fields. Data fields can not only be key figures but also character fields (order status, customer, or time, for example). You can use a delta update to update DataStore object data into connected InfoCubes or into additional DataStore objects or master data tables (attributes or texts) in the same system or in different systems. In contrast to multidimensional DataStores for InfoCubes, data in DataStore objects is stored in flat, transparent database tables. Fact and dimension tables are not created.

With DataStore objects, you can not only update key figures cumulatively, as with InfoCubes, but also overwrite data fields. This is especially important for transaction-level documents that change in the source system. Here, document changes not only involve numerical fields, such as order quantities, but also non-numerical ones such as ship-to parties, delivery date, and status. Since the OLTP system overwrites these records when changes occur, DataStore objects must often be moceled to overwrite the corresponding fields and update to the current value in BI.

DS Oject TypesSAP BI distinguishes between three DataStore object types: Standard, Write Optimized, and Direct Update. These three flavors of DataStore Objects are shown in the following figure.

1. The Standard DataStore Objectconsists of three tables (activation queue, active data table, and change log). It is completely integrated in the staging process. In other words, data can be loaded into and out of the DataStore Objects during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.

Architecture and Functions of Standard DataStore ObjectsStandard DataStore objects consist of three tables:Active Data tableThis is where the current status of the data is stored. This table contains a semantic (business-related) key that can be defined by the modeler (order number, item, or schedule line, for example). It is very important that the key be correctly defined by the modeler, as a match on the key initiates special delta processing during the activation phase (discussed later). Also, reporting via the BEx uses this table.Change Log tableDuring the activation run, changes are stored in the change log. Here, you can find the complete history of the changes, since the content of the change log is not automatically deleted. The connected targets are updated from the change log if they are supplied with data from the DataStore object in the delta method. The change log is a PSA table and can also be maintained in the PSA tree of the Data Warehousing Workbench. The change log has a technical key consisting of a request, data package, and data record number.Activation QueuetableDuring the DTP, the records are first written to this table. This step is necessary due to the complex logic that is then required by the activation process.

Schema for a Standard DataStore Objects

2.Write optimizedis a new kind of DataStore Object . It is targeted for the warehouse level of the architecture, and has the advantage of quicker loads.3.A direct update DataStore object(previous 3.x transactional ODS) has only the table with active data. This means it is not as easily integrated in the staging process. Instead, this DataStore object type is filled using APIs and can be read via a BAPI.

AMultiProvideris a special InfoProvider that combines data from several InfoProviders, providing it for reporting. The MultiProvider itself (InfoSets and VirtualProviders) does not contain any data. Its data comes exclusively from the InfoProviders on which it is based. A MultiProvider can be made up of various combinations of the following InfoProviders:. InfoCubes. DataStore objects. InfoObjects. InfoSets. Aggregation levels (slices of a InfoCube to support BI Integrated Planning)

UseA BEx query can only be written against a single InfoProvider. A MultiProvider is a single InfoProvider to a query but through it, multiple providers can be indirectly accessed.

Difference between 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 flowto an InfoCube without having a function does nothing except hinder loading performance.

Infocube, DSO, Multiprovider

Info CubeInfo Cubeis structured as Star Schema(extended) where a fact table is surrounded by different dim table that are linked with DIM'ids. And the data wise, you will have aggregated data in the cubes.Infocube contains maximum 16(3 are sap defines and 13 are customer defined) dimensions and minimum 4(3 Sap defined and 1 customer defined) dimensions with maximum 233 key figures and 248 characteristic.The following InfoCube types exist in BI:. InfoCubes. VirtualProvidersThere are two subtypes of InfoCubes: Standard, and Real-Time. Although bothhave an extended star schema design, Real-Time InfoCubes (previously calledTransactional InfoCubes) are optimized for direct update, and do not need to use the ETL process. Real-Time InfoCubes are almost exclusively used in the BI Integrated Planning tool set. All BI InfoCubes consists of a quantity of relational tables arranged together in a star schema.

Star SchemaIn Star Schema model, Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains millions to billions of records. On the other hand dimensional tables are very small. Hence they contain a few thousands to few million records. In practice, Fact table holds transactional data and dimensional table holds master data.The dimensional tables are specific to a fact table. This means that dimensional tables are not shared to across other fact tables. When other fact table such as a product needs the same product dimension data another dimension table that is specific to a new fact table is needed.This situation creates data management problems such as master data redundancy because the very same product is duplicated in several dimensional tables instead of sharing from one single master data table. This problem can be solved in extended star schema.

Extended star schemaIn Extended Star Schema, under the BW star schema model, the dimension table does not contain master data. But it is stored externally in the master data tables (texts, attributes, hierarchies).The characteristic in the dimensional table points to the relevant master data by the use of SID table. The SID table points to characteristics attribute texts and hierarchies.This multistep navigational task adds extra overhead when executing a query. However the benefit of this model is that all fact tables (info cubes) share common master data tables between several info cubes.Moreover the SID table concept allows users to implement multi languages and multi hierarchy OLAP environments. And also it supports slowly changing dimension.

MultiProviderAMultiProvideris a special InfoProvider that combines data from several InfoProviders, providing it for reporting. The MultiProvider itself (InfoSets and VirtualProviders) does not contain any data. Its data comes exclusively from the InfoProviders on which it is based. A MultiProvider can be made up of various combinations of the following InfoProviders:. InfoCubes. DataStore objects. InfoObjects. InfoSets. Aggregation levels (slices of a InfoCube to support BI Integrated Planning)

UseA BEx query can only be written against a single InfoProvider. A MultiProvider is a single InfoProvider to a query but through it, multiple providers can be indirectly accessed.

DataStore objectSince aDataStore objectis designed like a table, it contains key fields (document number and item, for example) and data fields. Data fields can not only be key figures but also character fields (order status, customer, or time, for example). You can use a delta update to update DataStore object data into connected InfoCubes or into additional DataStore objects or masterdata tables(attributes or texts) in the same system or in different systems. In contrast to multidimensional DataStores for InfoCubes, data in DataStore objects is storedin flat, transparent database tables. Fact and dimension tables are not created.

With DataStore objects, you can not only update key figures cumulatively, as with InfoCubes, but also overwrite data fields. This is especially important for transaction-level documents that change in the source system. Here, document changes not only involve numerical fields, such as order quantities, but also non-numerical ones such as ship-to parties, delivery date, and status. Since the OLTP system overwrites these records when changes occur, DataStore objects must often be moceled to overwrite the corresponding fields and update to the current value in BI.

DS Oject TypesSAP BI distinguishes between three DataStore object types: Standard, Write Optimized, and Direct Update. These three flavors of DataStore Objects are shown in the following figure.

1. The Standard DataStore Objectconsists of three tables (activation queue, active data table, and change log). It is completely integrated in the staging process. In other words, data can be loaded into and out of the DataStore Objects during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.

Architecture and Functions of Standard DataStore ObjectsStandard DataStore objects consist of three tables:Active Data tableThis is where thecurrent statusof the data is stored. This table contains a semantic (business-related) key that can be defined by the modeler (order number, item, orscheduleline, for example). It is very important that the key be correctly defined by the modeler, as a match on the key initiates special delta processing during the activation phase (discussed later). Also, reporting via the BEx uses this table.Change Log tableDuring the activation run, changes are stored in the change log. Here, you can findthe completehistory of the changes, since the content of the change log is not automatically deleted. The connected targets are updated from the change log if they are supplied with data from the DataStore object in the delta method. The change log is a PSA table and can also be maintained in the PSA tree of the Data Warehousing Workbench. The change log has a technical key consisting of a request, data package, and data record number.Activation QueuetableDuring the DTP, the records are first written to this table. This step is necessary due to the complex logic that is then required by the activation process.

Schema for a Standard DataStore Objects

2.Write optimizedis a new kind of DataStore Object . It is targeted for the warehouse level of the architecture, and has the advantage of quicker loads.3.A direct update DataStore object(previous 3.x transactional ODS) has only the table with active data. This means it is not as easily integrated in the staging process. Instead, this DataStore object type is filled using APIs and can be read via a BAPI.

Attributes

Attributes are InfoObjects that exist already, and that are assigned logically to the new characteristic

Navigational Attributes

A Navigational Attibute is any attribute of a Characteristic which is treated in very similar way as we treat as Characteristic while Query Designer. Means one can perform drilldowns, filters etc on the same while Query designing.

Imp Note: While Creating the Info Object -- Attributes Tab Page -- Nav Attri butes to be switched on . While Designign the Cube we need to Check mark for the Nav. Attributes to make use of them.Features / Advantages Nav. Attr. acts like a Char while Reporting. All navigation functions in the OLAP processor are also possible Filters, Drilldowns, Variables are possible while Reporting. It always hold the Present Truth Data . Historic Data is not possible through Nav. Attributes. As the data is fetching from Master Data Tables and Not from Info Cube.Disadvantages: Leads to less Query Performance. In the enhanced star schema of an InfoCube, navigation attributes lie one join further out than characteristics. This means that a query with a navigation attribute has to run an additional join If a navigation attribute is used in an aggregate, the aggregate has to be adjusted using a change run as soon as new values are loaded for the navigation attribute.http://help.sap.com/saphelp_nw04s/helpdata/EN/80/1a63e7e07211d2acb80000e829fbfe/frameset.htmTransitive AttributesA Navigational attribute of a Navigational Attributes is called Transitive Attribute.Tricky rightLet me explain If a Nav Attr Has the further more Nav. Attributes ( as its Attributes ) in it those are called Transitive Attributes . For Example Consider there exists a characteristic Material .It has Plant as its navigational attribute. Plant further has a navigational attribute Material group. Thus Material group is the transitive attribute. A drilldown is needed on both Plant and Material group. And again we need to have both Material & Plant in your Info Cube to Drill down. (To fetch the data through Nav. Attrs. we need Master Data tables hence, we need to check mark/select both of them in the Cube )http://help.sap.com/saphelp_nw04s/helpdata/EN/6f/c7553bb1c0b562e10000000a11402f/frameset.htm If Cube contains both Material and PlantDimension table having both Material and Plant will have Dim ID, Sid of Material, and Sid of Plant. Since both the Sids exists reference of each navigational attribute is made correctly. If Cube contains only 'MaterialDimension table having only Material will have Dim ID, Sid of Material. Since Sid for first level navigational attribute (Plant) does not exists, reference to navigational attribute is not made correctly.Exclusive Attributes / Attributes Only/ Display AttributeIf you set the Attribute Only Indicator(General Tab page for Chars / Addl Properties tabpage for Key Figs) for Characteristic while creating, it can only be used as Display Attribute for another Characteristic and not as a Nav. Attr.Features: And it cannot be included in Info Cubes It can be used in DSO, Infoset and Char as InfoProviders. In this Info Provider , the char is not visible during read access (at run time) This means, it is not available in the query. If the Info Provider is being used as source of Transformation or DTP the characteristic is not visible. It is just for Display at Query and cannot be used for Drill downs while reporting.Exclusive attributes:

If you choose exclusively attribute, then the created key figure can only be used as an attribute for another characteristic, but cannot be used as a dedicated key figure in the InfoCube. While Creating A Key Figure -- The Tabpage:Additional Properties -- Check Box for Attributies Onlyhttp://help.sap.com/saphelp_nw04s/helpdata/en/a0/eddc370be9d977e10000009b38f8cf/frameset.htm

Info Set ( Join )

Info Set is a Virtual Provider. Info Sets allow you to analyze the data in several Info Providers by using combinations of master data-bearing characteristics, Info Cubes and Data Store objects. The system collects information from the tables of the relevant Info Providers. If you are joining large sets of data from the master data or from DSO objects, SAP recommends that you use an Info Set. This improves performance as fewer temporary tables are required and the join is executed in the database itself.Joins are 4 types

: 1) Left outer Join2) Right outer Join.3) Temporary Join...based on any Date field.4) Equal JoinInner Join:

In case of inner join there should be an entry in all the tables use in the view.

Outer Join:

With the use of outer join you can join the tables even there is no entry in all the tables used in the view. Inner join between table 1 and table 2, where column D in both tables in the join condition is set the same:

Table 1 Table 2Inner Join---- ---- ---- ---- ---- ---- ---- ---- ----A B C D D E F G H---- ---- ---- ---- ---- ---- ---- ---- ----a1 b1 c1 1 1 e1 f1 g1 h1a2 b2 c2 1 1 e1 f1 g1 h1a4 b4 c4 3 3 e2 f2 g2 h2---- ---- ---- ---- ---- ---- ---- ---- ----

Left outer join between table 1 and table 2 where column D in both tables set the join condition:Table 1 Table 2A B C D D E F G Ha1 b1 c1 1 1 e1 f1 g1 h1a2 b2 c2 1 3 e2 f2 g2 h2a3 b3 c3 2 4 e3 f3 g3 h3a4 b4 c4 3 --- ---- ------------

Left Outer Join

A B C D D E F G Ha1 b1 c1 1 1 e1 f1 g1 h1a2 b2 c2 1 3 e2 f2 g2 h2a3 b3 c3 2 4 e3 f3 g3 h3a4 b4 c4 3 --- ---- -----------------------------------------------------------------A B C D D E F G H------------------------------------------------------a1 b1 c1 1 1 e1 f1 g1 h1a2 b2 c2 1 1 e1 f1 g1 h1a3 b3 C3 2 NULLNULLNULLNULLNULLa4 b4 c4 3 3 e2 f2 g2 h2

What makes difference between Inner Join & Left Outer Join

Inner join returns only the matching records from both tables.Left outer join returns complete details of left table which are matching with right table and non matching records also.

The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.

The set of hits determined by an inner join can therefore be a subset of the hits determined with an outer join.

Database views implement an inner join. The database therefore only provides those records for which there is an entry in all the tables used in the view. Help views and maintenance views, however, implement an outer join.Temporal Join

Join containing at least one time-dependent characteristic For example, a join contains the following time-dependent Info Objects (in addition to other objects that are not time-dependent).

InfoObjects in the join Valid from Valid toCost center (0COSTCENTER) 01.01.2009 31.05.2009Profit center (0PROFIT_CTR) 01.06.2009 31.09.2009

Where the two time-intervals overlap, means the validity area that the Info Objects have in common, is known as the valid time-interval of the temporal join.

Temporal join Valid from Valid to

Valid time-interval 01.03.2009 31.05.2009

You define an Info Set via the characteristic PROFIT Center, which contains the responsible person (RESP) as the time-dependent attribute and the characteristic COSTCENTER that also contains person responsible as a time-dependent attribute.

These characteristics contain the following records:

Profit Center Responsible Person DATEFROM* DATETO*BI A 01.01.2009 30.06.2009BI B 01.07.2009 31.12.9999

Cost Center Profit Center Responsible Person DATEFROM* DATETO*4711 BI X 01.01.2009 31.05.20094711 BI Y 01.06.2009 31.12.20094711 BI Z 01.01.2009 31.12.9999

If both characteristics are used in a join and connected via PROFITCENTRE, it is not true that all six possible combinations are valid for the above records. Instead only the following four:

PROFITC RESP Cost Center Profit Center Responsible PersonBI A 4711 BI X (01.01.2009-31.05.2009)BI A 4711BI Y (01.06.2009-30.06.2009)BI B4711 BI Y (01.07.2009-31.12.2009)BI B 4711 BI Z (01.01.2009-31.12.9999)

Equal Join

A join condition determines the combination of records from the individual objects that are included in the resulting set. Before an Info Set can be activated, the join conditions have to be defined in such a way (as equal join condition) that all the available objects are connected to one another either directly or indirectly.

An Equal Join is possible only with Same Values Technical Requirement is such way that both the Values has same Data Type & Length for Equal Join.

Definitions of some Objects in BI/BW

Info Area:

Element for grouping meta-objects in the BI system.

Each InfoProvider is assigned to an InfoArea. The resulting hierarchy is displayed in the Data Warehousing Workbench.

In addition to their properties as an InfoProviders, InfoObjects can also be assigned to different Info Areas.Info Area is a Top Level Object, which contains the data models in it .

In general,Info Areas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an Info Area. Through an InfoObject Catalog, each Info Object is assigned to an Info Area as well.

TheInfo Areacontains all objects used to evaluate for a business logical process.

Info Area in which Info Providers are stored.

Info Object Catalogs:

An Info Object catalog is a collection of InfoObjects grouped according to application-specific criteria.

There are two types of InfoObject catalogs:CharacteristicandKey figure.

Info Objects, (characteristics and key figures) are the basic data model of SAP Business information warehouse(BW/BI).

And the Info objects are stored in folders, it also called the InfoObject catalogs, the infoobject catalogs are also stored in a folder called Info Areas.

An Info Object catalog is assigned to an Info Area.

An Info Object can be included in several Info Object catalogs.

Info Objects:

Business evaluation objects are known in BI/BIW 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).

Info Objects are the smallest information units in BI/BW.

They structure the Information needed to create the data targets.

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

Application Component

Application Components are used to organize Data Sources. They are analogous to the Info Areas .

DataSourceA DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information.Four types of DataSources exist:DataSources for transaction dataDataSources for characteristic attributesDataSources for characteristic textsDataSources for characteristic hierarchies

If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BI/BW system.

Info Package:An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage's technical name.

PSAPersistentStaging Area is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.The PSA stores data in its original source system format. In this way, it gives us a chance to examine / analyse the data before we process them to further destinations. Most probably it is a temporary storage area, based on the client data specifications and settings.SIDSID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.

Star schemaA star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing(OLAP).

Business ContentBusiness Content is a complete set of BI/BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, Info Cubes, key figures, characteristics, Transformations and extractors for SAP R/3, and other mySAP solutions.

Compound attributeA compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.

Data packet sizeFor the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.

Data WarehouseData Warehouse is a dedicated reporting and analysis environment based on the star schema database design technique and requiring special attention to the data ETTL process.

Delta updateThe Delta update option in the InfoPackage definition requests BI/BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.

Equal Join

Table1 Table 2

Equal JoinX ------------------- X

Surrogate ID - Master Data Tables

Standard Info cube consists of fact table surrounded by many dimension table. SID table links these Dimension tables to master data tables.

SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO. In SAP BI Extended star schema, the distinction is made between two self contained areas: Info cube & Master data tables and connecting SID tables.

The master data doesn't reside in the Extended Star schema but resides in separate tables which are shared across all the star schemas in SAP BI.

An Unique Numeric ID , the SID is generated which connects the dimension tables of the infocube to that of the master data tables.The dimension tables contain the DIM IDs and SIDs of a particular Characteristic Info Object. Using this SID Table the Master data ( attributes and texts of Info Object) is accessed.

List of Technical Tables

F - Fact Table - Uncompressed Fact Table - Contains Direct data for cube Request wise ( Based on B-Tree Index )E - Fact Table - Compress cube - Contains compressed data without Request IDs( Request ID would be 'zero') ( based on Bitmap Index )M - View of Master Data Table-/BI0/MMATERIALP - Time Independent Master Data Table -/BI0/PMATERIALQ - Time Dependent Master Data Table -/BI0/QMATERIAL

H - Hierarchy table-/BI0/HMATERIALJ - Hierarchy interval table-/BI0/JMATERIALK - Hierarchy SID table -/BI0/KMATERIALI - SID Hierarchy structure -/BI0/IMATERIALS - SID table-/BI0/SMATERIALX - Time Independent SID table for Attr -/BI0/XMATERIALY - Time Dependent SID table fir Attr-/BI0/YMATERIAL

T - Text Table - /BI0/TMATERIAL

SID -- Master data Tables

Surrogate Keys are automatically generated uniform keys, which are uniquely identifying specific real-world key values.

SID are only the connectivity link between DIM IDs and Master Data Tables .

Let us take an Example of a Material Master Data Tables and understand the various connectivities with SID table.

(Click on the image to enlarge for better view)

Compounding InfoObject

In Compounding a Field or another Object is attached to an Info Object. A Compounding Characteristic is when object's definition is incomplete without the definition of the another Characteristic Info Object.

For the better understanding the Info Object - Location (0PP_LOCAT) has to be assigned with a Compound Info Object - Plant (0PLANT).

Here Plant(0PLANT) is the Superior Info Object of the Location(0PP_LOCAT)

The Info Object 0Plant has to be Installed/Created/ Activated first, later followed by Location(0PP_LOCAT)

While creating the Info Object itself we need to assign the Superior Object like below at Compounding Tab Page of Info Object.

Compounding Info Object Acts as a compounding Primary Key at the Master Data Table.

When a compounded Info object is included in an Info cube, all corresponding info objects are added to the Info cube.

If Location(0PP_LOCAT) is to be included in the Info Cube , Plant (0Plant) is automatically added to the Info Cube.

When a Compounded Info object is included in the DSO , all corresponding Objects are added to the DSO Key fields/Data Fields.

If Location(0PP_LOCAT) is to be included in the DSO , Plant (0Plant) is automatically added to the DSO.

If an info object is defined as an attribute, it cannot be included as compounding object.

The total length of the compounding info objects cannot exceed 60 characters.

An Info Object which is defined as an Attribute only setting can not be included in Compounding object.

The Compounding Info Objects at BEx Report out put will be 0PLANT/0PP_LOCAT.

SAP BI Terminology

Info Area Info Area is like Folder in Windows. InfoArea is used to organize InfoCubes, InfoObjects, MultiProviders, and InfoSets in SAP BW.InfoObject Catalog Similar to InfoArea,InfoObject Catalog is used to organize theInfoObject based ontheir type. So we will haveInfoObjects Catalogs of type Characteristics & KeyFigures.Info Objects It is the bsic unit or object in SAP BI used to create any structures in SAP BI. Each field in the source system is referred as InfoObject on SAP BI. We have 5 types of Info Objects: Characteristic, KeyFigure, Time Characteristic, Unit Characteristic, and Technical Characteristic.Data Source Data Source definesTransferStructure. Transfer Structure indicates what fields and in what sequence are they being transferred from the source system. We have 4 types of data source: Attr: used to load master data attr Text: Used to load text data Hier: used to load hierarchy data Transcation data: used to load transaction data to Info cube or ODS.Source System Source system is anapplication fromwhere SAP BW extracts the data. We use Source system connection to connect different OLTPapplicationsto SAP BI. We have different adapters / connectors available: SAP Connection Automatic SAP ConnectionManually My Self Connection Flat fileInterface DB connect External Systems with BAPIInfo Package Info package is used to schedule the loadingprocess. Info package is specific to data source. All properties what we see in the InfoPackage depends on the properties of the DataSource.

BI/BW Tips

BI Tip # 1

Struggling as there is no sample data for your newly developed Infocube, why not try this?

Try using ABAP program CUBE_SAMPLE_CREATE. It allows you to enter required sample data directly into your cube without using any flat files, source system configuration etc. Records are added to the cube in one request using the APO interface without monitor log.

Try exploring even further with all the options available there.

Needless to say try it on Sandbox, development system before attempting on production environment.

BI Tip # 2To check whether your query is migrated to SAP BI7 version already

Check the Table RSZCOMPDIR: Enter your Query Technical Name as input to the field COMPID and execute.

If Field VERSION in the Table RSZCOMPDIR has the value less than 100 that means Query is in 3.x version. If it is more than 100 means, it is already migrated.

BI Tip # 3Couple of interesting tricks -

RSDG_MPRO_ACTIVATE is a program to activate the Multi providers in production system directly. If there are any inactive MultiProviders due to some transport or any other reason, this will activate the Multiprovider without affecting reporting.Needless to say try it on Sandbox, development system before attempting on production environment.

BI Tip # 4Worried about Data Loss while changing extract structure, why not try this?

Run the Report RMCSBWCC before doing changes to the LO extract structure or while importing any changes done to the extract structure.

This report checks whether any of the clients in the system contains data in the V3 update (Extraction queue) for that application (specific to extract structure provided as input). If there is data in V3 updates then you need to start the update for that application. Without doing this you will not be able to change the extract structure and if you are importing the changes then you may end up losing data.

BI Tip # 5RSICCONT is a table used to delete the request of a data target including DSO or Cube. Facing any problem in deleting the request from a DSO or a cube while loading the data. Try this.

Needless to say try it on Sandbox, development system before attempting on production environment.

BI Tip # 6Most of you are aware of RSZDelete tcode, but lot of them face the issue of how to delete enmass queries on one infoprovider or something in multiples. Well the answer is in same tcode.For E.g.: You need to delete 10 queries out of 20 based on a infocube. Normally , developer tend to delete one by one. But you can delete multiple queries also.Infocube : ZSD_C03Total Queries : 25To Delete : 15

In RSZDelete,Type = REPInfocube = ZSD_C03

Execute.You get list of all queries.. select the one that requires to be deleted.

PS: This is an extremely DANGEROUS Transaction Please use responsibly.

BI Tip #7Replicate Single DataSource

- Use RSAOS_METADATA_UPLOAD function module to replicate single datasource. Logical system - put in field I_LOGSYS OLTP datasource name - put in field I_SOURC. and execute.

Trust you shall check this in Sandbox / Development System first.

BI Tip #8Load Monitoring Table..Did you explore table RSSTATMANPART?

Do you struggle every day while doing data load status monitoring and reporting? Did you ever thought of checking tableRSSTATMANPART?

Check the Manage tabs of multiple Targets or InfoProviders together ? Use the table RSSTATMANPART to obtain the same. This data will tell you whether the load to the target was successful or not & also will let you know whether the target is reportable or not.

I happen to come across couple of interesting content covering it on SDN, sharing for your reference This one is ABAP code for status monitoringhttp://wiki.sdn.sap.com/wiki/display/BI/Current+Day+Data+Load+Monitor+Program

Other one is the link of one of the forum thread https://forums.sdn.sap.com/thread.jspa?threadID=1232358

Needless to say try it on Sandbox / IDES system before going forward.

Happy Learning.

Display Cube Dimension Percentage UsedTo display, per dimension, the percentage used with regard to the number of entries in the fact table(s), function moduleRSDEW_INFOCUBE_DESIGNScan be used.Enter the name of the cube for input parameter I_INFOCUBE and execute the function module.Export parameter E_T_TABLSIZE will provide you the desired result as shown in the attached picture.

Infoproviders (Physical and Virtual)

Data Store Objects

A Data Store object is used to store consolidated and cleansed data(transaction data or master data) on a document level(atomic level).Although Datastore Objects can store master data, and and there arevalid reasons for this, they primarily store detailed transaction data.They can be used to support detailed operational reporting, or canbe part of the warehouse, where they canbe used to hold years of"potentially needed" data.

One major difference between Datastore Objects and Infocubes is thatDataStore Objects have the option to overwrite records, where infocubesdo not. This is a huge difference.

In contrast to multidimensional Datastores for Infocubes, data in DataStore objects is stored in flat, transparent database tables. Fact anddimension tables are not created.

With Datastore objects, we cannot only update keyfigures cumulatively,as with Infocubes, but also overwrite data fields. This is especiallyimportant for transaction-level documents that change in the sourcesytem. Here, document changes not only involve numerical fields, suchas order quantities, but also non-numerical ones such as ship-to parties,delivery date, and status. Since the OLTP system overwrites theserecords when changes occur, Datastore objects must often be moceledto overwrite the corresponding fields and update to the current valuein BI.

The Standard Datastore Object consists of thre tables(activation queue,active data table, and change log). It is completely integrated in thestaging process. In other words, data can be loaded into and out of theDatastore Objects during the staging process. Using a change log meansthat all changes are also written and are available as delta uploadsfor connected data targets.

Write Optimized is a new kind of Datastore Object. It is targeted forthe warehouse level of the architectur, and has the advantage ofquicker loads.

A direct update Datastore object has only the table with active data.This means it is not as easily integrated in the staging process.Instead, this Datastore object type is filled using APIs and can beread via a BAPI.

The following code is delivered for this purpose.

BAPI BAPI_ODSO_READ_DATA_UCRSDRI_ODSO_INSERTRSDRI_ODSO_INSERT_RFCRSDRI_ODSO_MODIFYRSDRI_ODSO_MODIFY_RFCRSDRI_ODSO_UPDATERSDRI_ODSO_UPDATE_RFCRSDRI_ODSO_DELETE_RFC

Direct Update DS Object usage in APD:The APD is a robust tool set for use by the best analysis. It allowsanalysts to manipulate and mine data for specific analysis goals.

Direct Update DS Object usage in SEM Business Consolidation(BCS):During consolidation of two legal entities, accounting entities aremade to direct update DS Objects to reflect the elimination ofinternal transactions.

The number of Datastore Objects that must be implemented dependson the complexity of the scenario that is to be implemented. Furthermore,a Datastore object can also form the end of a staging process. In otherwords,an Infocube does not necessarily have to be updated from the Datastoreobject.

Integrating a New Infocube Into an Existing Into an Existing Data Flow:

1. Create a transformation between the original source and the new target objects.2. Create both a full and delta DTP.3. Manually execute the full DTP.4. Create a new process chain to execute the delta DTP.5. Integrate the new chain into your existing nightly process chains.

Infoproviders are all objects that provide information to queries.Infoproviders are broken down into two grouping. Infoproviders thatstore the data persistently(in database tables) and those that do notstore the data in BI, but rather collect the data when the query isexecuted. The former grouping of infoproviders are sometimes calleddata targets. The ones that do not store data persistently in BI includeInfosets, Virtual Providers, and multiproviders.

Virtual providers are very special. Like all providers, they feedinformation to queries. However, a virtual provider represents a logicalview. Unlike Infocubes, no data is physically stored in BI. The data istaken from the source systems only after a query has been executed.There are three types of Virtual Providers, and each type can bedistinguished by the way in which it retrives data.

Based on DTP For direct accessBased on a BAPIBased on a function module.

Direct Access, a Definition:

A BI tool set that allows queries to be executed on temporary VirtualProviders that are tied directly to the source system.

We require up-to-date data from a SAP source systemOnly a small quantity of data is transferred(good query design)Only a small number of users work with queries in the dataset at any one time.

There are differences between analysis reporting and operational reporting.For example, a analysis of why accounts receivable is growing 5% ayear would be a BI Report. On the other hand, a list of unpaid invoicesto support dunning the customer for what they owe would be anOLTP-based report.

This theory of separtation of duties was completely valid when BI Systemswere first developed, but now the line is blurred. It becomes even moreso with the introduction of Real-Time Data Acquisition(RDA). RDA is a newSAP Netweaver 2004s tool set to support some limited operationalreporting needs inside BI.

With RDA, data is transferred into BI at regular intervals during theday and is then updated in the Datastore objects, which are directlyavailable for reporting Background processes(daemons) in the BI Systeminitiate the Infopackages and data transfer processes assigned to them(to update the PSA data in Datastore objects).

Real-Time Data Warehousing(RDA)

RDA is a framework for analyzing information from various sources inreal time as soon as the data becomes available in the source system.

Lower time scale than for schedeuled/batch data acquisitionStream orientedAlmost immediate availability for reporting(less than 1 minute)

RDA is used in tactical decision making.

Using a Webservice Push:

A web service push can write the data directly from the source to thePSA. The data transfer is not controlled by BI. An infopackage(for fullupload) is required only to specify request-related settings for RDA;itis never executed, as the data is pushesd into the BI PSA by a web service.

Using the BI Service API: If the source data is based on a source in anSAP Source system, the BI Service API is used. Many of the steps arethe same as with normal delta extractions, such as the requirement foran infopackage to initialize delta.

With RDA, it is these delta loads that are special. If the Datasourceallows for RDA ( a checkbox on RSA2), we can choose to utilize it inthis way. This involves the creation of a specific RDA Data Transfer Process.

The RDA processes focuses on obtaining data very frequently from yoursource system. Due to the limitations discussed above, many times youonly get to decide if the feed to your targets will be normal, periodicallyschedulled infopackage, or if it be RDA.

Infoproviders exist for Plan and Actual data of cost center transaction.This separate plan vs actual design suports BI Integrated Planning withone dedicated cube, and to support the loading of actual data fromSAP Source system. Your users now have requirements for plan add actualcomparision reports. We want to investigate a Multiprovider to solvethis need

Virtual Provider( Remote Cube)

VirtualProvidersrepresent a logical view. Unlike Info-Cubes, data is not stored physically in BI. Only the data is taken from the Source System as query executed. You use this Virtual-Provider if you want to display data from non-BI data sources in BI without having to copy the data set into the BI structures. The data can be local or remote.Following are the three type of Virtual Provider.. Based on DTP for Direct Access TheDirect Access (DTP-filled)Virtual-Provider allows you to define queries With direct access to transaction or master data in other source systems.. Based on a BAPI TheBAPI-basedoption allows reporting using data from non-SAP systems. The external system transfers the requested data to the OLAP processor via the BAPI.. Based on a Function ModuleFunction-Module-BasedVirtual-Provider supplies a clean interface to allow your custom code to be the source data. It is a very flexible way to populate a Virtual-Provider.

These options are shown in the creation GUI for Virtual-Providers

Aggregates

In an aggregate the dataset of an infocube is saved redundantly and persistantly in a consolidated form intothe database.

USE: The objective of using the aggregates is to improve the reporting performance in reporting. Aggregates makes it possible to access infocube data quickly in reporting. Aggregates serve in a similar way to databaseindexes to improve performance. The BW OLAP Processor selects an appropriate aggregate during a query run in the navigation step. If no appropriate aggregate exists, the BW OLAP Processor retrives data from the infocube. Aggregates are multidimensional data structures similar to infocube containing aggregated subset of information, in a summarized from. An aggregate is also called as baby cube for an infocube. An aggregates stores the data of an Infocube redundantly and in consolidated from in the aggregate table RSDDAGGRDIR. Aggregates are used mainly for one reason primarily to improve the reporting performance. When queries run faster, they may take less processing time and resources in addition to the enduser getting the information back i.e., response more quickly.

Life Cycle of Aggregates:1. Aggregates are defined by the DBA against an existing Infocube.2. Aggregates are updated when loading data into Infocubes from Infosource using the same updated rules basic infocube.3. During data loading, data is aggregated to the specific level of infocube dimension(characteristic)4. During querying, the OLAP Processor dynamically determines if an aggregate exist to satisfy the query.

Aggregates have 3 names:1. A system defined 25 digit unique name.2. A 6 DIGIT integer number3.A user defined description onlyRelationship between Aggregates queries and Infocubes:Infocube 1:N Aggregates i.e.,One Infocube maintains more than one aggregate2. Querystep 1:1 aggregate i.e.,One Aggregate is used in one query.When do you use Aggregates:It is recommed to use aggregates,1. If an Infocube contains lots of Data2. If attributes are used in queries often3. If the execution and the navigation of a query data leads to deploys with a group of queries.4.If you want to speed up queries reporting the characteristics hierarchies by aggregating data to a specific hierarchy level then we use aggregates.

Aggregation Level:An aggregation level indicates the degree of details to which the data of the Infocube is compressed. There are 3 levels of aggregates.

1. All characteristic values (*): The data is grouped by all the values of the characteristic or navigation attributes.2.Hierarchy Level(H): The data is grouped by Hierarchy node.3.Fixed value(F): The data is filled according to a constant or single value.

Important Information about Aggregates:An aggregate holds transaction data.An Infocube can have several aggregates.Each query can have only one aggregateAggregates must be recreated after the changes in the MD Attributes or hierarchies.(change run process)Aggregates are built against infocubes only but not with ODS Objects.Aggregates are useful for keyfigures with SUM,MIN,MAX Properties.Aggregates are selected by OLAP Processor during query processing.Aggregates can be built with display attributes.Aggregates are maintained in a table RSDDAGGRDIR.Switch OFF Aggregates during dataloading to improve the loading performance.Apply Rollup Process to fill the aggregates with the infocube data.Switch On Aggregates after ROLLUP to improve the reporting performanceMaintanance of aggregates includesCreate New AggregateActivate and Rollup.DeactivateDeleteCopy with TemplateAggregate TreePre Analysis of the Aggregate filling.Swith off aggregates will result in no data loss; structure remains as it is but aggregate or Baby cube wont be fill with data.aggregation deactivation will result in the data loss for the aggregates, but structure of aggregate remains as it is.Delete aggregate will result in data loss as well as structure loss.copy with template allows you to create new aggregates using with the existing aggregates.To check the data in aggregate(Baby Cube) place the cursor on the specific aggregate, then select

GOTO MENU........> Aggregates data.The technical name of Aggregate is a 6 digit integer number. Eg: 100426.Its dimension tables are; /BIC/D100426I, /BIC/D100426P, /BIC/100426UThe fact table of aggregate maintains an adding keyfigure 0factcount(It is the couter for occurance of request)

BI Table Types (MD, SID, DIM, etc)

Attribute tables: Attribute tbl for Time Independent attributes: /BI*/P stored with characteristic valuesAttribute tbl for Time Dependent attributes: /BI*/Q Fields DATETO & DATEFROM are included in time dependent attribute tbl. stored with characteristic valuesDimension tables: Dimension tbls(i.e. DIM tables): /BI*/D stores the DIMID, the pointerbetween fact tbl & master data tbl data is inserted during upload of transact.data (data is never changed, only inserted) Examples: /bic/D(cube name)Pis the package dimension of a content cube /bic/D(cube name)Uis the unit dimension of a content cube /bic/D(cube name)Tis the time dimension of a content cube /bic/D(cube name)Iis the user defined dimension of a content cubeExternal Hierarchy tables: /BI*/I*, /BI*/J*, /BI*/H*, /BI*/K* /BI0/0P... are tables that occur in the course of an optimized preprocessing that contains many tables. bic/H(object name) hierarchy data of object For more information see Note 514907.Fact tables: In SAP BW, there are two fact tables for including transaction data for Basis InfoCubes: the F and the E fact tables. /bic/F(cube name) is the F-fact table of a content cube /bic/E(cube name) is the E-fact table of a content cube The Fact tbl is the central tbl of the InfoCube. Here key figures (e.g. sales volume) & pointers to the dimension tbls are stored (dim tbls, in turn, point to the SID tbls). If you upload data into an InfoCube, it is always written into the F-fact table. If you compress the data, the data is shifted from the F-fact table to the E-fact table. The F-fact tables for aggregates are always empty, since aggregates are compressed automatically After a changerun, the F-fact table can have entries as well as when you use the functionality 'do not compress requests for Aggregates. E-fact tbl is optimized for Reading => good for Queries F-fact tbl is optimized for Writing => good for Loads see Note 631668Master Data tables /BI0/P /bic/M(object name) master data of object Master data tables are independent of any InfoCube Master data & master data details (attributes, texts & hierarchies) are stored. Master data table stores all time independent attributes (display & navigational attribues)Navigational attributes tables: SID Attribute table for time independent navigational attributes: /BI*/X SID Attribute tbl for time dependent navigational attributes: /BI*/Y Nav.attribs can be used for naviagtion purposes (filtering, drill down). The attribs are not stored as char values but as SIDs (master data IDs).P table: P-table only gets filled if you load master data explicitly. As soon as the SID table is populated, the P tbl is populated as wellSID table: SID tbl: /BI*/S stores the char value (eg customer number C95) & the SID. The SID is the pointer that is used to link the master data tbls & the dimension tbls. The SID is generated during the upload (uniqueness is guaranteed by a number range obj). Data is inserted during the upload of master data or of transactional dataS table gets filled whenever transaction gets loaded. That means if any new data is there for that object in the transactions then SID table gets fillled.Text table: Text tbl: /BI*/T stores the text for the chars data is inserted & changed during the upload of text data attribs for the InfoObject stored either language dependent or independent

M - View of master data table

Q - Time Dependent master data table

H - Hierarchy table

K - Hierarchy SID table

I - SID Hierarchy structure

J - Hierarchy interval table

S - SID table

Y - Time Dependent SID table

T - Text Table

F - Fact Table - Direct data for cube ( B-Tree Index )

E - Fact Table - Compress cube ( Bitmap Index )

What are the Setup Tables?

The Setup Tables are the objects from which the Business Warehouse system is going to extract data for Full loads and Initialization on LO DataSources.

When a Full extraction or a Delta Initialization is going to be performed, the Setup Tables need to be filled with all the historical data to be loaded to the Business Warehouse system. This ensures the extractors won't need to access the always busy application tables (like EKKO or VBAK).

Their content can be deleted any time, without affecting the R/3 transaction data. In fact, after the full/Init load has been performed, it is highly likely that the information contained in the Setup Tables is already not up-to-date anymore.Therefore, it would be no harm at all to delete their content. You may think of it as a "PSA" on the R/3 side.

If the load performed was an Initialization, the next records to be extracted will be sent to the Delta Queues.

RSRV

Analysis and Repair of BW Objects:This transaction contains a collection of Reports to check the consistency of the Metadata and the data in thesystem and offers repair payments for most inconsistencies.These reports should be periodically run as a preventive maintenance measures to create any data corruption etc.RSRV Transaction is used as a Testing tool.

Naming Convention in SAP BW

SAP BW has a naming convention related to its objects.

SAP BW prefixes /BIO/ to the namesof BusinessContentdatabase objects. It prefixes /BIC/ to the database objects created by users.

If a user creates characteristics type info object ZPRODUCT and activates it, information will be stored in following:

Data element: /BIC/IOZPRODUCTSIDtable: /BIC/SZPRODUCTMaster data table: /BIC/PZPRODUCTText table: /BIC/TZPRODUCTView: /BIC/MZPRODUCT

When an info cube ZSALES is created and activated, information will be stored in following:

ViewFact table: /BIC/VZSALESFTransparent Fact table: /BIC/FZSALESDimensiontables: /BIC/DZSALES1 to /BIC/DZSALESN where N being no. of dimensions/BIC/DZSALESP, /BIC/DZSALEST, /BICDZALESU for Data Packet, Unit & Time (maximum 16 dimensionsClasses of Data

There are 3 classes of data in SAP-BW.

1. Master Data : It Describes Business2. Transaction Data : It Describes Business Event.3. Configuration Data :

Master Data is further classified into 3 types:1. Attribute Data: It describes2. Text Data:3. Hierarchical Data:

Transaction Data is further divided into 2 types:1. Document Data 1. Header Data 2. Item Data 3. Schedule line Data2. Summary Level Data

If a hierarchy is used in an info object ZDATE, following tables will be created:

Hierarchy table: /BI0/HZDATEHierarchy SID table: /BI0/KZDATESID hierarchy structure: /BI0/IZDATEHierInterval table: /BI0/JZDATE

Routine Lesson 1

SCENARIO: THE DATA SOURCE DOES NOT HAVE DIVISION AND WE NEED TO DERIVE IT FROM MATERIAL WHICH EXISTS IN THE DATASOURCE. POPULATE THE CUBE WITH THE DIVISION.SOLUTION:DIVISION NEEDS TO BE DERIVED FROM MATERIAL AS DIVISION IS NOT RETRIEVED FROM THE DATASOURCE AND THE DIVISION NEEDS TO BE DERIVED FROM MATERIAL USING THE /BI0/PMATERIAL TABLE. WA_TH_MATERIAL IS AN INTERNAL TABLE DERIVED FROM A WORK AREA WHICH IS WA_MATERIAL AND WA_MATERIAL IS A WORK AREA DERIVED FROM THE STRUCTURE T_MATERIALSINCE T_MATERIAL HAS MATERIAL AND DIVISION AS THE 2 FIELDS AND THIS IS READ INTO A WORK AREA WA_MATERIAL USING A KEY WHICH IS THE -MATERIAL I.E. THE MATERIAL THAT IS LOADED INTO THE END ROUTINE OF THE TRANSFORMATION.START ROUTINE: USE A SELECT STATEMENT TO LOAD THE INTERNAL TABLE.CODE SNIPPET:IF WA_TH_MATERIAL[] IS INITIAL.*LOAD DIVISION BY MATERIALSELECT MATERIAL DIVISIONINTO TABLE WA_TH_MATERIALFROM /BI0/PMATERIALWHERE OBJVERS = A.END ROUTINE: USE A READ STATEMENT AND READ THE INTERNAL TABLE POPULATED IN THE START ROUTINE INTO A WORK AREA USING A KEY. IF DATA IS FOUND MAKE THE DATA FOUND EQUAL TO THE END ROUTINE FIELD.CODE SNIPPET:READ TABLE WA_TH_MATERIALINTO WA_MATERIALWITH TABLE KEY MATERIAL = -MATERIAL.IF SY-SUBRC = 0.-DIVISION = WA_MATERIAL-DIVISION.DATA DEFINITION:DATA:BEGIN OF T_MATERIAL,MATERIAL TYPE /BI0/OIMATERIAL,DIVISION TYPE /BI0/OIDIVISION,END OF T_MATERIAL,DATA: WA_TH_MATERIAL TYPE HASHED TABLE OF T_MATERIAL WITH UNIQUE KEY MATERIAL,DATA: WA_MATERIAL TYPE T_MATERIAL,

Routine Lesson 2

Scenario: cube needs a customer number and the datasource does not provide the customer number. The datasource however contains the country code such as DE,FR etc. based on the country code a particular customer number is assigned for eg: for DE it is DE01J45 and for FR it is FR023J4. This customer number needs to be populated in the cube.SOLUTION:In this scenario the transformation from the DSO to the cube is worked on where the start routine is coded to load a data element from a standard table with a field in the standard table as a reference. This is then used in the END routine with a CASE statement and the RESULT_FIELDS are loaded accordingly.START ROUTINE:Code snippet:select single low from ZBW_CONSTANT_TABinto g_de_billtowhere vnam = JV_DE_BILLTO.END ROUTINE:Code snippet:case -/bic/zjvsource.when DE.-Ship_to = g_de_billto.-Sold_to = g_de_billto.-billtoprty = g_de_billto.-payer = g_de_billtoend case.-/bic/zjvsource.case -/bic/zjvsource. when DE. -Ship_to = g_de_billto. -Sold_to = g_de_billto. -billtoprty = g_de_billto. -payer = g_de_billtoend case.

Routine lesson 3

Scenario: An info object in the cube has to be updated with a constant value and this info object does not come from the datasource. Update the info object in the cube with a constant value.Solution: go to the DSO and add the info object where the data is not being sourced from the datasource and in the transformation right click on the info object and click on RULE DETAILS which will provide the below screen shot. Now choose constant and enter the value.

BW InfoProvider Design Specifications

InfoProvider Identification

InfoProvider Name:InfoCube: 0IC_C03 Material Movements

Standard/Custom:StandardBusiness Content Std.Business Contentw/ Modifications Custom

Module(s):COFIHRMMPMPPSDPS

Other (specify):

Document History

Created By:Rodrick GaryDate Created:04/03/2006

Approved by:Date Approved:

Change History (To track changes to Request spec. after the specifications have been approved)

Date ModifiedModified byBrief Description of ChangeApproved byDate Approved

This Is What a Mothers Body Really Looks Like Without Airbrushing! Continued. | BuzzWok.com | The Best Buzzing Stories Frying In One Place(Buzzwok)1.Overview

This InfoCube allows you to evaluateSTOCKinventory. This InfoCube contains valuated stock, consignment stock, stock in transit, blocked stock, and inspection stock. Also, this InfoCube contains the issue quantity and receipt quantity of valuated stock, inspection stock, consignment stock, blocked stock, and stock in transit.

The InfoSources and DataSources are:InfoSourceDescriptionDataSource

2LIS_03_BXMaterial Stocks2LIS_03_BX

2LIS_03_BFMaterial Movements From Inventory Mgmt2LIS_03_BF

2LIS_03_UMRevaluations In Inventory Management2LIS_03_UM

The InfoSource 2LIS_03_BX allows you totransfer material stocks from an SAP R/3 system to SAP BW. The InfoSource allows you to set up stocks for stock InfoCubes.The InfoSource 2LIS_03_BF delivers the data for material movements from MM Inventory Management (MM-IM).The InfoSource 2LIS_03_UM delivers the data for revaluations from MM Inventory Management (MM-IM).

Standard reports such as the following are available:Stock OverviewStock In TransitInventory AgingVendor Consignment StockConsignment Stock at Customer

RICE NumberDescription

2.Data Flow

3.Business Content Installation3.1.R/3: Data Transfer to the SAP Business Information Warehouse3.1.1.Classification:Standard Business Content X Standard Business Content w/ Modifications __Refer to: __________Custom __ Refer to: __________3.1.2.In each of the designated source systems, transfer the following DataSource(s):DataSource:2LIS_03_BXDataSource:2LIS_03_BFDataSource:2LIS_03_UMSource System:F Box (Development Client TBD) X G Box (Development Client TBD) X E Box (Development Client TBD) X Note: This assignment has been activated per standard business content. No modifications have been made.

Use R/3 Menu Path:Data Transfer to the SAP Business Information WarehouseBusiness Content DataSourcesTransfer Business Content DataSources

3.2.BW: Set up InfoSource / DataSource Assignment3.2.1.Classification:Standard Business Content Standard Business Content w/ ModificationsRefer to: __________Custom Refer to: __________

3.2.2.Modeling: Source Systems: Replicate the DataSources of the following Application Components:Application Component(s):Inventory Management3.2.3.In each of the designated source systems, assign the following DataSource - InfoSource relationships:DataSourceInfoSource2LIS_03_BX 2LIS_03_BX2LIS_03_BF 2LIS_03_BF2LIS_03_UM 2LIS_03_UM

Source System:F Box (Development Client TBD) X G Box (Development Client TBD) X E Box (Development Client TBD) X

3.2.4.Install the Transfer Rules and Communication Structure.Note: This assignment has been activated per standard business content. No modifications have been made.

3.3.Activate InfoCube:0IC_C033.3.1.Classification:Standard Business Content X Standard Business Content w/ Modifications __Refer to: __________Custom __ Refer to: __________

3.3.2.From the Business Content area of the Administrator Workbench:3.3.2.1.Set Grouping to:Only Necessary Objects __ In Data Flow Before XIn Data Flow Afterwards __ In Data Flow Before & Afterwards __ 3.3.2.2.Set Collection Mode to:Collect Autmatically XStart Manual Collection __ Refer to: __________

3.3.2.3.Insert the following object(s) for Collection:Object:0IC_C033.3.2.4.InstallNote: This object has been activated per standard business content. No modifications have been made.

4.Dimensional Model(Include InfoProvider, master data, related ODS, and related aggregated cubes)4.1.Material Stocks/Movements (as of 3.0B) ( 0IC_C03 )Note: This InfoCube is set to be activated per standard business content.

Compound Key Navigational Attribute

Navigational Attributes

InfoObject_NAVName for NAVNAV turned on (yes=x)Standard Business ContentCustomReference Section

0PLANT__0COUNTRYCountry Of PlantXX

0MATERIAL__0DIVISIONDivisionXX

0MATERIAL__0MATL_CATMaterial CategoryXX

0MATERIAL__0MATL_GROUPMaterial GroupXX

0MATERIAL__0MATL_TYPEMaterial TypeXX

5.DataSource to InfoSource Mappings

5.1.DataSource 2LIS_03_BX to Infosource 2LIS_03_BX

Note: This DataSource assignment has been activated per standard business content. No modifications have been made.

InfoObject (InfoSource)DescriptionData Element in R/3Field in Transfer StructureTransfer RoutineStandar