Skip to Content
Technical Articles
Author's profile photo Alexander Bundschuh

Simplify the configuration of receivers in SAP Process Orchestration via Receiver Wildcards in Integration Flows

Besides the support of sender wildcards in SAP Process Orchestration that we have previously shipped, see blog, we now also support receiver wildcards in Integrated Configuration Objects and Integration Flows. This capability has been introduced with SAP Process Orchestration 7.5 Support Package Stack 06. This feature was actually a feature request from last year’s Customer Connection project, see the corresponding request Integration Flow: Visualization for large amount of receivers on the Customer Influence space.

What are the benefits?

Receiver wildcards are useful if an integration flow has a large amount of receivers with similar configuration of receiver interface, mapping, and interface conditions. It helps you to reduce the configuration effort in case of many receivers. You do not need to maintain the receivers in the Integration Flow beforehand, instead you can add a new receiver without the need to change the Integration Flow by adding a corresponding receiver agreement.


Similar to the sender wildcard support where we made the configuration object of a sender agreement available on SAP Process Orchestration, we now also support receiver agreement objects. With the new feature we follow the concept of loosely coupled configuration objects, so we decouple the message processing from the outbound processing. You can now create an Integration Flow with a receiver wildcard. For each receiver, you then need to create a receiver agreement. In figure below, you see the Integration Flow with receiver wildcard, and the list of related receiver agreements.

Note: You cannot use sender and receiver wildcards within one and the same Integration Flow, so it’s either the one or the other.

New pattern introduced

if you create a new Integration Flow, you have the option to select the pattern Recipient List (Arbitrary Receivers).

In the Runtime Configuration properties of the new Integration Flow, the check box Allow arbitrary receivers is preset. You can also switch to receiver wildcards in an existing Integration Flow by selecting the very check box, however be aware that this would remove the so far configured receivers.

The receiver system is then replaced by an asterisk, and the type is set to Wildcard.

Routing techniques

When using receiver wildcards, all routing techniques are supported: static routing, dynamic message routing based on mappings, and receiver rules. We have enhanced the condition editor of the static routing option to support XPath and context objects expressions making this option sort of dynamic as well. Context objects expressions are also supported when using receiver rules.

Let’s choose Static Routing here. In the condition editor you can either add or edit a static receiver based on the list of communication parties and systems maintained in the Directory, or you can add or edit a dynamic receiver and condition. Select Add Dynamic to add a new dynamic receiver rule.

In the dynamic receiver configuration, you can either select from constant party or system, based on a context object, or based on an XPath. The same applies to the dynamic condition.

As you can see below, we have maintained two conditions either retrieving the name of the receiver from a context object or from an XPath expression.

Receiver agreements

You have two options to create a new receiver agreement, either from scratch or from within the Integration Flow. For latter, select the receiver pool within the Integration Flow editor. In the properties, switch to Receivers. This shows you all possible receiver agreements that are related to the Integration Flow. From here, select button Add.

A new dialog comes up where sender system and receiver interface are preset. Maintain a new receiver party and system by clicking on Browse.

Once done, click on Finish.

This opens the receiver agreement editor where you at least need to maintain a receiver channel. The receiver agreement is stored below the business system.

You can create a new receiver agreement from scratch by selecting the business system, and then New Receiver Agreement from the context menu. This will also open the receiver agreement editor where you at least need to maintain the sender system, the receiver interface and the receiver channel.

Once done, you need to refresh the list of possible receiver agreements in the Integration Flow to get the new receiver agreement displayed.

Integration Builder

Receiver Wildcards are also supported for Integrated Configuration Objects within the Integration Builder. In the Integration Directory, create a new Integrated Configuration, and switch to tab Receiver. Here, you find the Allow arbitrary receivers flag.

Once selected, on tab Receiver Interfaces, asterisks are set for receiver communication party and receiver communication component.

Furthermore, the receiver agreement editor is also supported. However, other than for Integration Flows, for Integrated Configurations you won’t get the list of possible receiver agreements displayed.


Hope this blog entry is helpful for you to get started. For more details, see also release notes on

Assigned Tags

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


      We applied SP06, after that for existing iflow interfaces, we are getting below Error
      "Terminating queue worker-thread due to fatal error: java.lang.NoSuchMethodError:$AssignmentType.isWildcard()Z"

      do we need to set any parameter?



      Author's profile photo Jan Trobitius
      Jan Trobitius

      Hi Venky,

      this error complains about a missing method. But that method is part of the initial SP06 software. From that point of view it seems that SP06 hasn't been applied correctly on your system (maybe only partially ? ). Can you verify that, please ?

      This error is not caused by a missing parameter.


      Thanks and kind regards,


      PI dev

      Author's profile photo Shwetambari Saxena
      Shwetambari Saxena


      Is there any plan to make this feature available in AEX 7.4?

      Thanks and Regards,



      Author's profile photo Alexander Bundschuh
      Alexander Bundschuh
      Blog Post Author

      Hi Shweta,

      no, I'm afraid but we won't downport this to 7.4


      Author's profile photo Former Member
      Former Member

      Hi Alexander.

      In this configuration, as you said, It's only for receivers with similar configurations (Service Interface, Mapping and so on). What hapend, if you need to add a new receiver with another Service Interface definition and a different mapping? I tried to add a new receiver component and that is not possible. We can not build a new ICO / Iflow because it is the same Sender Component and Sender Interface and we have a duplicated object, so, it looks like a impossible configuration for the new receiver.

      Author's profile photo Emil Jessen
      Emil Jessen

      Hello Alexander,

      I was wondering whether this feature will allow for the combination of a Central and External Adapter Engine within a single ICO? Can the sender agreement use a different adapter engine than the ICO's receiver channel? If yes, then it would be a great help for our B2B scenarios using DMZ.

      Unfortunately, we are still waiting on a SP upgrade in order to test this, so I will have to keep my fingers crossed.

      Thanks for a good blog.

      Kind regards, Emil

      Author's profile photo Alexander Bundschuh
      Alexander Bundschuh
      Blog Post Author

      Hi Emil,

      no, this won't be supported, an integration flow or ICO runs within one adapter engine only, even if using wildcards.