Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Do not broadcast the values in the SOAP request

 
Baranenko Nikolay
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have example SOAP request



Try to create SOAP request on Java, using SAAJ API
this code



after I got this SOAP request



In result code absent values "http://examples/2001" "http://newsite/mon".

Please help me to find solve this problem.
 
g tsuji
Ranch Hand
Posts: 689
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those are not properly speaking "attribute". An SOAPElement may live in certain namespace or in a null namespace... That is what happens for GetParameter, request, MonCode etc...

Note also that the re-use of bodyElement, paramsElement may cause confusion at times... I can't say it is absolutely discouraged, but certainly not encouraged, as long as you can keep them on track - it is up to you.
 
g tsuji
Ranch Hand
Posts: 689
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also I just notice that you want request to be child to GetParameter, you have then to change this line.
 
Baranenko Nikolay
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for help,

in result this code



result




BUT still small questions

- how to addition this information in begin



- deleted "-ENV" and deleted "<SOAP-ENV:Header/>"




 
g tsuji
Ranch Hand
Posts: 689
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The package javax.xml.soap provides extensions to org.w3c.dom to help control of many aspects of the message which are not considered generic or universally significant to an xml compliant to the recommendation. They help coders to simplify certain non-generic manipulation much easier than otherwise available directly to xml processing in general. For instance, the choice of prefix should not be a generic thing one may be concerned of, say a choice of default SOAP-ENV (for soap 1.1) or env (for soap 1.2) should be 100% comfortable for anyone than a choice of soap - but it does not mean the library necessarily intends to dictate and force these choices upon you...

The things you're asked can be done relatively easily with javax.xml.soap packages.
- how to addition this information in begin
<?xml version="1.0" encoding="UTF-8" ?>

The SOAPMessage class provisions two fields that you can set at your discretion. One of them is WRITE_XML_DECLARATION, defaulted to "false". You can add this line after establishing SOAPMessage object.

- deleted "-ENV"

You actually mean in general to change the default choice of "SOAP-ENV" to "SOAP", or, in fact, could mean to change to any other prefix for the matter.
You can do it by a method setPrefix() inherited from org.w3c.dom interface but you have to apply the method inherited from SOAPElement removeNamespaceDeclaration() to eliminate the original namespace declaration left over and rendered useless, hence a cleanup is probably more elegant rather than straightly necessary. You have to do on every wrapping element proper to SOAPMessage: Envelope, Header and Body. Like this.

and you're done. There are other ways to do this as well at different stages of the process of invocation but those may be way too complicated conceptually and code-wise to entangle the issue directly.

...and deleted "<SOAP-ENV:Header/>"

Here you sometimes have to be careful on dealing with Header. Within the package when an instance of SOAPMessage is created, an empty Header element is automatically created. This may not be the case for other libraries... Having said, soapHeader is never null in this approach and you can spare the control of it. To eliminate the optional Header, you simply do this.

That's it as simple as that and it is also documented in the documentation.
 
Baranenko Nikolay
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for solve.


Please help to understand,
in some cases, correct use?

this onу



and this one



if I use this one



this example from http://stackoverflow.com/questions/15948927/working-soap-client-example

is working good, BUT first 2 variant returned error




 
Baranenko Nikolay
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Baranenko Nikolay wrote:Thank you for solve.


Please help to understand,
in some cases, correct use?

this one



and this one



if I use this one



this example from http://stackoverflow.com/questions/15948927/working-soap-client-example

is working good, BUT first 2 variant returned error




 
g tsuji
Ranch Hand
Posts: 689
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I can only comment on the code shown: I am not so sure, and I don't think so. The SOAPAction would not and could not be set that way. It is not an ordinary MimeHeader. It can be set via the Dispatch object. Setting MimeHeader(s) via SOAPMessage won't help in that regard. So if it (or anything) works, it works probably because of some other code not shown.

..., BUT first 2 variant returned error

The error is what sends back from the server. They are by themselves not capable of that kind of "error". If eventually what is dispatched without the correct SOAPAction, and that in consequence the server does not know what operation to dispatch to, the server could send you back fault code as that. But all these are caused by the dispatching and invoking code, unrelated to the construction of the SOAPMessage as request, I think, as I don't see the whole picture.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic