cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous XI->RFC and RFC->XI scenario - strange problem

Former Member
0 Kudos

Hello XI-Xperts,

I've come to really strange problem, which I would like to share with you and possibly get an explanation.

I have an asynchronous scenario with ending XI->RFC. The RFC function in R/3 has got an optional parameter called SENDER, which when is filled, the another asynchronous RFC->XI scenario should be started. (via ABAP code <i>CALL FUNCTION 'Z_XI_RETURN' DESTINATION gc_xi_destination</i> ... etc.)

Now, the direction XI->RFC is configured properly, but the way back NO(!). Anyway I thought that it wouldn't make me a trouble, because those two scenarios are IMHO absolutelly separated. So I'd presume that the the data should come to R/3 without problem, it should be processed, and in case the parameter SENDER is filled the R/3 would establish the RFC connection and the "return data" should go back in different XI thread.

Well I would think like that but the situation is different:

When the parameter SENDER is empty, all goes OK and I can see in Runtime Workbench Message Monitoring - Adapter engine - Detail - Audit log only "successes". But when SENDER is filled with a value and R/3 does CALL FUNCTION with DESTINATION to a <i>non-existing Sender agreement</i>, the R/3 apparently doesn't send a acknowledgement to Adapter Engine of first thread XI->RFC. Intstead of that there are three messages in audit log:

<i>MP: exception caught with cause com.sap.aii.af.ra.ms.api.RecoverableException: error while processing message to remote system:com.sap.aii.af.rfc.core.client.RfcClientException: JCO.Exception while calling Z_FIDATA_INPUT in remote system (RfcClient[IS2RFC_SAP_BG]):com.sap.mw.jco.JCO$Exception: (104) RFC_ERROR_SYSTEM_FAILURE: senderAgreement not found: lookup of binding via CPA-cache failed for AdapterType RFC, AdapterNS http://sap.com/xi/XI/System, di: com.sap.aii.af.rfc.afcommunication.RfcAFWException: error while processing message to remote system:com.sap.aii.af.rfc.core.client.RfcClientException: JCO.Exception w

</i>

Basically I understand what is happening on the background, but I really can't go over my persuation that in case of the ASYNCHRONOUS SCENARIO this should not happen.

Or is the RFC call (I mean XI->RFC) "pseudo-synchronous" even in asynchronous scenario ? I mean that Adapter engine waits for the result of RFC everytime ... ?!

Thank you

Tomas

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hello again guys,

so I've understood it on the end. My ABAP code didn't contain EXCEPTION part of CALL FUNCTION statement.

<i>CALL FUNCTION 'Z_XI_RETURN'

DESTINATION gc_xi_destination

EXPORTING

<PARS>

<b>EXCEPTIONS

communication_failure = 1

system_failure = 2.</b></i>

Without it the RFC short-dumped and AE correctly tried to call it 1+3 times. The thing, that the problem was connected to XI related topic, tricked me. Well it's smart, I must admit on the end

Reward points for interest.

THX Tomas

Former Member
0 Kudos

Hi,

Please also notice that you are calling another RFC in synchronous way.

Regards,

Wojciech

Former Member
0 Kudos

Sorry Wojciech, I don't follow.

You mean that with this ABAP coding the call is synchronous ?

Tom

Former Member
0 Kudos

I guess it isn't too late to answer

Yes, using "CALL FUNCTION xyz DESTINATION xyz" to call the remote-function, triggers a synchronous RFC call.

MichalKrawczyk
Active Contributor
0 Kudos

Hi,

did you have a look at question 19 from SAP note: 730870

Regards,

michal

Former Member
0 Kudos

Who else than Michal

Yes of course, as I wrote - I understand what is wrong. But what I mean is that this kind of error should not affect the asynchrounous run (whatever)->XI->RFC. But it does, it's true that only "the very last part" of the run - the adapter engine, but it does affect it.

But how I'm thinking about that, it maybe makes a sense. It is the AE's job to take care how the call end. I'll try to put the statement CALL FUNCTION with DESTIONATION into TRY-CATCH block. And in case there is a problem it will stay in R/3 (e.g. message to R/3 administrator will be sent), but RFC will end OK.

I'll keep the thread updated

Tom

MichalKrawczyk
Active Contributor
0 Kudos

hi,

can you try putting a

commit work.

before the second RFC is called?

but make sure it's executed before the second RFC ok ?

Regards,

michal

Former Member
0 Kudos

Hi Tomas,

Do you have "in background task" statement in your second RFC call?

Regards,

Wojciech