sap organizing database update

在一个transaction中应当把所有的database update捆绑到一块在一个dialog step中执行。在transaction中你需要把每个screen上要保存到database中的数据先存储在program的全局变量中，然后在最后一个dialog step一次把要改变的数据存储到数据库中。可以通过PERFORM <subroutine> ON COMMIT来实现将要改变的数据bundle在一起。PERFORM <subroutine> ON COMMIT用来注册subroutine直到遇到commit work语句时才会执行。如果在subroutine有database update，可以利用这个语句把database update从program logic中分离出来，在每个LUW上只执行一次PERFORM ON COMMIT。PERFORM ON COMMIT不允许嵌套。Commit work语句执行所有registered subroutine并在一个luw中更新数据库。在每个subroutine中如果更新失败都要报A MESSAGE，这样database会rollback，数据库又恢复到原来的consistency状态。PERFORM ON COMMIT的subroutine不能有interface它们所使用的必须是global data object。在程序内部执行update的特点：
l         简单，能够迅速实施
l         但是用户必须等到更新完成后再能进行其他的动作
l         Dialog work process并没有被释放
l         没有error log

l         多个database work process同时工作，影响数据库性能
l         不支持一些系统功能，所有的工作都要在程序中实现
l         适用于light LUWS或对系统性能影响不大的luw

更新原理：用户通过dialog program收集用户输入的数据，然后把修改后的数据传递给update program更新数据库中的数据。Dialog program和update program是在不同的work process中执行的。Update的步骤如下：
l         Dialog program接受用户输入的数据将其写到特殊的log table中。存储在log table中的数据将会被更新到数据库中。一个dialog program可以在log table中写多条记录。Log table中的记录代表了一个LUW，遵循all or nothing原理。
l         Dialog program关闭写入log table的logical data packed(LUW)然后通知basis system有数据要被更新。
l         Basis system读取log table中的数据并将其传递给update program

l         Update program接受传递过来的数据并更新数据库对应的纪录
l         如果update成功，basis system就会删除Log table中的记录。如果出现错误，这些记录就会保留在log table中，并标记为incorrect，触发update error的用户就会收到一个express email。可以通过参数rdisp/vbmail和rdisp/vb_mail_user_list。Rdisp/vbmail可以设为0或1（出现error时是否发送邮件）rdisp/vb_mail_user_list定义了出现update error时谁会收到邮件$ACTUSER代表触发update error的用户。可以通过SM13来监视update request。
为了实现update concept，除了需要在dialog program中收集用户输入的数据外还需要特殊的FM：update module。Update module跟其他module相似，也有interface，不过其interface只有IMPORTING和TABLES parameter。这些参数必须通过referenced fields或structure来定义类型。Export parameters和exceptions在update module中被忽略了。这个function module中包含实际的数据库更新语句。

       通过在dialog program中调用update module来创建update request。通过IN UPDATE TASK addition来表明这个function module不是立即执行的，而是跟他的input data一起写入了log table中。一个SAP LUW的update requests有相同的update key。他是SAP LUW的唯一标识。仅当碰到COMMIT WORK语句时，绑定在一起的update requests创建一个header entry。然后系统就会将这个unit close。当log header被创建后，系统就会告诉dispatcher一个update package已经准备好被处理了。

       有时候你可能想清掉当前SAP LUW中的到目前为止的change requests，比如你terminate当前transaction，可以通过ROLLBACK WORK或发送dialog A message来实现这一目的，这些动作都会导致：

l         到目前为止的所有change requests都会被删掉
l         到目前为止的所有lock都会被删掉
l         当前所有DB LUW的所有执行的数据更新都回被discard
l         所有通过语句PERFORM ON COMMIT注册的subroutine都会被discard
ROLLBACK WORK不会影响program context，也就是说程序中的所有变量都是unchanged状态。

       如果想在update module中触发一个database rollback，可以通过发出A dialog message来实现。它同时也终止了当前的SAP LUW。属于这个SAP LUW的log entry就会被标识为出现error，termination message也会写入到log中。可以通过SM13来查看这些log entry。系统会给相关用户发送express mail，告诉他相关的update被终止。同样你也需要配置相应的参数rdisp/vbmail和rdisp/vb_mail_user_list。在ABAP module中你不能使用COMMIT WORK或ROLLBACK WORK语句。
    如果在update technique与dialog program的locks一起，并且lock被设置为_scope = 2，你可以在COMMIT WORK把这些传递给update task。这样在dialog program中他就不再accessible了。在update module中你不需要explicitly释放lock，basis program会在更新结束之后自动释放lock。如果出现错误时，lock也会被自动释放。如果update module允许出现错误的update request可以被重处理，那么重处理的过程与失败时的处理就会不同，也就是lock就不会存在，因为lock在出现错误时已经被释放掉。比如如果因为table space的overflow导致的更新失败就会需要重处理。
    对于asynchronous update，dialog program和update program是分开执行的：
l         Dialog program将change requests写到log table中，然后通过COMMIT WORK关闭这个LUW

l         COMMIT WORK激活update处理update requests。Dialog program继续并不用等到update结束。
l         Update program在一个特殊的update work process中进行，它可以位于SAP System中的另外一个application server。
Asynchronous update适用于需要较长时间的database update，缩短用户的dialog response time。你可以实施log table VBLOG在你的system中作为cluster file，也可以通过transparent table VBHDR VBMOD VBDATA VBERROR来替代。
可以通过COMMIT WORK AND WAIT来触发synchronous update，dialog program等待update结束后再继续执行。这种模式适用于后续的动作依赖于这次update的结果。可以通过sy-subrc来判断更新是否成功。在等待阶段，dialog program处于rolled out状态。这意味着相应的dialog work process处于释放状态可以被其他用户使用。一旦update完成，system就会给dialog program分配一个新的free的dialog work process。
    Local Update：update function运行在与当前的dialog program的同一个dialog work process上，当update完成后dialog program才能继续。为了使update locally执行必须使用SET UPDATE TASK LOCAL语句。通过COMMIT语句关闭UPDATE requests。当local update被成功执行，DB commit就会被触发，dialog program继续执行。如果任何一个update module出现error或报termination message，当前sap luw的data changes就会被会滚，当前的dialog program就会终止。在local update模式中，change requests并不会写到数据库表VBLOG中，而是写在内存中。这样的话它的performance要好于synchronous和asynchronous update。缺点是它会占用work process。所以local update只适用于batch mode。只有在当前的LUW没有产生任何change requests时才可以使用SET UPDATE TASK LOCAL语句。它只有在下个commit语句前起作用。
    有两种类型的update module，V1和V2。UPDATE MODULE的mode决定了其处理方式。所有的V1 requests都是作为独立的DB LUW。只有V1 requests被成功处理V2requests才会被处理，也是作为一个独立的LUW。V2 UPDATE MODULE用于与v1 UPDATE相关的database update却又没有必要和V1 requests位于同一个DB LUW。V1可以被设为可以restart或不可以restart。可以通过SM13来restart出现错误的change request。V2 UPDATE MODULE总是可以被restart。Collective run update module使用与SAP内部的V2 UPDATE MODULE。相应的requests并不在V1 UPDATE之后执行，而在调用collector program RSM13005之后执行。V2 REQUESTS总是被存储在VBLOG TABLE中。V1 REQUESTS在v1 update work process中处理，只有在v1 update处理成功后，v1 requests被删除，所有的locks传给update task，并设置一个DB COMMIT。才会触发V2 UPDATE。V2 requests在V2 UPDATE WORK PROCESS中处理，他们也组成一个独立的DB LUW。若在系统中没有设置V2 UPDATE WORK PROCESS那么v2 request会在v1 update work process中处理。如果v2 requests处理成功，那么相应的记录也会在VBLOG中删除，同时设置一个DB COMMIT。V2 requests通常是在没有lock的情况下处理，因为这些lock已经在v1 update完成后删除了。如果v1 update出现错误，传给update task的lock就会被删除，并产生DB rollback，相关用户就会收到express mail。VBLOG中相应的记录就会写入termination message。V2 UPDATE不会被触发。然而当v2 update失败时会触发一个database rollback。SAP LUW的v2 changes会被undone，VBLOG中的相应记录会被标识error。在dialog program中_scope = 2的lock会在v1 update完成后或出现error时删除掉。所以lock entries不能被explicitly删除（有可能会太早）或者在update module中删除。V2 update总是在没有lock的情况下执行。

       每当要更新数据库中的记录时，相应的记录就会被lock，直到当前的LUW结束。这同样适用于语句SELECT…FOR UPDATE。但是处于性能的考虑，应当使这些锁的时间越短越好。这是因为在physical lock下要访问这些记录是不可能的。这样你需要遵循下面的原则设计inline change和update module：

l         首先插入新的记录

l         执行对性能影响不大的database update

l         最后执行对性能影响比较大的数据库的更新操作。

可以通过PERFORM ON COMMIT更新central table。把central table的update封装到update module相应的function group中。这些form routine直到最后一个update module处理完后才会被执行。不过要记住这些form routine必须得使用function group的global data。