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

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Venkatesh Manavala


    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?



    1. 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


Leave a Reply