A multi-operation web service scenario

[Dimitri]

Dear,

We have a simple synchronous scenario: SOAP <-> SAP PI <-> ABAP proxy.

In the outbound and inbound service interfaces, we have multiple operations.

The exact same scenario, using a single operation, works very fine.

Now the question is: is there something wrong with my configuration or it this a little bug in our SAP PI 7.11 SP11?

ESR

Outbound service interface with multiple operations

• All based on external definitions
• interface pattern is stateless because we have multiple operations

Inbound service interface with multiple operations

• all based on created data types/ message types
• interface pattern is stateless because we have mulriple operations

Operation mappings and message mappings created accordingly.

Please note that I use a XSLT mapping to read the SOAP header too.

ID

Sender Agreement

• linked to sender SOAP adapter with Do Not Use SOAP Envelope used.
• SWCV of sender interface indicated

Receiver Determination

• SWCV indicated
• type of receiver determination is standard
• operation-specific

Interface Determination

• SWCV of sender interface indicated
• Operation mappings indicated

Receiver Agreement

• points to a receiver XI adapter for proxy communication with the back end system.

Error

Test message in soapUI:

Thanks a lot!

[markangelo_dihiansan]

Hi Dimitri,

Eng is right, there will only be one root when Do Not Use SOAP Envelope is checked. There are two ways to solve this in receiver determination:

1. Do not select a software component or you can check not-operation specific (needs confirmation)

2. Use xPath for your condition as what is suggested here http://scn.sap.com/thread/3479420

In Interface determination this will get tricky, this time you have to use xPath to find the correct operation mapping.  Since you are reading the header via XSLT, you might need an additional field in your intermediate mapping (via Operation Mapping) to place the values there e.g

1st Mapping - Whole Soap Envelope to Message Type with the additional field

2nd Mapping - Message Type with the additional field to the Message Type in target Service Interface.

Hope this helps,

Mark

[Dimitri]

Hi Mark, Eng,

The option Do Not Use SOAP Envelope, I need for reading the SOAP header. I guess there is no other way to accomplish that without using that option?

I will take a further look at the receiver determination and xPath conditions.

But do I need that? There is only 1 receiver involved.

Kind regards,

Dimitri

[engswee]

Hi Dimitri

The option Do Not Use SOAP Envelope, I need for reading the SOAP header. I guess there is no other way to accomplish that without using that option?

AFAIK, there is no other way.

If you have only 1 receiver, then as Mark suggested, change the receiver determination to be NOT operation specific.

Then at interface determination, use the XPath conditions to choose the correct operation.

Rgds

Eng Swee

[Dimitri]

Hi Eng,

Thank you for the prompt reply...

Within the receiver determination, I have 2 options

option 1

• software component version: leave empty
• type of receiver determination: standard

option 2

• software component version: fill in
• type of receiver determination: standard
• not operation-specific

Should I go for option 1?

Kind regards,

Dimitri

[engswee]

Dimitri

I think both are fine because once the SWCV is empty, it should automatically remove the choice for operation-specific.

Rgds

Eng Swee

[Dimitri]

Hi Eng,

Within the Interface Determination, it seems that the condition field cannot be edited.

Also, when I add a line for an extra receiver, I can edit it.

But when I save, the condition disappears. Very strange.

Any thoughts?

Thanks a lot.

Dimitri

[engswee]

Hi Dimitri

That is the correct behavior.

In Interface Determination, you will need more than 1 operation mapping in order for the condition field to be editable. If you save the object with the 1 operation mapping after all your edits, it will auto remove the condition, which should be correct because there is only 1 operation.

Also, by the way, you can refer to William's reply to the first comment on a reason why the SWCV affects routing determination.

Rgds

Eng Swee

[Dimitri]

Hi Eng, Mark,

I reviewed the scenario again, but I lack knowledge to complete the interface determination step.

Mark replied to use an intermediate field. Should I fill it with the namespace or other data?

I guess this is needed to route the message to the correct second operation mapping?

My development skills are inadequate to complete this tricky part I'm afraid.

Any help is really appreciated!

Thanks a lot.

Dimitri

[markangelo_dihiansan]

Hi Dimitri,

I reviewed the scenario again, but I lack knowledge to complete the interface determination step.
Mark replied to use an intermediate field. Should I fill it with the namespace or other data?
I guess this is needed to route the message to the correct second operation mapping?

The intermediate field is used to place the value(s) from the SOAP Header since your target message type does not contain it. It will be used in a second mapping message (see my original reply) or just one mapping if you use Java mapping.

To point to the correct message type, all you have to do is to type xpaths e.g

/p1:Envelope/p1:Body/p2:YourMessageTypeHere (with namespace) EX

or

/p1:Envelope/p1:Body/YourMessageTypeHere (without namespace) EX

Hope this helps,

Mark

[Dimitri]

Hi Mark,

I already use an XSLT mapping to immediately map the SOAP header fields to the target structure in 1 step. But this only works for a WSDL containing 1 single operation.

I guess I need to drop the XSLT mapping for a multi-operation WSDL?

But if I use just 1 operation mapping, I cannot add any condition. So using 1 single java or XSLT mapping will not work, I guess?

Also, have 2 operation mappings in place means having 4 service interfaces to refer to.

I'm confused about the setup of such a case using an intermediate structure.

[UPDATE]

What about the condition within the Interface Determination in case 2 operation mappings are referred to?

One containing the condition and 1 blank or just the condition on the second operation mapping, assuming they are executed one after each other

Kind regards,

Dimitri

[engswee]

Hi Dimitri

Here is roughly how the Receiver Determination and Interface Determination objects would look like:-

Receiver Determination

It should be NOT operation specific - either set the SWCV to blank or set the checkbox for "Not Operation Specific". This is because your root node is always <Envelope> (due to the "Do not use SOAP envelope" setting) so it cannot dynamically determine the Operation.

Interface Determination

Here should also be not Operation specific - so set the SWCV to blank.

Similar to the first step, operation cannot be dynamically determined due to root node being always <Envelope>. Therefore use Conditions to select the correct operation mapping and receiver interface/operation.

The condition should be based on the existence of the Xpath of the sender operation, example from Mark's reply above:-

Condition 1 - /p1:Envelope/p1:Body/p2:SenderOperation1_MT  EX

Condition 2 - /p1:Envelope/p1:Body/p2:SenderOperation2_MT  EX

Then in your OM_Mapping1, you would map from SenderOperation1 to ReceiverOperation1. You can include the XSLT as one of the steps in the OM to retrieve the SOAP header details.

Hope this will be useful.

Rgds

Eng Swee

[Dimitri]

Hi Eng Swee,

Thanks a lot!

With this, I can try again...

Just 1 thing: for the name (in the interface determination), I need to enter the operation.

This means that I state it like this: InboundServiceInterface.Operation?

I cannot choose from the drop-down, so I guess I need to enter it manually?

For the moment being, I cannot choose the operation mapping nor can I enter it manually.

I hope that this will be enabled as soon as I have the name field available.

Thank you

Dimitri

[engswee]

Hi Dimitri

The receiver operation name is automatically populated from the operation mapping. Only if there is no operation mapping involved, then you can manually enter the receiver interface/operation name.

The main thing is to choose the operation mapping. If you use the search help, can you remove any specific criteria (sender system, sender interface, etc) and refresh the selection?

I don't have access to the system right now, so I can't simulate whether the blank SWCV is causing the operation mapping to be unavailable in the search help.

If the above does not work, can you test it out if the operation mapping is available if you put the SWCV?

Rgds

Eng Swee

[Dimitri]

Hi Eng Swee,

Leaving the SWCV blank, I cannot remove the search criteria. That is disabled.

When I fill in the SWCV, I see the operations appearing:

But in that case, I cannot see the logic of having multiple conditions for 1 single operation.

Kind regards,

Dimitri

[Dimitri]

Hi Eng Swee,

Let's try to finish this...

Can you think of an alternative?

I tried again, but still no luck when putting in a condition or indicate an operation mapping.

@ Mark dihiansan: any idea about the Interface Determination behavior? I know the conditions are

fairly easy, but I cannot get them in.

Thanks a lot.

Dimitri

[markangelo_dihiansan]

Hi Dimitri,

I was able to recreate your issue. I can conclude these two:

1. If an SWCV is not chosen and the corresponding inbound service interface/namespace has been entered, there is no operation mapping appearing on search help. If it is only allowed to choose operation mappings then it would not be an issue.

2. If an SWCV is chosen, it will result in a runtime error.

To make this work, you need to select stateless XI 3.0 compatible for both the sender and receiver.

Regards,

Mark

[Dimitri]

Hi Mark,

When I go for Interface Pattern Stateless (XI30-compatible), I get an error when I want to activate my Service Interface. Using that pattern, you can only have 1 operation in your service interface.

Seems like we are stuck, isn't it? Scenario is not even that complicated. I guess it must work using multi operations, no?

Kind regards,

Dimitri

[Former Member]

Hello Dimitri,

As per SAP Documentation

The difference between the stateless (XI 3.0-compatible) and stateless interface patterns is that the stateless interface pattern uses Web service technology, which also makes point-to-point connections without PI possible. Furthermore, stateless service interfaces can define several operations that lead to several methods of the proxy classes with the Web service proxies in the back-end system.

If you use only stateless you should be able to use mutiple operations.

Regards,

Sriprasad Bhat

[Dimitri]

Hi,

That is absolutely true, but then I got stuck in the Receiver Determination and Interface Determination steps.

Kind regards,

Dimitri

[markangelo_dihiansan]

Hi Dimitri,

It is true, that is why you need to use just a simple type like the one I did in this POC . The idea is to use Do Not Use SOAP Envelope, read the haeder and use xPaths for interface determination..

Regards,

Mark

[Dimitri]

Hi Mark,

I will go through that thread and try again...

So, this combination should work?

• Read information from the SOAP header
• Use Do not use SOAP envelope in the sender SOAP adapter
• multi-operations in the Service Interface

Kind regards,

Dimitri

[markangelo_dihiansan]

Hi Dimitri,

The service interface should be set to XI 3.0 compatible for the Do Not Use SOAP Envelope + Read Information Header to work. You can replace the contents of the SOAP message when posting it to XI as a substitute for the multiple operations.

Regards,

Mark

[Dimitri]

Hi Mark,

Can you be more specific on You can replace the contents of the SOAP message when posting it to XI as a substitute for the multiple operations ?

What about the operation in the service interface? Something generic?

And the mapping? Can I still use the XSLT I'm using now?

Thanks a lot.

Dimitri

[markangelo_dihiansan]

Hi Dimitri,

Technically if the service interface is XI 3.0 compatible, it will not care about the input message at all In your case, there would only be one operation and it is generic (just to generate wsdl). The SOAP Body can be replaced with different message types as per requirement and the XSLT mapping can still be used.

Regards,

Mark

[engswee]

Hi Dimitri

The issue is caused by the combination of "Do not use SOAP Envelope" and the sender service interface with multiple operations.

Because of the "Do not use SOAP Envelope" setting, the main document payload will have <soapenv:Envelope> as the root.

For multiple operations interface, during runtime, the determination is performed based on the root node. In order for multiple operations to work, all the operations must have different root nodes, i.e. <Operation1>, <Operation2>.

However, for your case, the root node will always be the soap envelope instead of <Operation1>, <Operation2>. If you look at the logs, it says that it failed to look for an operation with the root node Envelope.

For single operation, it does not check against the root node during Receiver Determination.

One alternative approach that I could think of is to combine all the definitions for the different operation into a single operation, and then use XPath condition based routing to determine the receiver.

Rgds

Eng Swee