SM58 Transaction Recorded Very Slow

[suwandi_cahyadi]

Dear Experts,

I have many tRFC in PI system in SM58 with status transaction recorded. This seems to be because there were an unusual data (file to idoc) from 1 interface that suddenly sends more data than usual. This happens at midnight, since then we have a queue at in SM58 with many  transaction recorded (until tonight).

Strange things is actually that when I try to execute the LUW (F6), the transaction could be processed successfully, even though sometimes after pressing F6, the processing time could take some time (marked by the loading cursor). When the processing time is long, I just stop the transaction, re-open SM58, then the transaction that was executed before will be in the "executing" status and then I execute LUW for the transaction again and it never takes a long time to execute it.

Trying to execute LUWs and ticking the recorded status would end up no transactions executed.

Checking in SMQS for the destination, it is rarely that the actual connection reach the maximum connection. Seeing QRFC resource in SMQS, the Resource Status shows OK.

Going to SM51 then Server Name > Information > Queue Information, there are no waiting requests.

Actually the transactions are do processed, it just they are processed very slow and this impact to the business.

What can I do when this happens? How to really re-process those recorded transactions?

Could this be because the receiver resources? How to check for this?

[prasanthi_chavala · Accepted solution]

Hi Suwandi,

Yes, it depends on the receiver resources. Ask the target system team to turn off the idoc immediate processing at their end and switch to idoc parking mode.

And then try reprocessing all the messages in Sm58 in SAP PI by running report "RSARFCEX".

Once your queue is empty then ask the target team to process the idocs at their end.

Thanks,

Prasanthi

[suwandi_cahyadi · Accepted solution]

Hi Prasanthi,

Thank you for the reply.

How to check the resource of the target system?

Checking the connection in SM59 is fast, checking the ICM resource in SMICM is ok too. The target system is ECC.

Thank you,

Suwandi C.

[engswee · Accepted solution]

Hi Suwandi,

Have you checked the IDoc partner profile setting in ECC based on Prasanthi's suggestion above?

Basically for inbound IDocs into ECC, if it is a high volume interface, the corresponding partner profile should be set to "Processing in background".

For your case, it might have been set to "Immediate processing" - with this setting, when the IDoc is sent from PI, the LUW session both creates the IDoc and tries to process it to create the target ECC document. The first step is very quick but the latter step can take up quite some time. This then might hold up the connection on PI side.

When the partner profile is set to "background", only the IDoc is created in the LUW session and then it is closed - this happens quite quickly. On the ECC side, you then have to set a background job to run program RBDAPP01 with the correct variant to process the IDocs created.

OSS note 1333417 (Performance problems when processing IDocs immediately) explains the situation in more detail.

Rgds

Eng Swee

[suwandi_cahyadi · Accepted solution]

Hi,

Thank you for the reply.

For the IDoc configuration actually it is not done by me.

But I believe, they configure immediate or process in background based on business requirement.

What if the high volume IDoc is required by business to be processed immediately?

Thank you,

Suwandi C.

[engswee · Accepted solution]

Hi Suwandi

I would still suggest to set the IDoc processing to background, and then schedule the background job more frequent (i.e. every 1 minute.)

With this approach, you decouple the processing of the IDoc at the backend and thus PI won't hold up the LUW long.

With this approach, you can still achieve a near real-time/immediate processing and it should still meet the business requirement for it to be processed immediately. This is a common approach for near real-time asynchronous interfaces.

Rgds

Eng Swee

Message was edited by: Eng Swee Yeoh

[suwandi_cahyadi]

Dear Experts,

Let me update the situation,

in SM58 there are transaction recorded messages and trasaction executing messages.

If I execute LUW for the transaction executing message, the message will be gone from SM58 immediately (I assume it means the message is processed successfuly)

If I execute LUW for the transaction recorded message, some times the message gets processed and gone from SM58, some times it takes a long loading time. If it is loading, I will just stop the transaction, go back to SM58 then the message that I executed LUW will be in "executing" then I will just execute
LUW for that message again and it will be gone from SM58.

There are messages in SM58, but if they are processed manually via execute LUW, they get processed fast.

Could this be because a big database table that needs maintenance?

Thank you,

Suwandi C.

[Former Member]

Hi Suwandi,

You can try using IDOC receiver channel as receiver channel in place of transmitting the idocs through tRFC(SM58). On doing so the idocs will be processed immediately with respect to the time stamp of the idocs when they reach the ECC system (the remaining idocs getting locked till then).

If you use ALE communication(SM58), the time consumed may be large because of huge bulk of data. Here, the idocs are not prioritized based on their time stamp when they reach ECC. So it is taking time. And when you execute LUW it gets executed immediately.

Thanks and Best Regards ,

Souvik

[suwandi_cahyadi]

Dear Experts,

According to this link,

http://wiki.scn.sap.com/wiki/pages/viewpage.action?original_fqdn=wiki.sdn.sap.com&pageId=145719978

"Transaction recorded" usually happens when A. processing idocs or B. BW loads.

A.If it occurs when processing idocs you will see function module "IDOC_INBOUND_ASYNCH" mentioned in SM58.
Check also that the idocs are being processed in the background and not in the foreground.

Ensure that background processing is used for ALE communications.

Report RSEOUT00 (outbound)can be configured to run very specifically for the high volume message types on their system. Schedule regular runs of report RESOUT00 it can be run for
IDoc Type and\or Partner etc..

To set to background processing for Outbound idocs do the following:

-> go to transaction WE20 -> Select Partner Select Outbound Message Type and change the processing method from
"Transfer IDoc Immedi." to "Collect IDocs".

Reading that explanations, should the setting of IDoc processing to background (Collect IDocs) is done in PI or the receiver?

If the IDocs is processed collectively, will it make the sending IDoc process faster from PI to the receiver system? What is the explanation that if the IDoc is processed collectively, it would make the IDoc sending to be faster?

Why should we use RSOUT00 report when we already have SM58, and we can execute LUWs in SM58?

Thank you,

Suwandi C.

[Harish]

Hi Suwandi,

The collect IDOC in Partner profile (WE20) is only for outbound idocs, when you want to send the idoc in a chunk (100, 200 etc). It is not applicable for inbound idocs.

regards,

Harish

[suwandi_cahyadi]

Hi Harish,

So we can also configure to immediately send or collect the IDoc for outbound IDoc in PI system using the TCode WE20?

Thank you,

Suwandi C.

[Former Member]

In Addition please check if there are any Locks in the IDOC jobs or user which might prevent the IDOC posting in receiver system.

[Former Member]

Hi,

Please check the below link

http://wiki.scn.sap.com/wiki/display/ABAPConn/tRFC+process+slow+in+SM58+and+Max.Conn+is+not+fully+us...

.............

Mutti

[suwandi_cahyadi]

Hi,

How to really check for the IDoc's lock?

Thank you,

Suwandi C.

[suwandi_cahyadi]

Hi Mutti,

Thank you for the reply.

I have checked the link, the symptoms really match my condition. I have increased the maximum Max runtime.

The result now is that there are still transactions recorded that just sit there and not directly processed.

I Will check the result again later.

Thank you,

Suwandi C.

[Harish]

Hi Suwandi,

Please check if you are having load balancer configuration in RFC destination. If you hit one server for all the calls then it slow the process. Please check the below blog

regards,

Harish

[former_member184720]

Hi Suwandi - * Did you try adjusting the "Max conn"

Entries in Transaction SM58 are in status "Transaction recorded" - ABAP Connectivi...

[suwandi_cahyadi]

Hi Hareesh,

Thank you for the reply. I've increased the maximum connection. But the transactions are still processed slowly.

The active connection rarely reach the maximum connection.

Thank you,

Suwandi C.