About LUW

Hi experts,
any body please tell me what is LUW and what is need of it inABAP pro

Hi,
Database Logical Unit of Work (LUW)
From the point of view of database programming, 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 was in before the transaction started.
The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the SAP System, database commits and rollbacks can be triggered either implicitly or using explicit commands.
Implicit Database Commits
A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call. Work processes trigger an implicit database commit in the following situations:
·        When a dialog step is completed
Control changes from the work process back to the SAP GUI.
·        When a function module is called in another work process (RFC).
Control passes to the other work process.
·        When the called function module (RFC) in the other work process ends.
Control returns to the calling work process.
·        When a WAIT statement interrupts the work process.
Control passes to another work process.
·        Error dialogs (information, warning, or error messages) in dialog steps.
Control passes from the work process to the SAP GUI.
Explicit Database Commits
There are two ways to trigger an explicit database commit in your application programs:
·        Call the function module DB_COMMIT
The sole task of this function module is to start a database commit.
·        Use the ABAP statement COMMIT WORK
This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).
Implicit Database Rollbacks
The following cases lead to an implicit database rollback:
·        Runtime error in an application program
This occurs whenever an application program has to terminate because of an unforeseen situation (for example, trying to divide by zero).
·        Termination message
Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.
Explicit Database Rollbacks
You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for ROLLBACK WORK).
From the above, we can draw up the following list of points at which database LUWs begin and end.
A Database LUW Begins
·        Each time a dialog step starts (when the dialog step is sent to the work process).
·        Whenever the previous database LUW ends in a database commit.
·        Whenever the previous database LUW ends in a database rollback.
A Database LUW Ends
·        Each time a database commit occurs. This writes all of the changes to the database.
·        Each time a database rollback occurs. This reverses all of the changes made during the LUW.
Database LUWs and Database Locks
As well as the database changes made within it, a database LUW also consists of database locks. The database system uses locks to ensure that two or more users cannot change the same data simultaneously, since this could lead to inconsistent data being written to the database. A database lock can only be active for the duration of a database LUW. They are automatically released when the database LUW ends. In order to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us to create locks with a longer lifetime (refer to The SAP Locking Concept).
Reward Points if useful
Raghunath.S
9986076729

Similar Messages

  • 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.

  • LUW example

    hello SAP Gurus,
                  can u explain me about LUW by using an example ?
    Regards,
    Vijaya.

    Hi Vijaya,
    An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW. There are various bundling techniques that you can use to ensure that all of the database updates belonging to an SAP LUW are made in the same single database LUW.
    Externally-called procedures do not open a new SAP LUW.
    However, when you start a new executable program or transaction, a new SAP LUW starts. Database updates belonging to these programs are collected in their own database LUW. If the new program does not return control to the calling program, the SAP LUW of the old program concludes when the new program is called. If, on the other hand, the new program does return control to the calling program, the new SAP LUW runs parallel to the SAP LUW of the calling program.
    The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the SAP System, database commits and rollbacks can be triggered either implicitly or using explicit commands.
    Implicit Database Commits
    A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call. Work processes trigger an implicit database commit in the following situations:
    ·        When a dialog step is completed
    Control changes from the work process back to the SAP GUI.
    ·        When a function module is called in another work process (RFC).
    Control passes to the other work process.
    ·        When the called function module (RFC) in the other work process ends.
    Control returns to the calling work process.
    ·        When a WAIT statement interrupts the work process.
    Control passes to another work process.
    ·        Error dialogs (information, warning, or error messages) in dialog steps.
    Control passes from the work process to the SAP GUI.
    Explicit Database Commits
    There are two ways to trigger an explicit database commit in your application programs:
    ·        Call the function module DB_COMMIT
    The sole task of this function module is to start a database commit.
    ·        Use the ABAP statement COMMIT WORK
    This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).
    Implicit Database Rollbacks
    The following cases lead to an implicit database rollback:
    ·        Runtime error in an application program
    This occurs whenever an application program has to terminate because of an unforeseen situation (for example, trying to divide by zero).
    ·        Termination message
    Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.
    Explicit Database Rollbacks
    You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for ROLLBACK WORK).
    From the above, we can draw up the following list of points at which database LUWs begin and end.
    A Database LUW Begins
    ·        Each time a dialog step starts (when the dialog step is sent to the work process).
    ·        Whenever the previous database LUW ends in a database commit.
    ·        Whenever the previous database LUW ends in a database rollback.
    A Database LUW Ends
    ·        Each time a database commit occurs. This writes all of the changes to the database.
    ·        Each time a database rollback occurs. This reverses all of the changes made during the LUW.
    For more help u can go on to help.sap.com
    Thnks.

  • HR_INFOTYPE_OPERATION is not working in user exit ZXPADU02

    Hi frndz,
      i want to delimit/modify record in infotype 0014 after checking some condition when user clicks on SAVE in infotype 0008.
    For this i'm using the code like below.
    In Include ZXPADU02.
    when '0008'.
    IF sy-ucomm = 'UPD'.
    chek <condition>
    if sysubrc = 0.
    Lock employee.
    Delimti(LIS9) record in IT0014 using HR_READ_INFOTYPE_OPERATION.
    Unlock employee.
    endif.
    Here every thing working fine but record is not getting delimitted.
    Could anybody please help me any other possibilities to solve it.
    Thanks and Regards,
    Venkat

    Hi,
    I tried to use the FM HR_INFOTYPE_OPERATION in ZXPADU02 but I found that it will
    not update data in the real DB table(PAXXXX).I found that in FM 'HR_MAINTAIN_MASTERDATA' from FM 'HR_INFOTYPE_OPERATION' will set the field 'PSPAR-PBPFL' as 'X'.
    In standard program, it looks like if this field is set it will not do the logic to update the DB table. So I put the code in other report and then call in the ZXPADU02. I think it's about LUW.
    Code as follows to understand.
    data:
          lw_p0008      LIKE p0008,
          lw_pskey      LIKE pskey,
          lv_option,
              EXPORT lw_p0008 lw_pskey lv_option
                to memory id 'ZXPADU02_0008'.
              submit ZHRR_PA_ZXPADU02_0008
                     and return.
    Inside program ZHRR_PA_ZXPADU02_0008
    IMPORT w_p0008 lw_pskey lv_option
        FROM MEMORY ID 'ZXPADU02_0008'.
      CALL FUNCTION 'ENQUEUE_EPPRELE'
            EXPORTING
              pernr          = lw_p0008-pernr
            EXCEPTIONS
              foreign_lock   = 1
              system_failure = 2
              OTHERS         = 3.
      CALL FUNCTION 'HR_INFOTYPE_OPERATION'
        EXPORTING
          infty                  = '0008'
          number                 = lw_p0008-pernr
          subtype                = lw_pskey-subty
          objectid               = lw_pskey-objps
          lockindicator          = lw_pskey-sprps
          validityend            = lw_pskey-endda
          validitybegin          = lw_pskey-begda
          recordnumber           = lw_pskey-seqnr
          record                 = lw_p0008
          operation              = lv_opera
    *      TCLAS                  = 'A'
    *      DIALOG_MODE            = '1'
    *      nocommit               = 'X'
    *     VIEW_IDENTIFIER        =
    *     SECONDARY_RECORD       =
        IMPORTING
          return                 = lw_return
    *      KEY                    =
      IF NOT lw_return IS INITIAL AND
         lw_return-type EQ 'E'.
        MESSAGE e000(38) WITH lw_return-message.
      ENDIF.
      CALL FUNCTION 'DEQUEUE_EPPRELE'
        EXPORTING
          pernr = lw_p0008-pernr.
    If this not works, then go for dynamic action from V_T588Z as suggested by Suresh.
    Regards
    Eswar

  • 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

  • R/3 SM58 - Cleanup

    Hi
    I see in SM58 in the R/3 production system that we have some old entries (target is BW) like:
    RSAR_TRFC_DATA_RECEIVED 23.12.2007 03:38:44 partner not reached (host xxx, service sapgw04)
    IDOC_INBOUND_ASYNCHRONOUS 23.12.2007 03:38:44 partner not reached (host xxx, service s
    The main part is RSAR_TRFC_DATA_RECEIVED entries - we have only a couple of IDOC_INBOUND_ASYNCHRONOUS entries.
    We have got all loads from this given day and the following days into the BW system. Some loads failed, but they where repeated and thereby loaded successfully the second time.
    A)
    It is then safe to delete these entries or should they be repeated?
    B)
    What happens if they are repeated (the loads for the given day and the following days are successfully)?
    C)
    Is there anything that I should be aware of regarding my SM58 cleanup?
    Thanks in advance.
    Kind regards,
    Torben

    Hi Aadil
    Thanks for your reply and explanation.
    Just want to make sure:
    I can delete because it is old entries. In case it was never entries where we had load which was not loaded successfully yet I could not delete (if I did - I would lose data).
    Just a follow-up question.
    Will new delta data be present in a new LUW? Lets say that the latest delta load for a given area where loaded successfully this morning 09.00.00, would a new LUW have been created containing data from 09.00.01? In case this is correct, then should I would lose data by delete this new LUW.
    Once again, thanks.
    Kind regards,
    Torben
    PS. Do you have any links where I can read about LUW, tRFC and so on - this is a area which I do not know anything about and which I would like to know more about.

  • Query on CIF Queues

    Hi Apo Experts,
    I am having some queries on CIF queues...
    > I am getting below SYSFAIL error in outbound queues at APO Side.
    I can see that error text as " Material status does not allow a planned independent " . But there is no material number in the error text. So i double clikced the queue again. then i get the below screen which gives information about LUW , whichj is very very long ....
    Q1. How to know the material number in this particular queue ? I have posted the same question in previous post and i got reply that u need to keep clicking the queue until u find material number. I have done the same , but i didnt find any material number. I was getting this LUW Information , which is very long and it is in digital coding .
    (""" I have checked these queues in SCM Queue Manager also, and i was unable to find the material numner )
    Q2. How to process this Queue again ? Can i maintain the Material Status in ECC Side and process this queue again ?
    Q3. One question on LUW. Does all the material numbers which are assigned in one Particular Integration model form a single LUW ??
    Suppose i have given 10 materials in a integration model X and another 5 materials in another integration model Y , Then there will be two LUW's .. is it right ??
    Q4.  ( this may question may sound stupid but still.... ) .. Outbound queue in APO gets created when we are transferring something from APO to R/3 , and system was unable to process. So due to the error, an Outbound Queue gets created . My question is , If suppose there is a porblem in R/3 side, then whether an Inbound queue gets created at R/3 side ?? Or only Outbound Queue in APO gets created ?? or both gets created ??
    I am having above serious doubts and working on the same. Request to kindly provide your inputs .Thanks to all for your time and support. Good Day !!
    Regards,
    Raghavendra

    Hi Emani,
    Below information is based on best of my knowledge and experience, please try and let me know i this helps.
    Q1. How to know the material number in this particular queue ? I have posted the same question in previous post and i got reply that u need to keep clicking the queue until u find material number. I have done the same , but i didnt find any material number. I was getting this LUW Information , which is very long and it is in digital coding .
    (""" I have checked these queues in SCM Queue Manager also, and i was unable to find the material numner )
    Ans: Please follow below steps
    SMQ1/SMQ2 --> double click on queue name ---> again double click on queue name ---> again double click on queue name.
    You will reach on a screen with heading , here you will be able to see material name and other information;
    Q2. How to process this Queue again ? Can i maintain the Material Status in ECC Side and process this queue again ?
    ANS: This will depend on the error message you are getting under status column, if this is due to some temporary reasons, then you can try executing by pressing execute button , or you might need to delete the queue ---> remove reason of sysfail ---> regenerate the queue.
    Q3. One question on LUW. Does all the material numbers which are assigned in one Particular Integration model form a single LUW ??
    Suppose i have given 10 materials in a integration model X and another 5 materials in another integration model Y , Then there will be two LUW's .. is it right ??
    ANS: Please check below link for more details on qRFC administration
    qRFC Administration - Connectivity - SAP Library
    Further for different objects different LUWs got formed i.e. Sales Orders, Purchase Orders, Stock etc., you  can find more information on qRFC communication model in below link.
    http://help.sap.com/erp2005_ehp_06/helpdata/en/48/9be66e1f84062ee10000000a42189d/content.htm?frameset=/en/48/9c44f92ab0062fe10000000a42189d/frameset.htm
    Q4.  ( this may question may sound stupid but still.... ) .. Outbound queue in APO gets created when we are transferring something from APO to R/3 , and system was unable to process. So due to the error, an Outbound Queue gets created . My question is , If suppose there is a porblem in R/3 side, then whether an Inbound queue gets created at R/3 side ?? Or only Outbound Queue in APO gets created ?? or both gets created ??
    ANS: Queues are getting created whenever you transfer some data from one system to another, if there is some issue then the queue doesn't get cleared, it gets stuck.
    If you are sending data from ECC to APO then it creates outbound queue in ECC and if it gets cleared then an Inbound queue in APO.
    Hope this answers your query.
    Rgds
    Sourabh

  • Perform oncommit

    what is difference between Perform
    and perform on commit

    HI Amruta,
    Perform ON COMMIT is used to just register your subroutine for execution when the statement
    COMMIT is called by the system or COMMIT is called explicitly in the program.
    We are supposed to write only the database update statments in such subroutines. This is actually realated to the concepts of LUW. Try to read in details about LUW.
    There is another object which is similar to PERFORM on commit. It is CALL FUNCTION <fmname> IN UPDATE TASK.
    Regards,
    Prakash Pandey

  • Starting new database LUW inside ABAP during IDoc posting

    Hi all,
    During posting of an inbound IDoc, I am trying to update my Z-table in user-exit. I want to do it regardless of the result of IDoc posting. The problem is: if IDoc posted successfully - table is updated because COMMIT WORK is called at the end of the posting, however, if IDoc not posted - ROLLBACK WORK is called and table is not updated. So, my aim now is to commit the update of Z-table in any case, but it is the only thing that should be committed - no other prior update FMu2019s should be committed.
    I'm aware about the following thread
    http://forums.sdn.sap.com/thread.jspa?threadID=1884700
    Author of this thread says that he solved a problem by means of RFC and STARTING NEW TASK. But ABAP help says
    that starting asynchronous RFC triggers immediately a database commit in the calling program (which is unacceptable because all prior update FMu2019s will be committed ). I've checked and it is really the case.
    From my point of view SET UPDATE TASK LOCAL with COMMIT WORK should work in such kind of tasks, but in case of IDoc processing the whole process runs in a local update (see SET UPDATE TASK LOCAL in FM 'IDOC_INPUT'), so writing once again SET UPDATE TASK LOCAL has no effect.
    I tested SUBMIT statement as well. It had no effect and then I found out from ABAP help that SUBMIT ... AND RETURN starts new SAP LUW, but NOT a DB LUW. That is if I update my Z-table in the program called by SUBMIT - all ROLLBACK statements still affect my  Z-table update.
    Is there any simple solution? Please suggest.
    Thanks in advance!

    Hello,
    Try SUBMIT VIA JOB.....
    Sample Code
    call function 'JOB_OPEN'
    exporting
    jobname = name
    importing
    jobcount = number
    exceptions
    cant_create_job = 1
    invalid_job_data = 2
    jobname_missing = 3
    others = 4.
    if sy-subrc = 0.
    submit z_idoc_create_process_order and return
    via job name number number
    with p_aufnr = it_header1-aufnr
    with p_werks = it_header1-werks
    with p_autyp = c_autyp
    with p_auart = it_header1-auart
    with p_dispo = it_header1-dispo
    with p_opt = c_opt
    with p_mestyp = c_mestyp.
    if sy-subrc = 0.
    call function 'JOB_CLOSE'
    exporting
    jobcount = number
    jobname = name
    strtimmed = 'X'
    exceptions
    cant_start_immediate = 1
    invalid_startdate = 2
    jobname_missing = 3
    job_close_failed = 4
    job_nosteps = 5
    job_notex = 6
    lock_failed = 7
    others = 8.
    if sy-subrc 0.
    endif.

  • LUW data for smq2--Error During Delivery: Ibound processing locked

    Hi all,
    There are lot of messages(more than 7000) stucked in d Inbound queues, as viewed by SMQ2, and are in the retry mode for long.
    In the LUW data the status of the queue is showing error during delivery and the error text is <b>Inbound Processing Locked for example Deadline Processing </b>
    can anyone please suggest what this problem is about and suggstions for removing this problem will be really appreciated.
    This is urgent as the problem is in production.
    Regards,
    Rookie.

    Hi Prateek,
    The BPM involved is a dicesion making BPM which is creting large Idocs.
    We have checked in SM12 and the messages are locked there. Can you please advice how can we unlock the messages from SM12.

  • Info about BDCPS table

    Hi Experts,
    I needed this  bit of information about change pointers.
    Can someone please tell me how the column 'ALE processing indicator' in BDCPS table  gets upadted?
    Also does BDCP and BDCPS table get updated simultaneousy
    whenever there is any change to the objects?
    Thanks in Advance.

    Here is a few notes I put together for some juniors - I hope it satisifies your question
    User Changes or Creates Master Data in BW. Example transaction: XD02
    This then genrates two entries..
    Entry posted into R/3 Table BDCPV (amongst others) for each field change. The message type captured identifies it as a Customer Attribute Change for BW. A key to the Data Record actually posted (e.g. KNA1) is included so the extractor can Select the contents of the fields. (e.g. SORTL)
    and
    Entry posted into R/3 Table BDCPS for the Change Pointer document and the Message Type. The Process Indicator field is field utilised for the  “Extracted to BW field” for the Delta. Initially set up as blank then when the delta is run this is updated to “X
    BDCPS holds the Data Not Sent to BW for a Message Type (Process Flag is blank). Data from BDCPV is used to read the base tables to obtain the field contents of the Change Documents. When extracted the Process flag in BDCPS is set to “X” (Extracted).
    Because the data for ALE type delta sources comes from the Change Pointer table – there is no BW Update Queue to rerun deltas. If data was not posted into a PSA and there are no LUWs to execute there there is no buffered mechanism to resend the last delta. The solution is to run report RSA1BDCP in the R/3 system.
    The Initialisation of a Delta compatible Master Data/Text Data Source DOES NOT update the Process Flag in BDCPS. This has a dramatic effect on the first subsequent delta if data has been posted before the initialisation. The first delta will extract all the entries from BDCPS even though there changed dates were before the Initialisation. The net result will be exactly the same but the size of the first delta can be quite large.
    Once a delta has been executed and is correct – there is no real reason to keep the Change Pointers for that particular Message Type. Millions of records will exist for the BW Message Types on the BDC* tables for systems that have been live for months. Transaction BD22 can be run to delete the old “obsolete” and already processed Change Pointers.

  • About web service transaction

    Hello everyone:
    I am a newcomer to web service, but now I have to simulate ws-businessactivity protocol. I don't have any idea about it and where to begin with. I made an survey about JTA and JTS, but it seems this api only supports ws-atomic transaction. And in WSIT tutorial, there is only one example. Besides, someone suggests to use web service callback (asynchronous) technology. I so hope somebody could give me advices about the way how to do this. Thank you very much.

    I haven't found any official info on it, but my simple testing (mainly via ST05) indicates that you should be able to call multiple web services within a single LUW -  there seems to be no implicit "commit work" issued by the framework (unlike remote RFC calls).
    Jonathan

  • What is LUW? How do we use it in SAP ABAP coding?

    Hi Friends,
    Kindly explain me what is LUW with examples and how do we use it in our ABAP coding with scenarios why and when we use it?
    Regards,
    Pradeep

    Hi,
    SAP LUW
    Die Verbuchungsverwaltung
    The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allow you to program database changes that extend over several dialog steps. Even if you have not explicitly programmed a database commit, the implicit database commit that occurs after a screen has been processed concludes the database LUW. The following diagram shows the individual database LUWs in a typical screen sequence:
    Under this procedure, you cannot roll back the database changes from previous dialog steps. It is therefore only suitable for programs in which there is no logical relationship between the individual dialog steps.
    However, the database changes in individual dialog steps normally depend on those in other dialog steps, and must therefore all be executed or rolled back together. These dependent database changes form logical units, and can be grouped into a single database LUW using the bundling techniques listed below.
    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. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW. The following diagram illustrates this principle:
    Database Logical Unit of Work (LUW)
    From the point of view of database programming, 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 was in before the transaction started.
    The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the R/3 System, database commits and rollbacks can be triggered either implicitly or using explicit commands.
    Implicit Database Commits in the R/3 System
    A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call. Work processes trigger an implicit database commit in the following situations:
    When a dialog step is completed
    Control changes from the work process back to the SAP GUI.
    When a function module is called in another work process (RFC).
    Control passes to the other work process.
    When the called function module (RFC) in the other work process ends.
    Control returns to the calling work process.
    When a WAIT statement interrupts the work process.
    Control passes to another work process.
    Error dialogs (information, warning, or error messages) in dialog steps.
    Control passes from the work process to the SAP GUI.
    Explicit Database Commits in the R/3 System
    There are two ways to trigger an explicit database commit in your application programs:
    Call the function module DB_COMMIT
    The sole task of this function module is to start a database commit.
    Use the ABAP statement COMMIT WORK
    This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).
    Implicit Database Rollbacks in the R/3 System
    The following cases lead to an implicit database rollback:
    Runtime error in an application program
    This occurs whenever an application program has to terminate because of an unforeseen situation (for example, trying to divide by zero).
    Termination message
    Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.
    Explicit Database Rollbacks in the R/3 System
    You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).
    From the above, we can draw up the following list of points at which database LUWs begin and end.
    A Database LUW Begins
    Each time a dialog step starts (when the dialog step is sent to the work process).
    Whenever the previous database LUW ends in a database commit.
    Whenever the previous database LUW ends in a database rollback.
    A Database LUW Ends
    Each time a database commit occurs. This writes all of the changes to the database.
    Each time a database rollback occurs. This reverses all of the changes made during the LUW.
    Database LUWs and Database Locks
    As well as the database changes made within it, a database LUW also consists of database locks. The database system uses locks to ensure that two or more users cannot change the same data simultaneously, since this could lead to inconsistent data being written to the database. A database lock can only be active for the duration of a database LUW. They are automatically released when the database LUW ends. In order to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us to create locks with a longer lifetime (refer to The R/3 Locking Concept).
    The bundling technique for database changes within an SAP LUW ensures that you can still reverse them. It also means that you can distribute a transaction across more than one work process, and even across more than one R/3 System. The possibilities for bundling database changes within an SAP LUW are listed below:
    The simplest form of bundling would be to process a whole application within a single dialog step. Here, the system checks the user’s input and updates the database without a database commit occurring within the dialog step itself. Of course, this is not suitable for complex business processes. Instead, the R/3 Basis system contains the following bundling techniques.
    Bundling using Function Modules for Updates
    If you call a function module using the CALL FUNCTION... IN UPDATE TASK statement, the function module is flagged for execution using a special update work process. This means that you can write the Open SQL statements for the database changes in the function module instead of in your program, and call the function module at the point in the program where you would otherwise have included the statements. When you call a function module using the IN UPDATE TASK addition, it and its interface parameters are stored as a log entry in a special database table called VBLOG.
    The function module is executed using an update work process when the program reaches the COMMIT WORK statement. After the COMMIT WORK statement, the dialog work process is free to receive further user input. The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.
    For further information about how to create function modules for use in update, refer to Creating Function Modules for Database Updates
    During the update, errors only occur in exceptional cases, since the system checks for all logical errors, such as incorrect entries, in the dialog phase of the SAP LUW. If a logical error occurs, the program can terminate the update using the ROLLBACK WORK statement. Then, the function modules are not called, and the log entry is deleted from table VBLOG. Errors during the update itself are usually technical, for example, memory shortage. If a technical error occurs, the update work process triggers a database rollback, and places the log entry back into VBLOG. It then sends a mail to the user whose dialog originally generated the VBLOG entry with details of the termination. These errors must be corrected by the system administrator. After this, the returned VBLOG entries can be processed again.
    For further information about update administration, see Update Administration
    This technique of bundling database changes in the last database LUW of the SAP LUW allows you to update the database asynchronously, reducing the response times in the dialog work process. You can, for example, decouple the update entirely from the dialog work process and use a central update work process on a remote database server.
    Bundling Using Subroutines
    The statement PERFORM ON COMMIT calls a subroutine in the dialog work process. However, it is not executed until the system reaches the next COMMIT WORK statement. Here, as well, the ABAP statement COMMIT WORK defines the end of the SAP LUW, since all statements in a subroutine called with PERFORM ON COMMIT that make database changes are executed in the database LUW of the corresponding dialog step.
    The advantage of this bundling technique against CALL FUNCTION... IN UPDATE TASK is better performance, since the update data does not have to be written into an extra table. The disadvantage, however, is that you cannot pass parameters in a PERFORM... ON COMMIT statement. Data is passed using global variables and ABAP memory. There is a considerable danger of data inconsistency when you use this method to pass data.
    Bundling Using Function Modules in Other R/3 Systems
    Function modules that you call using CALL FUNCTION... IN BACKGROUND TASK DESTINATION... are registered for background execution in another R/3 System when the program reaches the next COMMIT WORK statement (using Remote Function Call). After the COMMIT WORK, the dialog process does not wait for these function modules to be executed (asynchronous update). All of the function modules that you register in this way are executed together in a single database LUW. These updates are useful, for example, when you need to maintain identical data in more than one database.
    For further details, refer to the keyword documentation.
    For more details of RFC processing, refer to the Remote Communications section of the Basis Services documentation.
    Pls. reward if useful....

  • About rfc concept

    hi gurus,
    Can any body explain me about the rfc concept.
    Thanks.

    Hi Rangamma,
    Check this info.
    These are the types of RFC
    Asynchronous RFC (aRFC)
    Synchronous RFC (sRFC)
    Transactional RFC (tRFC)
    Queued RFC (qRFC)
    Parallel RFC (pRFC)
    Asynchronous RFC :
    This is used when you need to increase the performance of ABAP program by having system call more than one function module in parallel than forcing the program to wait for results .
    Transactional RFC
    This let you group one or more function module call together o tRFC LUW and ensure that fucnction module within LUW is called once . In contrast to aRFC and sRFC the tRFC belonging to tRFC LUW are executed in order .
    tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are
    1.Executed in the order in which they are called
    2.Executed in the same program context in the target system
    3.Run as a single transaction: they are either committed or rolled back as a unit.
    Implementation of tRFC is recommended if you want to guarantee that the transactional order of the calls is preserved
    Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
    • When the caller starts an asynchronous RFC, the called server must be available to accept the request.
    The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
    • Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
    • The calling program can receive results from the asynchronous RFC.
    You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the function’s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session
    RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
    IMPORTING
    TABLES
    EXCEPTIONS
    The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.
    Transactional RFC (tRFC) and Queued RFC (qRFC).
    tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Disadvantages of tRFC
    - tRFC processes all LUWs independent of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
    - In addition, the sequence of LUWs defined in the application cannot be kept. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously
    Therefore, Queued RFC is better than Transactional RFC.
    Remote Function Call:
    RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.
    RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.
    RFCs manage the communication process, parameter transfer and error handling.
    http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
    Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
    Synchronous RFC:
    The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.
    Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously
    For more information on RFC, please go through the link.
    http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
    Have a look at this link.
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf
    http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
    Rewards some points if it is helpful.
    Rgds,
    P.Naganjana Reddy

  • CIF Batch jobs and LUW

    Hi Experts,
    Can anyone tell me about CIF Batch jobs and LUW please. Explain these two in detail whether they are the same or any difference and any relationship between both.
    Thanks in advance
    Suvecha

    Hi
    LUW stands for Logical Unit of work.
    Its a way of binding data together(multiple CIF queues under a single entity)
    It is useful to maintain the atomicity of data.
    For ex :- Say u have 5 materials under a single TLB order and u have sent that order to R3 for recieving number.If any of those materials is having master data which doesn't satisfy the filter criteria for Integration Model then the whole LUW will be blocked.
    Signifies the entire data set will be passed on as a single LUW.
    For CIF batch Jobs could you please explain what exactly you want to know.
    Thanks
    Amulya

Maybe you are looking for