Delta load question

Hello All,
Could you please help by providing a high level step by step solution for the following:
Currently we have an ODS that is being filled by a selective delta load(2LIS_04_S621) by using production order ranges. We have loaded this data for the last 5 years and the number ranges are plant specific.
We now have the need to load all production orders for all plants which span over several number ranges. Please advise.
Thanks

Hello,
What about in R/3, did the extractor has data for all the plants , if yes then you can perform the repair full request excluding the selection previously given ( for the selective filed you can write a routine to exclude the current seletcion ).Might be this can help.
Thanks,

Similar Messages

Question for delta loading

Hi, Gurus,
I load data from a flat file into one infocube with delta loading option, and in the related datasource, i chose 'additive delta' option.
However after delta initial and delta update, when I checked cube content, I found that there are 2 records with the same characteristic value (just like duplicated key), and my expectation is to sum key figure with the same characteristic. Who can help me on that?
BTW: when I check delta queue, why there is not any queue?

Ls,
Please do not post same question in both forums - please refer the answers in the other post in the other forum.
Arun

Delta loading basic question

Hi guys,
since I'm learning and testing the SAP Netweaver BI 7.0 I'm loading with full upload to the targets (DSO, InfoCube).
Now I have read about loading with delta load.
As I have undetstood the delta load enables me to load only new data to the targets.
Now I'm wondering that in some forum threads people are writing that more Infopackages are neccessary if you want to load with delta.
Is it correct that more Infopackages are neccessary for delta load and why?
Is a How-to within SDN available? I couldn't find anything.
Thanks!

Hi,
To do the Delta one must load the INIT.
You can do inti in two ways
1. INIT with Datatransfer
2. INIT Without Datatransfer
The following are the general steps to load Delta
1. One IP for Init without datatransfer
2. One IP for Full Load
3. Another IP for Delta Load
You can also do
1. Create an Infopackage to do the INIT with Datatransfer(This is equivalent to INIT without Datatransfer+FULL load)
2. create another infopackage & make it delta in the update mode
Hope it is clear & helpful
Regards,
Pavan

Question for delta loading, why can not update existing record in cube

Hi, Gurus,
I load data from a flat file into one infocube with delta loading option, and in the related datasource, i chose 'additive delta' option.
However after delta initial and delta update, when I checked cube content, I found that there are 2 records with the same characteristic value (just like duplicated key), and my expectation is to sum key figure with the same characteristic. Who can help me on that?
BTW: when I check delta queue, why there is not any queue?

Hi,
In uploading of flat file , If you are able to capture the changes to the previously loaded records, Then you can follow the additve delta. So it decreases the time of uploading .Only changed or new records will be uploaded every time.
If you are not able capture the changes in flat file ,Every time you have to do full upload ,Before this delete the contents of Infocube. (Assuming there is no ODS B/W Infocube and Flat file).
With rgds,
Anil Kumar Sharma. P

About delta loading for master data attribute

Hi all,
We have a master data attribute loading failed which is a delta loading. I have to fix this problem but I have two questions:
1. how can I find the those delta requests because I need to delete all these failed requests first, am I right ? Master data is not like cube or ods that we can find the requests in Manage, for master data how can we find them ?
2. Could you please let me know the detailed procedures to perform this delta loading again ?
Thanks a lot

Hi...
1. how can I find the those delta requests because I need to delete all these failed requests first, am I right ? Master data is not like cube or ods that we can find the requests in Manage, for master data how can we find them ?
Look.....for master data.....no need to delete request from the target..........just make the status red.......and repeat the load.....But problem is that master data sometimes does'nt support Repeat delta..........if u repeat......then load will again fail with Update mode R.........in that case u hav to do re-init.......
1) delete the init flag.......(In the IP scheduler >> in the top Scheduler tab >> Initialization option for source system)
2) Init with data transfer(if failed load picks some records)..........otherwise .....init without data transfer.....if the last delta failed picking 0 records.......
3) then Delta.......
2. Could you please let me know the detailed procedures to perform this delta loading again ?
1) Make the QM status red.........to set back the init pointer.......
2) Repeat the load.....
After that.........if again load failed with Update mode R.....
1) delete the init flag.......
2) Init with data transfer(if failed load picks some records)..........otherwise init without data transfer.....
3) then Delta.......
Regards,
Debjani.....

Delta loading and Process chain BI

Hi experts,
Two Issues.
1)As i am loading FI data into dso through a process chain which includes Start process>Delta infopackage(which gets data upto psa)>Delta dtp-->Datastore activation.
But infopackage is picking up deltas but DTP is picking up all the previous records plus deltas.
100 records -- 1st day throught Intialization of Delta with Data Transfer
2 delta records -- 2nd day
But DTP is picking up 102 Records on the 2nd Day, which means it is also picking the old records as well.
The DSO must have just 102 records but it is having 202 records.
2) A process chain in running daily as scheduled , but I rescheduled with new scheduling options without deactivating the Process chain.
My Question is
Will the Process chain run for the OLD and the New Schedule or
Is it going to run for new schedule or old one?
or
will I face any Problem because I did not deactivate and made changes to the Change.
Please help me in this matter.
Thanks in advance.
Bhadri.

First query:
I believe that u have used FUll update type DTP is instead of the Delta DTP.. Please cross check the Update mode of the DTP once.
To resolve this issue, delete the total content of the DSO as u have Init and delta loads in PSA. And then using the Delta DTP of the Process chain, load the data. It will extract the total cotent what ever is there in PSA, and later the same DTP will act as the Delta type and will pick the data from the New request of the PSA.
Second Query:
Its always suggested to deschedule the process chain before changing the schedule timings. When ever u do this type of scheduling, just check how many number of JObs available in Schedule mode, if u can see more than one, then delete the older one and keep the new one as it is.
But I always suggest you to deschedule the process chain and reschedule PC with the new timings and then activate the same.
Thanks
Assign points if this helps

Can we use both 0FI_AP_3 and 0FI_AP_4 for Delta Loads at the same time.....

Hi Gurus:
Currently my company uses 0FI_AP_3 for some A/P reporting. It has been heavily customized & uses Delta loading. However, SAP recommends the use of "0FI_AP_4" for A/P data fro delta loads. I was able to Activate 0FI_AP_4 as well & do some Full Loads in Dev/Test boxes. Question is whether I can use both the extractors for "Delta" loads at the same time......? If there are any issue, what is the issue and how ccan I resolve it? Is the use of only one extractor recommended......??
Please let me know as this impacts a lot of my development....! Thanks....
Best...... ShruMaa
PS: I had posted this in "BI Extractors" forum but there has been no response...... Hope to get some response.......! Thanks

Hi,
I would recommend you to use 0FI_AP_4 rather using both, particularly for many reasons -
1. DS: 0FI_AP_4 replaces DataSource 0FI_AP_3 and still uses the same extraction structure. For more details refer to the OSS note 410797.
2. You can run the 0FI_AP_4 independent of any other FI datasources like 0FI_AR_4 and 0FI_GL_4 or even 0FI_GL_14. For more details refer to the OSS note: 551044.
3. Map the 0FI_AP_4 to DSO: 0FIAP_O03 (or create a Z one as per your requirement).
4. Load the same to a InfoCube (0FIAP_C03).
Hope this helps.
Thanks.
Nazeer

Loading through Process Chains 2 Delta Loads and 1 Full Load (ODS to Cube).

Dear All,
I am loading through Process chains with 2 Delta Loads and 1 Full load from ODS to Cube in 3.5. Am in the development process.
My loading process is:
Start - 2 Delta Loads - 1 Full Load - ODS Activation - Delete Index - Further Update - Delete overlapping requests from infocube - Creating Index.
My question is:
When am loading for the first am getting some data and for the next load i should get as Zero as there is no data for the next load but am getting same no of records for the next load. May be it is taking data from full upload, i guess. Please, guide me.
Krishna.

Hi,
The reason you are getting the same no. of records is as you said (Full load), after running the delta you got all the changed records but after those two delta's again you have a full load step which will pick whole of the data all over again.
The reason you are getting same no. of records is:
1> You are running the chain for the first time.
2> You ran this delta ip's for the first time, as such while initializing these deltas you might have choosen "Initialization without data transfer", as such now when you ran these deltas for the first time they picked whole of the data.Running a full load after that will also pick the same no. of records too.
If the two delats you are talking are one after another then is say u got the data because of some changes, since you are loading for a single ods to a cube both your delta and full will pick same "For the first time " during data marting, for they have the same data source(ODS).
Hope fully this will serve your purpose and will be expedite.
Thax & Regards
Vaibhave Sharma
Edited by: Vaibhave Sharma on Sep 3, 2008 10:28 PM

Inventory Cube Loading - Questions....

This is the process I intend to follow to load InfoCube 0IC_C03 and the questions therein. I have the "how to handle inventory scenarios" document, so please don't suggest I read that.
1A) Delete Set-up tables for application 03
1B) Lock Users
1C) Flush LBWQ and delete entries in RSA7 related to application 03 (optional - only if needed)
2A) Fill set up tables for 2LIS_03_BX. Do Full load into BW Inventory Cube with "generate initial status" in InfoPackage.
2B) Compress request with a marker update
3A) Fill set up table for 2LIS_03_BF with posting date 01/01/2006 to 12/31/2007 (Historical) and load to Inventory Cube with a full update
      QUESTION1: Does this need a marker update?
      QUESTION2: Is this a good strategy - do movement documents that old get updated once posted?
      QUESTION3: Does the posting dates restriction depend on on how far back in history we want to go and look at stock values?
3B) Fill set up table for 2LIS_03_BF with posting date 01/01/2008 to 9/9/999 (Current) and load to Inventory Cube with a delta init with data transfer.
3C) Compress load in 3B without a marker update
4A) Fill set up table for 2LIS_03_UM and load to Inventory Cube with a delta init
4B) Compress load in 4A without a marker update
      QUESTION4: How should we select the posting date criteria? Do I need to load from 01/01/2006 to 9/9/9999 since that's the range used for BF?
5) Start V3 update jobs via Job Control
6) Intiate subsequent delta loads from BF and UM and compress with marker update
QUESTION 5: Is the sequence of loading BX first, then BF and UM fixed? or can I do BF and then BX, UM
QUESTION 6: Any tips on minimizing downtime in this particular scenario? Please don't suggest generic steps. If you can suggest something specific to this situation, that'd be great.
I hope you can help with the 6 questions I asked above.
Regards,
Anita S.

Hi Anita,
Please find my answers below. I have worked enough with this scenario and hence feel that these would be worth considering for your scenario.
3A) Fill set up table for 2LIS_03_BF with posting date 01/01/2006 to 12/31/2007 (Historical) and load to Inventory Cube with a full update
QUESTION1: Does this need a marker update?
In this step we dont need marker update while compressing.
QUESTION2: Is this a good strategy - do movement documents that old get updated once posted?
I am able to get the question quite clearly.
QUESTION3: Does the posting dates restriction depend on on how far back in history we want to go and look at stock values?
Yes. We need to start from latest and then go back as backwards as we want to see the stock values. This holds true when we are using non cumulative key figures
4B) Compress load in 4A without a marker update
QUESTION4: How should we select the posting date criteria? Do I need to load from 01/01/2006 to 9/9/9999 since that's the range used for BF?
No need to provide any selection criteria for UM while loading to BW, as this would fetch the same data filled in setup of revaluations.Unless you are looking for only some history other wise you can fill that for company code list and bring the whole data to BW by a single full load, as the data wont be that huge as compared to BF
6) Intiate subsequent delta loads from BF and UM and compress with marker update
QUESTION 5: Is the sequence of loading BX first, then BF and UM fixed? or can I do BF and then BX, UM
This is fixed in terms of compression with marker updates.
QUESTION 6: Any tips on minimizing downtime in this particular scenario? Please don't suggest generic steps. If you can suggest something specific to this situation, that'd be great.
*Yes. Most of time consuming activity is for filling BF history. Negligable for BX and UM comparitively.
Either try having multiple BF selective setup filling based on posting date based on available background processes or filli open months setup during downtime and rest history once you unlock the system for postings. The reason for this being we dont expect any posting for history*
Feel free to ask any further questions about this.
Naveen.A

Problem with delta load urgent!!

Hi,
I have a problem with delta load
We have an IP, which loads data from R/3 system daily, its a delta load to the ODS and it updates to the cube with the selection on Company Codes and 0FISCPER
we are in 3.5 system
For a couple of company codes A & B, the init was done for the period 07.2010 to 12.2099 and after tht the deltas are loaded from 07.2010 till 12.2099 and there's no pblm with tht
Now, there was some updation in R/3 system and the data was maintained for the company codes in A& B for the FISCPER 001.2010 to 006.2010, for which init wasnt maintained...
now how shall we need to load the init in this case? dnt ask me how the postings was done in R/3, but my pblm is purely related to the loading data in BW from R/3, as its very imp for the customer to see the data from 01.2010 to 12.2010 in reports, but the data was only available in reports from 07.2010 onwards
do i need to create another IP and maintain the init for 01.2010 to 06.2010? so tht this selection will automatically appear in the ODS delta loading infopackage
pls throw ur inputs ASAP
thank you

Hi Prince,
No need to maintain any Init for this data, It will be enough if you can load the data from jan 2010 to jun 2010 into your Info Cube.
Follow the below steps:
1)create full load IP for this data source.
2) give the selection as A and B company codes and 0FISCPER as 001.2010 to 006.2010
3) in menu bar, click on scheduler --> select full repair request
4) In the next screen check the check box and save
5) Now execute the IP, it will the data with out disturbing your daily delta.
follow the same procedure to load data till to your Info Cube.
Please revert if you have any questions
Regards,
Venkatesh

Delta load from r3 to bw ?

i have one question on the mechanism of data transfer from r3 to bi 7.0. the followings is my concerns:
scenario:
The total numer of data is 1000 rows and these rows are seperated into 10 data package , each package contains 100 rows.
Now bw is trying to recieve these 10 packages from r3 in sequence.
When 5 data packages have been transfer to bi psa. the network is broken and the tranfer is canceled at the 6th data package.
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS.
How to find out how many records have been transfered from r3 to bw while the transfer has ended in
the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube.
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle ?
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer.
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Last doubt, what is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request ?
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
Please I am having all these doubts and I want you SAP experts to answer them please so that I can clear my doubts in production support . I really appreciate if someone explain me the scenarios here. It will be a really great help if someonce clears these doubts.

Hi......
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
If your connection is broken in between......inspite your load is through PSA...........you have to delete the request from the target(after making the QM status red)............then you have to reload it again............But before repeating the load check the connection is ok or not in SM59........
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS
This you can check in IP scheduler in the Update tab...........whether it is delta or full load.......
or you can also check in IP monitor(You can go here through RSMO..........IP monitor screen will open directly here............or you can also go through RSA1>> Find your IP >> Double click on it >> Click on the monitor icon in the top >> From the you will go to the IP monitor>> the under the Header Tab you can see whether it is a delta or Full update...........
Or you can check the datasource also..........
If it is a generic datasource go to RSO2..........and check...........If it is a standard datasource check it in RSA5...........
How to find out how many records have been transfered from r3 to bw while the transfer has ended in the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube
Your load cannot be ebded in the middle.........it can failed.............if it fails then you have to delete the request from the target..........and then repeat the load.......
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle
Yes.........
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer
If a full or delta load fails after extraction got completed due lock issue or SID issue.....etc..........and if you load is through PSA.............then just delete the request from the target without making the QM status red.......and reconstruct the request.........no need to repeat the whole load again........
But if you r load is not through PSA..........then make the QM status red........delete the request from the target........and repeat the load...........
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Yes.......
What is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request or reload request?
Suppose you delta load has failed ............and you have deleted the request from the target without making the QM status red............In this case your data will be lost and your delta mechanism will get corrupted............In this situation.............
1) Delete the init flag........
2) You have to do Full repair..........(After filling the set up table)
3) Init without data transfer to set back the init flag
4) Then Delta upload.............
In case of an ODS............you cannot load Full update and delta upload parrallely..............Your ODS activation will fail...........suppose you want full upload in the ODS..............then you have to go for Full repair............
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
I think Full repair concept is now clear............
Suppose your delta load fails...........After that you delete the request after making the QM status red............Then system will ask for a repeat delta when you will try to repeat the load...........which means it will pick the same delta records of the failed load..........
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
This you can do via infopackage or infopackage group...........schedule it at the specific time.....
Check these links :
http://help.sap.com/saphelp_nw04/helpdata/en/20/ad673844a7114be10000009b38f842/frameset.htm
Re: Schedule Infopackage for last day of a fiscal period
Hope this helps you.........
Regards,
Debjani...........

Delta load and PSA Reversal Indicator

Background:
After delta loading BW from R/3 Billing I noticed there were more records in the PSA than R/3 billing items. I found that some records had 3 duplicate records. The first was the orginal document from R/3. The second was the same with negative key figures and a reversal indicator. The third is the same record as the first. R/3 has only one record for these three.
Question:
1. Why was this record reversed in BW when there is no reversal in R/3?
2. Will the first occurance of this record post to the ODS load with the unique records option on?
Thanks for any quick answers!
New BW Analyst - Alan

Hi dear and welcome on board !
What you are seeing in PSA is the normal behaviour of Logistic Cockpit datasources...
In this way, thanks to BW, you can analyze all the history for every single billing item (that, clearly, in R/3 will continue to have only one record in VBRP, with all latest and updated info).
In other words R/3 reversal overwrited the unique record in VBRP, while BW stores this change !
About your second question, you don't have to flag in ODS the "unique records" option, since, clearly, you will receive a lot of records for the same key !!!
Hope now is clearer...
Bye,
Roberto
...and please don't forget to reward the answers...it's THE way to say thanks here !!!

Message__Type_X /DELTA LOAD

Team,
All our process chains were made in production in other words they were never transported thru the landscapes.
So finally we decided and consultants did a reverse transport.
Now i have the chain in dev no every time i run the chain it fet stuck on load process it is load delta 0uc_ius_01 for sales cube and gives me a message_x_type error which is long but here is the part of it
nformation on where terminated
   The termination occurred in the ABAP program "SAPLRSS1" in
    "RSM1_CHECK_FOR_DELTAUPD".
   The main program was "RSPROCESS ".
The termination occurred in line 1365 of the source code of the (Include)
    program "LRSS1F11"
   of the source code of program "LRSS1F11" (when calling the editor 13650).
   The program "SAPLRSS1" was started as a background job.
Job name........ "BI_PROCESS_LOADING"
   Job initiator... "JKHAN"
   Job number...... 11431602
I am thinking the reason it is failing in dev because of the reverse transport and deltas are not set am I correct.    Remember the chain works fine in production no problem , the reason I was checking in dev because I added a master load in the chain before the delta load . we have a 2 tier lanscape at this point.    and the master load works fine since it is full load but when it comes to the next step which is delta it fails with the mesage described above.
Since I am new my concern is that production will continue the way it is even though it is failing in dev.     Another thing when i go to infosource tab and try to double click the init or delta 0uc_ius_01 load it gives me the same error message.
Please advive.

Hi MK,
I just had this problem so you are at least in good company. You are getting the error because the initialization and the delta load tables do not match between BW and the client system. I was able to fix this by following note 852443. For reference here is what I did on my side (I add this because the instructions in the note did not completely fix my issue):
- Delete entries that match the object with the failure from these tables in BI: RSSDLINIT, RSSDLINITSEL
- Run RSA7 in the loading system and delete the same matching entries from above.
- Re-run the initialization run
- Re-start the chains that complete the delta runs.
Sorry this is abbreviated but if you have questions, just reply back to this message.
Thanks,
J. Haynes
Denver, CO

Full vs. Delta Load

Hi BI-Experts!
This is a rather general question.
Is there a recommendation when to use Full or Delta Load?
I know the functional differences but do SAP or some technical reasons say that each of them may only be used in special cases?
For example Delta Load can only be used with SAP source systems?
Best regards,
Philipp

Hi Philipp,
This is a pretty open-ended question. I will give you a few examples of when I use each ....
Delta's:
1.) If the record set is large and changes a lot daily. If you have a large initial load, let's say 2Million records and you get about 200k records per month, then you want to use a delta mechanism. There are just too many records to reload daily.
2.) If the record set is wide (many fields instead of a few), it will take less load time to run a delta than a full load.
3.) Datasource restrictions....some business content datasources don't have full loads and vice versa (some don't have deltas).
4.) Do my loads take too long? If so, I will convert full loads to delta's to shave off time here and there.
Full
1.) I gauge this mainly based on load time. If it takes 5 minutes to load 100k records, then it's going to take longer to figure out what delta's were missed (if there was a problem) than it would to just reload the dataset.
2.) Do my requirements dictate that I need to drop and reload the dataset? The best example of this would be the current year's forecast. Some companies revise the forecast and don't want to keep any previous revisions.
3.) Some data loads load a snapshot of a specific date. So, if I wanted to take a snapshot of inventory in a DSO/ODS on Monday, I would Datamart it into a Cube doing a full load for Monday's date.
Hope it helps!
Thanks,
Brian

Difference: Full load, Delta Load & INIT load in BW

Hi Experts,
I am new to SAP BW Data warehousing.
What is the difference between Full load, Delta Load & INIT load in BW.
Regards
Praveen

Hi Pravin,
Hope the below helps you...
Full update:
A full update requests all the data that corresponds with the selection criteria you have determined in the scheduler.
You can indicate that a request with full update mode is a full repair request using the scheduler menu. This request can be posted to every data target, even if the data target already contains data from an initialization run or delta for this DataSource/source system combination, and has overlapping selection conditions.
If you use the full repair request to reload the data into the DataStore object after you have selectively deleted data from the DataStore object, note that this can lead to inconsistencies in the data target. If the selections for the repair request do not correspond with the selections you made when selectively deleting data from the DataStore object, posting this request can lead to duplicated data records in the data target.
Initialization of the delta process
Initializing the delta process is a precondition for requesting the delta.
More than one initialization selection is possible for different, non-overlapping selection conditions to initialize the delta process when scheduling InfoPackages for data from an SAP system. This gives you the option of loading the data
relevant for the delta process to the Business Information Warehouse in steps.
For example, you could load the data for cost center 1000 to BI in one step and the data for cost center 2000 in another.
The delta requested after several initializations contains the upper amount of all the successful init selections as the selection criterion. After this, the selection condition for the delta can no longer be changed. In the example, data for cost
centers 1000 and 2000 were loaded to BI during a delta.
Delta update
A delta update requests only the data that has appeared since the last delta. Before you can request a delta update you first have to initialize the delta process. A delta update is only possible for loading from SAP source systems. If a delta update fails (status red in the monitor), or the overall status of the delta request was set to red manually, the next data request is carried out in repeat mode. With a repeat request, the data that was loaded incorrectly or incompletely in the failed delta request is extracted along with the data that has accrued from this point on. A repeat can only be requested in the dialog screen. If the data from the failed delta request has already been updated to data targets, delete the data from the data targets in question. If you do not delete the data from the data targets, this could lead to duplicated data records after the repeat request.
Repeat delta update
If the loading process fails, the delta for the DataSource is requested again.
Early delta initialization : This is a advanced concept, but just for your information ...
With early delta initialization you can already write the data to the delta queue or to the delta tables in the application while the initialization is requested in the source system. This enables you to initialize the delta process, in other
words, the init request, without having to stop posting the data in the source system. You can only carry out early delta initialization if this is supported by the extractor for the DataSource that is called in the source system with this data
request. Extractors that support early delta initialization were first supplied with.

Delta load question

Similar Messages

Maybe you are looking for