Update Database (ABAP) with special technology
One, the process
The 1,dialog program obtains the data that the user wants to update and writes it to a special log table, where the entries in the table belong to the same request type and contain data that will be written to the database later. A dialog program can write multiple data to log TABLE. Entries written into the log table belong to the same luw, meaning that they are either executed or not executed.
The 2,dialog program closes the LUW (package the entry for log table) and notifies the system that the basic program has a packet of data that needs to be updated.
3, the System Basic program reads the LUW data from log table and provides this data to the system updater.
4, the System updater accepts the data that is transmitted to it and updates the database.
5, if the update runs successfully, the system basic program deletes all data for this LUW in log table, and if it fails, the log table data is persisted and the token is unsuccessful. The user who triggered the update receives an e-mail message from the system about the error. You can use the parameter Rdisp/vbmail (1 rounds, 0 not issued) to control the error when e-mail and Rdisp/vb_mail_user_list ($ACTUSER on behalf of the user to create updated data) to control the error when e-mail to whom. You can use transaction SM13 to monitor update requests.
Second, technology realization
The updater must be implemented with a special FM (update module). The UPDATE module, like the other FM, has an interface for transmitting parameters, but only importing and tables, and the type can only be referenced or structured. The exporting and exception parameters are ignored in the update module. The update module contains the actual database update statements.
In the dialog program, the in UPDATE TASK is used with a special FM. Such as:
Call Functon ' F1 ' in UPDATE TASK
Exporting
P1 = A
P2 = B.
The FM that uses this notation is not executed immediately, but is written into the log TABLE, and as an execution request, an update request under an SAP LUW is stored under the same update key. For an SAP LUW, update key is a unique world-wide identifier, meaning that an SAP LUW update key is unique and will not be duplicated with the other SAP LUW update key.
Only when the program executes to the commit work will a header entry log header be created for these requests, indicating that these same update keys belong to the same package, and then the system shuts down the LUW. When the log header is created, the system notifies dispatcher that an update package is ready to be processed.
Sometimes, you may need to discard all changes of the current SAP LUW (such as End tcode), you can use rollback work or pop up a type a message, both of which can have the following effects:
-Delete all change requests before writing to this point
-Delete all locks before writing to this point
-Discards the changes of the current DB LUW execution
-Discard all subroutines registered in POC form
The ROLLBACK work statement does not affect the program context, meaning that all data objects remain intact. Display rollback work or commit work statements are not allowed in the UPDATE module.
If the update fails, the log entry belonging to this SAP LUW is flagged incorrectly, and the error message is saved to the log. You can use SM13 to check the log entries.
If the lock is set for the update technology in the dialog program, and the lock parameter _scope = 2, then the lock is passed to the update TASK with the commit work, and the lock cannot be accessed at this time in the dialog program.
The release lock does not have to be shown in the update module, because these locks are automatically released by the system as the last stage of the update process. Locks are also released automatically when an update task error occurs.
If the update module allows updating requests to be processed again, the data tables in the database may not be the same when they are processed, and there is no lock protection, because the locks are automatically released when the error occurs.
For example, if a credential is not successfully updated to the database because the database table space overflows, this time is more suitable for processing again.
Third, the updated mode
1, asynchronous mode
In this mode, the dialog program and the update program run separately. The dialog program writes a request to log TABLE and uses a commit work to close LUW. The update program is triggered by commit and starts running to process these requests, and the dialog program continues to run without waiting for the update program to end. The update program runs in a special update work process.
Asynchronous updates are important when the database update takes a long time and user dialog needs less response time. In dialog processing, asynchronous updating is a standard technique, meaning that the dialog program generally takes the form of an asynchronous update.
You can use the Vblog cluster table to implement log table, or replace it with a transparent table vbhdr,vbmod,vbdata,vberror.
2, Sync mode
You can use the commit work and wait statement to trigger a synchronous update, and the dialog program waits for the update program to finish before proceeding to the next step.
If the subsequent processing or the end of the dialog program depends on the results of the update, this time use synchronous mode. The SY-SUBRC can be used to check the execution of the synchronous update, while the program waits for the update program to execute, the dialog program's dialog work process is released, and after the update is finished, the system assigns a new idle dialog to the dialog program. Work process to do the next step.
3, Local mode
Using the SET Update TASK Local statement to execute locally using the update module, the same commit work is used to close the SAP LUW, and the update will be done in the same dialog work process, The dialog program waits for the update to complete (synchronous). When the local update is complete, a displayed DB Commit,dialog program is submitted to continue execution.
If an update is executed with an error, and one of the update module sends a message terminating the program, an automatic db rollback is executed to discard all changes to the SAP LUW, and the dialog program terminates with a popup program termination information.
In the LOCAL update mode, the update request is not written to the Vblog table, but in main memory, because there is no IO access, which is faster than the synchronous and asynchronous modes. The LOCAL update is only suitable for batch mode.
The Set update task local works until the commit work statement is encountered, meaning that the Set Update task local is no longer valid after the commit job executes.
Four, type of UPDATE module (V1&V2)
The processing type of the FUNCTION MODULE has three types, the NORMAL fucntion module,remote-capable module and the update module. Each of the following also contains 4 categories, start immediately, start immediately (not restart), delay the start, collective run. The first 2 types belong to V1 type, the latter two belong to the V2 type.
The type of UPDATE module determines the mode in which it is processed. All V1 requests in the dialog program will be executed in a separate DB LUW. The V2 request will be processed only when the V1 executes successfully, and V2 will be executed in a separate LUWS.
The DB changes processed by the update module for the V2 type is generally followed by the changes (MAIN changes) of V1.
The update module of the V1 type can be restarted or not restarted in two ways. The V2 type can always be restarted and processed again when an error occurs.
The V2 type of collective run is used internally by SAP. The corresponding V2 request is not executed directly after the V1 executes, but only after the program RSM13005 is called.
V1 requests are created by the V1 type Update module, and for synchronous asynchronous mode, the V1 type of update module creates the request to the Vblog table, and for the local update mode, the V1 request is created in main memory. Requests of type V2 are always created into the Vblog table.
V1 requests are handled in a V1 type of update work process (UPD) as a separate DB LUW. If the V1 update succeeds, the system deletes the V1 request and all locks on the V1 update task, sets a DB COMMIT, and then triggers the V2 update.
The V2 request is also handled in a V2 type of update work process (UPD2) as a separate DB LUW. If the SAP system does not set the V2 type of update work process, the V2 request is processed in a V1 type of update working process. If the V2 request processing succeeds, the related request is removed from Vblog and a DB COMMIT is set. V2 requests generally run without locks, because they are deleted after the V1 is complete. Therefore, the V2 update always runs without the SAP locks.
If the V1 update module terminates V1 updates with a terminating message, the lock on the V1 update task is deleted, the database is rollback, an e-mail is sent to the user who created the LUW, and the V1 request is marked as incorrect in the Vblog table. V2 updates will not be triggered.
If, of course, the V2 update module terminates the V2 update, the same, the database rollback, the V2 update belonging to this SAP LUW is not executed, and the V2 request is marked as incorrect in the Vblog table.
The locks created by the dialog program with _scope = 2 are passed to the V1 update task, which is automatically deleted at the end of the V1 update, regardless of whether the V1 update was successful or terminated. Therefore, you cannot explicitly delete these locks (too early) in the dialog program, or delete them (not necessary) in the update module.
Update Database (ABAP) with special technology
