‎2011 Oct 13 6:18 AM
Hi,
I am calling an RFC enabled FM BAPI_ALM_NOTIF_DATA_MODIFY and BAPI_ALM_NOTIF_SAVE to modify the data of a notification. These function modules are called within another FM which is also a RFC called in background as a separate task. The problem here is that, the data gets modified fine only when I am in the debugging mode and execute it. But if I execute without going to the debug mode, I cannot modify the notification data. Kindly suggest why this is happening and what the solution is. Thanks
‎2011 Oct 13 6:21 AM
‎2011 Oct 13 6:22 AM
‎2011 Oct 13 6:31 AM
Hi,
I have tried the wait option but doesn't work. I do not think I can use a commit statement because the Function module inside which I am calling these 2 FMs is inturn being called within an enhancement section. This main FM is called in background task as a separate unit. Can I use a commit work inside such a FM inspite of the fact that it is called inside an enhancement section?
‎2011 Oct 13 6:38 AM
‎2011 Oct 13 6:39 AM
Oh Sorry for the suggestion !!! Didnt get your question properly.
This main FM is called in background task as a separate unit
Does this enhancement gets triggered after the actual transactional flow, i.e actual commit of the transaction ?
‎2011 Oct 13 6:47 AM
Yes there is a function module inside the enhancement section which does the save of the order. When i checked in debug mode, I found that the main FM gets triggered as soon as the order save FM is executed. And I believe that there is a commit work inside this order save FM. Is there any other way I can run around this without using a commit work?
‎2011 Oct 13 6:50 AM
And I believe that there is a commit work inside this order save FM
If your functions are gettign called after the actual commit work of the transaction then a commit work is required for your operations else try to perform your operations in background task before tha actual commit of the transaction.
Kesav
‎2011 Oct 13 7:01 AM
Ok here is a brief decsription of what I am actually doing. I have an enhancement section where the order save happens. Just before the order save FM, I am calling a custom FM which is RFC enabled. I call this FM in background task as a separate unit. Inside this FM, I am calling NOTIF_MODIFY and NOTIF_SAVE FMs. One more thing I am doing here is, calling of another FM (STATUS_CHANGE_INTERN) to change the notification status. This is happening perfectly fine even when I am not using any commit work. The only problem is with NOTIF_DATA_MODIFY. If commit work was the solution then why is it working fine in the debug mode and why is the notif status getting updated? There should be some other reason for this. Is it the way I am calling these 2 FMs. Both BAPI_ALM_NOTIF_DATA_MODIFY and BAPI_ALM_NOTIF_SAVE are RFCs. Is there a specific way I have to call these FMs?
‎2011 Oct 13 7:02 AM
One other thing to add to this is that, I have tried calling these 2 FMs using a background task. But still the same problem.
‎2011 Oct 13 7:04 AM
If commit work was the solution then why is it working fine in the debug mode and why is the notif status getting updated?
Commit happens implicitly in each steps while debugging.
Note that RFC called as background task only gets executed when the comit work gets triggered, this is the reason i asked that whether your code is written after or before the actual commit of the transaction.
Kesav
‎2011 Oct 13 7:09 AM
I have written the background task FM before the order save FM which does the commit work. So what should I do to overcome this problem of execution happening only in debug mode?
‎2011 Oct 13 7:14 AM
What is the standard fm called by the transaction and the place where you have applied your enhancement ? let me check it
Kesav
‎2011 Oct 13 7:18 AM
Within the standar include LCOIHF2V, there is an exhancement section called ENHANCEMENT-SECTION FCODE_BU2_04 SPOTS ES_SAPLCOIH. I am calling my RFC FM just before CO_ZV_ORDER_POST.
‎2011 Oct 13 7:19 AM
Within the standard include LCOIHF2V, there is an exhancement section called ENHANCEMENT-SECTION FCODE_BU2_04 SPOTS ES_SAPLCOIH. I am calling my RFC FM just before CO_ZV_ORDER_POST.
‎2011 Oct 13 7:55 AM
Hi,
I think so your custom result is overwritten by the actual function in the queue . So you have to add you code just before the actual commit work of the transaction. in debugging mode may be your custom code executes first and the data is immediately replicated, did you check hitting f8 in debugiing mode after your code gets executed. Verify the result after F8, it will not be your desired result.
Kesav
‎2011 Oct 13 8:12 AM
Hi,
I did just as per what you said. That is set an enternal breakpoint in my FM, executed the transaction and waited till my FM gets triggered. And then simply pressed an F8. And it works fine this way.
‎2011 Oct 13 8:31 AM
Hi,
Wait for Suhas or Max to come .. They will surely make this out.
Regards
Kesav
‎2011 Oct 13 8:40 AM
Ok now can someone help me find out why the notif_data_modify works fine in debug mode. The status change works fine either ways (debug or direct execution) though
‎2011 Oct 13 8:45 AM
Didi you try putting a WAIt ( 3 sec ) after BAPI_ALM_NOTIF_SAVE
‎2011 Oct 13 9:50 AM
Yes Suzie, I put a wait up to 3 seconds after the notif_save. Yet it does not work. I have tried almost all possible solutions. It only works if i use a commit work. But i am very apprehensive about using a commit work. Hence please help with alternative approach.
‎2011 Oct 13 10:00 AM
Hi Smitha,
I dont know whether this will help you or not ..
But lets try out this also..
Try and create new Fm in this FM call the BAPI and call BAPI COMMIT WORK.
Then in your enhacement call this new FM as STARTING NEW TASK .
In this way your std code will not get affected due to commit work and I thik this will update the DB also.
CALL FM STARTING NEW TASK 'ZZTASK'.
thanks,
Anmol,
‎2011 Oct 13 10:17 AM
Will the commit work not give a problem in this case? Problem like Update termination error or a similar defect?
‎2011 Oct 13 10:42 AM
Any answer other than COMMIT? I am unable to find any way out of it
‎2011 Oct 13 10:46 AM
As you are calling the FM in new task the commit work will commit to db only from that task only
So I think it dont affect the actual transaction as STARTING NEW TASK will work as parallel processing..
Thanks,
Anmol Bhat.
‎2011 Oct 13 10:49 AM
Hi Anmol,
What if the actual flow of the standard transaction fails ? As this call implies a asynchronous way the ACID properties will not be satisfied.
Kesav
‎2011 Oct 13 11:12 AM
OK will try this method and check if it will work. Thanks anyways.
‎2011 Oct 13 11:43 AM
I created another function module which just these 2 FMs (NOTIF_DATA and NOTIF_SAVE) and called it in BACKGROUND TASK as a separate unit. But still the same problem.
‎2011 Oct 13 6:42 AM
Hi Smitha,
According to the BAPI documentation Commit work BAPI is required.
Try calling the BAPI in Update task.
Thanks,
Anmol.
‎2011 Oct 13 7:05 AM
hi,
Bapi_commit_transaction is a function module as well and you can use it with in your function module if not.
you can write an executable program and can write you bapi_commit_transaction in the that executable program and can use call transaction 'ztcode'.
‎2011 Oct 13 8:15 AM
Hi,
are you using a different destination when calling the function module (f.i. DESTINATION 'NONE')? If that is the case, the you should call function BAPI_TRANSACTION_COMMIT with the same destination. If not, could you copy the exact way you call the function here?
Roy
‎2011 Oct 13 8:28 AM
I am not using any destination. The code is as shown:
WAIT UP TO 5 SECONDS.
CALL FUNCTION 'BAPI_ALM_ORDER_GET_DETAIL'
EXPORTING
number = aufnr
IMPORTING
es_header = gf_header
TABLES
et_olist = it_ord_notif
return = it_ret
.
CALL FUNCTION 'BAPI_ALM_NOTIF_GET_DETAIL'
EXPORTING
number = gf_header-notif_no
IMPORTING
NOTIFHEADER_EXPORT = gf_notif_exp
.
CLEAR: gf_notif_no.
DESCRIBE TABLE it_notif_no LINES g_line.
READ TABLE it_notif_no into gf_notif_no INDEX g_line.
IF gf_notif_no-short_text+0(3) = 'PRB'.
clear: gf_notif_imp, gf_notif_imp_x.
gf_notif_imp-desstdate = gf_notif_exp-desstdate.
gf_notif_imp-desenddate = gf_notif_exp-desenddate.
gf_notif_imp_x-desstdate = 'X'.
gf_notif_imp_x-desenddate = 'X'.
CALL FUNCTION 'BAPI_ALM_NOTIF_DATA_MODIFY'
EXPORTING
number = gf_notif_no-notif_no
NOTIFHEADER = gf_notif_imp
NOTIFHEADER_X = gf_notif_imp_x
IMPORTING
NOTIFHEADER_EXPORT = gf_notif_result
TABLES
.
CALL FUNCTION 'BAPI_ALM_NOTIF_SAVE'
EXPORTING
number = gf_notif_no-notif_no
IMPORTING
NOTIFHEADER = gf_qmnum_save
TABLES
RETURN = it_ret2.
endif.
clear: gf_notif_no.
LOOP AT it_notif_no INTO gf_notif_no.
IF gf_notif_no-short_text+0(3) = 'PRB'.
SELECT SINGLE objnr FROM viqmel
INTO g_objnr
WHERE qmnum = gf_notif_no-notif_no.
SELECT SINGLE stsma INTO g_stsma FROM jsto WHERE objnr = g_objnr.
SELECT SINGLE estat INTO g_stat FROM tj30t WHERE stsma = g_stsma AND
spras = 'EN'
AND txt04 = 'SFMR'.
CALL FUNCTION 'STATUS_CHANGE_EXTERN'
EXPORTING
check_only = ' '
client = sy-mandt
objnr = g_objnr
user_status = g_stat
set_inact = ' '
set_chgkz = 'X'
no_check = ' '
EXCEPTIONS
object_not_found = 1
status_inconsistent = 2
status_not_allowed = 3
OTHERS = 4.
IF sy-subrc = 0.
ENDIF.
ENDIF.
ENDLOOP.
ENDIF.
ENDIF.
ENDIF.
‎2011 Oct 13 10:23 AM
Try calling CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' after completion of CALL FUNCTION 'BAPI_ALM_NOTIF_SAVE'.
Regards,
Ganesh
‎2015 May 14 11:24 AM
Hi All,
I have also same problem I have a program through wich I am creating a document and posting that document by bapi_post FM but that is working only in debugger not in direct execution.
I have tried with wait andbapi_transaction_commit FM also but still it has same issue.
Please do suggest any solution for it.
@ smita: do you got some solution?
Thanks in advance!!!
Deepti
‎2015 Jun 03 10:31 AM
Hi Deepti,
Did you get this fixed?
I'm also having the same problem where the BAPI being called through debugger
is working fine but not when I run without it switched on.
Andy
‎2015 May 14 11:22 PM
Hi,
We had the same problem while using these ALM function modules. COMMIT AND WAIT UP TO 5 SECONDS worked for us and we even tried a DO '' TIMES statement till it got saved, but it was a big debate when we went in for global code review!
Thanks,
Subhash.