06-09-2008 12:59 PM
I have defined a very simple RFC enabled FM to return the existence of a material. First call to the FM in a LUW works correctly, subsequent calls fail.
Parameter MATNR is passed into the FM. I have a log-point in the code to check what is passed in.
First call, value of matnr is 00000000000100000, which is correct.
Second call, value is logged as 〰〰〰〰〰〰〰〰
This happens when I execute the following code on the calling side:
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
Interestingly, if I hard code the materials like this:
CALL FUNCTION '000000000001000000'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION '000000000001000001'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION '000000000001000002'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
Then all three values of matnr are correct in the receiving system.
Any comments as to what could be the issue here?
06-09-2008 1:10 PM
So
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists..
doesn't work but when replaced by
CALL FUNCTION '000000000001000000'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR
IMPORTING
EXISTS = l_exists.
...it does work. I do not understand this. If Z_MAT_CHECK_EXISTENCE is your RFC, why are you not using it in both statements? '000000000001000000' looks like a MATNR; why are you calling it in the second statement as if it were a function?
06-09-2008 2:33 PM
How about: because I'm an idiot?
What I meant to write was this:
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = '000000000001000000'
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = '000000000001000001'
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = '000000000001000002'
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
Sorry for the confusion.
BR,
Tony.
06-09-2008 2:43 PM
Now that that's been sorted out .... is it IM_MATNR that is being filled with the odd characters? In which case you must be doing something odd with IM_MATNR that you're not telling us about. It looks like an ordinary variable and since it is being used only as an EXPORTING parameter from your calling program its contents won't be affected at all by the fact that you're calling an RFC.
06-09-2008 3:41 PM
The thing is, as you can see from the original code, IM_MATNR is populated once and it's value does not change in the calling side. I am not re-assigning it at all. I have verified that by debugging on the calling side.
I am using log points in the function module, and I can see the value being passed in by inspecting the checkpoint log. It doesn't get much simpler than this:
FUNCTION z_mat_check_existence.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(MATNR) TYPE MATNR
*" EXPORTING
*" VALUE(EXISTS) TYPE MATXS
*"----------------------------------------------------------------------
data: wa_matnr type matnr.
ASSERT ID z_i152_telema_orders CONDITION matnr IS NOT INITIAL.
LOG-POINT ID z_i152_telema_orders FIELDS matnr.
SELECT SINGLE matnr
FROM mara
INTO wa_matnr
WHERE matnr = matnr.
IF sy-subrc = 0.
exists = 'X'.
ELSE.
CLEAR exists.
ENDIF.
ENDFUNCTION.
I am not doing anything wrong here as far as I can tell; also, if I re-test in the class debugger, without entering the transaction again, the first call has matnr filled with the same junk values. I think it has got something to do with the RFC calls all being in the same LUW.
BR,
Tony.
06-09-2008 4:04 PM
So, on the calling side IM_MATNR is always set to the same value, a valid MATNR; the problem occurs only in the RFC when, for some reason, even though you are sending it a valid value, on the second and third calls it is receiving garbage. Is that right?
Shouldn't happen. The RFC is just a function module run remotely and should just receive the values you send it. And when you say it is all in the same LUW, you're issuing a COMMIT between calls which I would have thought would start a new LUW. And anyway, it shouldn't matter. Does it work without the ASSERT ID (which I've never used) and the LOG-POINT ID? Does it work if you pass it a different variable for each call?
If it's ok if you pass it a character string rather than a variable, then it MUST be something to do with IM_MATNR on the calling side.
06-09-2008 2:38 PM
In the second call try to give another variable .. as
IM_MATNR1 .. IM_MATNR2 ..
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR1
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
CALL FUNCTION 'Z_MAT_CHECK_EXISTENCE'
DESTINATION l_dest
EXPORTING
matnr = IM_MATNR2
IMPORTING
EXISTS = l_exists.
ex_exists = l_exists.
commit work and wait.
06-09-2008 3:59 PM
Hi Anthony,
Can you post the logic of calling program of the RFC ?
Thanks,
Keerthi.
06-09-2008 4:05 PM
Hi,
Well I have fixed the problem; I copied the method parameter IM_MATNR to a local variable L_MATNR and called the RFC using that. It completely fixed the problem
Don't know why using the class method parameter caused a problem, especially since it never changed value.
BR,
Tony.