on 03-17-2009 9:18 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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.
>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
User | Count |
---|---|
84 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.