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,
MadhuHi 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. -
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,
VenkatHi,
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 -
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,
RidhimaHey,
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 -
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,
TorbenHi 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. -
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,
RaghavendraHi 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 -
what is difference between Perform
and perform on commitHI 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. -
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. -
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,
PradeepHi,
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 users 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.... -
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 functions 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 -
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
SuvechaHi
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
-
Stolen iphone contacts no longer showing up in icloud
Hello everyone, Im writing on behalf of my mother-in-law, whos iPhone 4 was stolen today. She went and purchased a 5 right away, and her contacts were showing up from the cloud. However, just a few hours later, they are not there on her phone. Earlie
-
Usb 2 connection to laserjet 1100 possible?
want to use hp laserjet 1100 with laptop but can't find usb cable with connector that will fit laserjet's line in connector.
-
Integrating Apache Http Server with Streaming Server
Hi, How to integrate my Apache Http Server with a Darwin Streaming Server or any server? Any links are really appreciated. Thanks.
-
Cover Flow Won't Let Me Work Out!
So I have the 4th gen Nano, and when the cases come out that allow me to clip it to my belt, I won't be able to have it horizontally because cover flow will kick in. This is a problem! Apple, fix this please! If I orientate the Nano vertically, I can
-
This happens when I have several tabs. I'll click another tab and a tiled window appears with one window being the page of the tab and the other one the tab beside it. It's become quite annoying.