Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Idocs are sent in random order

Former Member
0 Kudos

Hello,

We use idocs DELVRY01 to send deliveries to external systems. The communication is done via RFC connections.

In the partner profiles, we customized the 'send immediately' option (in order to have real time interface).

We supposed that the idocs would be sent in the order of their idocs numbers or of their serialization orders, but it seems that it is not the case.

What is the way to ensure that the idocs are sent in a First in first out way?

Thanks a lot for any help

9 REPLIES 9

Former Member
0 Kudos

Hi Julien,

From my understanding, the serialisation handling is the reponsibility of the receiving application. This is the way its handled in SAP. The outbound Idocs are tagged with a serialisation number and then on the receiving side the idocs are processed in serialisation order.

This becomes problematic when you have process imediately, as different Idocs can be generated in different work processes and there is no guarantee that they will finish processing in serialisation sequence (and hence no guarantee that they are sent to the receiving system in serialisation sequence). If you collect the idocs and process in discrete packets, you have the chance (but not the guarantee) of sending them in serialisation order, but you will be able to process in serialisation order on the receiving end (by sorting by serialisation number before processing).

Hope that helps.

Brad

0 Kudos

Thinking about it, it would not be so difficult to create a custom version of RSEOUT00 so that it would only send an idoc if it were the next one in the serialisation order.

Thus, you could collect outbound idocs, and periodically schedule a Z version of RSEOUT00 so that it would send all idocs collected so far that were in serialisation order (with no gaps).

It would just then stop processing when it found a gap. The next execution would start from where the last one finished and again process until it found a gap. If the gap from the last execution was not filled then it would do nothing (as the idoc would still be being created in the application).

This means you could handle the serialisation on the SAP side without having to do lots of work on your legacy system or EAI tool (potentially much more work).

Hope that helps.

Brad

Former Member
0 Kudos

Hi Julien,

Since you indicate in the partner profile that IDoc's are to be sent immediately (packet size is always 1) each IDoc is treated as a separate process.

If you have more than 1 application server, it is possible that IDoc's can be processed at the same time on different application servers.

Sollution: Make sure IDoc handling is done by only one application server.

If you have delivery notes with differences (like delivery notes with only one delivery item and also delivery notes with many items), then the creation of one IDoc is faster with small delivery notes and slower with larger ones. Since more dialog processes are defined it is possible that smaller delivery notes are sent earlier as larger ones (thuis disrupting the order).

Solution: 1. Combine IDoc's by using the Collect IDocs with a small PacketSize (i.e. 10 - 20) and trigger report RSEOUT00 every now and than. (This reduces the IDoc delivery note interface to a batch interface).

Solution 2: Use message control (it goes to far to explain it here, but in SAP Help (located on the path /SAPHelp/Helpdata/EN/dc/6b803343d711d1893e0000e8323c4f/frameset.htm) you can find many details for this, also the selection conditions for sending the IDoc's.

If nothing is to your liking, you can always program your own processing unit that will ensure the right order (using the function module MASTER_IDOIC_DISTRIBUTE).

Hope this gives you some clues,

Regards,

Rob.

Former Member

Former Member
0 Kudos

Hello,

Thank you all for your answers.

In addition to this, does anyone know if it is possible to assign the sending of idocs to only one application server (we use 2 and i guess that is where my problem comes from)? If yes, what are the transactions involved or what is the procedure to follow?

Thanks in advance.

Julien

0 Kudos

Hi Julien,

The only way to do this is to either:

- restrict the users of applications which generate the idocs to one application server (not really practical), or

- turn off send immediately and schedule the RSEOUT00 as a background job on a specific application server.

But remember, even if it were possible to restrict the idocs to one application server and send immediately, there is still the possibility for then to send out of sequence (as per the example with the big delivery, small delivery provided by Rob).

Please close the thread when if have finished up with the questions.

Cheers,

Brad

0 Kudos

Hi Julien,

To assign processing to only ONE application server, you must first supply the following details:

- What is the partner type of the remote system you transfer IDoc's to. Use Transaction WE20 to find out.

- With the OUTBOUND parameters what Receiver port are you using (simply double click on the receiver port to get the details). Give the type (i.e. Transactional RFC, File, CPI-C, Internet, ABAP-PI or XML).

For some it is not possible (only if you would rebuild the interface to another type) and for the rest different approaches exist for SINGLE application server usage.

Regards,

Rob.

Former Member
0 Kudos

Hi Rob,

Thank you for your answer.

We use partner type LS and a TRFC port. Is there a way to assign one or the other to a single application server?

Thanks for helping.

Julien

Former Member
0 Kudos

Julien,

The following solution works really well with my current implementation.

Instead of using a TRFC port to send the IDOC, you should use an ABAP port. The ABAP port gives you full control of the IDOC, you can copy function module OWN_FUNCTION to start you off.

Inside the ABAP port, I have logic to check the serialisation sequence.

When the IDOC has passed the check, you then call functiom module IDOC_INBOUND_ASYNCHRONOUS with the RFC destination of the receiving system.

I then update the last successful IDOC sequence number on table BDRGOUT.

Cheers,

Kevin