Reducing the configuration effort in SAP Process Orchestration via Sender Wildcards in Integration Flows
With SAP Process Orchestration 7.5 Support Package Stack 04, we have released support for sender wildcards in Integrated Configuration Objects and Integration Flows that helps you to reduce the configuration effort for specific cases. This feature was actually top 1 requirement from our current Customer Connection project, see Allow multiple inb. Channels for one ICO on the Customer Influence space. Thanks to all customers and partners who have provided feedback and contributed here.
What are the use cases?
In general, the new feature is applicable to scenarios where you need to apply the very same routing rules for multiple senders. This could be suitable in B2B scenarios for instance where you have to handle multiple partners, or when connecting multiple clients of your SAP ERP system via the same interface. In any case, the benefits would be as follows:
- Add a new sender without changing the Integration Flow
- Reduce maintenance effort
- You only need to create one single Integration Flow, no need to copy the routing rules
- Changes of the routing rules have to be done only once and not redundantly
How does it work?
Those of you who were working or are still working with an SAP Process Integration dual stack, certainly are familiar with the concept of loosely coupled configuration objects. With the new feature, we follow the same approach, and decouple the inbound processing from the rest of the message processing. Here, we re-use the sender agreement objects, and make them also available on SAP Process Orchestration. You can now create an Integration Flow with a sender wildcard. For each sender, you then need to create a sender agreement. Note that within the Integration Flow wildcards are not supported for the sender interface.
How to create an Integration flow with sender wildcard?
When you create a new Integration Flow in the Process Integration Designer perspective of the SAP NetWeaver Developer Studio, you can now select a further pattern, the so called Recipient List (Multiple Senders) pattern.
In this case, the Allow multiple senders check box is automatically preset, and the type is set to Wildcard. In the graphical representation of the Integration Flow, the asterisks for sender and channel indicate that multiple senders are supported. In the figure below, I have already assigned a sender interface and maintained the routing rules including receiver split and mappings. By the way, you can also switch to the Wildcard type for an existing Integration Flow by simply selecting the Allow multiple senders check box. However note that in this case your previous settings may be lost.
How to create and add sender agreements?
You have two options to create a new sender agreement, either from scratch or via forward navigation. In the Integration Flow Properties section, switch to the Senders tab, and select button Add.
In the upcoming dialog, the sender interface name and namespace are preset based on the sender interface of the Integration Flow.
When selecting button Finish, the sender agreement editor comes up. Maintain sender channel and further attributes if applicable, then save. Note, that the sender agreement object is shown below the communication component node in the navigation tree.
You can also create a sender agreement from scratch. Select the respective system, and select New Sender Agreement from the context menu.
Once the new sender agreement has been saved, it shows up in the Possible sender agreements for this integration flow table of the "wildcard" Integration Flow. If you open the Integration Flow, the list is automatically refreshed. If the Integration Flow is already open when adding a new sender agreement, you need to refresh the list to get it displayed. By the way, when double-clicking on any entry in the table, you can navigate to the corresponding sender agreement.
Are the runtime properties still supported for sender wildcards?
For Integration Flows with sender wildcards, the runtime properties have been enhanced to cater for multiple senders. In order to show you the runtime properties capability, I have chosen an Integration Flow with sender wildcard and different types of adapters. Within the Process Integration Runtime perspective, select the Integration Flow, and select Show Runtime Properties from the drop down menu.
As you can see from figure below, for each sender the respective link to the channel monitor is displayed. In addition, for SOAP channels the WSDL URLs and SOAP endpoints are displayed. Another new feature is that now we also show REST endpoints.
How does this look like in the Integration Builder?
As mentioned above, the sender wildcards capability is also supported for Integrated Configuration Objects (ICO) maintained in the Integration Builder. If you create a new ICO in the Java WebStart client, you simply have to maintain an asterisk for the sender communication component (optionally for the sender communication party either).
As you can see in figure below, for ICOs with sender wildcards, you cannot maintain any channel in the Inbound Processing of the ICO anymore. Here, like for Integration Flows, for each sender you have to create a corresponding sender agreement. Unlike to Integration Flows, in the Integration Builder you cannot create sender agreements via forward navigation, here you need to create the sender agreements from scratch. Also, you won't get the list of possible sender agreements displayed.
Hope this blog entry is helpful for you to get started. For more details, see also release notes on help.sap.com.