You are on page 1of 14

Introduction to Database:

The main purpose of database is to store data and this data can be used for late
r purpose (analysis). Any big Enterprise we consider, they always store their bu
siness data into database. So that they use this data for analyzing their busine
ss.
Any database like (Oracle , Ms Access, SQL Server, Sybase
orm of a structure called TABLE .

) always store data in f

Table: Table is set of ROWS and COLUMNS


Each Row in a table is referred as Record
Primary Key:
It is a column in a database table which can maintain uniqueness for all the rec
ords in the table. It can be used to uniquely identify each and every record in
the table
In above example: In the Customer Table the

Customer Number

is the Primary Key.

Every table must have a Primary Key (In Exceptional Cases we can have a table wi
thout a primary)
we have 2 types of columns in a table.
1) Key Column
2) Non - Key Column
Key Column:- Column which is a part of Primary Key.
Non - Key Column:- Column which is not a part of Primary Key.
All Non - Key Columns act as Attributes or Properties for Key Column.

Composite Key:When 2 or more columns act as the primary key in a table.


In above Example, Bill No & Sno together act as the primary key in the database
table, So this is referred as Composite Key.
It is the limitation of the database that we can only have a maximum of 16 colum
ns act as the composite key.
De-Normalized Table:
When we store all the data in a single big table, and we find the data being sto
red redundently/Duplicatly,we call it as De-Normalized Table.
Limitations of De-Normalized Table:
1) Wasting Database Space
2) Complexity will be high.
Normalized Table:
Instead of storing the data in a single table, we split the data into multiple
smaller tables connected with Primary key - Foreign Key where there is no data r
edundency - Normalized tables.
Normalization:

The process of converting De-normalized tables into normalized tables by using


normalization forms.
Foreign Key:
When a Primary key of one table takes part in the other table we call it as For
eign Key.
Software Engineering process:
Whenever we develop a software we follow the SDLC cycle . SDLC contains 5 steps:
1)
Requirement Gathering
2)
Design
3)
Develop
4)
Testing
5)
Deploy
6)
Maintenance & Support
Requirement Gathering:
At this phase we gather the requirements from the end users and understand the b
usiness process.
Design:
As we know every application will have the Front End (Interface Screens) & Back
end (Database). As part of this phase we will have to design the Front end scree
ns and Design the Database (Database design is referred in the Next Section)
Develop
At this phase by using some Programming Language & some database we develop the
software.
Testing
At this phase we test the software, weather the software is working as per the u
ser requirements or not.
Deploy
Once the Software is tedted perfectly we deploy the software at the client locat
ion. So that the business can start using the software.
Maintenance & Support:
Once the software is deployed, we will have to provide the Maintenance & Suppor
t for any issues what the client/ Business faces.
Business: - Business / Business Process ....?
- Set of Business activities / Transactions ...?(Selling & Buying, Sales
Order,
Delivery, Billing............................)
- When 2 or more entities or parties or objects interact
with each
other to perform an event.
- Entity...?Any Object which can perform
work by itself or
which we can
use it to perform some work (Noun).
- Product id,name,qty,price,cno,cname,date,time,branch,................ (Transac
tion Data)
- Detailed information of an entity - Master data
Applications & Types:
Programming Language is used to design the frontend (i.e, Interface screens &Ap
plication logic)

Database is used to design the backend to store data

Operating system to run the application

Concept is the reason for what the application is designed for


We have 2 types of applications:

1)
2)

OLTP
OLAP

OLTP [Online Transaction Process]:


OLTP applications are mainly to record all the transactions of the business
OLAP[Online Analytical Processing]:
OLAP application takes in all the transaction data from different OLTP applicati
ons and provide the reports for analysis.
DATABASE DESIGN:
Database Design in OLTP:

ER Model [Entity Relationship Model] is used to design the database for


OLTP applications.

Database designed with ER Model is 2 Dimensional & it is completely norm


alized.
Database design in OLAP:
In OLAP applications we store data in MDM[Multi Dimensional Format] by using th
e following models:
1)
Start Schema or Traditional Star schema
2)
Extended Start schema or BW Star schema or BI star schema
3)
Snow Flake
4)
Hybrid
Star Schema:
Star schema is an MDM ( Multi Dimensional Model ) which contains Fact table / Tr
ansaction data Table at the center, surrounded by Dimension tables / Master Data
Tables existing within the Cube.
These Dimension Tables / Master Data Tables are linked to the Fact table / Tran
saction data table with Primary Key
Foreign Key Relationship.
Difference between ER Model & Star Schema
ER Model
Star Schema
2 Dimensional
Multi Dimensional
Normalized
De-Normalized
Limitations or Dis-advantages of Star Schema:
Master Data is not Reused:
In Case of star schema, Master data is stored inside the cube. So Master data ca
nnot be reused in other cubes.
Degraded performance:
Since all the tables inside the cube contains Alpha-numeric data, it degrades qu
ery performance. Because processing of numeric s is much faster than processing of
Alpha-numeric s
Limited Analysis:
In case of Star schema, we are limited to only 16 dimensions.
Extended Star Schema:

In case of extended star schema, we will have Fact table connected to the Dimens
ion 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).
Master data & SID tables:
Every characteristic Info Object will have its own SID table to convert the Alph
a-Numeric value to a Numeric value. But the Key figure Info Object will not SID
table because the keyfigure value is a numeric.
When ever we insert a value into the characteristic Info Object, system will gen
erate an SID number in the SID table which is a numeric value
Each Characteristic can have its own master data tables (ATTR,TEXT,HIER)
Attribute Table is used to store all the attribute or properties data
Text table is used to store the description in multiple languages
Hier table is used to store the Parent-Child data.
As you can observe the in above picture, Material Attribute table holds all the
attribute information like (Material Group, Material Price), Material Text table
Holds Description in multiple languages.
So when we load master data, SID s are generated in the SID table.
Fact Table & Dimension Tables:
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.


When we load Transaction data into Info Cube, System generates DIM ID based on t
he SID s and uses the Dim ID s in the Fact Table.
We can load the Transaction data without master data, In this case system first
inserts the Master data into Master data tables, then generates the SID ID s and b
ased on these SID ID d it generates DIM ID s and uses the DIM ID in the fact table.
Standards to Design Info Cube:
If we have 2 characteristics which are related as 1:1 or 1:M, we should assign
them to same Dimension table
If we have 2 characteristics which are related as M:M, we should assign them t
o different Dimension tables
Modeling of Characteristics:

If we model the Characteristic as an attribute of another Characteristic,


It gives Present truth because the property of master data is overwrite.

If we model the Characteristic as a separate Characteristic and assign t


he Characteristic to an Dimension table, It gives Fact.
Modeling of Keyfigures:

If we Model the Keyfigure as an attribute of another Characteristic, It


gives present truth because the property of master data is overwrite.


If we model the keyfigure inside the Fact table, it gives fact because t
he property of Info cube is additive.
SAP BW Architecture:
Points to be Noted regarding SAP BW:
In SAP BW we work with objects like (Info Cube, ODS, Info Source, data Source,
Info Package, Update Rules, Transfer rules, BEx queries .)
In SAP BW we will have 2 types of Objects:
1)
Standard or Business Content Objects:

These are the readymade Objects delivered by SAP.

All the standarad objects will have their technical name starting with t
he number 0.

All Business content objects will be in delivered version.


2)
Customized Objects:

These are the objects what we create as per our requirements.


Every Object in SAP BW will have the Technical name and Description
Once the Object is created we cannot change the technical name but we can change
the description
Info Area:
Info Area is like Folder in Windows.
It is used to organize the objects in SAP BW.
Info Object Catalogs:
Similar to Info Area, Info Object catalog is used to organize the Info Objects b
ased on their type.
So we will have Info objects catalogs of type Characteristics & Key figures.
Info Objects:
It is the Basic unit or object in SAP BW used to create any structures in SAP BW
(Info Cube, ODS, Info Source ..)
Each field in the source system is referred as Info Object in SAP BW.
We have 5 types of Info Objects:
1)
Characteristic
All Business subjects what we analyze
Ex:- Customer Number, Material Group, Company Code, Employee Group
2)
Key figure
All Quantitative measures used to analyze the subjects
Ex:-Price, Revenue, Qty, Number of employees, VAT %
3)
Time Characteristic
Characteristics which maintain Time factor information
We cannot create the Time Characteristics
Ex:- 0CALDAY, 0CALMONTH,0CALYEAR
4)
Unit Characteristic
Characteristics which can be used to hold Currencies and units.
Like 0CURRENCY, OUNIT
We always have to create unit Characteristic by taking 0CURRENCY OR 0UNIT as the
reference.
5)
Technical Characteristic
Characteristics which hold technical details like Request number, datapacket no
, Record Number.
Ex:- 0REQUID .
Info Cubes:
Info Cube is an Multi-Dimensional Object which is used to store the transaction
data.
Info Cube contains Fact Table & Dimension Table
Info Cube is referred as datatarget because it holds the data physically in it.
Info cube is referred as Info Provider because we can do reporting on Info cube
The property of Info Cube is additive.
ODS:

ODS stands for Operational data Store


It is an 2 Dimensional object
The property of ODS is overwrite
We use ODS for staging the data and also detailed reporting
Info Source:
Info Source defines communication structure
Communication structure is a group of Info objects which are required to commun
icate the fields coming from the source system
We have 2 types of Info Sources:
Direct update
Direct Update Info Source is used to load the master data objects
Flexible Update
Flexible update is used to load the transcation data to any data targets like(
Info Cube, ODS)
Data Source:
Data Source defines Transfer Structure
Transfer Structure indicates what fields and in what sequence are they being tr
ansferred from the source sytem
We have 4 types of datasource:
1)
Attr: used to load master data attr
2)
Text: Used to load text data
3)
Hier: used to load hierarchy data
4)
Transcation data: used tgo load transaction data to Info cube or ODS
Source System:
Source system Connection
We use Source system connection to connect different OLTP applications to SAP BW
.
We have different adapters / connectors available:
SAP Connection Manual
SAP Connection Automatic
Both these connections are used to connect any SAP application to SAP BW by RFC
connections.
Ex:- we use this connection to connect SAP R/3, SAP APO,SAP CRM to SAP BW
My Self Connection:
We use this connector to connect SAP BW to the Same SAP BW server.
We generally use this to load data from one Info Cube to another Info Cube.
Falt file Interface:
We use this adaptor to load data from flat files (It only supports ASCII or CSV
files)
DB connect
We use this connector to connect any SAP certified database to SAP BW.(Certfied
databases like Oracle, SQL Server, DB2 )
External Systems with BAPI
We use this connector to connect any 3rd party ETL tools like Informatics or Dat
a Stage.
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 info package depends on the properties of th
e DataSouce.
Business Explorer[BEx]:

We use BEx components to design all the reports in SAP BW.


RSA1: [Administrator workbench]:
- Modeling
We create the BW objects like (Info Area, Info Objects, Info Cube, Info Source,
ODS, Multi Provider, Info Set)
We do perform procedures to load data into these objects.
- Monitoring
We monitor all the BW Objects
we do even monitor the Loading Process
- Reporting Agent
To run / schedule the BEx reports in the background.
- Transport Connection
We use tab to transport the objects from one BW server to another
- Documents
BDS(Business Document Services), used to maintain documents within SAP BW
- Business Content
All the BC objects will be in Delivered version, But if we need to use the obj
ects they sholud be available in Active version, So in the Business Content Tab
- we install the Business content objects ( Creating a Copy of the Deliverd vers
ion objects into Active Version)
- Translation:
We use this tab to translate the objects from one Language to another Language
When we translate an object only Description of an Object will change but not
the Technical Name
- Meta Data:
Meta data is nothing but data about Data
Meta Data is Maintained in Meta Data Repository maintained by Meta Data Manage
r
How to load data from Flat file to Info Cube:
Case Study

Pre-requistes:
Source System connection Between Flat file and SAP BW.
Steps:
1) Design the Info Cube.
2) Implement the Design in SAP BW
2.1) Create the Info Area
2.2) Create the Info Object Catalogs
2.3) Create the Info Objects
2.4) Create the Info Cube
2.5) Loading the Info Cube from Flat file.
2.5.1) Created the Application Component
2.5.2) Create the Info Source
2.5.3) Assign the Data Source to Info Source
2.5.4) Activate the Transfer rules
2.5.5) Create the Update Rules
2.5.6) Create the Info Package and schedule the load
Deleting Data in Info Cube:

1)
2)
3)

Deleting data based on the request


Delete Data
Selective deletion

ETL Process:
When we start the Infopackage SAP BW triggers the loading process with the below
steps:
1.
SAP BW sends a request to the source system
2.
It gets confirmation OK from the source system
3.
Then SAP BW send the data request
4.
Based on the Data Selections, the data is extraction from the source syste
m
5.
The same data is transferred to SAP BW (Transfer methods PSA & IDOC)
6.
Then the data is loaded into the Data target through Transfer rules & upda
te rules.
Transfer Methods [PSA & IDOC]:
PSA:
Presistant Staging Area
It is a 2 Dimensional Table.
Data is transferred directly to PSA table and Information is transferred throu
gh Info IDoc s
When we activate the transfer rule with PSA as the Transfer method, the system
will automatically create the PSA table.
Every Data Source will have its own PSA table.
We can find the PSA table of a Data Source by using the T-code SE11
Structure of the PSA Table:- Transfer structure + 4 technical fields (Request
No, Data packet ID, Record No, Partition No).
PSA holds Replica of data coming from Source.
We can do editing in PSA
Error handling is possible with PSA
We can reload the records from PSA to the Data target by using - Reconstructio
n
We can delete data in PSA (Generally we delete data in PSA which is older than
7 days)
Allowing Special Characters into SAP BW - RSKC [76].
RSALLOWEDCHAR
IDOC:
Intermediate Document
It is the Standard used to transfer the data in SAP environment.
Data is transferred through Data Idoc's and Information is transferred through
Info IDoc's.
IDoc Maintenance

Infopackage Update Modes:


Full Update:
It extracts all the records from the Source system with respective to data Selec
tions.
Initialize Delta Update:
It is similar to Full update but enables us to run the Delta updates once the in
it is successful
Delta Update:
It only extracts the data what is newly created or modified since the last updat
e.
Note:-

With whatever data selections we run the init update, delta update also should
run with the same data selection
In the Infopackage we can see the Delta update option only if the data source s
upports delta.
Transfer Rules:
By using transfer rules, we can do mapping between Transfer structure & communic
ation structure.
Types of transfer rules:
1)
Direct Mapping: We use option to map the value from a source field in the
Transfer structure to the target Info object in the communication structure.
2)
Constant: We use option to specify a fixed/constant value for the records
loaded through transfer rules.
3)
Formula: we use option to implement a formula by using Formula editor.
4)
Routine [Transfer Routine]: when use this option to transform the data by
using ABAP/4 code. When implementing a transfer routine we must refer to the fie
lds by using the structure name as TRAN_STRUCTURE i.e, [TRAN_STRUCTURE-/BIC/PRICE]
. When debugging the name of the transfer routine will be formed as COMPUTE_FIEL
DNAME.
Update Rules:
Update rules specify the mapping between Source object and Target object. We use
update rules to perform all kind of Transformations. Update rules update the da
ta into the data target.
Types of Update rules:
Keyfigure:
Source Keyfigure or Direct Mapping
Formula: we use option to implement a formula by using Formula editor.
Routine or Update routine: when use this option to transform the value of a ke
y figure by using ABAP/4 code. When implementing an update routine we must refer
to the fields by using the structure name as COMM_STRUCTURE i.e, [COMM_STRUCTURE/BIC/PRICE]. When debugging the name of the update routine will be formed as ROU
TINE_001.
Routine with Unit: when use this option to transform the value of a key figure
and also value of the unit characteristic associated with it by using ABAP/4 co
de
Characteristic:
Source char or Direct Mapping
Constant
Master Data Attribute of: we use this option to feed value by doing lookup to
the master data tables.
Formula
Routine
Initial Value: Populates no value (by default NULL)
Time Characteristics:
Source char or Direct Mapping (Automatic Time Conversion)
Constant
Master Data Attribute of: we use this option to feed value by doing lookup to t
he master data tables.
Formula Routine
Initial Value: Populates no value (by default NULL)
Time Distribution: we use the option to distribution values from Higher level
Time characteristics to Lower level Time characteristics.
Start Routine:
Start routine is executed before individual update rules.
Start routine is executed packet by packet.

So we use start routine to perform or implement any kind of logic which is supp
osed to get executed before update rules.
When implementing start routine we use an INTERNAL TABLE
DATA_PACKAGE.
Sample code:
LOOP AT DATA_PACKAGE.
IF DATA_PACKAGE-/BIC/ZCREG <> AMR .
DELETE DATA_PACKAGE.
ENDIF.
ENDLOOP.
Return Table:
We use this option when we want to split one record from the source to multiple
records in the data target.
Difference between Update rules & Transfer rules:
Transfer Rules
Update Rules
Transfer Rules will just Transfer the data
Update Rules will update the data into data target
Transfer rules are specific to source system
Update rules are specific to Data Target.
Different Data flow Designs:
One InfoSource to Multiple Data Target Yes
Multiple InfoSource to Single Data Target
Yes
One InfoSource can be assigned with multiple DataSources
yes
Same DataSource cannot be assigned to multiple InfoSources
Master Data:
Detailed Information about any Entity is called as Master Data.
Ex:- Detailed information about a customer Customer Master data
In SAP BW, we have 3 types of Master data:
ATTR
TEXT
HIER
ATTR: is used store all the attributes / properties of an entity.
Text: is used to store all the descriptions in different languages
HIER: is used to store parent-child data
How to load Master data ATTR & TEXT from Flatfile
Steps:
Create the Application component
Create the Info Source of type Direct Update
Assign the DataSource to InfoSource
Activate the Transfer rules for ATTR & Text DataSources
Create the Info Packages and schedule the loads
Note:- we need to create one Infopackage for ATTR DataSource and one for Text Da
taSource
Hierarchies:
When do we go for hierarchies:
When the Characteristics are related as 1:M and in the Reporting if we need to d
isplay the values by using hierarchies (Tree like display)
Types of Hierarchies:
- Hierarchy Not Time dependent
- Hierarchy Structure Dependent on Time

- Entire Hierarchy Dependent on Time


- How to load Hierarchy from the flat file?
Steps:
Create the Info Source
Assign the Data Source
Create the file as per the Hierarchy
Create the Infopackage and schedule the load

Reference & Template:


Reference
If we have an info object
as the reference, all the
change any properties to
t it refers to the data /
Template

'A', when we create the Info object 'B' by taking 'A'


properties of 'A' are copied towards 'B' and we cannot
'B', We cannot load any data to the info object 'B' bu
data dictionary tables of main info object 'A'.

If we have an info object 'A', when we create the Info object 'C' by taking 'A'
as the Template, all the properties of 'A' are copied towards 'C' and we can ch
ange the properties of 'C', we can load the seperate master data for the info ob
ject 'C'.
When do we go with reference:
When we want to create the new master data object which is supposed to hold the
data which is already a sub set of some other Master data objects, we go for cre
ating the Master data object with reference.
Reference Example:- Sold to Party , Ship to Party, Bill to Party, Payer are created with reference
to Customer.
- Sende
r Cost Center and Reciever Cost Center are created with refer
ence to Cost Center.
Converting Master Data as Data Target:
ODS
ODS: (Operational Data Store)
ODS is also an Info Provider like Info Cube.
ODS is a 2 dimensional.
the Property of ODS is : Overwrite.
We perfer ODS to do detailed level of reporting
we also use ODS for Staging.
ODS CONTAINS 3 TABLES:New Data Table
Active Data Table
Change Log
1. Active Data Table:
/BIC,0/AXXXXXX00
Structure: - All Key Fields [Primary Key]+ All data Fields + Recordmode
Reporting
Active data table will be the Source when we schedule Init / Full update for
Data Mart
2. New data Table:
/BIC,0/AXXXXXX40
Structure: - Technical Keys [loading Request No + Data packet no + Record N
o] (Primary Key) + All Key Fields + All data Fields + Recordmode
First table where the data is staged in ODS.

3. Change Log Table:


- /BIC/B000*
- Structure: - Technical Keys [Activation Request No + Data packet no + Record
No + Partin no] (Primary Key) + All Key Fields + All data Fields + Recordmode
- Registry of all the changes in the ODS.
- Change log table will be the Source when we schedule Delta update for Data
Mart
Points to be noted:
when we design a report on the ODS, it fetches data from the active data table
.
When we load data from ODS to info cube with "Full update / Initialize delta u
pdate", it takes the data from Actve data table of the ODS.
When we load data from ODS to info cube with "Delta update", it takes the data
from Change log table of the ODS.
Note : Max no. of Key fields : 16
We cannot use keyfigures in the Key fields.
How does the overwrite functionality works by using thes tables:
when we load data into ODS, initially the data is loaded into New Data table. By
using "Set quality status to OK" we convert the request status from yellow to g
reen. once the request status is green we "Activate the DATA in ODS" - It delets
the records in the new Data table and then moves the records from new Data tabl
e to Activa data table by overwriting the records if it finds the records with t
he same key field combination and maintains respective entries in change log tab
le.
How to create the ODS?
How to load data into ODS from Flat file ?
Pre-requisites:
1) Flat file source system connection should be ready
2) Flat file should be ready
Steps:1.
Create the Application Component
2.
Create the Info Source - [ flexible update ].
3.
Assign the Data Source to Info Source
4.
Connect ODS to the Info Source with Update rules.
5.
Create the info package and run the load.
Deleting Data
1) Delete Data
- It deletes all the contents in all the three t
ables.
2) Deleting based on a Request
- It deltes data in all the tables .
- When we delete a request in a ODS it deletes the selected request and all the
requests above it.
3) Selective Deletion
- When we want to delete the records in the ODS based on the values of a particu
lar Characteristic.
- It Deletes data only in Active
Data Table.
4) Delete Change log Data
- It deletes data only in the change log table based on the request (no of days
, before particular date).
Condensing / Donot condense into Single reguest
- When we are activating multiple request in a ODS at a time, if
we select the option "DO NOT CONDENSE THE REQUEST INTO WHEN ACTVATION TAKES PLA
CE", each request will have its own Activaion request. if you dont select the op
tion "DO NOT CONDENSE THE REQUEST INTO WHEN ACTVATION TAKES PLACE", all the requ

est will have the same activation request. So if we delete a particular request,
it deletes all the other request in the ODS with the same Activation reuest.
Activation Serially / Parallel
Data Marts:
Case 1:
Loading Data from ODS to Info Cube
Pre-requisites:
1) Myself Source System Connection
2) Application Component - Data Mart (DM)
Steps:
1) Identify the Source object and the Target Object.
SO - yo_sd01
TO - yc_dm1
2) Check whether the Source Object has got the "EXPORT GENERATE DATA SOURCE". If
it is not there we have to explicitly generate the "EXPORT GENERATE DATA SOURCE
".
SO - yo_sd01 - EGDS - 8yo_sd01
3) Connect the Source object to the Target Object with the help of Update rules.
4) Find the Info source which gets created automatically when we build the updat
e rules and this Info source is also assigned with Myself source system connecti
on under the Application Component (Data Marts).
5) Create the Info Package and Schedule the load.
Case 2:
Loading Data from Info cube to Info Cube
Pre-requisites:
1) Myself Source System Connection
2) Application Component - Data Mart (DM)
Steps:
1) Identify the Source object and the Target Object.
SO - yc_dm1
TO - yc_dm2
2) Check whether the Source Object has got the "EXPORT GENERATE DATA SOURCE". If
it is not there we have to explicitly generate the "EXPORT GENERATE DATA SOURCE
".
3) Connect the Source object to the Target Object with the help of Update rules.
4) Find the Info source which gets created automatically when we build the updat
e rules and this Info source is also assigned with Myself source system connecti
on under the Application Component (Data Marts).
5) Create the Info Package and Schedule the load.
- How to correct the Delta Load ?
- Different Update Mechanisims to different Data Targets?
In case of ODS : we cannot do a "Full update" after doing "INIT" or "DELTA" upda
tes because this will reset the Delta Management of the ODS. So to overcome with

this problem we use "Repair Full Request".


In case of ODS : When we already have the full updates done to the ODS, The ODS
will Not accept to load data with "INIT and DELTA updates" . So by using the Fun
ction Module - "RSSM_REQUEST_REPAIR_FULL_FLAG" we convert all the request with "
FULL UPDATE" in the ODS to "REPAIR FULL REQUEST".

You might also like