on 10-06-2007 3:48 PM
Dear All,
May i knw the difference between the COPA and Logistic Delta Mechanisam h it works.
In our Production system, when ever a logistic delta fails we take action and repeat it then it will featch the delta on the same day,
where as in COPA delta, when it fails we take action and when we repeat it will fetch zero records and in the next day the delta will come.
What is the difference in both
What exactly is happeing in R/3 for these both delta mechanisam.
Thanks in advance,
K Janardhan Kumar
Hi Janardhan,
I hope with all these explanations you would have got a good idea about COPA Vs LO.
Just wanted to adda point, for COPA as u mentioned when it fails we take action and when we repeat it will fetch zero records and in the next day the delta will come.
The reason for this is every COPA Datasource extraction puts a lock on CESVB structure and sometimes fails to remove that lock once the structure is copied and used.
So the next COPA data source extraction fails in BW giving an error Error Due to lock in Source System.
This problem is due to a looping problem in Function Module (in BW 3.x) RKE_BIW_DATA_TIMESTMP_GET where in it tries to try 2 times to set a lock on CESVB and if CESVB is locked it fails the delta in BW.
Using Transaction KEB2 in SAP R/3 you can see how many times this happened for your datasource.
The good thing about all this error is that extractor is not called hence you dont loose delta.
And next day when system deletes the lock (hopefully), you get your delta records back.
How it clears.
Thanks
CK
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Guru,
I will explain about delta extraction with timestamp in general with an example:
timestamp is generally in yyyymmddhhmmss format
let's assume delta runs daily at 09:00 morning.Last delta ran at 09.00 yestreday.And today when delta runs it picks the data ranges between
09:01 (yesterday's) to 09:00(today).
if one record is posted at 09:10 today,then it will not be picked by today's delta(coz' it is posted after 09:00)
Hope now you are clear about timestamp.........
In case of COPA ,we are using timestamp as a tool to identify delta
now COPA delta mechanism has one more concept "saftey delta ":let's put a question to ourselves ,why we should use this;
SAP answer is "The reason for the selection of the safety delta is that there are possible level differences of the clocks on different application servers. If the delta is selected on a level that is too low, it is possible that records
are not taken into account when uploading into the BW."
'Safety delta' usually will be set to 30 mins during the initialization /delta upload(default).
This means that only records that are already half an hour old at the starting point of the upload are loaded into BW
Ex:
we have made following settings for copa
timestamp=09:00
safety delta=30 mins
now when you run daily delta,it picks data ranges between (current timestamp-safety delta) i.e 08:30 instead of 09:00(yesterday's)
to 09:00 today
check this oss notes 502380 for better understanding on COPA delta mechanism
Symptom
There is some confusion about how the delta process works with CO-PA DataSources and the old logic (time stamp administration in the Profitability Analysis) or there are data inconsistencies between the BW and OLTP systems.
As of PlugIn Release PI2004.1 (Release 4.0 and higher), a new logic (generic delta) is used during the delta process. Old DataSources can be converted to the new logic. New DataSources automatically use the new logic. With the new logic, the time stamp administration is located in the Service-API and no longer in the Profitability Analysis.
This note refers only to DataSources with the old logic.
Reason and Prerequisites
Administration of the delta process for CO-PA DataSources partly occurs in the OLTP system. In particular, the time up to which the data was already extracted is stored in the DataSource control tables (old logic).
Solution
Since the control tables for the delta process for the extractor are managed in the OLTP, the following restrictions apply:
1. There should only ever be one valid initialization package for a DataSource. Data inconsistencies may occur between BW and OLTP if, for example, you schedule an Init for various selections for the same DataSource and data is posted between the individual initializations to the Profitability Analysis. The reason for this is that each time the time stamp for the DataSource is initialized in the OLTP, the current value (minus the safety delta, see note 392876) is reset. Records from a previous selection are therefore no longer selected with the next delta upload if they were posted before the last initialization run with another selection.
2. Initialization can always only be carried out from one system. Inconsistencies may occur if the same DataSource is used from several BW systems and if data is posted between the initialization runs. This is because the time stamp for the replication status is reset for every initialization or delta upload in the OLTP. Records may therefore be missing in the system that was first updated if updates were made in the result area before the Init or delta run. In the system that was the second one to be updated, the records that were loaded into the first system are missing for a delta upload.
In the case of large datasets, you should therefore perform initialization either using several DataSources or with a combination of one or more full uploads and an init upload. Full uploads without errors are possible for closed periods/fiscal years because no additional changes are made to this data. Initialization should be performed, for example, from the current fiscal year. The full updates for the closed periods can also be split in time. If required, more characteristics, for example, the action type, can also be used for the selection. For information on the period selection, see note 425844
Hope you are clear now!!!!!!!!!
Cheers
Swapna.G
Message was edited by:
swapna gollakota
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi ,
In LO delta methods are broadly three types:
Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred by means of an updating collective run into the BW delta queue.
V3 (Non-Serialzed) Update: With this update mode, the extraction data for the application considered is written into the update tables. They are kept there as long as the data is selected through an updating collective run and are processed. The data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
so,what we have understood in lo extarction , whenever a record gets updated in R/3 the delta queue is also updated. A job runs and periodically pushes the records from Delta queue to the extraction queue. Then is available to the extractor for Delta.
In Lo the delta is identified by 0recordmode
The field 0RECORDMODE determines whether the records are added(in casecube)to or overwritten. It determines how a record is updated in the delta process: A blank character signifies an after image, X a before image, D deletes the record and R means a reverse image.
However in COpa the delta is based on timestamp,and here we have concept of safety delta:'Safety delta' is used for a half an hour during the initialization and delta upload. This means that only records that are already a half an hour old at the starting point of the upload are loaded into BW
means after the init load...we got to wait for at least 30 mins.... to allow the system to set up Time stamps.
so....as soon as the delta records comes, they were loaded in to the BW based on the Time stamp( the same order based on the time, they were created)..
If any delta load fails.... we need to do Repeat delta ....before that we need to manually re-set the time stamp to before the failed load, so that it will catch those records also and load in to BW...
Hope you have got clear idea!!!!!!!
Cheers,
Swapna.G
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't think there is any difference in that aspect, both COPA and Logistics extractors, delta gets extracted from RSA7, and when there is successful delta the rsa7 will be empty. But how the delta gets to rsa7 is different in both extractors, in COPA the extractor sends the delta as soon as the document gets changed or new records gets created, there is some safety time the data gets to rsa7 directly, but in LO as soon as the document gets changed or new one is created, there is in background called V3 job which gets the record and push it to lbwq and you have to run the job control in lbwe to move the records to rsa7.
Again regardless what the logic behind is, the load will get the data directly from rsa7 which doesn't make any difference either for copa or logistics.
thanks.
Wond
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.