on 06-23-2014 12:35 PM
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
Inbound service interface with multiple 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
Receiver Determination
Interface Determination
Receiver Agreement
Error
Test message in soapUI:
Thanks a lot!
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
Hi Eng,
Thank you for the prompt reply...
Within the receiver determination, I have 2 options
option 1
option 2
Should I go for option 1?
Kind regards,
Dimitri
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
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
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
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
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
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
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
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
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
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
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
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.