Call function in unique context

[christian_swonke]

Hi experts,

Currently I am implementing an function module which is able to be called by RFC. Inside this function a table - which is overtaken from the external system - will be processed by a regular loop.

For the RFC result I have to call an other function module (Z-function) and take over the result of this Z-function to the RFC result structure.

The Z-function itself is also ablte to be called direclty via RFC.

Currently it seems that there are any side effects with this Z-Function. So we have some strange situations were the Z-function is not delivering any result and we don't know why...

Like I already said the Z-function itslef is also configured as an RFC service and addtionally it is used inside a web service definition.

If an external program is using the web serice (single call) the problem with wrong result does not occur.

In my opinion the problem is an internal problem of the Z-function. Something that the context is not initalisized after first loop or something like this. Because the problem with wrong result do just occur in a multiple call (this means: 1. Call, 2. Call,...) inside loop...

The questions is:

- Is there any possibility to initalize the context of an Z-function?

- Can I call a Z-function in a separate unit and wait for the result of it?

I think about to call the service internaly with "IN BACKGROUND TASK AS SEPARATE UNIT" but then I will never get the result back. But something like this is necessary - if we have the right assumption.

Also I found the function TRANSACTION_BEGIN and TRANSACTION_END for BAPI implementation. So I saw that these functions will create/open a transaction as bracket for further function calls. But does it really help if I just call TRANSACTION_BEGIN, Z-FUNCTION, TRANSACTION_END?

Means new transaction = separate unti / new context?

Regards

Christian

[Sandra_Rossi]

I think you have an issue with your Z-function : global (or statics) variables not being cleared, which is the problem if the RFC connection was left alive between 2 calls. You may test the issue quickly by using RFC_CONNECTION_CLOSE between 2 calls.

I don't think you need to investigate the other "solutions" (i.e. tRFC or these TRANSACTION_* function modules)

[Former Member]

So

You have 2 functions (it doesn't matter they are RFC): the first one calls the second one.

The second fm works fine if it's called alone

First question: these two fm belong to the same function group?

[christian_swonke]

Yes that's exactly correct.

No the two functions belong to different function groups.

[Former Member]

Ok

So, as Sandra writes, try to check how the global data are managed or initialized: probably they have still some values set in the previous steps

It needs to consider the global data are automatically cleared only where the whole session is finished and closed

[Sandra_Rossi]

And, again, "You may test [whether] the issue [still occurs,] quickly by calling RFC_CONNECTION_CLOSE between 2 calls". If it doesn't happen anymore, then probably there's some global data somewhere which needs to be cleared...

[christian_swonke]

Hi, I have changed the implementation now. During the loop in function A, I call now the second Z-function B with destination NONE and afterwards the function RFC_CONNECTION_CLOSE will be called. The result is similar than before. So no side effects in this point...

My problem is that I can not rebuild thev constellation from productive environment which I described before in test enviroment.

It seems that I have to send the changed objects to productive to see if it is helpful or not.

In productive environment we talk about 200000 calls from external systems per day. Have I anything to keep in mind depending on processes our system performance depending to this change?

Regards Christian

[Sandra_Rossi]

If you can't reproduce a problem, it's useless changing the code unless you want to transport it to do the test in another system.

Just to make things clear, you have now:

In system 1, there is a:

CALL FUNCTION 'A' DESTINATION 'system 2'

In system 2, we have:

FUNCTION A.

  LOOP AT itab...

    CALL FUNCTION 'B' DESTINATION 'none'

    CALL FUNCTION 'RFC_CONNECTION_CLOSE' DESTINATION 'none'

  ENDLOOP.

ENDFUNCTION.

Okay for the workaround, to test whether it corrects the issue, but not good for performance.

You should define a way to activate or deactivate it externally, something like this :

    IF external condition.

      CALL FUNCTION 'B' (as before)

    ELSE.

      CALL FUNCTION 'B' DESTINATION 'none'

      CALL FUNCTION 'RFC_CONNECTION_CLOSE' DESTINATION 'none'

    ENDIF.

Personally, I would do everything I can to reproduce the error in another system.

[christian_swonke]

it seems to work on productive enviroment. Thank's for your support!