idoc trfc processing very slow

[Former Member]

Hello,

I am troubleshooting slow processing of idocs in an Xi test system.

idocs are being processed at a rate of betwen 40 / 60 per hour so at the current rate there will stil be another 3 days (approx) until the queue is cleared.

In SMQS on the Xi (source) system the specific idoc destination is set-up as follows: -

Clt - 10

Destination - R2RREG100

Type - R

W/o tRFC -

Max.Conn. - 10

Max. Runtime - 60

Status - WAITING

Act.Conn - 5

Host ID - ax2t003a_X2T_43

The RFC connection between the two systems has been tested successfully.

Selecting TRFC Monitor and there are still over 3000 rows similar to the following (was over 7000 when first checked)

Caller - PIAFUSER

Function Module - IDOC_INBOUND_ASYNCHRONOUS

Target System - R2RREG100

Date - 15.12.2011

Time - 12:38:22

Status Text - Transaction recorded

Transaction ID - 8218046C00014EC9DE911C9B

Host - ax2t003a

Tctn

Program - SAPMSSY1

Cln - 10

Rpts - 30

I am told by the application team that processing 7000+ idocs is not a large amount for this system

The Xi (source) system and the R3 destination system have both been restarted to clear memory etc but this has not improved speed of processing.

I presume the problem was caused by trying to process too many idocs at once through the Xi system as mentioned in SAP Note 1548446.

I have read SAP Note 1483757 and checked ST03n last minute load on RFC table in the R3 destination system -

Task Type Name - RFC

#Sequential Read - 4,782,264

1. T Seq Read - 1,157

Avg Seq Read - 0.2

#Accesses - 13,515,579

T Time - 204

Avg T - 0.0

#Changes - 54,206

T Changes - 63

Avg Changes - 1.2

1. Calls - 18,352,049

Avg Time - 0.1

#Reads - 1,828,651

#DB Recs- 109,376

#Records - 7,687,467

#Calls - 0

T Time - 0.0

Avg Time - 0.0

Last minute load Table Statistics for the destination system ARFCRSTATE table shows the following :

Table Name - ARFCRSTATE

1. Records - 1,822

Modifiable - 226

1. records - 0

2. Sequential Reads - 1,596

T Access - 1

In accordance with the note I tried setting the following on the detaination system but did not see any improvement in processing speed so have now removed the parameter and scheduling of the report.

1. Set the profile parameter abap/arfcrstate_col_delete to 'X' on the default profile of the destination system.

2. Periodically schedule the RSTRFCEU batch job in intervals of 5 minutes, in the destination system.

Q1 -after setting 'abap/arfcrstate_col_delete' I did not restart the R3 system. Is a restart required for this to take effect?

Q2 - What else should I check to identify why idocs are being processed so slowly ?

Q3 - Is there anything else I could change to speed up processing ?

Many thanks,

[Former Member · Accepted solution]

David,

To enhance performance , if you can hit the message directly to Integration Engine instead of Adapter Engine. This might improve the performance.

Also, try to club the Idocs together.

[Former Member · Accepted solution]

Many thanks jbagga for your reply.

My issue was resolved by SAP who suggested changing the processing mode for message type in WE20 on the receiver system from "Trigger Immediately" to "Trigger by background program".

With the processing mode set to "Trigger Immedaitely" the sender system calls the receiver, the idoc is stored on the dateabase and the application processing was carried out in the same LUW. As a result of this the send must wait until the application finishes processing the messages before it can anything else.

The processing mode was changed to "Trigger by background program" which decoupled the IDoc transfer from the IDoc application processing, performance immediately improved in the XI (sender) system and cleared the queue.

Regards,