Question:
I have questions about 3 new methods for LO extraction that replace serialized V3 update.
1. For the non-serialized V3 update, does it ensure the serialization of document? If not, it is a true that we shouldn't use this option to load to BW ODS? It seems to me this non-serialized update is just the "original V3 update". SAP tried to enhance it to become serialized V3 update before and still run into issues. So SAP abandon this approach and leave the v3 update as it was originally and create another 2 new methods.
2. If we go for either direct queue or queued delta, are we running into some potential risk (for example the V1 update failed and all the stuff queue in R/3?). Also, do we need to scheuld jobs for these V1 update and/or how we can check whether those V1 update are running?
3. If we use queued delta, is it true we can allow document postings once the setup table is filled up? In another word, can document posting happen the same time as BW initial run. What's the reason to execute the update collective run once to make sure that there are no old delta extraction remaining in the extraction queues during the recompilation run( I saw it in note 505700)? Doesn't it cause problem if we execute the update collective run when we are filling up setup table?
Your answer is appreciated.
Sean
Answer:
I have questions about 3 new methods for LO extraction that replace serialized V3 update.
1. For the non-serialized V3 update, does it ensure the serialization of document? If not, it is a true that we shouldn't use this option to load to BW ODS? It seems to me this non-serialized update is just the "original V3 update". SAP tried to enhance it to become serialized V3 update before and still run into issues. So SAP abandon this approach and leave the v3 update as it was originally and create another 2 new methods.
What do you think "non-serialized" stands for ?!
never use this method if you don't have a very specific scenario to use it.
if you don't know if your scenario is very specific, than it is not.
2. If we go for either direct queue or queued delta, are we running into some potential risk (for example the V1 update failed and all the stuff queue in R/3?). Also, do we need to scheuld jobs for these V1 update and/or how we can check whether those V1 update are running?
check your understanding of updates types V1 V2 V3 ; only V3 needs collective run
in other words, direct delta = direct, you just have to upload in BW
queued delta = you need a collective run before upload in BW
3. If we use queued delta, is it true we can allow document postings once the setup table is filled up? In another word, can document posting happen the same time as BW initial run.
only the area 11 of lo-cockpit allows you "early delta initialization"
there is no difference between direct and queued in this matter
so, the general answer is NO, as before, apart if you are dealing with area 11
What's the reason to execute the update collective run once to make sure that there are no old delta extraction remaining in the extraction queues during the recompilation run( I saw it in note 505700)? Doesn't it cause problem if we execute the update collective run when we are filling up setup table?
Your answer is appreciated.
Sean
You potentially change the structure of the transparent tables holding the data still in the queue and "pre-queue" -> you must ensure that those tables are completely empty to avoid data loss and possible problem
'hope this helps a little bit
Ch