Function Module Attribute : Update module in attributes of FM simply flags the FM not to be executed directly.

Prerequisites: When you are working with the SAP update system, it is important to make sure that only insert, update and delete statements are executed in the update. The necessary data should, of course, be gathered together beforehand (using select and so on). It skips the update Function Module and its coding till it reaches COMMIT/ROLLBACK statements. Once it finds it will go back and execute that Update Function Module.So it satisfies the concept of LUW. Update Function Modules are used for SAP Logical Unit of Work. This function modules are triggered when an Explicit or Implicit COMMIT WORK is encountered. It is basically used to bundle distributed updates within different programs spots, to one place (in FM). Such FM would store all the UPDATE/INSERT/DELETE statements which otherwise you would write in some program place. Now when system reaches CALL FUNCTION 'XXX' IN UDPDATE TASK it doesn't go inside. Instead in registeres this XXX FM in VBLOG table (you can see update tasks in SM13) to be executed later. Now when in program it reaches COMMIT WORK statement, it looks into that table and calls each registered functions. The aim is to either COMMIT all the changes at once, or ROLLBACK them all. This means that if inside one of any FM these statements are encountered system writes changes to DB permanently. Next it clears VBLOG table (so no FM are registered for change anymore) and continues the program. if you are asking yourself what is the reason for use of such bundling techniques. It is because [DB LUW differs from the SAP LUW. It is just a smaller part of the latter and is used to submit changes (permanently) in DB after each UPDATE/INSERT/DELETE. In case of later errors during DB update you could then no longer restore previous state of DB with ROLLBACK. That's why SAP created its own SAP LUW.

Example The real time example would be debiting money from one account and transferring this amount to different account. In such case first you would debit account (UPDATE) but DB would perfrom COMMIT. Now, if for some reason (i.e. loosing the connection) next UPDATE

(transferring them to target account) would not be reached, were would be your money? SAP LUW easily solves this issue:)

Update with immediate start ( V1 Job) Update w. imm. start, no restart (V1 Job) Update with delayed start (V2 Job) Collective Run (V3 Job)

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.

The V1 modules are processed consecutively in a single update work process on the same application server. This means that they belong to the same database LUW and can be reversed. Furthermore, V1 updates are carried out under the SAP locks of the transaction that creates the update. This ensures that the data remains consistent; simultaneous changes to the objects to be updated are not possible. All V2 updates are carried out in a separate LUW and not under the locks of the transaction that creates them.

Update tables can be bypassed (if you use 'direct' or 'queued' delta instead of V3) to send the updates (data) directly to the BW queue (delta queue). V3 is however better for performance and so it is an option alongwith others and it uses update tables.

Difference Between Direct Delta/Queued Delta/Unserialized V3 Update : Direct Delta: In case of Direct Delta LUW's (Logical Unit of Work) are directly posted to delta queue (RSA7) and we extract the LUW's from delta queue to SAP-BW by running delta loads. If we use direct delta it degrades the OLTP system performance because the LUW's are directly posted to the delta queue (RSA7), the application is kept waiting until the enhancement code is executed. RSA7 ---> SAP-BW

Queued Delta: In case of Queued Delta LUW's are posted to extractor queue (LBWQ). By scheduling the V3 jobs we move the documents from LBWQ to RSA7 and we extract the LUW's from delta queue to SAP-BW by running the delta loads. Queued Delta is recommended by SAP, it maintains the extractor log which is to handle the LUW's which are missed. LBWQ --- > RSA7 --- > SAP-BW

Unserialized V3 Update: In case of unserialized v3 update LUW's are posted to update queue (SM13). By scheduling the v3 job which moves the document from LBWQ to RSA7 and we extract the LUW's from delta queue to SAP-BW by running delta loads. SM13(update Queue) -- > LBWQ --- > RSA7 ---- > SAP-BW