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

[Shabarish_Nair]

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?