LO Extractor: user to update in ECC during setup table runtime

[Former Member]

Dear all

Is it true that for Queued Delta, user is allow to update during setup table runtime (filling) ?

Actually I refer to SAP Note: 602260 - Procedure for restructuring data for BW (point #8).

Won't it create double because the updated data would be written both in Extraction Queue and Setup table?

Thanks

Halomoan

[former_member188080]

Hi,

You can actually unlock users while you are loading data to BW...DATA in BW is extracted from set up table and not from any other queue say LBWQ or RSA7 at this point of time of data loading..

You can minimise downtime by just loading the set up table say for current 3 periods or as per say created on or posting date..

Thanks and regards

Kiran

[Former Member]

Correct Kiran, that could reduce the locking time for both Direct Delta and Queue Delta (+Unserialized V3).

But I want to know if the SAP Notes give a false info or there is something that I miss on how Queue Delta has shorter locking time compare to the Direct Delta. It said we can unlock the user during the restructuring setup table run time.

Halomoan

[Former Member]

With "Delta queued" and "unserialized V3 update", documents can already be edited again during the runtime of the initialization request.

With Queued or Unserialized updates, you would only need locking time till setup tables are filled. Point 8 from the note says that users could be allowed to post once setup tables and filled and even when initialization request from BW is running.

For direct delta users could be unlocked only after both activities - filling the setup tables and completion of the init request from BW, as there will not be intermediate queues like extraction queue/update queue in this case.

[Former Member]

Hi,

Actually there are chances of data duplication, if you read point no 3 and 4 from above note you will get the answer.

There are many alternatives for e.g. you can upload the data to DSO and then your delta will be managed from there.

Regards,

Durgesh.

[Former Member]

I agree with you guys, but I believe there is a reason behind why the Notes said Queued Delta has benefit over Direct Delta when performing restructuring.

We really look into this benefit to shorter the blocking time when filling the Setup table.

Anybody has the experience before?

Thanks

Halomoan

[Former Member]

Hi,

If you read the note carefully, it also mentions that the data will be duplicated and hence needs to be deleted.

*With "Delta queued" and "unserialized V3 update", documents can already be edited again during the runtime of the initialization request. The data is then collected in the update queue (LBWQ or SM13). However, under NO circumstances should you run the RMBWV3nn update report before successfully completing the initialization request

With "Delta direct", the initialization request must be successfully closed.

Additional information:

You may have to reconstruct individual documents or document groups and transfer them to BW again. In this case, you should carry out the steps described in the same way.

With this type of selective reconstruction of individual documents or, for example, specific organizational units, you must ensure that any existing data in BW is selectively deleted.*

basically what happens is that Direct delta directly transfers data to the RSA7 queues while queued delta picks up the values in the SMQ1 queues and you need to run the V3 job to transfer these to the RSA7 queues.

During the init phase, the RSA7 queue is not created, so if you are using direct delta, and a document is changed, you loose the change. If you are using Queued delta, then the document changes are captured in the SMQ1 queues. On completion of the init, you then run the V3 job and transfer the data to the RSA7 queues and then to BW. So depending on your model (if you are using a DSO etc), the data may get duplicated.

Hope this helps.

Regards.

[Former Member]

Hi,

I agree with you guys, but I believe there is a reason behind why the Notes said Queued Delta has benefit over Direct Delta when performing restructuring.

Yup, there is indeed time saving in Queued delta but you have probably misinterpreted it. With queued delta what you do is following.

1. Lock the users

2. Set up the datasource in Queued delta mode

3. Load the setup table.

4. Unlock the users.

5. Carry out init with data transfer

6. Run the V3 job.

whereas in the Direct delta, you can unlock the users only after the Init is completed.

What exactly happens is that until Init is completed, no postings can be made to RSA7 because the target system is not yet identified. If any postings are made by datasources in direct delta in this duration, those transactions will be lost. With queued delta, the transactions stay in outbound queue(it doesn't check for target system here) & once the init is completed & target system is identified by SAP, we can run the V3 job which would post these entries to RSA7.

Regarding the reduction in lock out period during setup table run, there is an option for you

If you can identify the time-range/ document range which would not be changed again, you can do setup table run for them in advance without locking users & wait for lockout period to fill only those ranges which can still be changed.

[Former Member]

Thank you for the replies but there is still a doubt.

Let simulate the condition like Rahul did.

1. Lock the users

2. Set up the datasource in Queued delta mode <= here Extraction Queue created and V1 will start to capture delta if there is change.

3. Load the setup table + unlock users. <= according to the Notes, during setup table runtime, we already can release the user lock.

4. Carry out init with data transfer

5. Run the V3 job.

The problem is on between point 3 and 4, Extraction Queue could have same data in the Setup table and eventually will be transfered to BW via Delta queue.

Is it true and how should we do?

Thanks

Halomoan

[former_member182470]

Hi,

I don't think you could do that. While filling Setup tables, we need to take down time and lock the Users/data postings etc..

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/90fddfcd-a956-2d10-19be-8f7bdd699a05

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/80f4c455-1dc2-2c10-f187-d264838f21b5

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f0709b9f-acbc-2c10-7a95-ab0ee18b921c

Regards,

Suman

Edited by: Jason Lax on Dec 28, 2011 2:18 PM (Updated URLs to correct format)