cancel
Showing results for 
Search instead for 
Did you mean: 

File 2 RFC scenario debugging

former_member187587
Contributor
0 Kudos

Morning all,

I have a very simple A sync. scenario File to RFC.

To allow debugging of the Interface,my ABAP programmer has created an endless loop.

What's strange is that on SM50 I can track a new Process created by the XI user and after

a few more seconds another session with a new ID appears....

Have you encountered a similar issue before? what is the reason for it then?

Any way, after removing the "debugging loop " everything runs fine.

Points will be awarded for the most reasonable answer....

Nimrod Gisis

Accepted Solutions (0)

Answers (4)

Answers (4)

former_member187587
Contributor
0 Kudos

After discussing the issue with a BASIS person , it appears that this behavior is normal for ABAP system and is a result of the number of dialog process defined in the system and the need of the application to distribute the system resources during the RFC call.

No duplicate data are inserted.

I guess the ABAP consultant blaming it on the XI didn't know much about that.

Thank you all for your posts.

Kind regards

Nimrod

MichalKrawczyk
Active Contributor
0 Kudos

hi,

>>>>a few more seconds another session with a new ID appears....

but does this ned session have the same Report and User

fields as the one with the loop ?

does it end or does it keep going like the one with the loop?

I check on my system and nothing like this happens

but to be sure you can do something like that:

inside your RFC make an insert to a Ztable

call your RFC from XI and check it you have one or two inserts...

Regards,

michal

Former Member
0 Kudos

Hi,

<i>To allow debugging of the Interface,my ABAP programmer has created an endless loop</i>

And you solved with

<i>Any way, after removing the "debugging loop " everything runs fine.</i>

Also you said it is in R3 Queues.

But i know how to solve the queu problem in XI side see the below link

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20bb9649-e86e-2910-7aa9-88ed4972...

Regards

Chilla

former_member187587
Contributor
0 Kudos

It was indeed solved but as the saying says:

"I'm not afraid of what I know , I'm afraid of what I don't know that I don't know.."

Meaning...if there is a strange behavior of XI or RFC I don't want to find it for the first time in Production system...

Any way I'm still waiting for some clues here guys...

Message was edited by:

Nimrod Gisis

Former Member
0 Kudos

Hi,

I do agree , see the below reason and links also

you can see that many dialog work processes are occupied with the program SAPLARFC. You might also see update or batch processes with the status stopped RFC.

This is because in transaction SMQS as many tRFCs were started at the same time as the parameter settings allow and this has resulted in the user contexts losing their rollability. This situation arises for instance when mass data is processed. See SAP note 726148 for more information and possible solutions.

http://help.sap.com/saphelp_nw2004s/helpdata/en/8a/145db7b9c3c64e8af1c0be1dae6f37/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/be/470dc21ca4447b828597f614aaaec1/frameset.htm

regards

Chilla

<i>reward points if it is helpful..</i>

Former Member
0 Kudos

can you debug both the sessions in sm50 .check whether rfc inserts data twice or after timeout it rstarts in Sm50 or prallel processing is used

MichalKrawczyk
Active Contributor
0 Kudos

Hi,

it must be an echo hehe:)

kidding:) I don't know what this might be

I debug this RFC from XI by stopping the queue

and luw debugging from smq2

or with the greate external breakpoints

(but only if ERP is based on WAS 7.0)

Regards,

michal

former_member187587
Contributor
0 Kudos

I guess it is an echo...Michal its a Sunday morning...forget about the SDN, relax..

If you have an idea....

I tried to debug the XBTI queue but couldn't "catch" the RFC (didn't want to deactivate all XBTs...)

you said:<i>I debug this RFC from XI by stopping the queue </i>

I'm talking about R3 queue not XI's.....

take care anyway.

Nimrod

MichalKrawczyk
Active Contributor
0 Kudos

>>>Michal its a Sunday morning...forget about the SDN, relax..

so time to go to the office but only after the gym

>>>>>I tried to debug the XBTI queue but couldn't "catch" the RFC (didn't want to deactivate all XBTs...)

my mistake, I always think about IDOCs as recenlty I had an issue with IDOC

debugging from R3 (in XI) (by stopping the queue and debugging in XI from R3)

anyway have a nice Sunday

Regards,

michal