‎2015 Jun 17 10:10 AM
Dear experts,
I have an HTTP request handler class which is used by a service defined in SICF. The request handler calls a Function Module that creates a log (application log) and at some point saves the log. Then execution returns to the http request handler which sends the response to the caller.
The problem I am facing is that afterwards if I call transaction SLG1 to see the created application log entry it is not there!! If, however, I remove from the http request handler class the code that sends the response to the caller and re-execute and then I call again transaction SLG1 the log is there!!!
Has anyone got any idea why this is happening? the code to send the response to the caller is the following:
* SERVER TYPE REF TO IF_HTTP_SERVER HTTP Server
DATA: lv_response type REF TO IF_HTTP_RESPONSE ,
lv_xml_string TYPE xstring ,
lcl_cl_http_server type REF TO cl_http_server ,
lv_rc TYPE i.
lv_response = server->response.
* set data of response
CALL METHOD LV_RESPONSE->SET_DATA
EXPORTING
DATA = lv_xml_string.
* widening cast
lcl_cl_http_server ?= server.
CLEAR: lv_rc.
CALL METHOD lcl_cl_http_server->SEND_RESPONSE
RECEIVING
RC = lv_rc.
Thanks in advance,
Konstantinos
‎2015 Jun 17 11:17 AM
Hi Konstantinos,
This is quite strange. If I understood how you have done the coding, correctly, it seems there is some database rollback happening in between your Application Log Update and sending the response back . When you don't have the code to send the response back the data is getting updated as RFC call is issuing the COMMIT automatically.
I am guessing you are using BAL_LOG_CREATE/BAL_DB_SAVE FMs to update your application log.
If so , and if possible to debug I will approach the issue like this.
Long way:
I will debug until BAL_DB_SAVE calls the FM BAL_DB_INTERNAL_NO_UPDATE_TASK in which the tables BALDAT and BALHDR are updated via INSERT/UPDATE statement. After the statement since there will be implicit COMMIT due to INSERT/UPDATE the data will be shown via SE16/SE16N.
2. Then I will execute the following steps where we are sending the response and doing F6 in each Method call and see if the data is getting disappeared. or not to find out the reason for rollback.
Short way ( May work actually ).
1. Trying to pass I_2TH_CONNECTION and I_2TH_CONNECT_COMMIT eq ABAP_TRUE in FM BAL_DB_SAVE or simply issuing COMMIT WORK after BAL_DB_SAVE. I know we do not need to issue commit in RFC calls but it can actually work sometimes.
R
‎2015 Jun 17 11:17 AM
Hi Konstantinos,
This is quite strange. If I understood how you have done the coding, correctly, it seems there is some database rollback happening in between your Application Log Update and sending the response back . When you don't have the code to send the response back the data is getting updated as RFC call is issuing the COMMIT automatically.
I am guessing you are using BAL_LOG_CREATE/BAL_DB_SAVE FMs to update your application log.
If so , and if possible to debug I will approach the issue like this.
Long way:
I will debug until BAL_DB_SAVE calls the FM BAL_DB_INTERNAL_NO_UPDATE_TASK in which the tables BALDAT and BALHDR are updated via INSERT/UPDATE statement. After the statement since there will be implicit COMMIT due to INSERT/UPDATE the data will be shown via SE16/SE16N.
2. Then I will execute the following steps where we are sending the response and doing F6 in each Method call and see if the data is getting disappeared. or not to find out the reason for rollback.
Short way ( May work actually ).
1. Trying to pass I_2TH_CONNECTION and I_2TH_CONNECT_COMMIT eq ABAP_TRUE in FM BAL_DB_SAVE or simply issuing COMMIT WORK after BAL_DB_SAVE. I know we do not need to issue commit in RFC calls but it can actually work sometimes.
R
‎2015 Jun 17 11:30 AM
Hi again Rudra,
actually the Short way method of simply performing explicit commit after log save worked!!!
Thanks a lot for your help,
Konstantinos