How to do delta detection and delta creation

Hi
i am new to OWB , please help me in
how to do delta detection and delta creation using OWB
Thanks

Hi Bassem,
for delta detection in your data source there are three possibilities:
1. the source data has some identifier when it has been modified and deleted data is marked an not physically deleted
In this case you just filter the data that has been changed in your owb mappings.
2. you use some change data capture technologies
You have to install this manually when using owb 11.1 or older versions (google for oracle and cdc). owb 11R2 brings built in support for change data capture.
3. you get all the data and identify the delta manually
In the owb mapping you left outer join the data from your source with the existing data in your target and filter for the data that is new or has been modified. In a second step you identify the deleted data by selecting the data in your target minus the data from your source.
Which approach is the best depends on your specific system architecture.
Regards,
Carsten.

Similar Messages

How to catch Delta Initialization and Delta Update in a Function Module

Hi Experts:
I'm developing a FM to extract data from R3. I wonder if anybody knows how to catch when i'm making a delta initialization and a delta update in my FM, because i have different parameters and routines from each one.
Thanks in advanced.
Points for helpfull answers.

Hi,
Keep one dummy date field in the structure. Make this dummy date field as delta enabled field. When you do Init load this date field value will be blank and next time when you do load it will have the last upload (in this case init load) date. You have to write a code before open cursor as below:
      LOOP AT s_s_if-t_select INTO l_s_select.
                              WHERE fieldnm = '(dummy date field name)'.
         l_date = l_s_select-low.
      ENDLOOP.
l_date will have the last upload date. This you can use to select the delta records from the table or for the further processing.
If you want to check the value during Init or delta load, go to RSA3 and debug it(Don't use F - Full load. Use I or D in the update field).
Hope this helps.
PB

Need to detect and remove malicious software on MacBook Pro

MacBook Pro 10.6.8 infected with Koobface Virus contracted @ facebook via Tag Friends App + Adobe Flash Player. Lost access to hacked fb page now shows as phishing site. How can I safely detect and remove malicious software?
Thanks

Welcome to Apple Support Communities
OS X has got its own security systems, so you don't need any antivirus. Furthermore, they will only slow down your computer. If you want more information, read > http://www.thesafemac.com/mmg
If you want an antivirus, install ClamXav, but you don't need an antivirus

How to delete the data in update queue and delta queue for Queued delta?

Dear BWers,
How do i delete the delta queue and update queue data before i fill the setup tables for a extraction based on Queued delta. Please help.
Thanks
Raj

Hi Raj,
I think you need some ground work for the LO extraction same as others here. Please read the 3 blogs expliciltly created for LIS by Robert Negro.
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
As well, the OSS 380078 would clear your doubts reagrding the the BW QUEUE mainatinance.
Please let me know if these material has been suffecient enough.
regarda,
raj

Require material on Delta's and how they posted from LO extraction to BW

Hi All,
Can any body send "material on Delta's and how they posted from LO extraction to BW and tell the scenario's"
Plz reply back me to [email protected]
Regards,
Kiran

Hi Kiran,
I have sent some information that what are delta that we use for
delta and how they work.
If you need any clarification let me know.
Thanks
If useful assign some points

How do i change 2 row of array into waveform with delta time and time

Hello,
How do i change 2 row of array into waveform with delta time and time
so the waveform graph will display two waveform,
waveform, not cluster =]
and how to extract 1d array from waveform?

Hi AxE,
Here is an example VI, that do what You asked for.
Both requests.
Hope it Helps...
Attachments:
2D_to_Waveform.vi ‏75 KB

I had an App on MacBook Air which would cause my computer to be locked. I delted it and reinstalled the App again from the AppStore. Now I am being charged again for the same App. How can I correct this issue and get refund for the double billing?

I had an App on MacBook Air which would cause my computer to be locked. I delted it and reinstalled the App again from the AppStore. Now I am being charged again for the same App. How can I correct this issue and get refund for the double billing?

You can't gift it, gifting can only be done from within the store, not from within your library.
Puchases are considered final but you can try the 'report a problem' link to contact iTunes Support and see if they will refund or credit you : http://reportaproblem.apple.com
If the 'report a problem' link doesn't work then you can try contacting iTunes Support via this page : http://www.apple.com/support/itunes/contact/ - click on Contact iTunes Store Support on the right-hand side of the page, then Purchases, Billing & Redemption

HT1725 Everytime I plug my phone into to sync, Itunes starts downloading the same rented movie over and over. I go in and delte it from my library but it does it again. How can I stop this from happening?

Everytime I plug my phone into to sync, Itunes starts downloading the same rented movie over and over. I go in and delte it from my library but it does it again. How can I stop this from happening?

The sort fields should generally be empty unless you've putting in custom values to sort solo artists by their surnames. You can apply common changes to thousands of tracks at once, just don't apply the wrong change because there is no undo.
It is a good idea to backup before undertaking large scale changes. See this backup tip for a suggested approach.
tt2
Message was edited by: turingtest2

How can one find the table name of the Delta Que and setup table?

Hi !
Is there any method to find the table name of the delta que and Extraction que ?

setup table = <extract structure>_setup
example: setup table for MC11VA0ITM = MC11VA0ITM_SETUP
Delta Queue is based on following 3 tables:
ARFCSDATA
ARFCSSTATE
TRFCQOUT
assign points if useful ***
Thanks,
Raj

Download new and delta sales price creation/change

I need to output both new and delta change to sales price conditions.
where can I get the change pointer inormation so as to get the latest sales price out into another system?
Thanks

I found out why IDoc not getting created for change to billing block on sales order.
SAP program ODTF_COBJ_SALES_ORDER_ITEM needs a fix.
Sales Order replication program ODTF_REPL_CO_SALESORDER_ITM has this piece of code:
    LOOP AT cp_so_it.
      ls_vbpos = cp_so_it-low.
      IF ls_vbpos-posnr IS INITIAL.
        APPEND ls_vbpos TO lt_vbeln.
      ELSE.
        APPEND ls_vbpos TO lt_vbpos.
      ENDIF.
    ENDLOOP.
For changes to table vbpa, for example, since vbpa key has posnr, ls_vbpos-posnr will have a value, and this code works.
But for changes to vbak, which doesn't have posnr in table key, ls_vbpos-posnr here is blank, not initial, and this code doesn't work.
eg. CDPOS-TABKEY/BDCP2-TABKEY for vbpa change might be something like "1300040000560000000RM", but for vbak something like "1300040000560".
This data feeds this IF statement above, which fails for changes to vbak data in triggering IDoc replication correctly.
ODTF_REPL_CO_SALESORDER_ITM should be modified to handle vbak change pointer data without the posnr field.

Direct Delta, Queued and Unseralized V3

HI
FOR IM datasources, BF and UM, the guide mentions Direct Delta as the preferred selection. How do we decide this?
Also for LO cockpit DS in SD, what selection is chosen?
Thanks
Harie

hi Harie,
take a look oss note 505700 -LBWE: New update methods as of PI 2002.1 and 500426 - BW extraction SD: alternatives to V3 updating
hope this helps.
505700
Symptom
Up to and including PI 2001.2 or PI-A 2001.2, only the "Serialized V3 update" update method was used for all applications of the logistics extract structures Customizing Cockpit. As a result of the new plug-in, three new update methods are now also available for each application.
The "Serialized V3 update" update method is no longer offered as of PI 2003.1 or PI-A 2003.1. Between installing PI 2002.1 or PI-A 2002.1 and installing PI 2003.1 or PI-A 2003.1, you should therefore switch to one of these new methods in all applications offering alternative update methods.
Rather than describing an error, this note helps you make the right selection of update methods for the applications relating to the logistics extract structures Customizing Cockpit.
Read this note carefully and in particular, refer to the essential notes required for some applications when using the new update methods.
You will also find more detailed information on the SAP Service Marketplace at: http://service.sap.com/~sapidb/011000358700005772172002
Or:
http://service.sap.com/BW > SAP BW InfoIndex > Delta Handling > New Update Methods in Logistics Extraction with PI2002.1 2.0x/3.0x (ppt)
Other terms
V3 update, V3, serialization, TMCEXUPD
Reason and Prerequisites
New design
Solution
1. Why should I no longer use the "Serialized V3 update" as of PI 2002.1 or PI-A 2002.1?
The following restrictions and problems with the "serialized V3 update" resulted in alternative update methods being provided with the new plug-in and the "serialized V3 update" update method no longer being provided with an offset of 2 plug-in releases.
a) If, in an R/3 System, several users who are logged on in different languages enter documents in an application, the V3 collective run only ever processes the update entries for one language during a process call. Subsequently, a process call is automatically started for the update entries from the documents that were entered in the next language. During the serialized V3 update, only update entries that were generated in direct chronological order and with the same logon language can therefore be processed. If the language in the sequence of the update entries changes, the V3 collective update process is terminated and then restarted with the new language.
For every restart, the VBHDR update table is read sequentially on the database. If the update tables contain a very high number of entries, it may require so much time to process the update data that more new update records are simultaneously generated than the number of records being processed.
b) The serialized V3 update can only guarantee the correct sequence of extraction data in a document if the document has not been changed twice in one second.
c) Furthermore, the serialized V3 update can only ensure that the extraction data of a document is in the correct sequence if the times have been synchronized exactly on all system instances, since the time of the update record (which is determined using the locale time of the application server) is used in sorting the update data.
d) In addition, the serialized V3 update can only ensure that the extraction data of a document is in the correct sequence if an error did not occur beforehand in the U2 update, since the V3 update only processes update data, for which the U2 update is successfully processed.
2. New "direct delta" update method:
With this update mode, extraction data is transferred directly to the BW delta queues every time a document is posted. In this way, each document posted with delta extraction is converted to exactly one LUW in the related BW delta queues.
If you are using this method, there is no need to schedule a job at regular intervals to transfer the data to the BW delta queues. On the other hand, the number of LUWs per DataSource increases significantly in the BW delta queues because the deltas of many documents are not summarized into one LUW in the BW delta queues as was previously the case for the V3 update.
If you are using this update mode, note that you cannot post any documents during delta initialization in an application from the start of the recompilation run in the OLTP until all delta init requests have been successfully updated successfully in BW. Otherwise, data from documents posted in the meantime is irretrievably lost.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) A maximum of 10,000 document changes (creating, changing or deleting documents) are accrued between two delta extractions for the application in question. A (considerably) larger number of LUWs in the BW delta queue can result in terminations during extraction.
b) With a future delta initialization, you can ensure that no documents are posted from the start of the recompilation run in R/3 until all delta-init requests have been successfully posted. This applies particularly if, for example, you want to include more organizational units such as another plant or sales organization in the extraction. Stopping the posting of documents always applies to the entire client.
3. The new "queued delta" update method:
With this update mode, the extraction data for the affected application is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
Up to 10,000 delta extractions of documents to an LUW in the BW delta queues are cumulated in this way per DataSource, depending on the application.
If you use this method, it is also necessary to schedule a job to regularly transfer the data to the BW delta queues ("update collective run"). However, you should note that reports delivered using the logistics extract structures Customizing cockpit are used during this scheduling. There is no point in scheduling with the RSM13005 report for this update method since this report only processes V3 update entries. The simplest way to perform scheduling is via the "Job control" function in the logistics extract structures Customizing Cockpit. We recommend that you schedule the job hourly during normal operation - that is, after successful delta initialization.
In the case of a delta initialization, the document postings of the affected application can be included again after successful execution of the recompilation run in the OLTP, provided that you make sure that the update collective run is not started before all delta Init requests have been successfully updated in the BW.
In the posting-free phase during the recompilation run in OLTP, you should execute the update collective run once (as before) to make sure that there are no old delta extraction data remaining in the extraction queues when you resume posting of documents.
If you want to use the functions of the logistics extract structures Customizing cockpit to make changes to the extract structures of an application (for which you selected this update method), you should make absolutely sure that there is no data in the extraction queue before executing these changes in the affected systems. This applies in particular to the transfer of changes to a production system. You can perform a check when the V3 update is already in use in the respective target system using the RMCSBWCC check report.
In the following cases, the extraction queues should never contain any data:
- Importing an R/3 Support Package
- Performing an R/3 upgrade
- Importing a plug-in Support Packages
- Executing a plug-in upgrade
For an overview of the data of all extraction queues of the logistics extract structures Customizing Cockpit, use transaction LBWQ. You may also obtain this overview via the "Log queue overview" function in the logistics extract structures Customizing cockpit. Only the extraction queues that currently contain extraction data are displayed in this case.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) More than 10,000 document changes (creating, changing or deleting a documents) are performed each day for the application in question.
b) In future delta initializations, you must reduce the posting-free phase to executing the recompilation run in R/3. The document postings should be included again when the delta Init requests are posted in BW. Of course, the conditions described above for the update collective run must be taken into account.
4. The new "unserialized V3 update" update method:
With this update mode, the extraction data of the application in question continues to be written to the update tables using a V3 update module and is retained there until the data is read and processed by a collective update run.
However, unlike the current default values (serialized V3 update), the data is read in the update collective run (without taking the sequence from the update tables into account) and then transferred to the BW delta queues.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method since serialized data transfer is never the aim of this update method. However, you should note the following limitation of this update method:
The extraction data of a document posting, where update terminations occurred in the V2 update, can only be processed by the V3 update when the V2 update has been successfully posted.
This update method is recommended for the following general criteria:
a) Due to the design of the data targets in BW and for the particular application in question, it is irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence in which the data was generated in R/3.
5. Other essential points to consider:
a) If you want to select a new update method in application 02 (Purchasing), it is IMPERATIVE that you implement note 500736. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBV302 report.
b) If you want to select a new update method in application 03 (Inventory Management), it is IMPERATIVE that you implement note 486784. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV303 report.
c) If you want to select a new update method in application 04 (Production Planning and Control), it is IMPERATIVE that you implement note 491382. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV304 report.
d) If you want to select a new update method in application 45 (Agency Business), it is IMPERATIVE that you implement note 507357. Otherwise, even if you have selected another update method, the data will still be written to the V3 update. The update data can then no longer be processed using the RMBWV345 report.
e) If you want to change the update method of an application to "queued delta", we urgently recommended that you install the latest qRFC version. In this case, you must refer to note 438015.
f) If you use the new selection function in the logistics extract structures Customizing Cockpit in an application to change from the "Serialized V3" update method to the "direct delta" or "queued delta", you must make sure that there are no pending V3 updates for the applications concerned before importing the relevant correction in all affected systems. To check this, use transaction SA38 to run the RMCSBWCC report with one of the following extract structures in the relevant systems:
    Application 02:   MC02M_0HDR
    Application 03:   MC03BF0
    Application 04:   MC04PE0ARB
    Application 05:   MC05Q00ACT
    Application 08:   MC08TR0FKP
    Application 11:   MC11VA0HDR
    Application 12:   MC12VC0HDR
    Application 13:   MC13VD0HDR
    Application 17:   MC17I00ACT
    Application 18:   MC18I00ACT
    Application 40:   MC40RP0REV
    Application 43:   MC43RK0CAS
    Application 44:   MC44RB0REC
    Application 45:   MC45W_0HDR.
You can switch the update method if this report does return any information on open V3 updates. Of course, you must not post any documents in the affected application after checking with the report and until you import the relevant Customizing request. This procedure applies in particular to importing the relevant Customizing request into a production system.
Otherwise, the pending V3 updates are no longer processed. This processing is still feasible even after you import the Customizing request using the RSM13005 report. However, in this case, you can be sure that the serialization of data in the BW delta queues has not been preserved.
g) Early delta initialization in the logistics extraction:
As of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the delta initialization for selected DataSources.
Only the DataSources of applications 11, 12 and 13 support this procedure in the logistics extraction for PI 2002.1.
The early delta initialization is used to admit document postings in the OLTP system as early as possible during the initialization procedure. If an early delta initialization InfoPackage was started in BW, data may be written immediately to the delta queue of the central delta management.
When you use the "direct delta" update method in the logistics extraction, you do not have to wait for the successful conclusion of all delta Init requests in order to readmit document postings in the OLTP if you are using an early delta initialization.
When you use the "queued delta" update method, early delta initialization is essentially of no advantage because here, as with conventional initialization procedures, you can readmit document postings after successfully filling the setup tables, provided that you ensure that no data is transferred from the extraction queue to the delta queue, that is, an update collective run is not triggered until all of the delta init requests have been successfully posted.
Regardless of the initialization procedure or update method selected, it is nevertheless necessary to stop any document postings for the affected application during a recompilation run in the OLTP (filling the setup tables).
500426
Symptom
With the BW extraction with the structures of the logistics extract structures customizing cockpit there is only V3 updating as an update method up to plug-in release PI-2001.2.
To make every possible effort to ensure the transfer of document postings to BW in the correct sequence the parameter "SERIAL" was added to the V3 collective update (refer also to note 385099). If this parameter is set at the start of the V3 collective update, the update data is read and processed by the database in the sequence of its creation time.
However, this procedure gives rise to the following major performance problem:
If documents are entered in an application in an R/3 System by several users that are logged on in different languages, the V3 collective run will only ever process the update entries for one language in a process call. A process call is then started automatically for the update entries of the documents which were entered in the next language. Accordingly, during the serialized V3 update only update entries which were generated in direct chronological sequence and with the same logon language can ever be processed. If the language changes in the sequence of the update entries, the V3 collective update process is terminated and restarted with the new language.
During every restart, the update table VBHDR is read sequentially on the database. If there are very many entries in the update tables, this can cause the processing of the update data taking so much time that more new update records are generated simultaneously than are processed.
Furthermore, the serialization is not 100% guaranteed in all scenarios when the V3 update is used, as described also in note 384211.
From plug-in PI 2002.1 the option is offered for the most important applications of the logistics extract structures customizing cockpit of selecting between several alternative update methods.
The serialized V3 update is no longer provided from plug-in PI-2003.1.
The modification provided here enables you to use the new update methods for the applications 11, 12 and 13 as early as from patch 5 of PI 2001.2 or PI-A 2001.2.
The following update methods are offered:
direct delta (update mode A):
With this update mode the extraction data is transferred directly into the BW delta queues with every document posting. Every document posting with delta extraction becomes exactly one LUW in the corresponding BW delta queues.
If you use this method it is therefore no longer necessary to regularly schedule a job to transfer the data to the BW delta queues. Otherwise there will be a substantial increase in the number of LUWs per DataSource in the BW delta queues since, unlike previously, with V3 updating the deltas of many documents are grouped together to form an LUW in the BW delta queues.
Furthermore you should note when using this update mode that during delta initialization in an application, from the start of the recompilation run in the OLTP no document postings may be made until all delta Init requests have been updated successfully in BW. Otherwise data in documents posted in the interim will be irretrievably lost.
queued delta (Update mode B):
With this update mode the extraction data of the affected application is collected in an 'extraction queue' instead of in the update dataand can be transferred via an update collective run into the BW delta queues, as is already the case during V3 updating.
For each DataSource,1000 delta extractions are summarized by documents of the application to form an LUW in the BW delta queues.
If you are using this method it is thus also necessary to regularly schedule a job for transferring the data to the BW delta queues. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313). You are recommended to schedule the job on an hourly basis in normal operation - that is following the successful delta initialization.
In the case of a delta initialization the document postings of the affected application can be included again after the successful execution of the recompilation run in the OLTP (OLI7BW, OLI8BW or OLI9BW) if you ensure that the update collective run is not started before all delta Init requests are updated successfully in BW.
In the posting-free phase during the recompilation run in the OLTP - as previously - the update collective run should be be run once successfully to ensure that there is no old delta extraction data in the extraction queues during the reinsertion of the document posting.
Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
unserialized V3 update (update mode C):
With this update mode the extraction data of the affected application is written to the update tables as before with the aid of a V3 update module and kept there until the data is read and processed by an update collective run.
However, unlike the current default values (serialized V3 update), in the update collective run the data is read and transferred to the BW delta queues without taking into account the sequence from the update tables. This is why the performance problem described above does not arise in this case.
This method should only be used if, due to the design of the cubes or ODS objects in the BW system, it does not matter whether the data is transferred to BW in exactly the same sequence in which it was generated in the OLTP System.
Other terms
V3 update
Reason and Prerequisites
Additional desired functions.
Solution
If you already want to use one of the above-described new update methods in the applications 11, 12 or 13 with PI 2001.2 or PI-A 2001.2, you can do this with the corrections given here. However, it is vital that you bear in mind the following points:
1. The corrections described here consist ofa modification which is not included in any PI Support Package. Check whether the described corrections are necessary. When you import a PI Support Package, parts of these corrections may be overwritten. When importing the PI Support Package ensure that you have got all of these corrections (SPAM/SPAU).
2. Only copy these modifications in consultation with SAP logistics extraction development.
3. The corrections presented here should only ever be regarded as an interim solution. The functions are only fully available with PI 2002.1 and PI-A 2002.1. You should also consider the option of upgrading soon to PI 2002.1 or PI-A 2002.1.
Note also that if the update methods of the applications 11, 12 and 13 are changed prematurely, other applications can still only offer the serialized V3 update. The performance problem described above continues to apply to these applications. It should, however, be significantly reduced by the absence of the modules of applications 11, 12 and 13.
4. The corrections described here necessitate the importing of Support Package 5 of PI 2001.2 or PI-A 2001.2. The corrections described here are not possible in a lower plug-in release or Support Package status since the functions of the new update methods are not available.
5. If you want to change the update method of an application to "queued delta", you are strongly recommended to first install the most current qRFC version. Refer to note 438015.
6. If you use the corrections below to change from the update method "Serialized V3" to "Direct delta" or "queued delta" in an application, you must ensure that before the corresponding corrections are imported there are no more open V3 updates for the corresponding applications in all affected systems. To check this, you can execute the report RMCSBWCC in the corresponding systems with transaction SA38 with one of the following extract structures:
    Application 11:   MC11VA0HDR
    Application 12:   MC12VC0HDR
    Application 13:   MC13VD0HDR.
The change is possible if you are not referred to open V3 updates. Of course, no document postings should be made in the affected application after the check with the report until the transfer of the corrections. This procedure applies in particular to the importing of the corrections into a production system.
7. If you are already using the update mode "queued delta" with one of the applications 11, 12 or 13 with the corrections stored here before PI 2002.1 and if you want to make changes to the extract structures in this phase via the cockpit, you should ensure that there is no data in the extraction queues before you execute these changes in the affected systems. In particular this applies to the transportation of changes into a production system. In this case it is not sufficient to execute the check report RMCSBWCC recommended in the cockpit and to eliminate the problem areas specified there.
Below we describe how you can check and ensure this condition.
8. When you import PI 2002.1 the changes made here will always be ineffective and you will get the update method "serialized V3" again as the preset update method.
If you have already changed to a different update method in advance in one of the applications 11, 12 or 13 via the corrections stored here, you must consider the following points during the plug-in upgrade to PI 2002.1 or PI-A 2002.1:
a) Before the upgrade you must ensure that there is no more data in the extraction queues MCEX11, MCEX12 and MCEX13. Otherwise it may no longer be possible to process the data, which may have to be deleted from the queues, due to an extract structure enhancement with the new plug-in. You can do this by starting the collective update report (RMBWV311, RMBWV312 or RMBWV313) and by subsequently checking the extraction queues using transaction SMQ1.
b) After the upgrade you must ensure that before the inclusion of new document postings, the update method of the corresponding application used in advance by the corrections specified here is also set in the cockpit of the logistics extraction (LBWE), and that this setting is transported into all clients of the affected systems.
Note in this context that the corrections specified here change the update method so that it is client-independent. The new functions in the cockpit of the logistics extraction from PI 2002.1 or PI-A 2002.1 then allow the client-specific selection of the update methods.
9. If you want to use the update method "direct delta" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
10. If you want to use the update method "direct delta" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
11. If you want to use the update method "direct delta" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000373868" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
12. If you want to use the update method "queued delta" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
13. If you want to use the update method "queued delta" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
14. If you want to use the update method "queued delta" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380083" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
15. If you want to use the update method "unserialized V3 update" in application 11 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX11TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
16. If you want to use the update method "unserialized V3 update" in application 12 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX12TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).
17. If you want to use the update method "unserialized V3 update" in application 13 instead of the serialized V3 update, copy the changes specified in the correction instructions "0120061532 0000380084" given below for the include MCEX13TOP using the ABAP editor (transaction SE38) (these guidelines can be used both for PI 2001.2 and PI-A 2001.2).

ODS Delta Process, DataSource and Delta Queue

Hi to all,
loading data from a SAP source system into SAP BW 7.0 via generic 3.x datasource causes problems.
Here is a short description:
The data flow is from a source table using a generic extractor into a target ODS in full update mode.
Update rules should move data from table structure into ODS structure in this way:
Source table structure
CustKey1     Key2
13386          C23
13386          B14
13387          A13
13387          E25
ODS structure
CustKey1     col1     col2
13387          A13     E25
This works pretty well - as long as all records with the same CustKey1 are transfered in the same data package. Data Browser (SE16) shows the situation in ODS-"New data" view (data is not activated):
Request    Data_packet_number     Data_record_number      CustKey1
112           000003                  1.061              0000013386
112           000004                      1              0000013386
112           000004                      2              0000013387
There are two records for CustKey1 0000013386 with
data record 1.061 in data packet 000003   and
data record       1 in data packet 000004.
The obove constellation is the cause for errors in the ODS Delta Queue and subsequent data processing.
I think there may be one solution to solve the problem by changing the Delta Process of the Data Source.
The properties are:
- Record type: Full, delta, before, after images
- Delta type: Delta from delta queue or from extractor
- Serialization: No serialization, serialization of request, serialization of data packages
But how can I change these settings? Transactions RSA2 RSO2 RSO6 RSO8 don't do this.
What is the right delta process to use?
I have tried changing the delta process generating several 3.x datasources with the following delta processes (see table RODELTAM)
- " " (Full-upload)
- AIE
- ADD
Unfortunately with no effect.
Who can help?
Regards
Josef
Edited by: Josef L. on Mar 20, 2009 7:44 PM

hi venkat,
whenever you load a delta from ods to cube , whatever the data changed in ods since last delta will be updated, hence from you case, both req1 and req2 will be loaded to cube.
Assign Points if useful
Ramesh

0FC_BP_ITEMS: ERP customizing and delta mechanism

Hi BI fans
I have two questions:
1.) The following link describes how to make the settings for delta enabling of datasource 0FC_BP_ITEMS:
http://help.sap.com/saphelp_nw70/helpdata/en/27/42073e774a4329b6dd6bab21eef613/frameset.htm
Prerequisites-
"...If you want to use the delta method, you first have to activate it in the Implementation Guide for Contract Accounts Receivable and Payable -> Integration Business Intelligence -> Maintain Central Settings in the clients of the OLTP system..."
But I cannot find the setting for "Maintain Centrall Settings" in the implementation guide!
Any idea from your side?
What I see are entries for:
Define Fields for the Extraction of Items
Define Grid for Grouping of Items
2.) What is the exact delta logic of this extractor (working through function module)?
Which fields are relevant for the delta logic?
Thanks
BEOplanet

Hi Andrea
First of all I activated the whole content (datasource, BW content, etc.).
Regarding the pseudo-delta on CPUDT I have designed a BEx variable on a DATS 8 time characteristic, e.g. 0NETDUEDATE. It is a BEx variable feeded by a customer exit, you will find a sample coding below. Furthermore an interval variable, mandatory input.
Screen for BEx variable properties:
Assign this BEx variable into your infopackage for intended use of pseudo-deltas, type OLAP-variable:
The sample coding below gives you an idea about our pseudo-delta mechanism, from 1st. of last month until sy-datum.
Data wa1 like line of e_t_range.
data d1 type d.
data fdate type d.
data fyear type d.
data ldate type d.
data fmonth type d.
case i_vnam.
when 'ZL2MTDY'. "BEx variable on 0NETDUEDATE or any other DATS 8 time characteristic
d1 = sy-datum.
fdate = d1 - 31.
fdate+6(2) = '01'.
ldate = sy-datum.
wa1-opt = 'BT'.
wa1-sign = 'I'.
wa1-low = fdate.
wa1-high = ldate.
append wa1 to e_t_range.
ENDCASE.

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

Generic Delta: Init, Full Upload and Deltas...

Dear All,
Last week on 10.04.2014 I've created "Generic DataSource with Generic Delta" and used CalDay as Delta-Specific Field and lower limit kept to blank and upper limit to 1. On 11.04.2014 I've initialized the Delta with Data Transfer using Process Chain: Time 1:15 p.m (Note: Posting was on)
see below screen shot:
Result: Process Chain was scheduled to immediate and it executed and initialized the delta and brought records as well. See below screen shot of RSA7:
Q: 1: Why generic delta current status is 10.04.2014, as I'v scheduled delta through process chain on 11.04.2014 @ 20:50: and why Total column is showing 0 records? Even I've checked Display Data Entries with Delta Repetition, but could not find any records?
Following is the InfoPackages which I created for Delta Loads and used in another Process Chain for Delta scheduled (daily @ 20: 50).
Following is the DTP used into Delta Process Chain:
On 12/04/2014 when I checked my InfoCube, and found that same number of records being loaded again despite InfoPackage and DTP were created as Delta, see screen shot:
On 12/04/2014 See below PSA table:
On 14/04/2014 when I checked InfoCube and I saw deltas being loaded successfully: see below screen shot:
On 14/04/2014 see below PSA table:
On 14/04/2014 see below RSA7 BW Delta Queue Maintenance screen shot:
Q: 2: Why am I unable to load the Delta records on the day(11/04/2014) when I initialized it with Data and why same number of records being loaded again on 11/04/2014?
Q: 3: On 11/04/2014, around 1:15 p.m I've initialized Delta with Data successfully and the same day (11/04/2014) was my first load of delta records (Time: 20: 50), could this be a problem? as the posting period was on when I initialized and I tried to load the delta on the same day?
Q: 4: Why the pointer is showing me Current Status: 12/04/2014 today and this time around I can find last delta records from "Display Data" option with Delta Repetition?
Q: 5: Have I missed something in the design or data flow?
Q: 6: How can I verify deltas records accuracy on daily basis; is it from RSA3?
or How can I verify daily deltas with ECC delta records?
Q: 7: What is the best practice when you load full data and initialized delta and schedule deltas for Generic DataSources with CalDay as delta specific field?
I will appreciate your replies.
Many Thanks!!!
Tariq Ashraf

I clearly got ur point.....But
If i have situation like ....." I loaded the LO data from R/3 with Init delta......then i loaded 5 loads of delta too.......due to some error in data now i am trying to load all th data......In this case if i do Full upload it is going to bring all the data till 5 th delta load .......If i do Init delta again it is going to bring the same data as full upload..........In LO while loading both Full load or delta init load we need to lock R/3 users....I believe we can load delta even after full upload by using "Init delta without data transfer"............So that wont be the barrier....then what is the difference or how should i figure out which load should i do.............If i am wrong please correct me.......
Thanks

How to do delta detection and delta creation

Similar Messages

Maybe you are looking for