Queued delta enable extractions having entries in SM13. Is this correct?

I Have the following issue:
The 11 application module in LBWE is Queue delta enabled
But I am seeing the changes to VA02 in SM13. why is this?
Thanks
Simmi

Hi simmi:
when ever we change the structure (enhancements, user exit) to any LO extractor its always a good practice to make sure we transport the request to prod on the same day and also make sure we do our setup tables and re-initilization's on the same day. as mentioned by you, you have a time lag and i think thats causing you some discrepancies. any ways, check in SM13 and if you think you can sustain with the data volume go and do a INIT to capture everything. or else go according to the date whe you do a load.
assign points if helpful
kalyan

Similar Messages

Trying to delta enable 1CL_OEQU001

I have created a data source 1CL_OEQU001 to extract classification data associated with 0EQUIPMENT. I would like to be able to delta enable extraction and can not figure out if it is possible to delta enable.
Thank You in advance for any assistance.

Hi there you can only have single value since in this case the specific key would be equipment nr and therefor each entry would have to have a distinct value.
For your 0Equipment_Attr loads are you actually carrying out daily deltas or full loads if full than your 1CL should fall in line.
Where I am at the moment there is not a classification system set up, can you check in RSA2 the extraction method and details of the extractor for the 1CL in question

Queued delta

Hi Gurus,
Can you any body tell what are the advantages between queued and other(Un serilised, direct) deltas.
Thanks
Shiva

Hi..........
QUEUED DELTA : Data extracted from the application will be collected in an extraction queue before transferred into DELTA QUEUE..upto 10,000 delta extraction documents will be summarized into DeltaQueue as a single LUW..
V3 UPDATE : Extraction data from the application will be collected in update tables ,it will be send to delta queue only if update collection runs.
Also look out this
Roberto Negro's Weblogs on LO Cockpit in SDN.
Cheers,
Shana

1CL_OXI_018 : can we make this Classification DS as delta enabled??

hey all
help required..
i want to make 1CL_OXI_018 classification DS as delta enabled..
can any how i do this? if so kindly respond.
regards
vijay

Hi Vishnu,
In your case you need to build the logic for your custom fields as you have enhanced the Business Content DS..
The way you can build the logic would be using the CDHDR and CDPOS tables if the changes are recorded in those tables.
The above tables contain any changes done to any documents..
Let me know if it helps..
Best Regards
Avinash

R/3 extraction.{direct delta and queued delta and V3}

Hi,
I am new to BW.Can anyone explain me about R/3 extraction in detail and steps to extract from R/3 to BW.
I understood direct delta.But i couldn't understand queued delta.Can anyone please explain queued delta and also V3.Are queued delta and V3 same?
Detail explanation or links will help a lot.
Thanks,
Sunny.

Hi Sunny,
Procurement - MM :
MM is a part of SCM. There are several section in this, say Procurement, manufacturing, vendor evaluation etc... All can be found under follwoing link.
Please find the procedure and important links for LO extraction..
LO'S Procedure:
Go to transaction code RSA3 and see if any data is available related to your DataSource. If data is there in RSA3 then go to transaction code LBWG (Delete Setup data) and delete the data by entering the application name.
Go to transaction SBIW --> Settings for Application Specific Datasource --> Logistics --> Managing extract structures --> Initialization --> Filling the Setup table --> Application specific setup of statistical data --> perform setup (relevant application)
In OLI*** (for example OLI7BW for Statistical setup for old documents : Orders) give the name of the run and execute. Now all the available records from R/3 will be loaded to setup tables.
Go to transaction RSA3 and check the data.
Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.
Go to BW system and create infopackage and under the update tab select the initialize delta process. And schedule the package. Now all the data available in the setup tables are now loaded into the data target.
Now for the delta records go to LBWE in R/3 and change the update mode for the corresponding DataSource to Direct/Queue delta. By doing this record will bypass SM13 and directly go to RSA7. Go to transaction code RSA7 there you can see green light # Once the new records are added immediately you can see the record in RSA7.
Go to BW system and create a new infopackage for delta loads. Double click on new infopackage. Under update tab you can see the delta update radio button.
Now you can go to your data target and see the delta record.
Re: LO-Cockpit V1 and V2 update
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
Also Refer this link:
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Inventory.. dwload go thru it
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
*Steps*:
1st delet the septup table----lbwg(for application 3)(need to cleanup the setup tables in r/3 side by using (LBWG for AC:03)
1) Fill setup table (fill up the set up tables BX, BF and UM by using (MCNB,OLI1BW and OLIZBW).
for BX(Open stock)-tcode--MCNB,
for BF Tcode(oli1bw)
for UM tcode(olizbw)
after that pull data to BW with (Once the data is ready in RSA3, then in BW you have to set up compression for zero marker update for the Cube (coz is related to Noncummulative Keyfiger scenario) then load BX data. onces its completed load normally the BF and UMs.
BW side:-
make the compression
for BX load normally
and BF&UM(step table data):-compression with zero mark update(select that check box option)
after completion of compression do delta(Note: for deltas follow the compression normally)
http://help.sap.com/saphelp_nw2004s/helpdata/en/29/79eb3cad744026e10000000a11405a/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/c5/a26f37eb997866e10000009b38f8cf/frameset.htm
SD - Enterprise Sales and Distribution
SD comes under CRM application component (ERP Analytics).
sd flow
salesorder:
VBRK - header
VBAP - item
VBEP - scheduling
delivery:
LIKP - header
LIPS - item
billing:
VBRK - header
VBRP - item
shipement
VTTK - header
VTTP - item
customer data
SD links FI table
salesarea data general data companycode data
knvp kna1 knb1
material master data
SD link to MM table
salesdata Basic data salestext data
MARC MARA STXH(Textfile header)
MVKE MAKT STXL
process:
1.sales reresntive enter sales order in R/3 system, it sotres the transaction into three
SD tables.
2.delivery due list is executed for all sales orders and delivers are created in table LIKP, LIPS.
A goodsissue updating MKPF & MSEG.
3.invoice due list is then executed for all deliviers. after an invoice is created, which creates an acct.doc ( BKPF & BSEG, FI TABLES) and set up the receivalbe in table BSID (open tem).
4.The receivalbe is cleared when paymen check is required. anoher acct.doc is created ( BKPF & BSEG) the open receivable is cleared and table BSAD (closed line item) is updated
First u select application component.. SD,MM,FI,PM
then got to rsa5.. u can install data source...
after next step RSA6-Display data sources
Then select our ds which we need to enhance then click on the
append structure (application tool bar)
u can see start with ZAGTFIGL_4 ( fi example)
u given component name and component type ( here given to existing
data element)
save + activate....
then go to the t code CMOD...>there select the project
name--> go to the exit in RSAP0001->
or also u can goto tcode se37 fuction module.. EXIT_SAPLRSAP_001
transactional data
click on display...
then u can see INCLUDE ZXRSAU01( program ) double click it.....
then u can change option click it.
So please follow the link below:
http://help.sap.com/saphelp_nw70/helpdata/en/c5/bbe737a294946fe10000009b38f8cf/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/17/cd5e407aa4c44ce10000000a1550b0/frameset.htm
Check these links,
http://help.sap.com/saphelp_47x200/helpdata/en/dd/55f33e545a11d1a7020000e829fd11/frameset.htm
http://www.sapbrain.com/TUTORIALS/FUNCTIONAL/SD_tutorial.html
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/MYSAP/SR_MM.pdf
http://sap-img.com/materials/what-is-the-dataflow-of-mm.htm
http://www.erpgenie.com/abap/tables_sd.htm
http://www.erpgenie.com/abap/tables_mm.htm
/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
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
/people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
Re: LO-Cockpit V1 and V2 update
http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
Regards
CSM Reddy

Extract ECC 5.0 New GL transaction Line item to BI 7.0(delta enabled)

Hi all,
The back end system is ECC 5.0 and i need to extract New GL line item transaction level data (with document/transaction currency amount) to BI 7.0 .0FI_GL_4 datasource is on GLT0 table instead of NEW GL FAGLFLEXA and 0FI_GL_14 is available only from ECC 6.0onwards.What should be the approach/advice to accomplish this wth delta enabled
regards
savvy

In my previous implementation, what we followed was
We used 0FI_GL_10 to fill 0FIGL_O10 & 0FIGL_C10 for totals and
for line items load DSO 0FIGL_O02 through 0FI_GL_4
And we had drilldown (RRI) reports from C10 to O02

What is differences extraction queue, delta queue and uddate queue ?

hi guru's
What is differences between extraction queue, delta queue and uddate queue ? can u describe briefly?
Thanks & Regards
nandi

Dear Prabha,
Basically when any document is posted in R/3, it is updated to the update table, from there it is taken to our delta queue for send it to BW side.
When extraction starts, data is sent to BW from delta queue. then again this cycle starts.
When you post any document in OLTP system (eg SAP R3),
say create sales order by VA01, then posting is made to application tables (VBAK/VBAP) through V1 and also to sm other tables through V2, Communication structure written to update queue/extraction queue/delta queue(directly) as per the update mode selected. V3 is always followed by V2 and we are supposed to schedule it.
From this delta queue, data is extracted by BW infopackages.
There are various update methods according to which extraction or delta queue are used, so when document posting takes place it also write data into extraction queue (through V1 update) and if we use queued delta method then this data is collected in collection run and written to delta queue and from this delta queue we request for data from BW.
There are lots of posts on SDN for this, please have a look on those.
one for your reference...
https://www.sdn.sap.com/irj/sdn/profile?userid=3507509
Hope it helps...
Message was edited by:
Ashish Tewari

In Generic Extraction how can we know whether it is Delta Enabled or not?

In Generic Extraction how can we know whether it is Delta Enabled or not?
Thanks,
Pramod.

Hi Pramod,
In R/3 use RSO2 tcode and enter your DS name and click "Change / Display" In this "Press F7 or Display Filed List" icon near to Generic Delta.In this Screen if Delta Update is Checked means it supports delta method otherwise it won't support delta method.
Note:Assign Points if it helps.
-Arun.M.D

Why we will go for Queue delta instead of Unserialized and Direct delta ?

Hi Experts,
Why we will go for Queue delta instead of Unserialized and Direct delta ? specify any reasons for that ?
What happens internally when we use Queue delta , Direct delta ?
I will allocate points to those who help me in detail. My advance thanks who respond to my query.

Hi,
Direct Delta
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.
Queued Delta
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. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313).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 (e.g OLI7BW, OLI8BW or OLI9BW), 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.
Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
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
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 document) 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.
Un-serialized V3 Update
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
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.
Thanks,
JituK

How to make enhanced fields of data source delta enabled?

Hi ,
I have a scenario, in which we are using the DS 0CUSTOMER_ATTR to load the master data.There are some fields added to this data source but this fields are not delta enabled. I have tested these fields from R/3 side using BDCP, CDPOS tables. All the fields are writing the changes correctly. But when extracting them using delta they are not capturing.If we load the full,it is capturing all the changes.
So running full load every week is taking more time.
Can any one suggest how to make this fileds delta enabled to capture the change in BW side as well to extract only changed records?
Any help will be greatly appriciated !
Thanks & Regards,
Vishnu

HI,
It is not possible to load delta this data. Your datasource only detects changes in the customer table and when any customer has been modified the record is loaded to BW. In this moment the datasource fill the append extructure.
The problem is that if you modifies some record from the append extructure the datasources doesn't detects the changes. When you does a full load you are filling the append extructure for the entire records and it works.
If you want to catch this deltas you should make a delta datasource for CDPOS but depending on the number of records of the tables it won't be possible.
You could check if there is any event to detects the modification and create a delta queue datasource for the append extructure.
Then, you can mix both datasources in a DSO in BW.
You can look for a " how to create generic datasources which use delta queue"
I hope it helps

Delta enabled generic data source not updating delta

HI,
   Created one Delta enabled generic datasource with the help of ztable .Fill the content of table by manual entries.
   While executin init,records are extracted from R/3 system. After made a change in table entries , it is not captured in RSA3.
   Data source is avaialble in RSA7 after execueting init.
   Delta type== TIME STAMP
   fIELD NAME=zTIME
SAFETY LIMIT=30 SEC
ITS FROM 'NEW STATUS FOR CHANGE RECORDS'
Please help me on this issue..
Regards,
MohammeD

how did you create your data source? - based on view, table for Function Module?
If it is based on a View or table, ideally delta should have worked. If it is not working, please chedk the data type of the field. Make sure that delta field (i.e. ZTIME) is getting updated evertyime you change any record in ztable. While extracting data in RSA3 in delta (D) mode, make sure you also give the target system ID. Also try runnign the delta infopackage in BW if it fetches data.
If nothing works, try creating your data source again.
If it is based on Fuction Module, you will have to include the delta functionality in your code.
Regards,
Gaurav

Delta Enabled Generic Data Source

Hi All,
I have created one Delta Enabled Generic Data Source with
Function Module. The Delta field is Date Field. The Data source picks data from R3 to BW.
In RSA3, I executed the Extractor with the Delta Type "C" i.e Delta Initialization ... but it is throwing the error "Errors occured during the extraction". I also checked the Display Log and the error message is "Could not determine BW release of logical system".
Moreover I am not able to see the Delta Attributes in
RSA7. I checked with the other delta enabled generic extractors which uses Views .. is found to be working fine ... and I also able to see the Delta Attributes in RSA7.
Any suggestions?
Bye
Dinesh

Dinesh,
Once you have generated transfer rules in BW for the datasource, delta init can be tried out in RSA3. It iwll not create the delta queue though. Only test the initialization.
To do this, once you have created the transfer rules in BW, specify the logical system name of the BW system in the target system field. After that the extractor can be run in RSA3. It is flagged as read only so delta queue will not get created.
Cheers
Aneesh

Regarding the Extractor Queue (Queued Delta) In LO

Hi guyz,
Can anyone let me know where can we see all the Erroneous records which are in Extractor LOG, while performing Queued Delta In LO-Extraction.
I mean the T-code as well as navigational Steps.
Thanks and Regards,
Hawkin.

Hi,
what kind of error do you have exactly?
some of them can bee seen in SM13 (updates) and also tRFC (SM58)....
hope this helps...
Olivier.

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

Sequence of operations - Direct Delta, Queued Delta, Unserialized V3 Update

Is the below understanding about each update method correct?
a) Direct Delta
- The user selects a process (e.g. creating, updating or deleting a purchase order), fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the Application Tables.
- This or another module inserts delta relevant information (e.g.: before and after image, the key for deletion, reverse image, etc) about this PO in the Communication Structures.
- Another module reads the Comm Structures and inserts this information in the Delta Queue.
- COMMIT the operations in the App Tables and in the Delta Queue.
- The user receives a success message.
b) Queued Delta
- The user selects a process, fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the App Tables.
- This or another module inserts delta relevant information about this PO in the Comm Structures.
- Another module reads the Comm Structures and inserts this information in the Extraction Queue.
- COMMIT the operations in the App Tables and in the Extraction Queue.
- The user receives a success message.
- Periodically, a Collective Run inserts this information in the Delta Queue and deletes it from the Extraction Queue.
c) Unserialized V3 Update
- The user selects a process, fills the fields in the screen, presses SAVE.
- A module makes inserts, updates and deletes on the App Tables.
- COMMIT the operations in the App Tables.
- The user receives a success message.
- This or another module inserts delta relevant information about this PO in the Comm Structures.
- Another module reads the Comm Structures and inserts this information in the Information Structures (also known as Statistical Tables), as part of the LIS data flow u2013 as I understand it has nothing to do with LO data extraction, but it is coded this way.
- If the inserts into the Information Structures work well, another module reads the Comm Structures and inserts this information in the Update Table.
- Periodically, a Collective Run inserts this information in the Delta Queue and deletes it from the Update Table.
Thanks
César Menezes

Krishna
Thanks for your attention, but I've already read:
- Roberto Negrou2019s blogs,
- OSS Note 505700,
- Power point u201CNew Update Methods for Logistics Extraction with PI 2003.1u201D (quoted in the OSS Note, link u201Chttp://service.sap.com/~sapidb/011000358700005772172002u201D),
- many threads wich provided very useful information.
I need now more detailed information, step by step operation on each update method, like I posted in the thread.
Actually I want to cross this information with another thread I posted (), about Figure 6 (Comparison among call function hierarchies involved in different update methods).
This Figure is showed in Negrou2019s Episode Three and in the power point. I believe that this figure is wrong or at least is missing something.
Do you know about these two points, or can you please forward to someone who can help us ???
Thanks
César Menezes

Queued delta enable extractions having entries in SM13. Is this correct?

Similar Messages

Maybe you are looking for