Multiple RFC Destinations

[Former Member]

Hi

I have 75+ idoc interfaces. some are high priority interfaces and some are low priority interfaces.

We did queue prioritization for those interfaces too....But we have only one RFC destination for

all the interfaces.

We are thinking to go for one more RFC destination(SM59), so that we can route low priority high volume

load through this. This way high priority messages can't be effected.

Is this the right approach of implementing ?

thanks

kumar

[MichalKrawczyk · Accepted solution]

Hi,

I don't think anymore RFCs are necesary as this they will not give you

anything more as RFCs are only pointing to the ERP processes (numer of work processes)

and this is what defines how quickly the flow will go to ERP

what you could do is to define all interfaces in WE20 in ERP

for run by background program

and then try to stear the program to process then in a different way

(high and low) - this could speed up high priority interfeaces

much more then many RFCs I believe

see also optimizing IDOC inbound perf:

http://help.sap.com/saphelp_sm32/helpdata/en/5f/45f93b4139b478e10000000a11402f/content.htm

and OSS note: 399271

Regards,

Michal Krawczyk

[Former Member]

Hi,

I do not think using different RFC destination in general can give you some benefits if they point to the same application server, the "bottleneck" is the number of dialog WP.

But maybe using different logon groups you could be able to give higher priority to a process (which uses a powerfull logon group) then to another one which is using a smaller logon group.

Regards,

Sergio

[MichalKrawczyk]

Hi,

>>But maybe using different logon groups you could be able to give higher priority to a process (which uses a powerfull logon group) then to another one which is using a smaller logon group.

don't you think that all in all it goes to one principle that each idoc goes to one work process in - process immediately mode

and you can only change it if you set all IDOCs to run by scheduled backgrudnd program - RBDAPP01 as I mentioned ?

and only this program can change the bahavior as it can transfer

packages to work processes ?

Regards,

Michal Krawczyk

[Former Member]

Hi Michal,

yes, I agree, the background approach is the one that allows idocs to be processed much faster, my point was more on the prioritization.

I mean, the packaging mode allows you to increase the volume but it also increases the latency of messages to be processed which depends on the frequency of RBDAPP01 for a specific idoc.

Using different logon groups + immediate processing could allow to prioritize messages also on the backend without impacting the latency, even if at the end the total throughput is lower.

For sure this also depends on WP and prioritization on the IS.

I think one approach is more oriented to high volumes, the other more to "real time" processing (please note the quotes ).

What do you think?

Sergio

[Former Member]

If it is outbound idoc (ECC-xi-third party), then workprocesses of ECC will be consumed right ? and not XI ? Plz correct me if I am wrong.

Meanwhile could you plz comment on my below points. Why this wont help

If we have only one RFC destination:

1. out of 75+ interfaces, e.g if one high volume-low priority interface triggers 10k idocs and after

that if high priority interace get triggers, then first high volume-low priority messages will be piled up

in RFC destination and after they get processed then only high priority messages will ger process.

If We have 2 RFC destination:

2. we can route high volume-low priority interface into one RFC destination and high priority interface

into another RFC destination. This way high priority interfaces won't be effected.

[Former Member]

>If it is outbound idoc (ECC-xi-third party), then workprocesses of ECC will be consumed right ? and not XI ? Plz correct me if I am wrong.

Both WP will be used on ECC and XI

>If we have only one RFC destination:

>

>1. out of 75+ interfaces, e.g if one high volume-low priority interface triggers 10k idocs and after

>that if high priority interace get triggers, then first high volume-low priority messages will be piled up

>in RFC destination and after they get processed then only high priority messages will ger process.

>If We have 2 RFC destination:

>

>2. we can route high volume-low priority interface into one RFC destination and high priority interface

>into another RFC destination. This way high priority interfaces won't be effected

If both RFC destinations point to the same logon group, WP's to be consumed will be taken from the same "pool" so I see no benefit in separating RFC destinations, it's the same of using a single RFC destination.

If you use different logon group then it's different, because you can assing more resources to a logon group than to another (this means different number of WPs) and at the end different priority.

Regards,

Sergio