tRFC processing for outbound IDocs for Transfer Idoc Immediately

[vikas2]

Introduction:

We recently had a performance issue raised by BASIS team . It was reported that many DIA processes are busy processing IDocs. The interesting part was that a lot of tRFCs were getting created with destination NONE which wasn’t obvious for us .

The partner profile points to the PI system with IDocs to be triggered immediately and we were not sure why tRFCs will get created with destination NONE.

Through this blog, I’ll show the tRFCs getting created for outbound IDocs when

• Partner profile is set to "Transfer IDocs Immediately"


• Partner profile is set to “Collect IDocs”

Please note that the steps in the test will stop tRFC processing and it should be done in a sandbox system so that no users are affected.

Set up:

tRFC processing for a well-functioning SAP ABAP system is so fast that it will be very difficult to monitor the tRFCs . Hence, to proceed with testing, we'll need to register the destination ‘NONE’ in SMQS so that it can be controlled like a normal RFC destination by the scheduler.

• Add NONE to the tRFC scheduler and stop automatic processing.

This can be achieved by transaction SMQS and adding destination NONE.

• Click on Registration and give the destination 'NONE'

 



 



 



 



Now that NONE has been registered like a normal destination, we can deregister it so that tRFCs are not automatically processed. However, they can be manually processed from SM58.

Any tRFC pushed to destination NONE won’t get executed and stay as a tRFC entry. This will allow us to watch the tRFC.

• Derigster PI_DESTINATION in the tRFC scheduler to stop automatic processing.

We also deregister the PI destination but the concept is general and it’ll work for any destination pointed by the port of the IDoc.

 



 



 

Test Overview.

 

Both NONE and PI_DESTINATION have been deregistered.

This means SMQS scheduler won’t process the entries automatically for these destinations. You can still process them manually in transaction SM58.

 

-Partner profile for the messages is set as trigger immediately.

 

Test with IDoc triggered via output type.

We test with a message triggered by output type:

 



 

• There is an entry created for destination NONE and function module IDocS_OUTPUT_TO_R3.

 



 

And the IDoc stays in status 30 (even though the partner profile is set as trigger immediately).

 



 

If we now process this entry by either registering the destination NONE

 



 

The previous tRFC gets processed , a new tRFC gets created with a new TID.



In addition, the IDoc gets pushed to status 03.



 

Test with IDoc triggered via change pointers.

To be sure it's not specific with output type processing, we tested an IDoc not triggered via output type.

 



 

Just like previous tests, a tRFC entry gets created for destination NONE and IDoc gets created in status 30.



 



We now register the destination NONE. This causes the tRFC entry to be processed and the IDoc status moves to 03. A new tRFC entry gets created for PI destination.

 



 

CALL STACK ANALYSIS

Looking at the call stack to understand why a tRFC gets triggered for destination NONE, the call to function module IDocS_OUTPUT_TO_R3 is embedded in call of EDI_OUTPUT_NEW.

 



Here it calls function module IDocS_OUTPUT_TO_R3 in background task which triggers a tRFC with destination NONE.



 

• 
  

  IDocs with partner profile set up as "Collect IDocs"

  
  

There is nothing out of ordinary here .

• IDoc gets created in status 30 . No tRFC entry is created.

• Output processing program as RSEOUT00 will process the IDoc and set the status to 03 and create a tRFC entry for the RFC destination of the IDoc port.

Summary

In summary for outbound processing there are 2 tRFCs when the partner profile is set as "Trigger IDoc immediately"

-              IDoc is generated in status 30 and a tRFC entry gets generated for destination NONE.

-              If the above TID is processed - IDoc is processed to status 03 and a new tRFC gets generated for destination of the IDoc port.

 



This was a learning for us as we thought that for trigger immediately option, IDoc gets created and sent to the target destination via a tRFC but as we see in this blog, this step is broken into 2 steps.

Note 1862248 mentions how to fix the delays in outbound processing but wasn't explicit in mentioning the 2 step tRFCs and hence we decided to do the test to clarify it for us.