COPA Delta

Hi,
I am using delta enabled COPA datasource to extract copa data into BW. In our delta que(RSA7), COPA datasource is not accumulating any new or changed delta records. After a full load, I have successfully initialised delta and I can see the COPA datasource in RSA7. Can someone tell me what are the steps for a successfull delta method.
Thanks,
Rao.

Simulate Initialization of Delta Process using KEB5 transaction and read <u>following SAP provided information thoroughly before you start doing this:</u>
You can use this function to simulate the initialization of the delta procedure for a DataSource and to set the time stamp of the DataSource to a desired value. You can then plan an InfoPackages for delta updates.
Note: Only use this function in the cases described below. Inappropriate use can cause irreparable inconsistencies in your data in the SAP BW.
The simulation occurs as follows: the system sets the DataSource status to "Update successful" and gives it the time stamp you entered. A data package is also logged with the interval 0 to that time stamp. This data package sends 0 records to the SAP BW.
It makes sense to simulate the initialization of the delta procedure under the following circumstances:
You want to perform an initial test in the SAP BW using just a reduced amount of transaction data so that you can view reports with data from your CO-PA DataCube, for example, without having to replicate several million data records in the SAP BW.
In this case, set the DataSource time stamp in the Date and Time field to a date a few weeks ago.
Apart from executing this function, you also need to make the following settings in the SAP BW to simulate the initialization of the delta procedure.
a) In transaction RSADMIN in the SAP BW, enter your name in the field User for whom the debugging mode is active.
Consequently, the indicator Update data in the source system immediately in the tab page Update parameters in the InfoPackage Scheduler is then unlocked for entries.
b) Create an initialization InfoPackage and deactivate the indicator Update data in the source system immediately for this InfoPackage. In this way, you stop the system from immediately processing the request IDoc in the source system.
c) Start the initialization InfoPackage.
d) In the monitor, set the overall status for this InfoPackage to "OK" (green light).
You want to continue a delta replication from a different DataSource. This is sometimes necessary (for example, after an upgrade from R/3-Release 3.x to 4.5) if you wish to use the new option for updating multiple valuations (transfer prices). You then need a DataSource containing the valuation category (VALUTYP) as well as the currency type (CURTYPE).
In this case, simply copy the time stamp from the old DataSource by entering the name of that DataSource in the field from a different DataSource. Then continue the delta replication from the new DataSource.
Note: The initialization of the delta procedure must also be simulated in the SAP BW for the new DataSource. To do this, follow the points a) thru. d) described above.
Hope this is helps; please assign points if it does...thanks
A.Ramasubban

Similar Messages

Standard and generic COPA delta

Hello
I dont understand why many people say standard copa delta , generic copa delta.
COPA is a generated application and delta should be generic.
What do you mean when you are talking (many posts in this forum) about standard copa delta?
Thanks

Hi,
Copa extraction is generated application based on the operating concren configured in R/3 system. and same applied to delta process.
R/3 table TKEBWTS contains information about the COPA load requests that have been posted into BW. time stamp entries in this table can be maintained to reintialize the delta. this may be the reason some may call in generic or standard delta.
Dev

Error in COPA Delta

Hi,
While I was trying to change the Timestamp of a COPA Delta load to a previous load in transaction KEB5, I got the following Error Message:
"Master Record for Datasource 1_CO_PA800IDEA_AC is defined for generic delta Read
Timestamp could not be set"
What might be the possible reason for such a Error Message. Could anybody help me in this regard ???

Please get me the solution for this particular scenario.
Let us suppose that i created the datasource some 1 year back and running the deltas successfully since then.
Let us number the requests from 1,2,3... and so on since 1st jan 2009. And let us suppose each request loads
some 1000 records everyday from ECC to BI.
Now on 10th august some change was made to ECC( such as change in the User Exit ) that caused the mismatch in number of data records ( loading only 950 records ) since the change was made on 10th August. But I identified the problem on 17th august with request number 160. Let us say those request numbers are 153(10th),154(11th),155(12th),156(13th),157(14th),158(15th),159(16th),160(17th). I fixed the program in ECC on 17th and further the requests from request number 160(17th) are fetching the correct number of data records. Now I need to delete the data in BI for request numbers 153 till 159 since they are not reconciling the data of ECC with BI. Now we reload the deltas for such requests from ECC to BI. So how do I reload the deltas now in this scenario since ECC system keeps track of the last delta ie.. on 17th august(Req no 160). But how do I Load the deltas from req number 153 to 159 from ECC to BI.
One proposed solution to this problem was setting the timestamp of COPA to 10th august. But it is not advised to set the timestamp for COPA datasources using the KEB5 transaction in a production system.
Now in this scenario how do I load the request numbers 153 to 159 from ECC to Bi to fetch the correct data records for that period. Please propose a solution for this problem ASAP. U can also call me back whenever u need.
Thanks in advance

COPA delta Request

Hi,
I Updated my update rules,I want this to apply for last 5 requests.
I am extracting from COPA.
How can I extract last 5 delta's.
Do I have to set the time stamp in R/3? where and How?
I want to know the options available.
Tim

Hi Tim,
You do have the data in the PSA? If yes then you can reload from the PSA itself and it will be processed according to your new update rules. You can change the timestamps, but keep that as the very last resort as it is not a suggested practise.
Hope this helps...

Is it possible to initialise COPA deltas to multiple BIW systems?

Hi Experts
I wish to load COPA data to our BWD system in parallel with our BWP system from our Production R/3. Is this possible?
If I do an Initialisation without Data Transfer from the BWD, which timestamp will it start with for the BWD deltas? I expect that Initialisation without Data Transfer will set the starting timestamp for following deltas at the first record in R3 that satisfies my selection criteria.
Is this correct, and can it be done without upsetting the timestamp administration of the usual deltas to BWP?
Any advice would be appreciated - points forthcoming.
thanks
tony

Hello,
Yes it is possible to do that, you will see a third column in rsa7 with bw system.
Take a look at this note:
OSS Note 775568 'Two and more BW systems against one OLTP system'.
But if you execute it in parallel you can face with this:
"If delta initialization requests run from several BW systems in parallel, the time stamp pointer of the delta administration that is set at the end of the first delta initialization is overwritten by the second one. This may result in data that was already extracted in the delta initialization appearing in the subsequent delta from the first BW system."
Regards,
Jorge Diogo

COPA - delta relevant field

hi experts,
I have created COPA data source in keb0, the delta method shows as Generic delta. here i have not done any settings for delta management. but when i do Full, init & delta info packages it woks correctly.
i have some doubts... on whether delta relevant field is set automatically here. if so, how do we know which field it is.?
also,
what is the difference between generic delta and timestamp delta..
should we do any settings related to delta, so as to make delta work correctly.
regards.

can anyone explain different fields of exmethods in roosource like
V          Transparent Table or DB View
D          Fixed Domain Value
F1         Function Module (Complete Interface)
F2         Function Module (Simple Interface)
FS         Function Module (Segmented Data Transfer)
Q          Extraction Using ABAP Query
A          DataSource Append
2. is extractor RKE_BIW_GET_DATA_API automatically created, is this FM getting automatically changed when we append fields to structure of a data source?
regards.

COPA Delta Mechanism

Hi All,
Can any one explain about Delta Mechanism in COPA ie.,
How delta works in COPA,
From where the delta record are picked,
When the Delta Queue is filled,
what is Safety Delta,
What is Relignment and when we go for that, etc.....
Thanks in Advance,
Regards
Ramakrishna Kamurthy

Hi Ramakrishana,
Up to and including Plug-In Release PI2003.1, a DataSource is only
defined in the current client of the R/3 System. This means that a
DataSource can only be extracted from this client. The DataSource has a
timestamp for the delta method, and this timestamp is only valid for th
current client. This timestamp is managed by Profitability Analysis.
With Plug-In Release PI2004.1 (Release 4.0 and higher), timestamp
management was converted to a new method, called generic delta. This
method works in connection with an SAP BW system with Release 2.0 and
higher. With this method, timestamp management is no longer performed b
Profitability Analysis, but instead by the Service API (interface on th
R/3 side between Profitability Analysis and SAP BW). Exclusively in
Release 3.1I, Profitability Analysis continues to support timestamp
management.
Compared to timestamp management in Profitability Analysis, the generic
delta allows for several enhancements:
o   You can apply the delta method simultaneously using the same
     DataSource from more than one R/3 System client because a separate
     timestamp is saved for each logical system.
o   You can apply the delta method for the same R/3 System client
     simultaneously using the same DataSource from several SAP BW
     systems.
o   You can perform several initializations of the delta method with
     different selections using the same DataSource from a given SAP BW
     system for the same R/3 System client.
o   The DataSource commands the Delta Init Simulation mode. With
     timestamp management in Profitability Analysis, this mode had to be
      implemented using the Simulate Delta Method Initialization function
      (see SAP Note 408366).
For more information on the generic delta, see Delta Transfer, whereby
the steps of the Specify Generic Delta for a DataSource section are
performed automatically for Profitability Analysis when a DataSource is
created. For this, the field determining the delta is taken as the
timestamp for Profitability Analysis (TIMESTMP), and the timestamp is
stored for summarization levels and line item tables. However, in
contrast to generic DataSources, the TIMESTMP field is not generated in
the extraction structure because this is not necessary for DataSources
in Profitability Analysis. As with timestamp management in Profitabilit
Analysis, an upper limit of 30 minutes is set as the safety interval.
You find the timestamp of a DataSource for the delta method in the
current logical system either in the Header Information for the
DataSource using the IMG activity Display Detailed Information on
DataSource or using the IMG activity Check Delta Queue in the Extractor
IMG. The timestamp is shown here when you choose the selection button i
the Status column for the combination of DataSource and SAP BW system.
DataSources created after implementing PI2004.1 automatically apply the
new method. DataSources that were created in Plug-In releases prior to
PI2004.1 still continue to use timestamp management in Profitability
Analysis but can be converted to the generic delta. For this, an
additional selection option Convert to Generic Delta appears in the
selection screen of the IMG activity Create Transaction Data DataSource
when a DataSource with timestamp management in Profitability Analysis i
entered. Conversion from the generic delta to timestamp management in
Profitability Analysis is not supported.
Conversion is only possible for DataSources that are defined in the
current client of the R/3 system and for which the delta method has
already been successfully initialized or for which a delta update has
successfully been performed. This is the case once the DataSource has
the replication status Update successful. Furthermore, no realignments
should have been performed since the last delta update.
For the conversion, the timestamp for the current R/3 System client is
transferred from Profitability Analysis into the timestamp of the
generic delta. In this way, the transition is seamless, enabling you to
continue to perform delta updates after the conversion. If delta updates
are to be performed from different R/3 System clients for this
DataSource, you first need to initialize the delta method for these
clients.
The conversion must be performed separately in each R/3 System because
the timestamp information is always dependent on the current R/3 System
and is reset during the transport. If, however, a converted DataSource
is inadvertently transported into a system in which it has not yet been
converted, delta extraction will no longer work in the target system
because the timestamp information is deleted during the import into the
target system and is not converted to the timestamp information of the
generic delta. If in this instance no new delta initialization is going
to be performed in the target system for the DataSource, you can execute
program ZZUPD_ROOSGENDLM_FROM_TKEBWTS from SAP Note 776151 for the
DataSource. This program reconstructs the current time stamp information
from the information for the data packages transported thus far and
enters this time stamp information into the time stamp information for
the generic delta. Once this program has been applied, delta extraction
should work again. Normally, however, you should ensure during the
transport that the DataSource uses the same logic in the source system
and the target system.
After the conversion, the DataSource must be replicated again from the
SAP BW system.
A successful conversion is recorded in the notes on the DataSource,
which you can view in the IMG activity Display Detailed Information on
DataSource.
Since the generic delta does not offer any other log functions apart
from the timestamp information (status: Plug-In Release PI2004.1),
Profitability Analysis still logs the delta initialization requests or
delta requests. However, the information logged, in particular the
timestamps, only has a statistical character because the actual
timestamp management occurs in the generic delta. Since the delta method can be performed simultaneously for the same R/3 System client using the
generic delta from several SAP BW systems, the information logged is
stored for each logical system (in R/3) and SAP BW system. When a delta
initialization is simulated, only the timestamp of the generic delta is
set; Profitability Analysis is not called. Consequently, no information
can be logged in this case. Messages concerning a DataSource are only
saved for each logical system (in R/3). You can use the IMG activity
Display Detailed Information on DataSource to view the information
logged.
Another enhancement from Plug-In Release PI2004.1 means that you can no
longer exclusively perform full updates for DataSources of the Extractor
Checker of the Service API that have recently been created or converted
to the generic delta. The following update modes are possible:
o   F - Full update: Transfer of all requested data
o   D - Delta: Transfer of the delta since the last request
o   R - Repeat transfer of a data package
o   C - Initialization of the delta transfer
o   S - Simulation of the initialization of the delta transfer
In the case of all update modes other than F, you have to specify an SAP
BW system as the target system so that the corresponding timestamp
and/or selection information for reading the data is found. The Read
only parameter is set automatically and indicates that no timestamp
information is changed and that Profitability Analysis does not log the
request.
Update mode I (transfer of an opening balance for non-cumulative values)
is not supported by Profitability Analysis.
Assign Points if useful
Regards
Venkata Devaraj

Copa delta problem

Hi All,
I enhanced the copa DataSource by adding the new value field,then i have loaded the data
Initial Load without data transfer then run the delta update it is give ZERO records.
When i checked in COPA table level and KE24 report level in r/3 side data is there.
Is there any problem in my delta.If is there delta problem where to check and how to resolve this.
Please help me ASAP.
Thanks in advance.
prasantha

HI Sathish,
Based on in your information i have checked in KEB2 it is giving the below error.can you help wht is this
and how to resolve this error.
the below error is keb2 tcode(based on below error i have one doubt delta is geting the data into
head level data.
Subsequent time stamp information only has statistical character.
The time stamp relevant for reading data is found in the header information for the
DataSource.
For data extraction from several BW systems, the number of records read and sent that is
displayed does not have to agree with the actual number (due to Service API logic).
Delta init simulations are not listed in the overview because the CO-PA extractor
is not called in this case and it consequently does not update any log entry.
Thanks and regards,
kumar.k
Edited by: kumar reddy on Jan 20, 2009 8:10 AM

COPA delta and Full load inconsistent result

Hi ,
whn i do a Full load for COPA(datasource 1_CO_PA1159000) for one particular order number, it returned 5 line items.but when i tried to do Initialization load it returned only 4line items. One line item is missing.
Can anyone let me know what could cause this inconsistence between a full load and initialization load on the same datasource extraction.
Appreciate feedback from anyone.
Thanks.
Regards,
Maili

Hi,
Data could be picked from summarization levels or the base tables. The source of data may vary for Full/Init. Please check section 3.4 Data source for CO-PA extraction in the How to CO-PA extraction doc....
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sapportals.km.docs/library/business-intelligence/g-i/how%20to%20connect%20between%20co-pa%20and%20sap%20bw%20for%20a%20replication%20model.0x

Difference between COPA and Logistic Delta Mechanisam

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

Data source not delta capable

Hi ,
i have an issue here my copa datasource is not delta capable, how will I make it delta capable.I dont want to use an ODS here.please this is an urgent issue
regards
rak

Hi Rakshita,
Check here.......
COPA Delta
Simple Question on Delta Info Package
dummy delta/pseudo delta
Psedo Delta
Delta load for flat file
Regards,
Vijay.

COPA full load monthly process chain

hi guys,
our COPA delta does not work. So we need to automate monhly COPA data extraction. is there any FM that can show the monthly fiscal year peiord i.e 01 = july ?
lets say: this month is march 2010, so my Infiopackage Period/year field will automatically take 09.2009
I need FM that can generates 09.2009

You can use DATE_TO_PERIOD_CONVERT. Pass date and fiscal year variant as input.

Roll-up not possible - Help

Hi,
COPA delta load is successfully loaded in to the data target, some how i am getting the following error message and Roll up failed for the last two times.
Roll-up not possible; no filled aggregates available
Issue happend in Production, Could you please help me, to complete the roll up for the last two requests, which is loaded without any error into the target.
Thank You
Senthil

Hi Raj,
Sorry, There is an aggregate available for the data target and half a million records loaded to the target in the past two requests.
Anyway thanks.

Orchestration Dependeny Queue not being updated

Hello,
We want to increase the consumer count for the orchestration dependency queue from 16 to 30. We have made the changes to the weblogic-ejb-jar.xml updated the oms.ear. But unfortunately, the consumer count is not being updated. Can someone please help me urgently !!!!!!!!!!!!!!
Regards,
RavRao

Hi,
Did you check in KE24 and R/3 data is there or no?
Next you can check your Delta Settings.
Fyi... there is no Delta Queue in Copa.
Follow this issue:
copa delta problem
Let us know, if it works.
~AK

Scenarion of Delta Load problem in COPA Extraction

Please get me the solution for this particular scenario.
Let us suppose that i created the datasource some 1 year back and running the deltas successfully since then.
Let us number the requests from 1,2,3... and so on since 1st jan 2009. And let us suppose each request loads
some 1000 records everyday from ECC to BI.
Now on 10th august some change was made to ECC( such as change in the User Exit ) that caused the mismatch in number of data records ( loading only 950 records ) since the change was made on 10th August. But I identified the problem on 17th august with request number 160. Let us say those request numbers are 153(10th),154(11th),155(12th),156(13th),157(14th),158(15th),159(16th),160(17th). I fixed the program in ECC on 17th and further the requests from request number 160(17th) are fetching the correct number of data records. Now I need to delete the data in BI for request numbers 153 till 159 since they are not reconciling the data of ECC with BI. Now we reload the deltas for such requests from ECC to BI. So how do I reload the deltas now in this scenario since ECC system keeps track of the last delta ie.. on 17th august(Req no 160). But how do I Load the deltas from req number 153 to 159 from ECC to BI.
One proposed solution to this problem was setting the timestamp of COPA to 10th august. But it is not advised to set the timestamp for COPA datasources using the KEB5 transaction in a production system.
Now in this scenario how do I load the request numbers 153 to 159 from ECC to Bi to fetch the correct data records for that period. Please propose a solution for this problem ASAP. U can also call me back whenever u need.
Thanks in advance

As stated in a previous post...
How you choose to do this can be summed up by the question: Does the target for this data have cumulative or non-cumulative Key Figures?
If you are doing an overwrite to the Key Figures, you could just execute a Full Repair InfoPackage that extracts the data for the days that you found inconsistencies instead of attempting to change the timestamp in KEB5 on the source ECC environment.
However, if you're target has cumulative Key Figures you're left with very few options (a couple of them are time-consuming):
1) Changing the timestamp in KEB5, if your plug-in is PI 2003.1 or older. Newer versions of the plug-in do not allow the changing of the timestamp as was pointed out by Ferruccio earlier.
2) Deleting the keys in the target InfoProvider for those records that you extract in a Full Repair extract.
3) Delete all data in BW for COPA and start from the beginning. This may be your best bet for cleaning up the issues in this scenario.

COPA Delta

Similar Messages

Maybe you are looking for