Getting Soap Fault on hitting a WebService using JMETER - web-services

I'm trying to contact a webservice via Jmeter (3.0), and I get the following error:
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Body>
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
<s:Subcode>
<s:Value xmlns:a="http://schemas.microsoft.com/ws/2005/05/addressing/none">a:ActionNotSupported</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="es-AR">The message with Action '' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
</s:Envelope>
I haven't encountered any issues contacting the web service from SoapUI, so I'm wondering what could cause this problem.
You can see the screen shots here:
The HTTP Request within the tree, first part of the HTTP Request data, the HTTP Header Manager settings: https://i.stack.imgur.com/6HxIK.jpg
Here are the results on SoapUI (works just fine):
Results and log
Is it possible that the way that SoapUI sends the requests differs from the way Jmeter does and that's why it works?
Please help. Thanks!

You need to put this action bit to be a part of the Content-Type header like:
I would also recommend adding HTTP Cookie Manager to your Test Plan
Out of interest, why don't you just record the request originated from SoapUI using JMeter HTTP(S) Test Script Recorder like:
Configure JMeter for recording. The easiest way of doing this is using JMeter Templates feature
From JMeter main menu: File - Templates - Recording - Create
Workbench - HTTP(S) Test Script Recorder - Start
Configure SoapUI for recording
From SoapUI main menu: Preferences - Proxy Settings
Proxy Settting: manual, host: IP address or hostname of machine where JMeter is running, port: 8888
Execute request in SoapUI
Inspect the recorded request in JMeter under Workbench -> Recording Controller.

I think you have some trivial error in the value of http header SOAPAction.
Happened to notice(in the image you attached) that there are double quotes in its value.
Just remove the double quotes " from the SOAPAction value.
UPDATE:
It is noticed, while editing the question, that soapui has sent an additional http header action with a value (you masked the value).
So, please add action header in the jmeter request as well the right value in the jmeter plan.

Related

Unable to send JMeter token value as cookie

0
I have issues running scripts that work fine on my laptop but not on Server VMs (Both Windows and Linux).
Some of the modules on the application I test communicates with the client through Cookies. bearer authentication token is expected to be sent with the request header as cookie when accessing these functionalities. These are mostly javascript events on the browser.
JMeter 5.3 on my laptop is successfully sending these cookie values with / in server name field to the application server and also get the successful HTML response. But on the Linux/Windows server, it gives illegal character error (rightly so).
I then decided to develop the scripts directly on Windows Server. When I remove and added / in the path instead of the host name, the cookie value (token) was not sent and the application server throws authentication error. If I add 2 forward slashes, it works for some endpoints it works with 3 forward slashes. ///. Some endpoints works with // and if you choose "Redirect Automatically" only. If you choose "Follow Redirects", the application again throws authentication error. The developers are blaming JMeter for incorrect request but are not giving me more information.
Also tried setting the CookieManager.save.cookies=true in jmeter.properties
Can someone please help with this weird JMeter behavior?
Thanks,
Partha
If you're talking about "Domain" field of the HTTP Cookie Manager:
then you can tell your developers that they should stop blaming JMeter for sending incorrect requests but they should rather read RFC 6265 followed by RFC 1034, once done they should quit their developer jobs and become rickshaws.
If you want to know more how does JMeter handle cookies the best way is enabling debug logging for the HTTP Cookie Manager by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.control" level="debug" />
and next time you start JMeter you will see way more information regarding cookies extraction and manipulation in the jmeter.log file.

How to validate input and output messages in proxy service against wsdl

Is there any way to validate input and output messages in proxy service against specific wsdl?
Have a situation, when proxy generates invalid output message, so i want to catch this inside my proxy just before responding to client.
Also i want to check if input message is valid.
You can use a tool like SoapUI to validate scenario like this. You can generate a test using particular wsdl. And you can use tool like tcpmon to validate the message going between proxy and the particular endpoint.
As a example use one tcpmon listening to out port to the proxy and redirect it to the actual port.
You can find soapui from [1] and if your using wso2 ESB the tcpmon is available at /bin directory and you can start it using
sh wso2esb-4.5.0/bin/tcpmon.sh
By looking at the message passing through tcpmon you can validate the message going out from your proxy.
[1]. http://sourceforge.net/projects/loadui/files/latest/download?source=files
You can validate the payload of the wso2 esb proxy using the Validate mediator.
Example,
<validate source="//xpath_of_element_to_validate">
<schema key="local_entry_name_of_your_schema_file"/>
<on-fail>
*This part contains the code to handle validation failure*
</on-fail>
</validate>
This Validate mediator can be used anywhere in the proxy. To validate the request, use it as the first line and to validate the response, use it before the respond mediator
You can refer the below link for more details,
https://docs.wso2.com/display/ESB490/Validate+Mediator
Hope this helps!!
Thanks!!

Apache CXF (2.6.1): Client gets "Content is not allowed in prolog"

I'm using Apache CXF (2.6.1) in my java application to consume 3rd party Web Service. But I have a problem with it, in particular if I use JAXB for databinding while stubs generation my client will always send requests with "header" like "--uuid:e47f145b-38f7-4402-8eec-657d71bc8ad4..." (see client request below), i.e. besides XML part there is some special info...
It looks like this special info causes error reply from server "Content is not allowed in prolog" (see server response below), i.e. server is not expecting such body. What is interesting here is that if I generate stubs using XMLBEANS for databinding everything starts to work just fine (and there is no such "special" info in request body, only XML). After some googling I suspect that my client for some reason tries to use MTOM (with JAXB) and I don't know how to turn it off. I've already tried the following to turn MTOM off (with no luck):
((BindingProvider)port).getRequestContext().put("mtom-enabled", Boolean.FALSE);
((BindingProvider)port).getRequestContext().put("write.attachments", Boolean.FALSE);
((BindingProvider)port).setMTOMEnabled(false);
Please help I would really want to move to JAXB since it's much more compact in comparison with XMLBEANS...
Client code:
AdminServiceV2 ws = new AdminServiceV2();
AdminV2 port = ws.getAdminPortV2();
Client client = ClientProxy.getClient(port);
HTTPConduit http = (HTTPConduit) client.getConduit();
AuthorizationPolicy authorizationPolicy = new AuthorizationPolicy();
authorizationPolicy.setUserName("user1");
authorizationPolicy.setPassword("password1");
authorizationPolicy.setAuthorizationType("Basic");
http.setAuthorization(authorizationPolicy);
try {
port.getUsersInfo("user1");
} catch (Exception e) {
e.printStackTrace();
}
Client request:
--uuid:e47f145b-38f7-4402-8eec-657d71bc8ad4
Content-Type: text/xml; charset=UTF-8; type="text/xml";
Content-Transfer-Encoding: binary
Content-ID: <root.message#cxf.apache.org>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:getUsersInfo xmlns:ns2="http://service.admin.ws.five9.com/v2/"><userNamePattern>user1</userNamePattern></ns2:getUsersInfo></soap:Body></soap:Envelope>
--uuid:e47f145b-38f7-4402-8eec-657d71bc8ad4--
Server response:
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><env:Fault xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><faultcode>env:Client</faultcode><faultstring>org.xml.sax.SAXParseException: Content is not allowed in prolog.</faultstring></env:Fault></env:Body></env:Envelope>
Thanks,
Konstantin
No CXF request ever starts normally with --uuid. That is part-way through a multi-part HTTP message. With or without MTOM, a normal SOAP message consists of an HTTP header followed by the XML content. If it's MTOM, the HTTP header declared multipart, and then there are multipart separators and sub-headers.
If you are using a custom front-end to ask for 'plain XML' messages without the usual required HTTP headers, then that, combined with MTOM, might have the undesirable effect at hand.
JAXB will generally only enable MTOM if you have #XmlMimeType("application/octet-stream") annotations(s). You should also look at the WSDL/XSD for the service and see if it has xmime annotations in there.
See the CXF MTOM doc for more details.
You haven't specified the CXF version or how you configured your CXF client endpoint. You might get better assistance by sending all that data to the CXF user mailing list.
The question was answered on CXF user mailing list by Daniel Kulp, for details see
http://cxf.547215.n5.nabble.com/Apache-CXF-2-6-1-Client-gets-Content-is-not-allowed-in-prolog-td5713009.html#a5713055. In short the problem was with WSDL (it contains swaRefs) that forces CXF to send messages like with attachments. Workaround was also provided...

WSO2 ESB providing HTTP 202 response on Proxy Service

I am trying to setup very simple WSO2 ESB Proxy service. While using it, I am getting HTTP 202 response back and WSO2 ESB is not doing anything with the request beside logging it. Here is the background of my setup
My service implementation is using SOAP 1.2 over Http 1.1. When my client opens the connection to the server, it fires first request and asks for keep-alive connection. The ESB passes the request to the actual implementation and sends response back with transfer-encoding as chunked. So far it works as desired.
After the initial request response exchange, my client submits several requests in parallel and I get HTTP 202 responses for all of them. Looking at logs, it seems ESB is not sending the request to the actual implementation ever.
Is there something that I am doing wrong? How do I fix it?
What happens in this scenario is that your subsequent requests are hitting the main sequence of the WSO2 ESB. That is why you can only see a log for those requests. As you have already narrowed down this happens due to the jsessionId attached to the URL. To overcome this issue you can create a REST API with URL pattern to match the correct URL path. Please refer the following documentation.
https://docs.wso2.com/display/ESB481/Creating+APIs

SOAP request logging Tomcat 7 Axis2

We are trying to log all http requests made to our Tomcat server, in particular SOAP requests.
Our server setup is as follows:
Tomcat 7.0.11
Axis 2
Gentoo Linux
So far we have used the RequestDumperFilter class however this only shows us the header information.
What we require is the ability to view the request body containing the SOAP request XML.
I guess you could make use of some request processing components but I'm not sure if there is an easy way to view the request body in Tomcat.
From what I know, the ExtendedAccessLogValve provides the most information about the request but even this is missing the body.
The most simple solution would be to move the logging away from Tomcat and use a proxy server. You place the proxy between the server and it's clients and do the logging in the proxy.
Proxy receives request, logs it, then forwards to Tomcat which generates response, sends it to the proxy which logs it and then sends it to client. The simplest proxy I used (and did its job pretty well) was the Apache TCP Monitor.
Additionally you could look at something like Fiddler and see if that helps.