Delta handling

Hi,
How do i handle delta records in BI7.0?

hi ravi,
go thru the following link....
Delta Mechanism?
Help with Delta Init and then Delta (how to)
Which delta mechanism?
ajay
Edited by: Ajay Chauhan on Dec 21, 2007 11:53 PM
Edited by: Ajay Chauhan on Dec 21, 2007 11:54 PM

Similar Messages

CL_BSP_UTILITY DOWNLOAD with delta handling

Hi Experts,
I use the method cl_bsp_utility=>download in the do_handle_event of a subcontroller.
For the main controller delta handling is swiched on. (In this download method the navigation->complete is executed)
After the do_handle_event of the subcontroller the method CL_BSP_CTRL_ADAPTER->do_request is executed. In this method some javascript coding will be append to my response data:
parent.bspDH_newDelta("864D5C4A1F20A60FE1000000AC13AA25");
parent.bspDH_newDeltaLoaded();
It cones from the following statement:
Tail part of delta handling
IF delta_handling IS NOT INITIAL.
   mdelta_handler->PAGE_END( ).
ENDIF.
The outcome is that it's not possible to open my downloaded files. Only txt files can be opened but with the javasript code in it...
Any ideas? or is it in general not possible to use the download function together with delta handling?
Thanks, Markus
Edited by: Markus Doell on Jul 14, 2009 1:42 PM

Hi,
Try the below code in place of the cl_bsp_utility=>download.
DATA: L_APP_TYPE TYPE STRING,
         L_FILENAME TYPE STRING,
         L_XSTRING   TYPE XSTRING,    "needed for HTTP response
         L_XLEN       TYPE I.
* Setting Content Type
MOVE 'application/msexcel' TO L_APP_TYPE.
MOVE 'attachment; filename=webforms.xls' TO L_FILENAME.
CLEAR L_XSTRING.
L_XSTRING = V_XSTRING. " Here you can directly pass your XSTRING
* Fill HTTP request
RESPONSE->SET_HEADER_FIELD( NAME = 'content-type'
                              VALUE = L_APP_TYPE ).
RESPONSE->DELETE_HEADER_FIELD(
                      NAME = IF_HTTP_HEADER_FIELDS=>CACHE_CONTROL ).
RESPONSE->DELETE_HEADER_FIELD(
                      NAME = IF_HTTP_HEADER_FIELDS=>EXPIRES ).
RESPONSE->DELETE_HEADER_FIELD(
                      NAME = IF_HTTP_HEADER_FIELDS=>PRAGMA ).
RESPONSE->SET_HEADER_FIELD(
                       NAME = 'content-disposition'
                       VALUE = L_FILENAME ).
* finally display XLS format in Browser
L_XLEN = XSTRLEN( L_XSTRING ).
RESPONSE->SET_DATA( DATA   = L_XSTRING
                      LENGTH = L_XLEN ).
NAVIGATION->RESPONSE_COMPLETE( ).
I have used it one of my program and it worked.
Thanks,
Sreekanth

Switching off BSP delta handle.

Hello All,
I want to switch of the <b>delta handler</b> for a BSP page. I have been told that there are 2 delta handlers. One on the server side and another on the client side as a JavaScript optimizer.
Please suggest on how I can switch off the functionality for a particular page.
At the moment I have a page where the unchanged data doesn't flow back to the server because of the delta handler. This results in incorrect posting of data.
The effort for persisting the values on the server side is very high and hence I would prefer to switch off the delta handler.
Thanks and regards,
Murli Rao

Hello Gregor,
This javascript has to be added in the view in which you want to disable client side delta handling.
This is not a modification to standard. I had a Z view in which I wanted to switch of client side delta handling.
If you want to do that for a standard view then there are two options.
1. Do a modification to standard.
2. Do a controller replacement and when you copy the
view into your own package then you can add the
javascript.
I hope I have answered your question satisfactorily. If you still have any doubts please feel free to post a new question.
Thanks and regards,
Murli Rao

Brwoser does not refresh for each server event if delta handling is on

I wrote a simple stateful BSP page. When I turn on delta handling(to remove flickering) on the page, page is refreshed only for every other server event. This page contains two table views and I use table view iterator for one of them. How can I force browser refresh for each server event? Browser is IE and version is 5.5.
This problem doesn't exist if turn off delta handling. But I want to stop flickering any how, since users are complaining.

Learning BSP is similar like driving a car. You first need to get a driver's license. So you study a bit, take a test and are ready to drive. Thereafter, flipping that deltaHandling checkbox is like getting into a big plane and trying to fly. It is unfortunately a quantum jump from using BSP to activating the DH system. Which also has a lot of very special constraints, etc.
This was a very special development we did for a big application group inhouse. The first version was good, but did not exactly meet all our expectations. So we redid a lot of the work/concepts. All of this is highly specialized and not documented.
What I could recommend is that you look at BSP application IT05. It should help a little. Otherwise, I am going to ask that you please open an OSS message (please reference this thread!). Then we can look at your application and show you what is to be done. But it is definitely not all moonshine and roses. Our standard answer is "do not use it" when people can not ride this bull. I will add it onto my weblog schedule for some future date.

Docu on Delta Handling?

I really like the concept of Delta Handling in BSP Applications, because it avoids the usual "flickering" of the whole page if you only work in one special section of the page.
I tried to look for documentation on this but I couldn't really find any. Can anybody provide a link or something.
I tried to switch on Delta Handling (setting the flag in the controller and adding Delta Handler Blocks) but it seems that it is not activated (how can I tell anyway? Only from the page's source code?).
Best regards,
Daniel

Delta Handling is a fickle beast. Even within the BSP support team at SAP it is supported on a "Best Effort" basis. That means that if you can't get it to work in your application, their best advice is to turn it off.
I have gotten DH to work in some of my applications. Sometimes it provides a nice effect and a good performance boost - other times it completly screws things up.
The best information I can give you is - you application must be stateful. DH only works in IE. Also you must set the DH flag on the properties of the View and the Controller - from the highest level controller on down.
I'm afraid you won't find much detailed documentation on DH. To know if it is turned on, you usually can peak at the generated source code on the client. DH source will look VERY different.

Delta Handling of "How-to... Load a File into"

Hello,
i have to load several files into an transactional InfoCube. The structure of the files is always the same.
The Problem is it can occur that i have to upload the files serveral times with different data. Following changes within a file can appear.
1. exactly same data again
2. same data again, but the value of a key figure has been changed
3. same data again, but the value of a characteristic has been changed
4. file contains more/less data records than the original file
How does the Cube handle these different versions of data?
If the upload by BPS function allows no delta handling what kind of conventional method (Upload to ODS or Cube) do to recommend for flat file upload?
Thanks for advise.

Hi Sam
follow the link
How-to... Load a File into SAP NetWeaver BI Integrated Planning
Regards,
Gregor

FI-SL Delta Handling: Note 328197

Due to a project requirement we are considering the implementation of note 328197, in order to extract FI-SL data in Delta Mode (ABR). FI-SL Extrators are already in use with some Virtual InfoCubes, and we would like to access the same DataSources to feed a Basic InfoCube
The questions we have about this implementation are:
1 - Will the Extractors modified to Init-Delta Mode still be accessible with Virtual InfoCubes?
2 - Is it possible to de-implement Note 328197?
3 - Considering that Note 328197 acticipate a standard functionality of R/3 4.7 is it fully supported?
Did somebody experienced on such a problem?
Many thanks in advance ... 10 points for sure, if you have a good answer!
GFV

While I haven't used this report I can tell you the following information:
1. Take a look at field VIRTCUBE in table ROOSOURCE. This talls you if a data source is available for a virtual cube. The delivered reports don't change the field so virtual cubes should work fine.
2. Basically yes even if I don't think it should be necessary. All the datasources still run in full mode.
But you should be very careful de-implementing it. I would do it only if absolutely necessary.
3. The note is fully supported. You only need to make sure that you discard the mentioned changes during 4.7 upgrade (especially if you don't do it soon but in some years).
Best regards
Dirk
3.

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

HOW DELTA WORKS IN FI MODULE?FI_AR,FI_AP

HOW DELTA WORKS IN FI MODULE?FI_AR,FI_AP

Hi
See the links in the thread
delta handling in FI
delta handling in FI
Assign points if useful
Cheers
N Ganesh

Regarding Making DB Connect Delta Capable with external Sources

Hi Everyone!
Although as standard DB Connect does not support Delta, this much I have understood. Lately I came across an article from Shreekant Shiralkar and Bharat Patel, BW System Managers, Bharat Petroleum, India in an old BW Expert Article... I have understood that this is from BW 3.0 upwards. Can this be applied to BI 7.0? The Title of the article is "Make DB Connect Delta Capable with External Sources"
Chetan? Edwin? Olivier? Anil? Sandeep? Moderators?
Regards,
Philips

Hi Philips,
I didn't read this article but I'll expose what we have implemented here.
All data coming from non SAP systems are loaded into what I named a "pre staging" database (PSDB) prior extracted to BW. This PSDB is nothing else than a simple, cheap, easy to manage MSSQL server 2000.
Our BW has this PSDB system declared as DBConnect source system.
In few words, we do data cleansing, preparation, formatting in this PSDB when any non SAP data shall be loaded in SAP BW. In addition, we use this machine to perform any R/3 datamigration required for new Rollouts.
Coming back to the delta handling: we don't handle deltas with this DBConnect source system because SAP BW doesn't consider it as delta capable natively.
We develop function modules extractors having the MyBW as source system. MyBW then "think" it is a SAP delta capable source system and we can then setup our MyBW DataSources with any kind of delta type by changing manually the core table ROOSOURCE.
The extractor itself does many things because all structures are handled dynamically and some part of the extractor coding itself is generated on the fly.
The extractor also creates temporary stored procedure directly in the PSDB so that only deltas are delivered to BW.
The core of the extractor, I think everyone would agree, is the OPEN CURSOR statement. The OPEN CURSOR in our case is simply done within an EXEC SQL having our PSDB connection open.
I could discuss this approach at length but we are now running this for more than 3 years (of course a certain effort has been done initially) to our full satisfaction.
I am now finalizing the next "generation": having the PSDB server posting itself, deltas to the MyBW TRFC queue, emulating some how a LO/LIS DataSource.
hope this shed light (at leas mine...)
Olivier.

Delta load error in quantity of sales overview cube 0sd_c03

Hi All,
The quantity(0quant_b) is fetching properly for full upload.But when delta load is done 0quant_b is not fetching correctly.
For example,
quantity was changed from 100 to 120 for an order. When delta is run, only 100 is uploaded instead of 120. In PSA it is showing 120. If a full upload is run it is fetching 120.
I was wondering what could be the reason for a mismatch. I would really appreciate for any clues provided.
Thanks,
Jerry

Hi Jerry,
Please understand the following:
If you have the initial quantity in the R/3 system as 100 and this is loaded to the BW system in the your model(PSA then Infocube) there is no mechanism in your model where in delta can be handled.
The quantity is now changed to 120 in R/3 side now you are expecting this to be captured into the InfoCube which in your model is not possible.
The reason is that in BW the delta handling will be as follows(taking your example):
100 is the initial quantity and this will be flown in to the target with no issues.
Now the quantity is changed to 120 in R/3 side, this will be flown till PSA as 120 itself.
But a field called ROCANCEL will be populated as New record.
This should be mapped to the field RECCORDMODE in DSO on which the delta will be captured.
where I mean to say DSO is mandatory in between. In DSO as I told in the previous post the delta handling will be done as the (new image - before image), in your case it is 120 -100 = 20.
As the property of the InfoCube is addition this 20 will get summed up in to the InfoCube making the quantity 120.
If there is no DSO in between this record will not be considered in the Infocube so you will be left with 100.
Hope this explains your query in detail.
Thanks & Regards,
Vishnu

Delta Extraction Using Function Module ( Customization )

Dear Experts,
I want a sample code for Delta Extraction using Function Module ( If it is customized already working code very helpful ), I have already created Function Module but Full update is happening. If I give delta update again it is retrieving all records. It is very urgent, if you have please send me to the following mail ID.
[email protected]
Best Regards,
SGK.

Hi SGK,
I've done this for a delta based on a timestamp and it's actually pretty easy. The basic steps are:
1) Create an extract structure in SE11. Make sure the structure has a date or timestamp field in it that you can use for delta. You'll need to include the field twice if you also want to extract it to BW/BI since once it's chosen as the delta field then it will be hidden in the interface.
2) Create the extractor function module in SE37. You can use RSAX_BIW_GET_DATA_SIMPLE as a template. Make sure your logic restricts the data it retrieves according to the selections that are passed in I_T_SELECT, including restrictions on the delta field.
3) Create a generic DataSource in RSO2. Click Extraction by FM then fill in your extract structure and function module. Click Generic Delta and pick your delta field and the appropriate radio button (time stamp or calendar day). If your delta field is a timestamp field then be sure to set the upper and lower safety limits to -86400 and 86400 respectively. This might not be necessary on your version of SAPI but on mine there is a bug where it doesn't translate between system time and UTC (GMT) correctly so this was necessary.
You don't need to program any special delta handling logic in your function module as long as you restrict the data you retrieve based on the delta field (I_T_SELECT). This is because the SAPI takes care of catching the init, delta and repeat requests, translating them to the appropriate delta field values, and then passing them to your function module as if it was a full extraction for a specific date or timestamp range.
Hope this helps!
Jason

Delta update for Cube : 0CRM_PRI - Service Orders and Confirmations: Item

Dear experts,
For Cube : 0CRM_PRI - Service Orders and Confirmations: Item
Source data is from Two ODS
1. Confirmations (Item Data) : 0CRM_CNFI and
2. Service Orders: Item Data : 0CRM_PROI
I have done Init upload to this cube from both this ODS.
I am not getting delta option to this.
When I am trying update Delta after init from ODS message is No new deltas in DataStore object 0CRM_PROI for update. No delta option available . It is showing Initial and Full Update option only.
How i can initiate delta option for this Cube ? Please update us.
Thanks in advance.
Regards,

Hi,
you can use DTP's to laod data from ODS to cube .. it will take deltas ..
With a data transfer process, you can transfer data either in full extraction mode or in delta mode. In full mode, the entire dataset of the source is transferred to the target; in delta mode, only the data that was posted to the source since the last data transfer is transferred. The data transfer process controls delta handling and therefore allows you to fill several targets with different deltas from one source. With a data transfer process, you do not need to explicitly initialize the delta method as you do when copying data with an InfoPackage.
or you can create a sepeate Ip for delta apart form full and init .. that will laod delat data in cube ..
Regards,
shikha

Generic Queue not necessarily for delta only

Hi,
I am using the R3 transparent table to store the data extracted, and I am using it to create the datasource from RSO2 => 'Extraction from DB view'. Is there a way to write the data from this table to a queue on the R3 side every time the data is extracted?
Thank you

Dear Crysral Smith,
As Sat was explaining:
1) If your datasource setup (in RSO2) had the suitable
   delta handling mechanism....the R3 system will write
   the delta records to the suitable queue
   "automatically".
2) You would have chosen a suitable timestamp or date
   or a numeric pointer type field for the sytem to base
   the delta mechanism.
Check the link:
   Need "Generic Data source using Function module" to handle Delta
Good luck, BB

Help needed for -- RSVD_BW_GET_DELTA_DATA

Hi Gurus,
<b>I need some help regarding
Delta Extraction FM : RSVD_BW_GET_DELTA_DATA</b>
The pointer for the date up to which delta was extracted during
the last delta update is held in table ROBWQTSTAT.
When I tried testing this function module,
I found that the table ROBWQTSTAT is always empty;
Should I ideally test this from my BW server?
I would appreciate if one of you can guide me step by step.
(Custom modified code would be Great)
Points assured !
Thanks for your time and help,
Aby Jacob Bangalore... :-D
===============

Hi,
this worked for me and ROBWQTSTAT is empty as well.
My parameters executing from R/3:
I_REQUNR                        REQU
I_ISOURCE                       D82CLNT100
I_MAXSIZE                       000000
I_INITFLAG
I_UPDMODE
I_DATAPAKID                     000000
I_RLOGSYS                       D82CLNT100
I_READ_ONLY                     X
For which DSource are you running it?
But more important; what do you want to achieve? You should be carefull since I am not sure what this will do in terms of delta handling...
For instance, I ran it once and got 800 records as delta. ran it a second time having exception "NO_MORE_DATA"; the third time I had a dump!!
The fourth time gave me again 800 records...
let us know...
Olivier.

Delta handling

Similar Messages

Maybe you are looking for