cancel
Showing results for 
Search instead for 
Did you mean: 

2LIS_02_SCL in LBW1

Former Member
0 Kudos

Hello,

Which update method (trans. code LBW1) is to be recommended for extractor 2LIS_02_SCL? I use the synchronous update (with delta for BW), but I'm not fully sure of the exact differences between the methods (V1, V2, V3 etc.).

Furthermore, is it necessary to do some settings in "application specific setup of statistical data". I have loaded my cube via the LIS-extractor and everything seems to work fine...

Thanks,

Fredrik

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi dear!

Did you read some of my related weblog ?

Anyway, you have to choose between direct, queued or unserialized delta...about which mechanism (V1, V2 or V3) these methods use, refer to

/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods

Hope it helps!

Bye,

Roberto

..about "statistical...", this function refer to setup table filling job (OLInBW...), that you need to perform in order to have data for initial or full upload!

Former Member
0 Kudos

Hello again and thanks!!!

About statistical; I was referring to the appl specific setup of stat data relating to "managing transfer information structures". In this tran code it is possible to copy/delete versions, PURCHIS Statistical Setup, LIS/Setup/Log. This does not seem really necessary since I have not yet touched this part and still it works... Am I right?

Furthermore I use update mode "Queued delta" in LBWE (Logistics cockpit). Then in LBW1 (movement data for logistics) I use the synchronous update type. Would you recommend this combination?

Thanks,

Fredrik

Former Member
0 Kudos

Hi Fredrik,

I think you are mixing the old LIS datasources with the new Logistic Cockpit datasources !!!

You need only to take care about LBWE settings and OLI3BW transaction in order to fill setup table for your initial dataload !

Hope now is clearer...

Bye,

Roberto

Former Member
0 Kudos

Thanks a lot!

You've been a great help!!!!

Points are awarded.

Best regards,

Fredrik

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Fedrik,

Here are few points about V1,V2 & V3 updates:

V1 - Synchronous update

V2 - Asynchronous update

V3 - Batch asynchronous update

These are different work processes on the application server that takes the update LUW (which may have various DB manipulation SQLs) from the running program and execute it. These are separated to optimize transaction processing capabilities.

Taking an example -

If you create/change a purchase order (me21n/me22n), when you press 'SAVE' and see a success message (PO.... changed..), the update to underlying tables EKKO/EKPO has happened (before you saw the message). This update was executed in the V1 work process.

There are some statistics collecting tables in the system which can capture data for reporting. For example, LIS table S012 stores purchasing data (it is the same data as EKKO/EKPO stored redundantly, but in a different structure to optimize reporting). Now, these tables are updated with the txn you just posted, in a V2 process. Depending on system load, this may happen a few seconds later (after you saw the success message). You can see V1/V2/V3 queues in SM12 or SM13.

V3 is specifically for BW extraction. The update LUW for these is sent to V3 but is not executed immediately. You have to schedule a job (eg in LBWE definitions) to process these. This is again to optimize performance.

V2 and V3 are separated from V1 as these are not as realtime critical (updating statistical data). If all these updates were put together in one LUW, system performance (concurrency, locking etc) would be impacted.

Serialized V3 update is called after V2 has happened (this is how the code running these updates is written) so if you have both V2 and V3 updates from a txn, if V2 fails or is waiting, V3 will not happen yet.

Hope it helps!!!!

Amit