SAP V1 V2 V3 JOBS
Before starting with V-series jobs, lets review some fundamentals.
Data base LUW: It consists of sequence of DB operations(INSERT,UPDATE,DELETE) that needs to be committed to either all or none to keep DB in consistent state. COMMIT will be executed when all DB operations were successfully executed, once COMMITTED these changes can't be ROLLED BACK. This is part of traditional ACID property of any RDBMS. If a failure happens while executing the LUW(will be mostly technical like memory crunch,integrity violation or data base crashed,power failure) and when DB is restarted, DB will be ROLLed BACK to previous state. Which is nothing but the state when last COMMIT was happened. In other words, when ROLL BACK happens DB will be safely brought to previous COMMIT state. DB maintains log of actions performed since last COMMIT and as part of recovery process, all these actions will be reversed. All RDBMS will have in-built locking/multi concurrency control such that dirty READ-WRITE operations will be avoided.
In context of SAP, a DB LUW will be executed implicitly in below situations, however we can always perform explicit always.
1. When a screen PAI is executed and before displayed to user for input again, in other words screen returns to SAP GUI
2. Due error/status message, screen is showed to user
3. When a report is executed
Simply, before rendering screen all the DB operations till that point will be COMMITTED. However this process wont work for SAP transactions which consists of multiple screens. In VA01, we will traverse through many screens before pressing save button(sales, schedule lines,tax terms).Lets say if we have screens 100, 200, 300 in our code, a COMMIT happens when we go to 200 screen once, 300 screen once. Clearly this is not the case with dialog programming where we traverse through many screens and SAVE operation depends on many external factors. Hence for SAP dialog programming, in informal context, COMMIT operation needs to happen only when SAVE button is explicitly clicked and we have to avoid implicit DB commits for each screen.
SAP LUW
Hence SAP came up with SAP LUW concept. As DB LUW contains all the DB operations set, SAP LUW bundles all the DB operations from the whole transaction across all screens. Once the ABAP COMMIT WORK statement is executed, this SAP LUW gives all the set of operations to DB and DB LUW is executed. While we traverse across screens, SAP LUW keeps collecting all DB operations through out the program and DB COMMIT is executed only once.
Note : for ABAP reports, even though we don't issue COMMIT WORK explicitly, COMMIT will be done while exiting report.
SAP Locks: As mentioned earlier, all RDBMS will have default locking mechanism. Whenever any CRUD operation is being done, DB locks the table for that moment. However, in SAP context, we want keep the table/rows to be locked while traverse across screens, input data. Hence we need locks to be existing for longer times while keeping other users modifying the table data.
when a user searching for flight data, we want him to see consistent data till he finishes his booking operation. To achieve this we use SAP locking mechanism. These locking objects needs to be created in ABAP dictionary before putting to use(we aren't discussing about how to create lock objects).
To read data from table, we request Shared lock, to modify we request Explicit lock. When we ENQUEUE a table, corresponding entry will be made in locking server/message server(in case multiple instances) and further requests(shared and explicit) will be rejected in case of explicit lock. However, multiple shared locks can be requested. In order to allow other users to read/write to these tables, we need to DEQUEUE tables at end of program.
Note: Locking is implemented only in application server instance and specific to SAP. These locks wont be existing in DB physically. Hence this requires co-operation from other programmers. All developers needs to use ENQUEUE/DEQUEUE in their objects.
UPDATE MODULES :
Having understood these concepts, the best way to handle data updations is to combine them in a module.
Dialog modules program structure will be like,
1. Accepting input from user
2. Validate data, search for all possible violations,confirmations
3. Collect and call update module to execute SAP LUW
This could be done by executing updates via a CALL FUNCTION .....IN UPDATE TASK. This will start a new LUW and executes all operations in sequence at once. This LUW will be invoked when a COMMIT WORK statement is executed. Hence when the input validations are done, we can call this FM. The FM interface data will be stored in VBHDR, VB* tables. When the COMMIT is executed in the end, this FM will be executed. Although the program is exited,this LUW works in a separate process. Hence program need not wait till all DB actions will be saved. This is known as Asynchronous processing. Also, when we have multiple independent set of operations like tax and stock operations, these could be called in two UPDATE TASKS which will execute concurrently in different work processes. However when COMMIT WORK AND WAIT is issues, application program waits till the execution of LUW is done.
V1 V2 jobs : Further optimization can be done by executing critical updates immediately and non-critical updates later. While creating sales order when an LUW is triggered, VBAK,VBAP tables should be updated immediately. However SD statistic tables like S001 can be updated later. Hence updates to live tables are critical and needs to be executed immediately. Updates to statistic table can be done later. SAP came up with V1 updates for priority tasks and V2 for low priority tasks. To execute updates via V1 task, while creating FM to be called in UPDATE TASK, we needs to select "Start Immed" or "Immediate start, No restart" under Update Module section. To be excuted as V2 tasks, select "Start Delayed". We will talk about "Collective Run" in an other post.
Monitoring Updates
As mentioned earlier, if we perform updates asynchronously, it is important and interesting to see, how to handle update failures.
When data is passed to LUW for execution, failure mostly happens due to technical reasons not due to data issues. As we have to thoroughly check data for all validations and possible combinations of errors that might arise. When a failure happens, DB rolled back. Corresponding entry wont be deleted in VBHDR tables where as in case of green signal these entries will be deleted. Hence we can go to SM13 tcode to debug/reprocess these failed updates.
Whether the corresponding V1 task could be restarted or not depends on the option we selected in UPDATE module section in SE37. We have to keep monitoring this tcode and take appropriate actions for failures.
Data base LUW: It consists of sequence of DB operations(INSERT,UPDATE,DELETE) that needs to be committed to either all or none to keep DB in consistent state. COMMIT will be executed when all DB operations were successfully executed, once COMMITTED these changes can't be ROLLED BACK. This is part of traditional ACID property of any RDBMS. If a failure happens while executing the LUW(will be mostly technical like memory crunch,integrity violation or data base crashed,power failure) and when DB is restarted, DB will be ROLLed BACK to previous state. Which is nothing but the state when last COMMIT was happened. In other words, when ROLL BACK happens DB will be safely brought to previous COMMIT state. DB maintains log of actions performed since last COMMIT and as part of recovery process, all these actions will be reversed. All RDBMS will have in-built locking/multi concurrency control such that dirty READ-WRITE operations will be avoided.
In context of SAP, a DB LUW will be executed implicitly in below situations, however we can always perform explicit always.
1. When a screen PAI is executed and before displayed to user for input again, in other words screen returns to SAP GUI
2. Due error/status message, screen is showed to user
3. When a report is executed
Simply, before rendering screen all the DB operations till that point will be COMMITTED. However this process wont work for SAP transactions which consists of multiple screens. In VA01, we will traverse through many screens before pressing save button(sales, schedule lines,tax terms).Lets say if we have screens 100, 200, 300 in our code, a COMMIT happens when we go to 200 screen once, 300 screen once. Clearly this is not the case with dialog programming where we traverse through many screens and SAVE operation depends on many external factors. Hence for SAP dialog programming, in informal context, COMMIT operation needs to happen only when SAVE button is explicitly clicked and we have to avoid implicit DB commits for each screen.
SAP LUW
Hence SAP came up with SAP LUW concept. As DB LUW contains all the DB operations set, SAP LUW bundles all the DB operations from the whole transaction across all screens. Once the ABAP COMMIT WORK statement is executed, this SAP LUW gives all the set of operations to DB and DB LUW is executed. While we traverse across screens, SAP LUW keeps collecting all DB operations through out the program and DB COMMIT is executed only once.
Note : for ABAP reports, even though we don't issue COMMIT WORK explicitly, COMMIT will be done while exiting report.
SAP Locks: As mentioned earlier, all RDBMS will have default locking mechanism. Whenever any CRUD operation is being done, DB locks the table for that moment. However, in SAP context, we want keep the table/rows to be locked while traverse across screens, input data. Hence we need locks to be existing for longer times while keeping other users modifying the table data.
when a user searching for flight data, we want him to see consistent data till he finishes his booking operation. To achieve this we use SAP locking mechanism. These locking objects needs to be created in ABAP dictionary before putting to use(we aren't discussing about how to create lock objects).
To read data from table, we request Shared lock, to modify we request Explicit lock. When we ENQUEUE a table, corresponding entry will be made in locking server/message server(in case multiple instances) and further requests(shared and explicit) will be rejected in case of explicit lock. However, multiple shared locks can be requested. In order to allow other users to read/write to these tables, we need to DEQUEUE tables at end of program.
Note: Locking is implemented only in application server instance and specific to SAP. These locks wont be existing in DB physically. Hence this requires co-operation from other programmers. All developers needs to use ENQUEUE/DEQUEUE in their objects.
UPDATE MODULES :
Having understood these concepts, the best way to handle data updations is to combine them in a module.
Dialog modules program structure will be like,
1. Accepting input from user
2. Validate data, search for all possible violations,confirmations
3. Collect and call update module to execute SAP LUW
This could be done by executing updates via a CALL FUNCTION .....IN UPDATE TASK. This will start a new LUW and executes all operations in sequence at once. This LUW will be invoked when a COMMIT WORK statement is executed. Hence when the input validations are done, we can call this FM. The FM interface data will be stored in VBHDR, VB* tables. When the COMMIT is executed in the end, this FM will be executed. Although the program is exited,this LUW works in a separate process. Hence program need not wait till all DB actions will be saved. This is known as Asynchronous processing. Also, when we have multiple independent set of operations like tax and stock operations, these could be called in two UPDATE TASKS which will execute concurrently in different work processes. However when COMMIT WORK AND WAIT is issues, application program waits till the execution of LUW is done.
V1 V2 jobs : Further optimization can be done by executing critical updates immediately and non-critical updates later. While creating sales order when an LUW is triggered, VBAK,VBAP tables should be updated immediately. However SD statistic tables like S001 can be updated later. Hence updates to live tables are critical and needs to be executed immediately. Updates to statistic table can be done later. SAP came up with V1 updates for priority tasks and V2 for low priority tasks. To execute updates via V1 task, while creating FM to be called in UPDATE TASK, we needs to select "Start Immed" or "Immediate start, No restart" under Update Module section. To be excuted as V2 tasks, select "Start Delayed". We will talk about "Collective Run" in an other post.
Monitoring Updates
As mentioned earlier, if we perform updates asynchronously, it is important and interesting to see, how to handle update failures.
When data is passed to LUW for execution, failure mostly happens due to technical reasons not due to data issues. As we have to thoroughly check data for all validations and possible combinations of errors that might arise. When a failure happens, DB rolled back. Corresponding entry wont be deleted in VBHDR tables where as in case of green signal these entries will be deleted. Hence we can go to SM13 tcode to debug/reprocess these failed updates.
Whether the corresponding V1 task could be restarted or not depends on the option we selected in UPDATE module section in SE37. We have to keep monitoring this tcode and take appropriate actions for failures.
Comments
Post a Comment