Hi
I wanted to share a piece of information about what I have experienced lately and also ask for opinions to others if they experienced the same situation.
I've been using TO_XSTRING method of if_http_entity to get a full copy of http message in binary and pass this value to database or other rfc systems to populate and process the same http request in a later stage. And I was using FROM_XSTRING to create a copy of the original HTTP request whenever I need to regenerate the request to process again.
In one of my projects, customer upgraded their netweaver to EHP7. And this coding happens to fail for multipart messages. I've been digging internet, debug http sessions, trace ICM and finally I have figured out the reason.
After EHP7 upgrade, TO_XSTRING method returns a different value comparing to previous version of NW. it modifies http header (content-type "boundary" attribute changes and also boundary ids on the parts). And when you try to create a new request instance by calling FROM_XSTRING, object seems to be instantiated but when you try to access multipart segments it fails. calling NUM_MULTIPARTS method results rc=29 when you check with GET_LAST_ERROR. And this value is not documented anywhere.
Instead of using TO_XSTRING i have tried GET_RAW_MESSAGE method. The first thing to notice is that the length of the return values are different. GET_RAW_MESSAGE returns 10 bytes shorter value (i have tried it with different http requests, difference is always 10 bytes) .
And creating a new request instance with FROM_XSTRING works only when you use the xstring value generated by GET_RAW_MESSAGE (at least for multipart messages as far as I noticed) .
And I still don't know why TO_XSTRING started behaving differently after release upgrade. And I also don't know if there are other side effects using GET_RAW_MESSAGE, but for now my case is closed.
Version information is;
EHP7 für SAP ERP 6.0
ICM Version 7.41, multithreaded, Unicode, 64 BIT
SAP_BASIS 740 0005
Hope this helps to anyone who may face this problem in the future and it is much appreciated if you'd share opinions if you know some solid information regarding this situation.
Regards
Sahin Suleymaniyelioglu
Note: Here is the piece of code to observe the problem in a EHP7 system. In the releases prior to EHP7 it may work properly.
You can put this coding in the IF_HTTP_EXTENSION~HANDLE_REQUEST method of your ICF service handler (or DO_REQUEST method of your BSP controller) and put an external break point and activate ICF debugging. And call your service through a SOAP tool with a multipart request.
DATA rc TYPE i.
DATA bin_data TYPE xstring.
DATA multi_parts TYPE i.
DATA copy_request TYPE REF TO if_http_request.
DATA lo_part TYPE REF TO if_http_entity..
DATA part_body TYPE xstring.
DATA part_body_size TYPE i.
DATA index TYPE i.
CREATE OBJECT copy_request TYPE cl_http_request.
DO 2 TIMES.
CLEAR rc.
CLEAR bin_data.
IF sy-index = 1.
"at first loop pass, bin_data is retrieved from to_xstring
bin_data = server->request->to_xstring( ).
ELSE.
"at second loop pass, bin_data is retrieved from get_Raw_message
bin_data = server->request->get_raw_message( ).
ENDIF.
rc = server->request->get_last_error( )..
CHECK rc = 0.
copy_request->from_xstring( bin_data ).
CLEAR rc.
multi_parts = copy_request->num_multiparts( ).
rc = copy_request->get_last_error( )..
CHECK rc = 0. "rc = 29 in the first loop pass,
"works fine in the second
IF multi_parts = 0.
part_body = copy_request->get_data( ).
ELSE.
DO multi_parts TIMES.
index = sy-index .
CLEAR rc.
FREE lo_part .
lo_part = copy_request->get_multipart( index ).
rc = copy_request->get_last_error( )..
IF rc <> 0 OR lo_part IS NOT BOUND.
EXIT.
ENDIF.
part_body = lo_part->get_data( ).
part_body_size = xstrlen( part_body ).
ENDDO.
ENDIF.
ENDDO.