RE:logical unit of work

Hi guys,
What do u mean by logical unit of work...Can anyone explain me with an example.
Regards,
Alex.

hi,
this gives complete idea
SAP LUW
Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
Two techniques are available for bundling the change statements in a database LUW:
Bundling via function modules (update)
Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
Bundling via function modules (transactional RFC)
Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
Bundling via subprograms
Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
Statements for SAP LUWs
A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
Note
A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
COMMIT WORK
Variants:
1. COMMIT WORK [AND WAIT].
2. COMMIT CONNECTION con.
Effect
Terminates an SAP LUW and stores the changes.
Variant 1
COMMIT WORK [AND WAIT].
Effect
The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
It executes all subroutines registered using PERFORM ON COMMIT.
It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
It initiates the processing of all registered update function modules in the update work process.
This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
It triggers a database commit that also terminates the current database LUW.
The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
System fields
sy-subrc Meaning
0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
Note
The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
Variant 2
COMMIT CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
On the specified secondary database connection, the database commit:
Closes all open database cursors (OPEN CURSOR)
Releases all database locks
Note
Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
Exceptions
Non-Catchable Exceptions
Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
Cause: COMMIT WORK is not allowed in the update.
Runtime Error: COMMIT_IN_POSTING
ROLLBACK WORK
Variants:
1. ROLLBACK WORK.
2. ROLLBACK CONNECTION con.
Effect
Terminates a SAP-LUW without storing the changes.
Variant 1
ROLLBACK WORK.
Effect
The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
Executes all subprograms registered with PERFORM ON ROLLBACK.
Deletes all subprograms registered with PERFORM ON COMMIT.
Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
Triggers a database rollback, which also ends the current database-LUW.
After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
Variant 2
ROLLBACK CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
Notes
As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
Exceptions
Non-Catchable Exceptions
Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
Cause: ROLLBACK WORK is not allowed within an update.
Runtime Error: ROLLBACK_IN_POSTING
SET UPDATE TASK LOCAL
Syntax
SET UPDATE TASK LOCAL.
Effect
This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
System fields
sy-subrc Meaning
0 The local update function is activated.
1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
Notes
The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
The occurrence of a database rollback during the local update affects all previous change requests.
Regards
vasu

Similar Messages

  • What is luw (logical unit of work)

    pls tell me what is luw (logical unit of work)
    what r the types of luw .
    2 what ispurpose of code inspector and extended program check
    pls expalin the diffrence b/w those two
    3what are the candidate keys in db tables
    4 what is the difference b/w  occurs 1 and occurs 2 clauses
    data : begin of itab occurs 0 .
    data : itab type standard table of structure type initial size 1 with header line
    pls tell diffrence between theese two statements
    5can u pls tell what is the client in sap
    pls tell answers to questions
    pls dont give any websites addresses to see answers
    6 what is the transaction from database point of view
    7 what is the variant in alv reports
    how do we use reuse_alv_grid_variant_get fun module in alvs

    hi,
      this gives complete idea
      SAP LUW
    Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
    To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
    Two techniques are available for bundling the change statements in a database LUW:
    Bundling via function modules (update)
    Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
    Bundling via function modules (transactional RFC)
    Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
    Bundling via subprograms
    Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
    Statements for SAP LUWs
    A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
    Note
    A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
    COMMIT WORK
    Variants:
    1. COMMIT WORK [AND WAIT].
    2. COMMIT CONNECTION con.
    Effect
    Terminates an SAP LUW and stores the changes.
    Variant 1
    COMMIT WORK [AND WAIT].
    Effect
    The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
    It executes all subroutines registered using PERFORM ON COMMIT.
    It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
    It initiates the processing of all registered update function modules in the update work process.
    This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
    If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
    In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
    It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
    It triggers a database commit that also terminates the current database LUW.
    The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
    If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
    In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
    In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
    You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
    System fields
    sy-subrc Meaning
    0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
    4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
    The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
    Note
    The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
    Variant 2
    COMMIT CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
    On the specified secondary database connection, the database commit:
    Closes all open database cursors (OPEN CURSOR)
    Releases all database locks
    Note
    Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
    Exceptions
    Non-Catchable Exceptions
    Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
    Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
    Cause: COMMIT WORK is not allowed in the update.
    Runtime Error: COMMIT_IN_POSTING
    ROLLBACK WORK
    Variants:
    1. ROLLBACK WORK.
    2. ROLLBACK CONNECTION con.
    Effect
    Terminates a SAP-LUW without storing the changes.
    Variant 1
    ROLLBACK WORK.
    Effect
    The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
    Executes all subprograms registered with PERFORM ON ROLLBACK.
    Deletes all subprograms registered with PERFORM ON COMMIT.
    Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
    Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
    Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
    Triggers a database rollback, which also ends the current database-LUW.
    After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
    Variant 2
    ROLLBACK CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
    Notes
    As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
    After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
    ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
    The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
    Exceptions
    Non-Catchable Exceptions
    Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
    Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
    Cause: ROLLBACK WORK is not allowed within an update.
    Runtime Error: ROLLBACK_IN_POSTING
    SET UPDATE TASK LOCAL
    Syntax
    SET UPDATE TASK LOCAL.
    Effect
    This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
    At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
    System fields
    sy-subrc Meaning
    0 The local update function is activated.
    1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
    Notes
    The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
    The occurrence of a database rollback during the local update affects all previous change requests.

  • Logical units of work

    I was wondering and now sure so i am asking this questions
    How many logical units of work can you have in a stored procedure?

    872959 wrote:
    I was wondering and now sure so i am asking this questions
    How many logical units of work can you have in a stored procedure?when all else fails, Read The Fine Manual!
    http://docs.oracle.com/cd/E11882_01/server.112/e25513/limits003.htm#i288032
    The limits typically range from 2000 to 3000 lines of code.
    Handle:      872959
    Status Level:      Newbie
    Registered:      Jul 16, 2011
    Total Posts:      56
    Total Questions:      32 (26 unresolved)
    why so many unanswered questions?
    Edited by: sb92075 on Dec 11, 2011 3:20 PM

  • Logical unit of work

    Hi all,
    Can help me regarding LUW(logical unit of work) and its importance in r/3 ?
    Thanks and Regards
    Ravi

    Hai Ravi Charan
    There are 3 types of LUW's available in SAP
    1)Database Transaction or DBLUW
    2)SAP      Transaction or SAPLUW
    2)ABAP     Transaction or ABAPLUW
    1) DBLUW : when it is called it locks the rows , Update the rows & commit the rows issued by auto Commit
    2) SAPLUW : collection of Business reports is called SAPLUW and Issuing the Commit
    here UPDATE,INSERT,MODIFY statements are valid
    Commit work is given by Developer Side.
    3) ABAPLUW : What ever Transaction Code we are creating is called ABAPLUW  it is belongs upon Developers
    here 3 types of updates available
    1) Bundled Updates
    2) Un-Bundled Updates
      1) Bundled Updates :
        in Bundled Updates all your updates in a single unit of work present in a PERFORM 'XYZ'
    PERFORM 'XYZ' on Commit.
    here PERFORM-kept in Buffer 'XYZ' this form having all your update statements
    Priarities of execution.
    Perform xy on comit it will execute first
    perform ab on comit it will execute second
    I want to change this execution Order
    Perform xy on comit Level 2 it will execute second
    perform ab on comit Level 1 it will execute First
    because it will depends on Level command
    Using in Function Modules
    Call Function XYZ in Update Task.
    Commit work.
    In this case it stores in a buffer once encounters the commit statement this will executes from the buffer
    so it is an asynchronos method
    2) Un Bundled Updates
    these are two types
    1) Inline Updates
    2) Buffered Inline Updates
    1) Inline Updates : INSERT,UPDATE
    when update statement found in a program then it is called inline update and you should give the 'commit work'after a update statement
    inthe inline update if you not issue a commit work the system will automatically issues the commit work.
    2) Buffered Inline Updates:
    you will buffer all your inline updates and executes after Encounter the 'COMMIT WORK'
    100
       XYZ --> we can not roll back here
    200
       ABC---> if here is using commit
    Thanks & Regards
    Sreenivasulu P

  • Logical unit of works

    Can some one tell me abt logical unit of work(LUW).

    Hi,
    A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
    LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
    An LUW begins
    o each time you start a transaction
    o when the database changes of the previous LUW have been confirmed (database commit) or
    o when the database changes of the previous LUW have been cancelled (database rollback)
    An LUW ends
    o when the database changes have been confirmed (database commit) or
    o when the database changes have been canceled (database rollback)
    Two types of LUW are:
    1)      DB LUW - A database LUW is the mechanism used by the database to ensure that its data is always consistent. A database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it had before the transaction started.
    2)      SAP LUW - A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes.
    More on this .
    http://help.sap.com/saphelp_nw2004s/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm
    Regards,
    Raghav

  • Sequencing 3 sceanrios as one logical unit of work

    Hi,
    I have 3 business services BS1,BS2,BS3
    BS1 is source database DB1 which has 2 tables DB1_table1,DB1_table2
    BS2 is another source datbase DB2 which has one table DB2_table1
    BS3 is target database  DB3 which has 2 tables DB3_table1,DB3_table2
    And the  three scenarios are as below
    1.Data from DB1_table1 has to be inseted into DB3_table1  -
    from BS1 to BS3
    2.Data from DB1_table2 hasto be inserted into DB3_table2 -
    from BS1 to BS3
    3.Data from DB2_table1 has to be inserted into DB3_table2 -
    from BS2 to BS3
    But i want all these 3 sceanrios as one logical unit of work and 1,2,3 should be in a sequence.If any one of these fails remaining processes should fail. for ex if 1 fails 2,3 should not occur.
    How can i achieve this?
    Thanks & Regards,
    Jyothsna

    Hi,
      you can able to achive this using BPM.Check the below links for creating BPM scenarios..
    [https://weblogs.sdn.sap.com/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]]
    [Schedule Your BPM]
    [Walkthrough with BPM]
    [The specified item was not found.]
    [RFC Scenario using BPM --Starter Kit]
    [/people/sravya.talanki2/blog/2005/08/24/do-you-like-to-understand-147correlation148-in-xi]
    [The specified item was not found.]
    [One Logical System Name for serveral BPM Acknowledgements]
    [Illustration of Multi-Mapping and Message Split using BPM in SAP Exchange Infrastructure]
    [Posting multiple IDocs with Acknowledgement]
    Regards,
    Prakasu

  • Differences between Commit work, Logical Unit of Work and Roll back work

    Hi all,
    Can any one explain me in details what is the difference between Commit Work, Logical Unit of Work and Roll back work. Pls explain by providing some example.
    and also explain me where and when these are used and what are the importance of using these.
    Thanks in advance.
    Regards
    Ramana Prasad.T

    Hi Ramana Prasad,
    A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
    LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
    An LUW begins
    o each time you start a transaction
    o when the database changes of the previous LUW have been confirmed (database
    commit) or
    o when the database changes of the previous LUW have been cancelled (database rollback)
    An LUW ends
    o when the database changes have been confirmed (database commit) or
    o when the database changes have been canceled (database rollback)
    COMMIT WORK.
    Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that
    all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and
    all database locks are released.
    COMMIT WORK also
    calls the subroutines specified by PERFORM ... ON COMMIT * executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK ) specified in these subroutines or started just before,
    processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK ,
    cancels all existing locks (see SAP locking concept ) if no update requests exist,
    closes all open database cursors (see OPEN CURSOR ) and
    resets the time slice counter to 0.
    COMMIT WORK belongs to the Open SQL command set.
    Return code value
    The SY-SUBRC is set to 0.
    ROLLBACK WORK.
    Closes a logical processing unit by reversing all database changes made since the last COMMIT .
    You use this statement if you cannot be certain that all the database changes have been executed correctly.
    The update routines are not performed.
    ROLLBACK WORK belongs to the Open SQL command set.
    Note
    If the ROLLBACK statement occurs within a SELECT loop, the processing cannot continue because the database cursor is invalid. After the ROLLBACK statement, you should therefore ensure that all SELECT processing has been explicitly terminated.
    <b>Plz. Avoid Duplicate Threads.</b>
    Hope this resolves your query.
    Reward all the helpful answers.
    Regards

  • Bapi and Logical Unit of Work

    Hi all,
    I am using Bapi to post records in a loop on internal table itab. After posting records, I am again looping at itab and populating those records to my custom table.
    Does this scenario use 2 logical unit of work?
    If yes, then please tell me how do I use one logical unit of work.
    Thanks,
    Ridhima

    Hey,
    You should not post records to the custom table if the BAPI posting has failed.
    In order to maintain data consistency the logic in your program should be as below:
    LOOP AT itab.
    CALL BAPI.
    IF BAPI Call is successful
    Post data to Custom table.
    CALL BAPI_TRANSACTION_COMMIT.
    ELSE.
    CALL BAPI_TRANSACTION_ROLLBACK.
    ENDIF.
    ENDLOOP.
    Talking about LUW's, any program uses 1 SAP LUW and Multiple Database LUWs depending on the number times you COMMIT the data to the database.
    If in your program you were to use only one COMMIT statement or no COMMIT statement at all, your program would use 1 SAP LUW and 1 database LUW.
    -Kiran
    *Please mark useful answers

  • Can I create my own logical unit of work (LUW)?

    Good day, everyone!
    This is an off-shoot to a Why does the NOCOMMIT parameter not work in HR_INFOTYPE_OPERATION? yesterday in this forum.
    It appears that the FM I'm calling is going to do a commit, no matter what.  The only thing I can tell is that the NOCOMMIT parameter is used to do a rollback only in the event of a problem.
    What I'd like to do is somehow "encapsulate" my call to this function with my own "LUW" designation so that, depending on what a user selects in a selection screen (run as test only? checkbox) I can rollback changes on my own.  Unfortunately, I don't know if this is even possible and, if so, how to do it.  I need to do something because the end users running this function would like to be able to do a "test run" of all the address transactions to see if there's any errors, data that still needs cleaned up, etc.
    Any ideas?  Points awarded for all helpful answers, as always.

    Hai Dave Packard
    Go through the following Link
    For Logical database
    Logical Unit of Work (LUW)
    A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
    LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
    An LUW begins
    each time you start a transaction
    when the database changes of the previous LUW have been confirmed (database commit) or
    when the database changes of the previous LUW have been cancelled (database rollback)
    An LUW ends
    when the database changes have been confirmed (database commit) or
    when the database changes have been canceled (database rollback)
    Database commit and rollback
    Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback.
    In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system.
    Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system.
    A database commit is triggered automatically by
    each screen change, and especially after the ABAP/4 commands CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE or
    a Remote Function Call
    A database rollback is triggered automatically by
    errors which occur at runtime or
    the ABAP/4 command MESSAGE with the message type 'A'
    After each database commit or rollback, the database locks set in the LUW are released (see Database Locking).
    Thanks & regards
    Sreenivasulu P
    Message was edited by: Sreenivasulu Ponnadi

  • RE:  LUW ( LOGICAL UNIT OF WORK

    HI EXPERTS
           WHAT DO YOU MEAN BY " LUW  "
       CHEERS
       NAREN

    Hi,
    Logical Unit of Work
    http://help.sap.com/saphelp_nw2004s/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm
    http://help.sap.com/saphelp_nw2004s/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm
    regards
    Happy Tony

  • Related to LUW(logical unit of work)

    Hi Experts,
          Based on an inbound idoc i need to change some data in delivery. SD_DELIVERY_UPDATE_PICKING is used to update delivery(PGI details). And also i need to change some other data(which is not possible with the above function module), so i used WS_DELIVERY_UPDATE.
           But the problem is these 2 function modules are calling the standard SAP routines which are used in the program(SAPLV50L)  which used for VL02N.
         Now i changed my code, instead of FM <b>WS_DELIVERY_UPDATE</b>  i used BDC, now it is giving error like 'This delivery(number) is currently processed by another user (my user id) which means i am trying to change it in same program. 
       How can i use these above 2 Function modules in my program. Even i am using COMMIT WORK it  creates problem.
        Is there any Function module or any command(other than COMMIT WORK) to ends a LUW(Logical Unit of Work).
       I need your inputs.
    cheers,
    Bujji

    Hi,
           You can do one thing to over come this problem.....
    After calling the 1st function module .....using do --while loop check if the update has taken place by checking the tables.......Once its done you can call the second function module......
    I think we can also check for locked objects ....let me think over it
    regards,
    vijay

  • StoredProcedures Logical Unit of Work (Transactionality)

    I haven't experimented yet about the bahaviour when calling multiple storedProcedures in a single XI-JDBC call.
    When I call multiple stored procedures and if the transaction was partially successfull which means One storedProcedure call executed successfully and other failed in this scenario will this call treats as LUW and rolls back all the successful ones on the DB? or will be partial success?
    Since the actual SQL commands are inside the storedprocedure how do we pass the exception/failed signal back to caller?
    This is similar to calling insert/update statements using JDBC adapter I know that in this case each message call treats as LUW which means message will fail/rollback if any one of the statements failed.
    Thanks in advance...
    Laxman Molugu

    Hai Ravi Charan
    There are 3 types of LUW's available in SAP
    1)Database Transaction or DBLUW
    2)SAP      Transaction or SAPLUW
    2)ABAP     Transaction or ABAPLUW
    1) DBLUW : when it is called it locks the rows , Update the rows & commit the rows issued by auto Commit
    2) SAPLUW : collection of Business reports is called SAPLUW and Issuing the Commit
    here UPDATE,INSERT,MODIFY statements are valid
    Commit work is given by Developer Side.
    3) ABAPLUW : What ever Transaction Code we are creating is called ABAPLUW  it is belongs upon Developers
    here 3 types of updates available
    1) Bundled Updates
    2) Un-Bundled Updates
      1) Bundled Updates :
        in Bundled Updates all your updates in a single unit of work present in a PERFORM 'XYZ'
    PERFORM 'XYZ' on Commit.
    here PERFORM-kept in Buffer 'XYZ' this form having all your update statements
    Priarities of execution.
    Perform xy on comit it will execute first
    perform ab on comit it will execute second
    I want to change this execution Order
    Perform xy on comit Level 2 it will execute second
    perform ab on comit Level 1 it will execute First
    because it will depends on Level command
    Using in Function Modules
    Call Function XYZ in Update Task.
    Commit work.
    In this case it stores in a buffer once encounters the commit statement this will executes from the buffer
    so it is an asynchronos method
    2) Un Bundled Updates
    these are two types
    1) Inline Updates
    2) Buffered Inline Updates
    1) Inline Updates : INSERT,UPDATE
    when update statement found in a program then it is called inline update and you should give the 'commit work'after a update statement
    inthe inline update if you not issue a commit work the system will automatically issues the commit work.
    2) Buffered Inline Updates:
    you will buffer all your inline updates and executes after Encounter the 'COMMIT WORK'
    100
       XYZ --> we can not roll back here
    200
       ABC---> if here is using commit
    Thanks & Regards
    Sreenivasulu P

  • Number of data records per logical unit of works (LUW)

    When initialising opening stocks by default there are 5,000 data records per LUW.  For our extract this works out to 204 LUW.  Is there any optimium setting of number of LUW or data records per LUW? Thanks

    Niten
    See the below link
    URGENT! - Data Packet Size
    Assign points if has really helped you.
    Regs
    Gopi

  • Determine if program are in the same Unit of Work

    Hi ,
    I am currently determining if the EXPORT/IMPORT to memory id will work in 2 separate user exits. Is there a way to determine if 2 programs are in the same Logical Unit of Work ?
    Thanks.

    I tested in our sandbox and apparently, it did not work.
    When I placed a break point in the first user exit, it does the EXPORT successfully.
    As for the 2nd user exit (I placed a break point and activated the "Update Debugging" because the system will not stop at the break point without doing this), the IMPORT statement returned a sy-subrc = 4. It is not a case of a wrong IMPORT syntax because I also tested placing the IMPORT statement on the first user exit and it returned a SY-SUBRC = 0.
    When a break point stops during "Update Debbuging On" , what does this mean ? Does this imply that they belong to a different LUW ?
    Thanks/

  • Explanation required about LUW(Logical unit Work) and V1 nad V2 updatations

    Hi,
    Could you please explain about LUW(Logical unit Work) and V1 nad V2 updatations with examples.
    Thanks,
    Madhu

    Hi madhusudhanarao,
    1.   LUW(Logical unit Work)
      Its nothing but a technique of
      ALL OR NOTHING  concept.
    (Either all the corresponding database tables
    are updated in BUNCH, or
    none of them is updated)
    2.   V1 nad V2 updatations
    They come into picture only when
    UPDATE Module (thru Update FM) is used.
    v1 = updates which are very urgent and MUST (TIME CRITICAL)
    v2 = updates which are necessary but can be done
         after a little time.
    regards,
    amit m.

Maybe you are looking for

  • Can't Install Windows 7 Home Premium on my new Pavilion dv6

    Well guys I have a serious problem here. I recently bought myself a new HP notebook and as I took a first glance at all the unnecessary programs and applications that were allready installed I decided to reinstall windows from the start. So i downloa

  • Dynamic variable in template

    I would like to have variable which changes value for each po. Actually controlling po lines for each page, I have restricted to 5 as constant variable. But even though sometimes due to long description, line text, short text for po line which are va

  • Assign activity: xsd complex type variable assignment

    <selectionFailure xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"><part name="summary"><summary>XPath query string returns multiple nodes. According to BPEL4WS spec 1.1 section 14.3, The assign activity part and query /ns5:returnResul

  • Character Movement

    In the game I'm doing, the character can move in six directions by pressing the individual individual arrow keys, or press two at a time for the intermidiate direction. When you're not pressing any keys, the character stays still, facing the directio

  • Changing the APEX framework Error Message

    I was wondering if anyone could help me out here.  I am faced with a security issue where I need to hide any and all APEX framework error messages.  Specifically, I need to hide the error messages on the screen you get when trying to access an applic