Skip to Content

Service interface and Multiple Operations – Is it just an Hype?

Its been quite a long time for now since the release of the latest prodigy in the SOA Middleware genre, PI 7.1 (EHP1). Most of us ideally must have found enough time on our hands to play around with PI 7.11 and many might have even completed successful ‘Go Live’.

So considering this time span, I would like to raise some questions around the Service Interface and the support for Multiple Operations within.

There is a good blog around on SDN titled Using Service Interfaces? Now Reuse One! that talks about the re-usability feature plus eventually the usage of the service interface when involved with multiple operations.

Examples of scenarios where I have found the SI to work miracles for me is;

1.A multiple method ABAP proxy – This is so cool. Now I generate a SI with multiple operations and when I expose it as an ABAP proxy, it generates a class with multiple methods. This makes life so easy unlike the old days of the message interface when you had to create multiple interfaces and generate multiple Proxies.

2. A classic example would also be what the blog (mentioned earlier) talks about.  Now in one service interface you can define multiple modes i.e an operation which is asynchronous and also another that is synchronous.

But then even with all this, there is one thing that bothers me a bit.

Let me give you an example;

Lets say I have a requirement to call an external WS. This particular webservice has multiple operations and hence it has multiple SOAP Actions.

If I am to design my scenario as an ABAP proxy to WS call, I would start by creating an outbound SI with multiple operations (like the WS itself) which would result in multiple methods being called from SAP R3/ECC. During the configuration in ID, everything should go fine as expected until we hit a roadblock.


What if I have the same Receiver and I need to call multiple communication channels for the same service interface?

Now Why would I need multiple communication channels?

a. Even though I may have the same Target URL, I want to define multiple SOAP Actions i.e even though the Target URL for the WS remains the same, I need to define different SOAP Actions for the SOAP Operations. ex. ABAP Method 1 should call SOAP Action1 and similarly Method 2 should call SOAP Action 2 of the WS.

b. I want to call multiple Target URLS itself.

I dont argue the fact that the requirement can be easily achieved using Dynamic configuration which will enforce only one channel and its adapter specific attributes like the target url and action to be determined dynamically in my mapping. Or maybe create different inbound service interfaces per operation instead of a single SI (so much for the service interface and multiple operations support eh?). But why would I need to be forced to do that?

I personally believe that when there is support for a single SI to handle multiple operations, there should be a feature as to when I do my Receiver Agreement, I can control the determination of the communication channel based on my operation also.

What could have helped is an option based on the Operation?

Right now the Receiver Agreement  looks something like the below;


What if we introduce another selection criterion as below?


and thus eventually depending on the operation, we can provide a specific communication channel?


Well what do you think? Is this a good idea?How would you want to see it done? Do you have a better workaround currently?

PS: Or did I get the whole thing wrong?  – Is there a way to configure multiple receiver adapters per operation for the same inbound service interface?

You must be Logged on to comment or reply to a post.
  • Confession time: I’m confused on this one Shabz.

    I understood the reason for change (to Service Interface with multiple operations) was to cater for SOA (or ESOA) progression.

    Using that as my perspective, if you would want to add a new Soap Action then the service provider would simply add a new operation & then you could simply re-gen your client proxy. Or if there is Service Lifecycle governance on the provider side then they would version step the service without any impact on all the consumers.

    I’m thinking along the same lines for the requirement of a different target URL per operation. That would go against the grain of SOA. So you have one service interface for a particular business object (refined to a suitable level of granularity to enable re-use) with multiple operations to cater for all the different (& permissable) SOAP Actions using one target URL. This makes it easier for Service Lifecycle management. It also makes it easier for consumers generating proxies (Abap or Java) because you have one WSDL (with one URL) to work with.

    It sounds like you may be thinking more along the lines of ROA (Resource Oriented Architecture). I’ve just recently blogged about having SA & ROA co-exist (architecturally). It may just work with having just Abap & only using PI only during design-time. If we’re using PI at run-time, then it will probably need a combination of old-school style PI development (a single service interface & 1 operation) & new-school style PI (1 service interface with multiple operations).

    Just my take though 🙂

    • Trevor,
      thanks for the comment.
      I understand you have every reason to get confused here 🙂

      To simplify things, my question would be that if PI needs to call a multi operation web service  (Receiver Service), is there a way we can do the configuration using the same service interface (that has the multiple operations)?

      The problem i found was that if I had to invoke various actions on the same webservice, I couldnt find a standard config available.

      So my personal belief is that there should be another parameter i.e the operation to define the message flow at the receiver end 🙂

      Too much to ask i guess… maybe i am just being Grumpy???


      • Grumpy Indeed! 🙂

        I guess I would probably understand it better if you had a business use case reference.

        Case in point, you have a client proxy on Abap & you’ve adopted a mediated approach through PI. You would need something to trigger the appropriate method (or Soap Action if you like)in the client proxy (with the required parameters), something like a UI. The message flow in this case would be determined by what’s coded in Abap. The SOAP Action along with the PI operation triggered & the provider operation triggered are all determined by the client proxy method that was originally initiated in Abap. This is all done for us through the proxy framework with no additional work required on PI.

        Would you use some business rules to determine which action/s to invoke on the same service interface?

        The way I see it, if you’re planning calling multiple operations on the same (or different) service interface/s then we’re venturing into Service Orchestration territory. Composition Environment & Netweaver BPM handles that with ease & the you have the added benefit of aligning the operation calls (or sequence of operation calls) to any number of business rules. The good thing about this approach is that it adds a huge degree of flexibility when you need to change the status quo.

        As a last ditch effort, you could try some service orchestration on the Abap side but I don’t think it will look as pretty & it won’t be very flexible.

        Sorry Shabz, I guess I’m against adding the additional operation parameter. But I love the discussion 🙂

        • i have tried to add some diagrams. maybe that should help the readers.

          And yes, you have got the problem statement correct. So if my requirement is indeed to use the same SI for the receiver, you still wouldnt recommend a mechanism for PI to handle that as part of standard config? If so I will be forced to create two different SI and handle this as part of Interface Determination so that I can support two different Actions or else go down the Dynamic conf. ASMA way.

          Hmmmm … Well this is indeed a good discussion and really glad you found time to drop comments but then still I would love to see that additional parameter 😉

          PS: Will really wait to see what others have in mind. I believe its a conversation worth having!!

          • You can still use same SI just create another “Communication Component” and “Communication channel”, in communication channel you can assign specific SOAPAction.
          • Gourav,

            that is exactly what is being questioned in this blog.
            why would i be forced to create another communication component? That doesnt fit an ideal development standard.


          • As Trevor pointed out you can still call service with multiple operation from ABAP proxies and Logical port you can configure SOAP action for each operation.
            Usgae of PI on other hand recommended for mediated calls only so you can create as much “Communication Component” you want and it will work.
            Agree there are some shortcoming in present SOAP receiver adapter and multiple SOAP action should be allowed(I never tried if it is possible to add multiple SOAPAction using some tricks).
            Another idea for acessing multiple SOAPAction is usage of Adapter Specific attribute in receiver communication channel, which is populated by “Java UDF” in mapping.
            Having said that multiple operations are not “over rated” and they are right approach to design for SOA.
          • Gaurav,
            Assume you have web service provider with two methods in a single service. In that case, with one service for receiver I would never be able to complete my configuration to use both the operations. Creating another business service is not absolutely logical in this situation..!!


  • Hi Shabarish,
    Good point. I have noted this issue sometime back and always wanted to have this feature and I was hopeful about 7.1 EHP1.

    I was working on 7.1 at one client and I absolutely assumed that, operation based mapping is available then and went ahead with my design and development.Finally got a shock when I was trying to create the objects in ID as, for a single receiver, we can not map multiple operation. Then I searched on SDN and found out that, operation based mapping is going to be available in 7.1 EHP1 (looks like they found the missing thing immediately and added). However, looks like this works only for different systems on the receiver side.

    Never knew how to suggest something to SAP for PI..!!

    When we select the software component version and select  “operation-specific” in receiver determination, it does show the operations in the sender interface. But unfortunately, if we add the same business system for each of the operation, the configuration over view does not allow us to create multiple sets if interface determination and receiver agreement for corresponding multiple operations.

    As per the solution, as you suggested, the agreements should always be at the operation level (as there is always the default operation in 7.1 ESR objects). This means, similar to operation mapping, once we select the interface, it should force us to select an operation and should be displayed as interface.operation (single field). In addition to this, the receiver determination also should be modified to allow the creation of multiple sets of interface determination and receiver agreement based on operations.

    This way, we can eliminate giving multiple WSDLs for operations like create/update/delete of a single business object.

    Hope SAP PI product engineers listen to this conversation..!!

    “Lets make PI better.”

  • Hi Vijay,

    I am also facing the same Problem today, I believe this issue is not only with the SOAP Receiver but also with the File receiver channel as well.