Thursday, 26 December 2013

SAP BW/BI InfoObjects

Info objects are business evaluation objects in BI/BW. Info objects are the smallest information units in BW. They structure the information needed to create data targets. Info objects with attributes or text can be either data target's or info providers.


InfoProviders are made from InfoObjects and form something critical that permits end users to report from.
 



You will find five different types of InfoObjects offered in the SAP BW environment.
Types of InfoObjects:
A) Characteristics (Employee, Customer, Material)
B) Key Figures (Quantity Sold, Amount, Weight)
C) Time Characteristics (Year, Month, Period, Quarter)
D) Unit InfoObjects (Currency Unit, Measurement Unit)
E) Technical Characteristics (Data Load Request ID, Change Run ID, Package ID)

Key figures:
Key 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.

Characteristics

Characteristics 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 characteristics

Unit characteristics provide a meaning of key figures values, stores currencies or units of measure (e.g., currency unit, value unit).

Time characteristics

Time 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 characteristics

Technical characteristics have administrative purposes (e.g., stores request ID, change ID).

InfoObjects catalogs

SAP 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.
 
Different Data types allowed for creating a characteristic info object are
CHAR, NUMC, DATE, TIME

Different Data types allowed for creating Key figure info object are
Amount, Quantity , Number, Interger, date , time 
 
For example:
ABC Corporation is interested in finding out how much of product x shipped on date x to factory x.

0NAME (ABC Corporation), 0MATERIAL (Product x), 0DATE (Ship date x), 0LOCATION (factory location) would be our characteristics needed
0AMOUNT (Quantity shipped) would be our key figure used to measure the quantity of products shipped

We know that we would need at a minimum, an InfoProvider that incorporated the above five InfoObjects.  This is important when building in BW to get the client to let you know all the pieces they are wishing to analyze (InfoObjects) so you can produce an InfoProvider containing applicable InfoObjects that will create valuable reports and in turn information for the business.

SAP delivers  standard InfoObjects.  These objects are actually in the BI content (Business Content).  BI content is SAPs strategy for an out of the box answer to your business requirements.  These objects begin with ‘0’. If SAP delivered InfoObjects will not meet your needs for development, you can effortlessly create a customized object that will meet your requirements.  You can create custom Characteristic, Key Figure, and Unit InfoObjects.

Multiprovider

Definition
Use
A MultiProvider allows you to analyze data based on several InfoProviders.
We have seen InfoProviders like DSO, InfoCube, InfoObjects... (can physically hold data)

we have some more infoproviders on which reporting can be performed, but they cannot physically hold data... and they won’t be having any tables also..

They are virtual Infoproviders..

  • Multiprovider
  • Infoset
  • Virtual Cube
The design of a data target such as an Info Cube or DSO is based on one business process,
for example, one Info Cube for sales billing processing and another one for sales order processing. In this way BI will have multiple Info Cubes, each supporting an individual business process. In real time we will get scenarios where data from two different Info Cubes needs to be joined.

A Multi Provider is a logical definition that doesn’t physically store data. The data lies in the underlying data provider on which the Multi Provider is created. A MultiProvider can consist of different combinations of the following InfoProviders: InfoCube, DataStore object, InfoObject, InfoSet, VirtualProvider, and aggregation level

Multiprovider can also be create on a single info provider.
A union operation is used to combine the data from these objects in a MultiProvider. Here, the system constructs the union set of the data sets involved; all the values of these data sets are combined. 

In a MultiProvider, each characteristic in each of the InfoProviders involved must correspond to exactly one characteristic. If this is not clear, you have to specify the InfoObject to which you want to assign the characteristic in the MultiProvider. You do this when you define the MultiProvider.

lets see how we create a multiprovider on a DSO and Cube
lets create a multoprovider on top of the highlighted Cube and DSO..
Drag and drop the dimensions(with characteristics) or only characteristics(creating dimensions)  and keyfigures to respective places..
Now we have to identify the characteristics included in the Multi Provider and match them to the characteristics or navigation attributes in the base info cubes.
Identify characteristics for all characteristics and Identify keyfigures for all keyfigures..

And activate Multiprovider
Select the Multiprovider and right click and select "Display data" option to see the virtual data.
we don't find Tranformation and DTP  for Multiprovider because we are not loading physical data.







DTP Error Stack

Error stack DTP functionality:
 When know that as source may sends wrong data on daily/weekly cases, rather than reloading whole data into target. we use error stack which can hold error records and correct records will update to target.

 Check the error stack record and correct them at PSA and save it. then trigger the error stack DTP which can update corrected error stack records to target.

 At target level we may see the requests as:
one request loaded through normal DTP will be in red status, we can make it green once we loaded corrected records through error stack DTP. once you make this as green, data was available for reporting.



If 100 records are getting transferred to Target. and if there is error in 5 records, we don't want the entire 100 records to pulled back..

In this concept our 95 records will reach target.. and erroneous 5 records will be moved to error stack.
we can correct the errors in error stack and send it to target using an error DTP..

Now lets see this using an example

In our source data we are purposely giving some errors to see the functioning of Error Stack and Error DTP..

We entered two entries in small letters which the system won’t accept in normal case...
  
This is where we are going to load data..

Run  infopackage and load data to PSA of Datasource..


While configuring DTP.. give Error handling as "update valid records"..

Activate and Execute DTP..
  

In this we can see... ^ records are updated... remaining 2 erroneous records are blocked..
  

click on Error stack 

 
now correct the error records and save...


Now create Error DTP... 


Activate and execute the Error DTP


Corrected records are now moved from Error Stack to Cube

let us display data of cube