Messaging Principles for Interface Designers

This article is part of our Integration Cookbook.

Quality of Service

If you can influence the application design of the sender or receiver (doesn’t apply if an external partner/service provider with an existing service is involved):

QoS = Quality of Service

  • BE: Best Effort (Synchronous: the sender waits for immediate response. Basic integration which every beginner understands.)
  • EO: Exactly Once (Asynchronous: decoupled integration, a response might be answered by another message)
  • EOIO: Exactly Once in Order (Asynchronous, but serialized with specific queues)


  • Asynchronous Communication where possible, to reduce dependencies between sender and receiver applications and enable decoupling. Real-time Integration can also be achieved asynchronously, e.g. by using events to trigger an immediate message exchange. (Asynchronous does not mean batch mode!)
  • Synchronous Communication only where necessary: Quick Implementation (Error Handling is pushed to the sender/consumer), but strong dependency regarding development/maintenance as well as for the runtime behaviour. There should be a good reason to go for synchronous integration. Examples: Creditlimit-Check, ATP-Check.
  • BUT: Don´t be afraid, if the best fit is a synchronous setup – in the past there was a rule of thumb, to avoid synchronous interfaces in PI (for technical reasons). This does NOT apply anymore. PI serves this pattern very well by exposing SOAP/REST based services, e.g. to connect with databases (via JDBC) and decouple them from the front-end.

Usage of Queues (Async Only)

  • Dynamic Queue Assignment where possible using the object id  (Order, Material, Customer, …) for single messages
  • Static Queue Names for bulk messages (if the throughput allows it, see below)
  • No Queues, if high volume requirements exist (parallelization and mass processing with bulk messages). To ensure correct serialization (sequencing of objects), use timestamps inside the messages.

Message Throughput

For mass data scenarios, consider the following principles:

  • The ideal message size is within 500 KB and 10 MB in SAP PI
  • EO Messaging (Avoid EOIO with static queue names to allow  parallelization)
  • Consider direct (P2P) vs. mediated communication (EAI/HUB)