cancel
Showing results for 
Search instead for 
Did you mean: 

IDOC adapter message limitation Status 64

Werner_Magerl
Participant
0 Kudos

Hello,

we have implemented an IDOC R/3->XI->R3 scenario.

Sometimes it happens, that the sending system generates a hugh number of idocs.

In this case, the IDOCs are posted to the receiving R/3 system, but stay on status 64 which says,

"...to few dialog processes...."

So the receiving SAP system has to few processes to start the processing of the idocs.

But we can no enhance the amount of the processes.

Is it possible, to limit the calls of the IDOC adapter

or to schedule the idocs, or to make a package?

This should be done on XI!!!!

I have read the QUEUE option, but we are working on 4.6BASIS, so this did not solve the problem.

best regards

Werner

Accepted Solutions (1)

Accepted Solutions (1)

MichalKrawczyk
Active Contributor
0 Kudos

Hi Werner,

have you tried this weblog:

/people/sreekanth.babu2/blog/2005/01/05/delayed-xi-message-processing ?

maybe you can post idocs at night with this configuration?

Regards,

michal

Werner_Magerl
Participant
0 Kudos

hello michal,

this weblog does not fit for all the messages.

Maybe it works for the problems with the ALEAUDIT, as a lot of them stay in status 51 in the receiving system, as the AUDIT statistc is locked.

But for my bigger problem is does not help,

because I during the day, I receive the messages in a normal amount. But during the night, the partner start some mass processing and the we get a lot of message, and I do not know at which time this is.

I do not want to schedule the job during the day.

There are >200 message within some seconds then.

How does the job process the messages then. One after the other or also parallel???

best regards

Werner

Steven_UM
Contributor
0 Kudos

Hi Werner,

If real-time processing during the day is not a real requirement then you might want to opt to collect those idocs and schedule a background job for example every hour that will process a number of them ( you can configure the package size via a variant ).

In most SAP systems, the number of background processess is much higher during the nights so you would be able to cope with the higher increase ...

Regards,

Steven

Answers (2)

Answers (2)

Former Member
0 Kudos

Werner-

This situation can be handled using some variations to your suggestion of handling it in XI.

1) In the Partner profile of the target R3 system, use the option 'trigger by background program' in the inbound parameters. This way, the IDOCs will be created in the database, syntax checked and will be set to status '64' but with a different message (mostly No filters....). At this point, we are not even trying to post the IDOC to the application, which takes the most processing time.

2) Then in your traget SAP system, schedule program RBDAPP01. There are various options available to restrict your selections. By scheduling this program to run in regular intervals, you can process IDOCs which are in status 64, there by re-processing them if some failed during the last run because of lack of processes.

Some additional information on performance improvment:

RBDAPP01 is an interesting program, because it allows you to parallel process the IDOCs plus process them in packets. That is, instead of processing IDOCs one by one, you can make the program to use all the available free processes to process the IDOCs in parallel. This will greatly reduce your processing time.

If you see, this program has a tab called 'Parallel Proc' (assuming you are logged on in English). You can activate the check box 'Parallel Proc. Active' and choose a 'Server Group'.

Now, before using this option, you need to understand that this program will occupy all free DIALOG processes. Which means no process will be available for users to log on (even admins) while the program is busy posting IDOCS. However, this limitation can be overcome by fixing a system parameter on the server group which will limit the number of processes to be used by this program. For e.g., in one of my implementations, we set up the profile parameter in such a way that out of 13 dialog processes available, the program will always leave 5 processes free thereby occupying only seven free processes max.

This setting was done by the basis team and probably you or your basis team already know about it. If not, let me know, I will try to find it out from our guys here.

Hope the above explaination help. For more information check note 399271 and other related notes for RBDAPP01 PARALLEL PROCESSING.

KK

0 Kudos

Hi,

The problem "to few dialog processes .." usually is solved changing the inbound parameter of partner profile.

It's recommneded to use "Trigger by background program" despite of "Trigger Inmediately".

With this option, you have to scheduled a job ( RBDINPUT) in order to process Idocs in status 64. With this option, system use Background process, not dialog process.

Good Luck.

Francisco