RFC Adapter blocks during asynchronous RFC

[Former Member]

Hi guys,

I have a RFC-XI-File scenario in which the RFC is called asynchronously.

The RFC is called in a report as follows:

<i>

CALL FUNCTION 'CONTROL_RECIPE_DOWNLOAD' IN BACKGROUND TASK DESTINATION 'EXD001_TEST'

EXPORTING

client = client

TABLES

CRFT = it_CRFT

CRFV = it_CRFV

CRHE = it_CRHE

TLINES = it_TLINES.</i>

the RFC destination is of type"T" with registered program ID(same program ID as in my comm channel) and works fine when i do the connection test.

I have the following problem though.

When I call the RFC once, I see the message appearing in the SXMB_MONI and the flat file gets put away. So far, so good.

But when I call the RFC again, nothing happens. It seems like the scenario works only 1 time. If I re-activate my RFC communication channel for this scenario however, the next transaction works fine again. The next one is blocked again.

I've been investigating this and I've noticed the following:

When I look in SM58 in the sender R3 system, there remains a line saying "transaction executing" for my particular RFC call and destination (the first one, the one that get through).

For the next RFC calls a line saying "transaction recorded" appears in SM58.

I'm guessing since this first call is still executing, the next calls do not get handled and they stay on "transaction recorded" (in the queue) .

When I delete the line with transaction executing in SM58 nothing happens, I have to reactive the RFC communication channel, that is used for this particular scenario (the program ID must be re-registered?).

Any ideas why this is happening?

Regards,

Bob

[Former Member · Accepted solution]

Hi Bob,

one (silly?) suggestion.

After RFC Call:

commit work.

regards Mario

[Former Member · Accepted solution]

I'm sorry Mario,

I've forgot to put the commit on Sdn, The complete call is as follows:

<i>CALL FUNCTION 'CONTROL_RECIPE_DOWNLOAD' IN BACKGROUND TASK DESTINATION 'EXD001_TEST'

EXPORTING

client = client

TABLES

CRFT = it_CRFT

CRFV = it_CRFV

CRHE = it_CRHE

TLINES = it_TLINES.

COMMIT WORK.</i>

Regards,

Bob

Message was edited by:

B. Vrancken

[Former Member · Accepted solution]

can you call using separate background task rathr then same background task

Thanks

Sreeram

[Former Member · Accepted solution]

When I do the suggested, I get a runtime error in R3 and the RFC doesn't even get sent:

CALL_FUNCTION_DESTINATION_NO_T

It says that the error is the consequence of calling an asynchronous RFC via an RFC destination of type 'T'. According to the error screen the RFC destination should be type 'I' or '3' when calling RFC asynchronously. Funny because for the RFC communication channel it should be type 'T' and it works.

The code I used to accomplish the call is the following:

<i>CALL FUNCTION 'CONTROL_RECIPE_DOWNLOAD' STARTING NEW TASK 'myTask' DESTINATION 'EXD001_TEST'

EXPORTING

client = client

TABLES

CRFT = it_CRFT

CRFV = it_CRFV

CRHE = it_CRHE

TLINES = it_TLINES.

COMMIT WORK.</i>

Any ideas?

Bob

[Former Member · Accepted solution]

you should have start new task in BACKground

[Former Member · Accepted solution]

How will I do that ABAP wise?

I'm no ABAP expert and I do not know the syntax to accomplish this...

Regards,

Bob

[Former Member · Accepted solution]

same here friend

[Former Member · Accepted solution]

I think the syntax I used with "starting new task" does indeed start a task in the BACKground.

It seems like this does'nt solve the problem...

Does anybody else has any ideas?

Regards,

Bob

[former_member431549 · Accepted solution]

Any errors showing up in SM58 on source system ? Is the interface defined as EO on the XI side ?

[Former Member · Accepted solution]

Hi Tim,

In the first post in this thread I explained the message in SM58.

The first one stays in SM58 as "transaction executing", as if it nevers get finished (how can this be, it's asynchronous right?).

The ones after that are displayed in SM58 as "transaction recorded", they stay in the queue. If I delete the first one (transaction executing), nothing happens. I'f I reactivate my sender RFC communication channel, the line saying "transaction executing" disappears, and one of the lines changes from "transaction recorded" into "transaction executing". But then this one nevers changes, so the others are blocked again...

Any ideas?

Regards,

Bob

[Former Member · Accepted solution]

can you test program indivally whether it works or not. what is the data size your transfering through RFC if it is huge data then you will get same error. then you need to use proxy instead of RFC.

Thanks

Sreeram.G.Reddy

[Former Member · Accepted solution]

Hi Mario,

Can u replace the Commit work statement with

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

and give it a test

Regards

Kavitha

[Former Member · Accepted solution]

The data size of the packages is very small, so I won't expect a problem there.

I've changed the commit work to CALL FUNCTION 'BAPI_TRANSACTION_COMMIT', but to no avail. The problem remains the same...

Thanx for the help though!

Regards,

Bob

[Former Member · Accepted solution]

can run yur program with out calling to XI.

[prabhu_s2 · Accepted solution]

anything weird when testing the RFC destination in SM59 ?

[prabhu_s2 · Accepted solution]

can u check with Note 730870 - FAQ XI 3.0 RFC Adapter.

Can there be multiple function module calls within one transaction for RFC sender channels?

A: RfcAdapter will only support transactions (sometimes also called LUW) with one call. If an attempt is made to place a second call within one transaction an exception is raised. This is done because within XI there is no transactional context between messages and each RFC call is wrapped into one message.

[Former Member · Accepted solution]

When you execute with 'In background task' it is a QRFC call....can you check in SMQ1 and see if there is any erroneous entry in there ?

Also, please check the following...

check that the Sender agreement is correct

check the RFC metadata system details given in the RFC sender channel....this system has the RFC FM in it ..right?

All these are points i thought you might want to check....

what you have done seems right and the same scenario with similar code as you initially posted works perfectly fine for me.....

Thanks.

[prabhu_s2 · Accepted solution]

also can u test it by wrapping ur RFC in one F/N mod

[Former Member · Accepted solution]

The connection in SM59 works perfectly fine.

[Former Member · Accepted solution]

I tried to run the program without calling to XI. No errors whatsoever.

No errors in SMQ1 also.

I've checked the Note 730870 - FAQ XI 3.0 RFC Adapter already many times. As far as I can see there isn't any information in it that relates to my particular problem.

I'm also quite sure the Sender agreement and the RFC metadata settins are allright.

Many thanx on all the suggestions!

Please keep them coming...

[prabhu_s2 · Accepted solution]

can u test the rfc by wrapping in a f/n module? keep us posted on the o/p

[Former Member · Accepted solution]

I do not understand your suggestion:

what do you mean by wrapping it in a f/n module?

I've you could explain it a little more, then I could try it out!

Bob

[prabhu_s2 · Accepted solution]

have a f/n module created and inside the created f/n mod use this rfc and test the scenario.

[prabhu_s2 · Accepted solution]

hi bob, any updates on this?

[prabhu_s2]

check if any of these helps you

<a href="/people/shabarish.vijayakumar/blog/2008/01/08/troubleshooting--rfc-and-soap-scenarios-updated-on-20042009 - RFC and SOAP scenarios</a>

<a href="http://help.sap.com/saphelp_46c/helpdata/en/22/0424ba488911d189490000e829fbbd/frameset.htm">RFC Programming in ABAP</a>

<a href="http://help.sap.com/saphelp_nw04/helpdata/en/c8/e80440a832e369e10000000a155106/content.htm">http://help.sap.com/saphelp_nw04/helpdata/en/c8/e80440a832e369e10000000a155106/content.htm</a>

[Former Member]

They don't seem to really help for my particular problem but thanks anyway!

Bob