SOAP Service: Missing WS-Addressing header - soap

I have a Netbeans SOAP service I can deploy with no issues and a Silverlight client.
When I call the service from Silverlight, I get (in silverlight):
new DiscourseParserWSClient created;
event handler added;
service called; Service State is: Open
http://localhost:8080/DiscourseParserWS/DiscourseParserWSService
An exception occurred during the operation, making the result invalid.
The remote server returned an error: NotFound.
After the client calls the service, GlassFish v3 Domain responds with the following problem I fail to decipher:
WARNING: A required header representing a Message Addressing Property is not present, Problem header:{http://www.w3.org/2005/08/addressing}Action
com.sun.xml.ws.addressing.model.MissingAddressingHeaderException: Missing WS-Addressing header: "{http://www.w3.org/2005/08/addressing}Action"
at com.sun.xml.ws.addressing.WsaTube.checkCardinality(WsaTube.java:235)
at com.sun.xml.ws.addressing.WsaTube.checkMessageAddressingProperties(WsaTube.java:183)
at com.sun.xml.ws.addressing.WsaServerTube.checkMessageAddressingProperties(WsaServerTube.java:281)
at com.sun.xml.ws.addressing.WsaTube.validateInboundHeaders(WsaTube.java:140)
at com.sun.xml.ws.addressing.WsaServerTube.processRequest(WsaServerTube.java:147)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:112)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:195)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:127)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:295)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:515)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:285)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:143)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:147)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
I'm using Metro 2.1 and after quite some googling I suspect the problem might have something to do with it...
I can see the service's wsdl so I believe it can't be an implementation problem. But that warning's stack goes down to the Thread class o.O?
public void run() {
if (target != null) {
target.run(); // <-- to this line to be exact
}
}
Please help shed some light; I already have a couple of eclipse soap services working with this client, but I don't have experience with Netbeans, GlassFish and Metro and can't figure out what's causing this...

Don't know whether or not it is too late, but it helped me sometimes to add the
#Addressing(enabled=true,
required=false)
to the WebService (class annotation). Then the exception usually disappears.
For some more information about the addressing stuff you can refer to 1.

I was receiving the same WARNING and thought this might help someone else.
If you're using the "Reliable Message Delivery" option in Netbeans visual web service designer then you may get this warning.
If you don't require the "Reliable Message Delivery" you can simply turn it off.

I was facing this issue today and the problem was resolved by using the Action attribute on the soap header. I have confirmed this using SoapUI.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mal="http://example.com">
<soapenv:Header>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:2c7ea154-668e-4c8b-abaa-8b119f91b8dd</MessageID>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://example.com/input</Action>
</soapenv:Header>
<soapenv:Body>
......
</soapenv:Body>
</soapenv:Envelope>
If we arent passing the Action attribute than we get error message:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<FaultDetail xmlns="http://www.w3.org/2005/08/addressing">
<ProblemHeaderQName>{http://www.w3.org/2005/08/addressing}Action</ProblemHeaderQName>
</FaultDetail>
</S:Header>
<S:Body>
<SOAP-ENV:Fault xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageAddressingHeaderRequired</faultcode>
<faultstring>A required header representing a Message Addressing Property is not present</faultstring>
</SOAP-ENV:Fault>
</S:Body>
</S:Envelope>
The value of Action header is determined from #Action on the webmethod.
#Action(input = "http://example.com/input", output = "http://example.com/output")

Related

Received non-all-whitespace CHARACTERS or CDATA event in nextTag

I am using web service consumer(1.6.9) in Mule4 and triggering the external soap service, the external service is returning SOAP FAULT and below is the SOAP fault which I am getting as below
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<soapenv:Body>
<soapenv:Fault>
<faultcode>Internal Server Error</faultcode>
<faultstring>Unexpected close tag
</urn:UniqueName>; expected
</urn:UniqueNam>
at [row,col {unknown-source}]: [40,54]
</faultstring>
<Detail>Invalid incoming request /Buyer/soap/C133/X-T/testPull?null</Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
but Web service consumer in mule is returning the below error:
Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag()
Please let me know what is the issue, it seems web service consumer is throwing the above error while parsing the above soap fault.
It seems to be complaining that the SOAP fault response is not valid XML because of this line:
</urn:UniqueNam>
at [row,col {unknown-source}]: [40,54]...
</faultstring>
Note how the text is between </urn:UniqueNam> and </faultstring>. That's not valid in XML. There should be an XML tag or nothing there instead of plain text.

How to invoke a webservice with SAML assertion in header using Oracle SOA BPEL

I need your valuable help/support in solving the below issue Im facing.
I have a requirement to develop a service in Oracle SOA BPEL 11g(11.1.1.5) to invoke a SAML Assertion secured Webservice(ServiceB).
The SAML Assertion will be the response from another Webservice(ServiceA) which will be invoked prior to invoking ServiceB.
This SAML assertion which came as response from the ServiceA should be passed to enter code hereServiceB at the headers.
Below are the ways I tried but failed
1) created a header variable and assigned the SAML assertion to it and added it as a Header property while Invoking the ServiceB.
Error Message:‘The token is missing or is of the wrong data type.’
2) Added OWSM policy 'oracle/wss10_saml_token_client_policy' in the composite at Adapter binding level. And tried passing the Value of SAML by defining a variable at the binding level.
Error Message: 'Unable to access the following endpoint(s): https://www.tpvs.hmrc.gov.uk/dps/dps.jws'
I tried testing the SOAP serviceB from SOAPUI passing the SAML details in headers and its successful.
Request the community to please throw some light and help me in this regards.
Please let me know if you need any further information from my end.
TIA
Shan
Below is the Sample request with SAML assertion at the header:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="cc36a795db335637b5b0da5c383e5a77" IssueInstant="2019-06-21T08:56:56.268Z" Issuer="http://online.hmrc.gov.uk/SAML" MajorVersion="1" MinorVersion="1"><saml:Conditions NotBefore="2019-06-21T09:56:56.268Z" NotOnOrAfter="2019-06-21T13:56:56.268Z"></saml:Conditions><saml:AuthenticationStatement AuthenticationInstant="2019-06-21T09:56:56.268Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="SubjectNameQualifier">SubjectName</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject><saml:SubjectLocality IPAddress="32.42.18.148"></saml:SubjectLocality></saml:AuthenticationStatement><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="SubjectNameQualifier">SubjectName</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject><saml:Attribute AttributeName="SESSION_ID" AttributeNamespace="http://online.hmrc.gov.uk/SAML"><saml:AttributeValue>28c0d81f-3385-4c45-b91e-3b80c5713bd9</saml:AttributeValue></saml:Attribute><saml:Attribute AttributeName="USER_AUTHENTICATION_TOKEN" AttributeNamespace="http://online.hmrc.gov.uk/SAML"><saml:AttributeValue>os0EEQtZLq6kfzm+57M6wbfaWXRGXKV63uV4RPqbd+SKvSS3DeqJ3922dAPw0xL0GQGJgqcTmtkcgHEfuf2jLnywuy427nWe7E0D4KRnz9g77PdH58bDCOV2vAuVHL9p9HFeyO1Oniy7ct9o143rvJ+o6GZtLhotWKnZ9Yi+IW3IbskIWEVIf7OOyHRLq5p3YnLawZnM6LY51wBhpUQCMkornRpjejcrUKTWjlwesKg=</saml:AttributeValue></saml:Attribute></saml:AttributeStatement><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"></ds:SignatureMethod><ds:Reference URI="#cc36a795db335637b5b0da5c383e5a77"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml samlp typens #default"></ec:InclusiveNamespaces></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod><ds:DigestValue>8I/Ilid0fZIqHvXtCZESjgpw9h4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>hCNEvtoRKxNDFFtuXmpzCcd4R5o=</ds:SignatureValue></ds:Signature></saml:Assertion>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:DPSretrieve xmlns:m="https://tpvs.hmrc.gov.uk/dps">
<m:version>1</m:version>
<m:vendorID>your 4 digit vendorID</m:vendorID>
<m:service>PAYE</m:service>
<m:entityType>EmpRef</m:entityType>
<m:entity>as advised by SDS Team</m:entity>
<m:dataType>P6</m:dataType>
<m:got>0</m:got>
<m:nItems>0</m:nItems>
</m:DPSretrieve>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
==============================================================

Wildfly 13.0.0.Final error UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character ä in request-target

We have recently migrated and deployed our application.EAR (API's) packages in wildfly 13.0.0.Final from GlassFish 3 in Linux environment. While testing application api's its not supporting scandic characters and giving below error (Error copied from server.log from wildfly). But the same test request working fine with the application api's deployed in GlassFish server. I tried to study so many blogs related to wildfly but could not get any solutions. Could some one help here please.
I tired below setting changes in standalone.xml file to set the charset to UTF-8, but its not helped.
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" url-charset="UTF-8"/>
<servlet-container name="default" default-encoding="UTF-8">
2018-07-13 17:06:45,189 DEBUG [io.undertow.request.io] (default I/O-4) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character ä in request-target
at io.undertow.server.protocol.http.HttpRequestParser.handleQueryParameters(HttpRequestParser.java:523)
at io.undertow.server.protocol.http.HttpRequestParser.beginQueryParameters(HttpRequestParser.java:486)
at io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:410)
at io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:147)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:93)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:52)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
Below is the request XML which we are sending to application deployed in both Wildfly and GlassFish
<SOAP-ENV:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<StartHeader SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="0" xmlns="http://www.openuri.org/2002/04/soap/conversation/">
<callbackLocation>http://TESTUI</callbackLocation>
</StartHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ListAttributeValues xmlns="http://www.openuri.org/" xmlns:v001="http://xml.comptel.com/NIMS/address/listAttribteValuesRequest/v002" xmlns:v0011="http://xml.comptel.com/NIMS/address/v002">
<listAttributeValuesRequest xsi:schemaLocation="http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002 http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002" xmlns="http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002" xmlns:spec="http://xml.comptel.com/NIMS/address/v002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spec:searchItemList>
<spec:attribute>
<spec:name>district</spec:name>
<spec:value>Jär</spec:value>
</spec:attribute>
</spec:searchItemList>
<spec:attributeName>district</spec:attributeName>
<spec:maxItems>100</spec:maxItems>
</listAttributeValuesRequest>
</ListAttributeValues>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Finally i managed to fix the problem with help of JBossDevelopers community
I don't think it's the contents of SOAP message that is the problem, but the URI that is used to touch the web service. Problem can be fixed using any of the below option. Option 2 will be recommended for latest wildfly versions where undertow subsystem introduced.
By adding the following Java option to startup script :
-Dorg.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true
or we can set the allow-unescaped-characters-in-url="true" and url-charset="windows-1252" flags in the undertow subsystem in standalone.xml file.
I think these options were added as part of the undertow:6.0 schema as attributes of the https-listener and http-listener elements.
See here:
wildfly/wildfly-undertow_6_0.xsd at master · wildfly/wildfly · GitHub
An example configuration:
wildfly/undertow-6.0.xml at master · wildfly/wildfly · GitHub

Mule: how to consume a service from a remote client

I have been following this tutorial which is really great to consume wb services from WSDL http://training.middlewareschool.com/mule/consuming-wsdl-first-service/.
I have been trying to do a similar approach by generating a client web service in Eclipse using CXF and publishing the web service in Mule. My question is: if I configure for the client and mule application to have the same endpoint (for example: localhost:8082/ipsoap/test), how can I have the web service work the same way as with the tutorial.
Meaning if I test sending a request to mule from the client (in eclipse) I should receive the right response from mule. Thank you in advance for your time.
So in short:
1-I generated a client app in eclipse using the wsdl in the following link in the tutorial: http://ws.cdyne.com/ip2geo/ip2geo.asmx?wsdl
2- As a start in Mule, I added an http connector and a logger and changed the endpoint path in eclipse to the one I set on the HTTP connector on Mule. Thus, I can see that there is a payload when I am sending a request to Mule from the client in Eclipse.
3- I need to have an application, namely my client app in eclipse, consume a published service in Mule. Now I think this is achieved using the CXF component but I still fail to make it work. In fact, I wonder if this is one valid way of using Mule since I couldn't find any tutorial about what I am trying to achieve.
So here is how I test it:
I used the same endpoint I used in Mule and receive the following log:
> INFO 2014-07-07 13:19:46,124
> [[soapservice].connector.http.mule.default.receiver.02]
> org.mule.api.processor.LoggerMessageProcessor: message transformation
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:q0="http://ws.cdyne.com/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Body>
> <q0:ResolveIP>
> <q0:ipAddress>173.194.36.39</q0:ipAddress>
> <q0:licenseKey/>
> </q0:ResolveIP> </soapenv:Body> </soapenv:Envelope>
>
> ERROR 2014-07-07 13:19:46,134
> [[soapservice].connector.http.mule.default.receiver.02]
> org.mule.exception.DefaultMessagingExceptionStrategy:
> ******************************************************************************** Message : wrong number of arguments. Failed to route
> event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor.
> Message payload is of type: String Code :
> MULE_ERROR--2
> -------------------------------------------------------------------------------- Exception stack is:
> 1. wrong number of arguments (java.lang.IllegalArgumentException) sun.reflect.NativeMethodAccessorImpl:-2 (null)
> 2. wrong number of arguments. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of
> type: String (org.mule.api.transport.DispatchException)
> org.mule.module.cxf.CxfOutboundMessageProcessor:150
> (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/DispatchException.html)
> -------------------------------------------------------------------------------- Root Exception stack trace: java.lang.IllegalArgumentException: wrong
> number of arguments at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
As you can see the soap request can be seen but it is not consumed at the level of the CXF component. Here is my mule code:
<flow name="SoapService" doc:name="SoapService">
<http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8082" path="test/cap.asmx" doc:name="HTTP"/>
<byte-array-to-string-transformer doc:name="Byte Array to String"/>
<logger message="message transformation #[message.payload]" level="INFO" doc:name="Logger"/>
<flow-ref name="RequestResponse" doc:name="Flow Reference"/>
<logger level="INFO" doc:name="Logger" message="after posting #[message.payload]"/>
<mulexml:object-to-xml-transformer doc:name="Object to XML"/>
</flow>
<flow name="RequestResponse" doc:name="RequestResponse">
<cxf:jaxws-client operation="ResolveIP" clientClass="pck.IP2Geo" port="IP2GeoSoap" wsdlLocation="file:/C:/Users/12204-hajjam1/workspace/ipgo/src/ipgeo.wsdl" doc:name="soap 2"/>
<logger message="before posting #[message.payload]" level="INFO" doc:name="Logger"/>
<http:outbound-endpoint exchange-pattern="request-response" method="POST" address="http://localhost:10387/ip2geo/ip2geo.asmx" doc:name="HTTP"/>
</flow>
Also if I add a set payload with the ip #[{'173.194.36.39',''}] (the second argument can be left empty) before the cxf component it returns a an empty element. Yet, the response should be something like this:
<pck.IPInformation>
<city>Mountain View</city>
<stateProvince>CA</stateProvince>
<country>United States</country>
<organization/>
<latitude>37.4192</latitude>
<longitude>-122.0574</longitude>
<areaCode>0</areaCode>
<timeZone/>
<hasDaylightSavings>false</hasDaylightSavings>
<certainty>90</certainty>
<regionName/>
<countryCode>US</countryCode>
</pck.IPInformation>
Thus, my problem is with the consumption and retrieval of the response.
I apologize for the length but I have been struggling with this and haven't found a solution online. Thanks in advance.
You should create an instance of the message class that as been generated for the ResolveIP method from the WSDL and use it as the message payload before the cxf:jaxws-client element.

BancBox SOAP API getClient - call fails using WCF client infrastructure

I apologize in advance if this post feels too long. But 1) this is my first post ever and 2) I have really been over the river and through the woods trying to figure this out.
The Add Service Reference feature in Visual Studio 2012 produces a proxy that (apparently) generates invalid SOAP messages. I suspect it has to do with serialization or how the proxy types are decorated but I cannot seem to figure it out. Help is much appreciated.
Detail 1. My environment is Visual Studio 2012 and I have created a .NET 4.5 class library with a service reference to https://sandbox-api.bancbox.com/v1/BBXPort?wsdl. I'm attempting to call the getClient() function; which is defined here. (http://www.bancbox.com/api/view/45)
The code looks like this:
public void GetClient()
{
// create an instance of the service reference proxy class
var bbx=newBBXClient();
bbx.ChannelFactory.Endpoint.Behaviors.Remove<System.ServiceModel.Description.ClientCredentials>();
bbx.ChannelFactory.Endpoint.Behaviors.Add(new CustomCredentials());
bbx.ClientCredentials.UserName.UserName="MY_USERNAME";
bbx.ClientCredentials.UserName.Password="MY_PASSWORD";
var customerId=newid {
subscriberReferenceId="44XX33YY"
};
var request=newgetClientRequest {
subscriberId=MY_SUBSCRIBER_ID,
clientId=customerId
};
var response=bbx.getClient(request);
}
Detail 2. I have made many successful calls into the web service via SoapUI. The successful SoapUI-produced SOAP messages look like this
<soapenv:Envelope xmlns:sch="schema.bancbox.com" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-11">
<wsse:Username>MY_USERNAME</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">tRLo6AlRKl+/rULiKq6A6g==</wsse:Nonce>
<wsu:Created>2013-02-22T18:32:02.204Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<sch:getClient>
<getClientRequest>
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<!--Optional:-->
<subscriberReferenceId>44XX33YY</subscriberReferenceId>
</clientId>
</getClientRequest>
</sch:getClient>
</soapenv:Body>
</soapenv:Envelope>
Detail 3. Per Fiddler, my failed SOAP messages look like this
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPozcAgEH0QhJHloqMBWUf3mAAAAAA5wy3enJkDUGU8IaMUCFyEjzfL+1Uez1HhAvEeFpJ+30ACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-6e1c9f81-0651-41f7-b659-26b191bf7e13-1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:Username>MY_USERNAME</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</o:Password>
<o:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">hGggJkxurSkHQ3MKoeBK6AmEHNs=</o:Nonce>
<u:Created>2013-02-23T11:24:47.663Z</u:Created>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<getClient xmlns="schema.bancbox.com">
<getClientRequest xmlns="">
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<subscriberReferenceId>XX55YY22</subscriberReferenceId>
</clientId>
</getClientRequest>
</getClient>
</s:Body>
</s:Envelope>
The SOAP message above is produced when running the GetClient() method. GetClient throws the following Exception.
System.ServiceModel.FaultException
Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'getClientRequest' to a type definition for element 'getClientRequest'.
When I replay the same failing message using SoapUI, I get the following response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'getClientRequest' to a type definition for element 'getClientRequest'. </faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Detail 4. Based on my research, this indicates that the server on the other end is Apache CXS. It's choking on my SOAP request. So I started playing around with my SOAP message and submitting it via SoapUI.
The first glaring distance in the successful message and my fail message are these lines
SUCCESS
<sch:getClient>
<getClientRequest>
FAIL
<getClient xmlns="schema.bancbox.com">
<getClientRequest xmlns="">
So the first thing that I did was make my getClientRequest tag identical to the successful one.
<getClient xmlns="schema.bancbox.com">
<getClientRequest>
This produced the following response.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Found element {schema.bancbox.com}getClientRequest but could not find matching RPC/Literal part</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
The next thing that I did is change the way the getClient tag is assigned a schema.
BEFORE
<getClient xmlns="schema.bancbox.com">
AFTER
<s:Envelope xmlns:bb="schema.bancbox.com" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
. . .
<bb:getClient>
<getClientRequest>
. . .
</bb:getClient>
The resultant SOAP message looks like this and it is successful.
<s:Envelope xmlns:bb="schema.bancbox.com" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPozcAgEH0QhJHloqMBWUf3mAAAAAA5wy3enJkDUGU8IaMUCFyEjzfL+1Uez1HhAvEeFpJ+30ACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-6e1c9f81-0651-41f7-b659-26b191bf7e13-1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:Username>MY_USERNAME</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</o:Password>
<o:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">hGggJkxurSkHQ3MKoeBK6AmEHNs=</o:Nonce>
<u:Created>2013-02-23T11:24:47.663Z</u:Created>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<bb:getClient>
<getClientRequest>
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<subscriberReferenceId>XX55YY22</subscriberReferenceId>
</clientId>
</getClientRequest>
</bb:getClient>
</s:Body>
</s:Envelope>
So the million dollar questions are WHY and HOW.
*WHY does the .NET proxy class serialize the SOAP message the way it does?
*HOW do I fix it? How can I may my proxy serialize into the SOAP message above? How can I force the serializer to define shorthand for the message namespace in the Envelop and then use the shorthand in the message tag?
FYI, to even get to this point I had to get past a number of WCF WSE issues and ended up implementing the solution so generously provided on Rich Stahls blog. I would post the link but apparently I don't have enough rep.
From I understand, the SOAP message that WCF produces is syntactically correct. However, Java CXF web services are very rigid with regards to the SOAP messages that they will accept.
The solution to specific problem setting aliases for xml namespace definitions in the Operation node of the SOAP messages produced by WCF proxies involves implementing a Custom Message Inspector is detailed here: Force WCF to create an xml namespace alias in client proxy.
This has completely resolved my issue.