Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

I came across with  a situation where client was looking out for one WSDL with multiple operations in it. Lets say, If one cleint program depending upon incoming values from legacy, want to route messages to a particular endpoint which will do some operation in R/3 side. For example – If data is sepecific for insert/Update/Delete in legacy.

We often receive requirements to create separate interfaces for Insert/Modify/Delete and normally we follow below approaches:

  1. If Source structure are almost same then create a generic structure with indicator field in it which will specify if incoming data is Insert/Modify/Delete.
  2. If structures are different then import three structure in source mapping and do n:1 multi mapping using BPM, which hits the performance and it complicates the solutioning.

and so on..

Like wise we think about different solutions with respect to our requirement. We came across to a situation where client required one WSDL with multiple operations in rather having separate WSDL’s for all end to end scenarios. In actual scenario, we have  created a SOAP to Proxy synchronous call and achived this solution successfully.

In this weblog, I am creating one Asynchronous SOAP to File scenario mainly focussing on how to handle multiple operations in ESR and ID.

We are working on SAP PI 7.31 – SP- 05.

Below is the development done for this scenario. I am just showing the important steps done for this development.


I assume we are done with creation below Data Types and Message Types.

Service Interface

Create one service interface with Multiple operations in it. Have a look into below screenshot.

Above picture depicts three operations Add/Modify/Delete, with Message Type for Add operation selected. Similarly we have to provide Message Type for each operation created above in last step.

Next step is to create three different Message and Operation Mappings for each operation we created in service interface.


In Integration Directory, Create 1 SOAP Sender Communication Channel and 1 File Receiver Channel. Once done, create an ICO like this.

Inbound Processing – Provide Sender Communication Channel and other values.

Receiver – Receiver tab contains the trick for Operation Specific  receiver determination. Have a look into below screenshot.

As we can see in above screenshot, we have to use Operation specific option to use multiple operations and depending upon these operations, we can send these data to multiple receivers (As per our requirements.). In our scenario, we are sending all files to same receiver.

Receiver Interfaces –  Next step is to provide Receiver Interfaces (Operations Mapping) for each operations. In ESR, we have created multiple Operation mapping for each operation. We will use that in this step. Have a look.

This receiver interface contains data for Add operation, similarly we can assign operation mapping for each operation.

In outbound processing provide, receiver file channel and activate these developments.  Next step is to download WSDL and publish this to service registry.

Once you open downloaded WSDL in SOAP UI, it will look like below screenshot.

Similarly, you can check these operations in WSNAVIGATOR too if you have published this on SR.

This is just an example scenario and we can use this feature to provide different solutions and it reduces complexitiy. In ID part using operation Specific option, provides various gates for enhance receiver determination and integrating various things into one.

Keep us posted with the requirements, you are using similar kind of approach.

Labels in this area