SOAP in XI: message use="encoded" and binding/@style="rpc"

[Former Member]

Hi

Hope somebody who is familiar with XIs SOAP implementation could give the answer for my questions. Problem is that the SOAP server is not working but I am afraid that the reasons are not really simple.

In our company we have to provide some SOAP services. I have entered as much as I could in IR ... including a simple scenario. Then imported the scenario to ID and the wizard created a number of agreements and determinations...

As I need to describe the service to external parties, then I used IDs Web Service definition tool to generate the WSDL.

But as the external messaging framework (for us a preprogrammed SOAP client) is fixed, I noticed that there are some differences that might matter.

XI generated WSDL where SOAP binding has

wsdl:binding/soap:binding/@style="document" but I would need it to be "rpc"

And the second thing is that in binding message bodies have attribute @use="literal" but as the messages should have several parts then it should be "encoded" (and encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

also is needed then).

Could somebody explain if these may be the reasons why the soap server does not work. And if there is a way to define soap interface so that it would have above mentioned properties as needed.

A easy question also... I would need for a method to have an empty message... inside soap body there should be just a tag with the message name and no content. But I can not figure out how to create a message type with no datatype.

Thanks for any input!

[stefan_grube]

Hi Heiko,

I have not understood fully. When you have a SOAP server in your company and want to use XI as SOAP client, the SOAP server should generate the WSDL. If this is not possible, you should create the WSDL with an external tool like XMLSpy.

If the XI is the server, you generate the WSDL here and provide this for the Web Service client. In this case the external parties should be able to work with the WSDL provided by XI.

The SOAP adapter has some restrictions. When you want to use RPC style, it might not work. Look in note 856597 (FAQ: XI3.0 SOAP Adapter) for details.

Regards

Stefan

[Former Member]

Hi, Stefan

Thanks for the answer. To clear my questions: we want to deploy XI as the SOAP server (sry I have not figured out if it is a sender or receiver channel by name - all this inbound-outbound naming in XI is quite complex). Our SOAP server/XI is actually just one part of a big SOAP network and MAFIA it uses rpc styled SOAP messages.

The note is really useful, but still it does not give any hint how to make a RPC styled SOAP interface. So the problem is still up for me. As I am not very familiar with WSDL bindings and SOAP... for the message it self, is there any difference as for the RPC vs DOCUMENT style is discussed? Is it possible that the physical structure of a SOAP envelope could be the same?

And the second question: is there a way in IR to define several parts for a message. Something like:

<message name="isiku_andmed">
  <part name="paring" type="tns:isiku_andmed_paring" />
  <part name="keha" type="tns:isiku_andmed_keha" />
</message>

[stefan_grube]

Hi Heiko,

You are not able to create a WSDL with RPC style. In SP16 you will be upload an WSDL with RPC style into XI, but during the upload it is changed into document style.

http://help.sap.com/saphelp_nw04/helpdata/en/43/ce993b45cb0a85e10000000a1553f6/frameset.htm

I am not familiar with RPC style and don't know MAFIA. If your SOAP client is not able to upload WSDL in document style, you have to change the generated WSDL of XI afterwards with an XML tool.

Regards

Stefan

[Former Member]

Hi

At first... the forum speller somehow (I didn't do anything, honestly) managed to turn AFAIK to MAFIA. Sry.

Thanks for the reply... so I think I am practically stuck with implementing the interface in XI with document style - so that it would look like a SOAP encoded RPC-styled message and then after publishing/activating the service I will have to rewrite the WSDL manually. I think I can live with that.

Found good reading: http://searchwebservices.techtarget.com/ateQuestionNResponse/0,289625,sid26_cid494324_tax289201,00.h...

I think I'll come back with some further questions soon.

Thanks,

Heiko