InfoObjects

at 9:43 PM 0
InfoObjects
  • InfoObjects are the smallest pieces in SAP BI . InfoObjects are used to describe business information and processes. For examples InfoObjects are: Customer Name, Region, Currency, Revenue, Fiscal year. 
  • There are five types of SAP BW InfoObjects:
    • Characteristics
    • Key figures
    • Unit characteristics
    • Time characteristics and
    • Technical characteristics.

Characteristics

  • Characteristics describe business objects in SAP BI like products, customers, employee, and attributes like color, material, company code.
  • They enable us to set select criteria during which we display required data.
Key figures
  • Key figures describe numeric information that are reported on in a query.
Unit characteristics
  • Unit characteristics provide a meaning of key figures values, stores currencies or units of measure (e.g., Currency Unit).

Time characteristics

  • Time characteristics describe time reference of business events.
  • They build the time dimension - obligatory part of InfoCube.
  • The complete time characteristics 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. Request ID).

Labels:

Error calling number range object

at 10:10 PM 2

Solution

1. Note down the InfoCube and Dimension name.

2. Go to T-Code: RSRV --> All Elementary Tests --> Transactional Data then double click on “Comparison of Number Range of a Dimension and Maximum DIMID” --> then click the same on the right side pane --> Mention the InfoCube name and Dimension name, click on Transfer button --> Click on top Correct Error.

 
 
Labels:

PSA error record

at 9:00 AM 0
Reason

It may happen some times that the incoming data to BW is having some incorrect format, or few records have few incorrect entries. 



Solution

1. Go to details tab, find its packet number and its record number.


2.  Click on PSA icon in monitor and select the error Data Packet

 

3. Double click on error record and edit it to the correct value, Select Save.

Now update from PSA to target by selecting the option Start update immediately. 
 

Labels:

Time stamp error

at 8:40 AM 0
Reason
  • The “Time Stamp” Error occurs when the Transfer Rules or Transfer Structure are internally inactive in the system.
  • They can also occur whenever the DataSources are changed on the R/3 side or the DataMarts are changed in BW side. In that case, the Transfer Rules is showing active status when checked. But they are actually not, it happens because the time stamp between the DataSource and the Transfer Rules are different.



Solution 

1. Go to RSA1 --> Source system --> Replicate DataSource



2. Run the program RS_TRANSTRU_ACTIVATE_ALL



3. Mention Source System and InfoSource and then execute.



Now the Transfer Structure will be automatically activated then proceed with the reload, it will get success now.

 
Labels:

SAP BI Terminology

at 11:24 AM 1 comments
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 the InfoObject based on their type. So we will have InfoObjects 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 defines Transfer Structure.
  • 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 an application from where SAP BW extracts the data. 
  • We use Source system connection to connect different OLTP applications to SAP BI.
  • We have different adapters / connectors available:
    • SAP Connection Automatic
    • SAP Connection Manually 
    • My Self Connection
    • Flat file Interface
    • DB connect
    • External Systems with BAPI
Info Package
  • Info package is used to schedule the loading process. 
  • Info package is specific to data source. 
  • All properties what we see in the InfoPackage depends on the properties of the DataSource.

Labels:

Extended Star Schema

at 6:01 AM 0
Extended Star Schema

  • The BW extended star schema differs from the basic star schema, in case of extended star schema, we will have Fact table connected to the Dimension table and the Dimension table is connected to the SID table and SID table is connected to the master data tables.
  • Fact Table and Dimension table will be inside the cube.
  • SID table and Master data tables are outside the cube.
  • One Fact table can get connected to 16 Dimension tables, one Dimension table can be assigned with maximum of 248 SID tables (248 characteristics).
  • When we load Transaction data into InfoCube, System generates DIM ID based on the SID’s and uses the Dim ID’s in the Fact Table.
  • Each Characteristic can have its own master data tables (ATTR, TEXT, HIER). Attribute Table is used to store all the attribute data, Text table is used to store the description in multiple languages, Hier table is used to store the Parent-Child data.
 
  
Fact Table   

  • Fact Table will have Dimension ID’s and Key figures. 
  • Maximum DIM ID’s – 16 
  • Maximum KeyFigure – 233 
  • The Dimension ID’s in the Fact Table is connected to the Dimension Table. 
  • Fact Table must have at least one Dimension ID.
Dimension Table  

  • Dimension Table contains Dimension ID and SID columns. 
  • One column is used for Dimension ID.
  • We have maximum of 248 SID Columns.
  • We can assign maximum of 248 characteristics to one dimension.
 

Labels:

Star Schema

at 8:13 AM 0
Star Schema

  • InfoCubes are made up of a number of InfoObjects. All InfoObjects (characteristics and key figures) are available independent of the InfoCube. Characteristics refer to master data with their attributes and text descriptions.   
  • An InfoCube consists of several InfoObjects and is structured according to the star schema. This means there is a large fact table that contains the key figures for the InfoCube, as well as several dimension tables which surround it. The characteristics of the InfoCube are stored in these dimensions.  
  • The dimensions and the fact table are linked to one another using abstract identification numbers (dimension IDs) which are contained in the key part of the particular database table. As a result, the key figures of the InfoCube relate to the characteristics of the dimension. The characteristics determine the granularity at which the key figures are stored in the InfoCube.  
  • Characteristics that logically belong together are grouped together in a dimension. Dimensions are to a large extent independent of each other, and dimension tables remain small with regards to data volume. This is beneficial in terms of performance as it decouples the master data from any specific InfoCube. The master data can be used at a time by multiple InfoCubes. This InfoCube structure is optimized for data analysis.  
  • The fact table and dimension tables are both relational database tables.  
  • Characteristics refer to the master data with their attributes and text descriptions. All InfoObjects (characteristics with their master data as well as key figures) are available for all InfoCubes, unlike dimensions, which represent the specific organizational form of characteristics in one InfoCube.  
  • You can create aggregates to access data quickly. Here, the InfoCube data is stored redundantly and in an aggregated form.  
  • You can either use an InfoCube directly as an InfoProvider for analysis and reporting, or use it with other InfoProviders as the basis of a MultiProvider or InfoSet.
Fact Table

  • The fact data are stored in a highly normalized fact table.
  • In a star schema, typically the fact table is very large with small dimensional tables.
  • The fact tables has a relatively small number of columns (attributes) and a large number of rows (records) where associated dimension tables to have a large number of columns (attributes) and small number of rows.
Dimension Table

  • Dimension data are stored in dimension table.
  • Dimension table link to the fact table has a group of similar characteristics. For example, a customer dimension table may contain three characteristics: customer name, address and sales organization. There will be one customer dimension record for each unique combination of these three values.  For example, each record in customer dimension may represent a specific customer.

 

Limitations of Star Schema

 

  • In Case of star schema, Master data is stored inside the cube. So Master data cannot be reused in other cubes. 
  • Since all the tables inside the cube contains Alpha-numeric data, it degrades query performance. Because processing of numeric’s is much faster than processing of alphanumeric.
  • In case of Star schema, we are limited to only 16 dimensions.
Labels:

OLAP and OLTP

at 11:19 PM 0
Online Transaction Processing (OLTP) refers to a class of systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing.

On Line Analytical Processing (OLAP), a series of protocols used mainly for business reporting. Using OLAP, businesses can analyze data in all manner of different ways planning, simulation, data warehouse reporting, and trend analysis.

OLAP and OLTP are two absolutely different systems since they have different purpose and environments. OLAP for analytical compare to OLTP for transactional.

Difference between OLAP and OLTP

  • Target 
    OLTP is used in operative environment to get efficiency through automation of business processes. OLAP is used in informative environment, usually used by management to support in decisions making.
  • Priorities 
    As transactional system, OLTP has high availability and higher data volume.OLAP as analytical system is very simple data and has flexible data access.
  • Level of detail 
    OLTP stores data in a very high level of detail, whereas OLAP stores data in aggregation.
  • Age of data 
    OLTP data are current data. It means the data stored in OLTP with minimal history. OLAP data are historical data.
  • Database operation 
    Frequent data changes are a feature of operative system. So, in OLTP system we can read, add, change, delete or refresh data. In OLAP, we only can read the data since they are frozen after a certain point for analysis purpose.
  • Integration of data from various applications (system) 
    Since the OLTP system is for operation, it has minimal integration with other applications. In contrast to the OLTP system, OLAP need high integration of information from many application or system because it used for analysis.
  • Normalization in database 
    Due to reduction in data redundancy, normalization is very high requirement in OLTP. In OLAP, typically de-normalized with fewer tables; use of extended star schema and lower performance.

Labels:

Enterprise Resource Planning (ERP)

at 10:38 PM 0
ERP stands for Enterprise Resource Planning.  ERP is a way to integrate the data and processes of an organization into one single system. Today's ERP systems can cover a wide range of functions and integrate them into one unified database.

For example functions such as   Human Resources, Supply Chain Management, Customer Relations Management, Financials, Manufacturing functions and Warehouse Management functions were all once stand alone software applications, usually housed with their own database and network, today, they can all fit under one umbrella - the ERP system. 

There are many advantages of implementing an EPR system:

  • A totally integrated system 
  • The ability to streamline different processes and workflows
  • The ability to easily share data across various departments in an organization
  • Improved efficiency and productivity levels Better tracking and forecasting 
  • Lower costs Improved customer service 
 
 

Labels:

Introduction to SAP R/3

at 8:49 PM 0
SAP R/3 is SAP's integrated software solution for client/server and distributed open systems.

The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software.  When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web server is configured against the database server or how the Web server itself distributes the transaction and presentation logic.
SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
  • Data Management 
  • Application Logic
  • Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.

Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.
When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks.

 

Labels:
Subscribe to: Posts (Atom)
 
free counters