Skip to Content
Author's profile photo Former Member

Achieving Serialization Behavior in Typical Asynchronous Interfaces

In any SAP System landscape, there is always a requirement to maintain runtime/processing order for interfaces.  This would result in designing Async Interfaces, using the quality of service EOIO.  The configuration for this is Standard Out of the Box in PI, and can be achieved with minimal effort.  The challenge occurs when there is a requirement for a typical Asynchronous interface, to run in a serialized mode

The following  blog, discusses such a business case, and possible technical options around it.

Business Case:

This related to a Work Management System, which Integrates with an SAP ISU box.  SAP  ISU box, send out jobs or service orders to the work management system.  The Field Service personals , execute the jobs at the customer  location and send out updates for the jobs back to  SAP.   These updates either include change, completion and job duplication details. 

Technically,  the work management system publishes status sync messages, which SAP PI subscribes to.  This is via a Async. web service call.  The volumes of these calls are high, with over 5000 jobs on any given day.

Technical Challenge:

The same technical Interface, bring in updates for completion and change statuses.  In case of completion, every message is unique and does not have an inter-dependency.  The updates are consumed in ECC and the service orders are updated.

In case of changes, the updates in ECC need to be processed in the order in which, they are processed at the work management system. 

Since this interface, has an Async pattern,  it results in a challenge to  achieve the above integration.  

Technical Solutions:

  1. Change the mode to Queue Based message processing:

        A simple solution would be to change the pattern to queue based processing.  The problem with this is that all status sync messages would be queued, irrespective of dependency requirements, resulting  in the following issues:

          a)   Enhancement processing time, due to queuing of message

          b)  Possible queue blockages due to failure on any message of the queue.

  1. Content Based Queuing:

Another approach is develop content based queuing mechanism  in PI. This would involve, building a custom adapter module, to generate queue names based on payload content.  This might have the following problems:


         a)  Additional  processing times, due to payload parsing in the adapter module.  This can become a potential bottleneck in case of time sensitive interfaces

        b)  Adapter  modules cannot typically be used with Sender SOAP Adapters.  In the above case, the subscription was via web services.

  1. Using a classical  TRFC/QFRC based approach in ECC:

The following are the details of this approach:

ECC provides mechanism  to call function modules in TRFC. The following is the link to the details around this from SAP Help

TRFC based integration provides a mechanism to call any function module IN BACKGROUND TASK AS A SEPERATE UNIT.   A QRFC is an extension of TRFC and can easily be achieved by assigning a queue name before the TRFC call.  Following is the documentation around this

The following can then be the approach for achieving serialization:

  1. Define custom queues in ECC ( SMQR)

The following needs to be done in the inbound proxy class:

  1.    Have business rule checks implemented in ECC,  to determine the need for serialization

  2.     Separate business logic in a RFC.

  3.     Once the need for serialization is determined,  call the FM TRFC_SET_QUEUE_NAME to set the defined custom queue.

  4.     Call the business logic in TRFC as  IN BACKGROUND TASK AS A SEPERATE UNIT with a local destination

The following are the benefits of this:

  1.   No additional development to determine content based queues
  2.   Business logic remains in ECC to determine serialization.
  3.   Selective serialization possible based on filters in ECC
  4.   The interface can run in Async mode in majority of the cases.
  5. Data base locks can be avoided if the queue processing segregates logical unit of work.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member


      By letting the need for serialization determined in the inbound proxy implementation, you can ensure the processing order for the messages after they hit the SAP ISU's local IE.

      But, how would you ensure the order of the message processing from WMS ->PI i.e Change Msg 1 always precedes Change Msg 2?

      Author's profile photo Shabarish Vijayakumar
      Shabarish Vijayakumar

      I am a bit confused here. Maybe you can explain the problem statement better?

      Are we just looking at sending messages from ISU to PI in EOIO mode? Guess I am missing something here!