Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Http request handler - Application log (SLG1)

konstantinos_vassiliadis
Active Participant
0 Likes
1,458

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

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,201

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

2 REPLIES 2
Read only

Former Member
0 Likes
1,202

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

Read only

0 Likes
1,201

Hi again Rudra,

actually the Short way method of simply performing explicit commit after log save worked!!!

Thanks a lot for your help,

Konstantinos