I created an API test plan in JMeter.
(Post) Login Authentication API
(Get) API to search for data (Authenticated with the help of correlation)
The Login API works fine I am able to see the response. But, the Search API is returning an error "Service unavailable. Please try again later." with error code 500. My API request has got all the data required Can someone help me to fix the issue.
Thanks,
As per 500 Internal Server Error description:
The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future.
So my expectation is that you should rather check your server logs to figure out the root cause of the problem rather than looking for a solution from JMeter side.
In general if something is wrong with your request the server should respond with 4xx status code
If you have another way of sending the "search" request you can inspect it and cross check all the associated data including:
URL
Headers (can be passed via HTTP Header Manager), pay attention to Content-Type one
Request body
The value you correlated which can be checked using Debug Sampler and View Results Tree listener combination
Related
I am trying to post a simple json to our backend api through REST POST snap. Everything was working. And then we changed the url to a new url and I updated the url in the snap.
But now request is simply not reaching our new api server.
In fact, the snaplogic pipeline also completes successfully, with all snaps turning green. Only when I click on the properties of pipeline, I get to know that REST POST snap has failed, with attached screenshot error.
Please note that we are able to reach the new api server via postman or any other rest client. Nothing has changed at all except for the url.
Can you please help me understand, what exactly is going wrong and where? How to debug this?
Just for everyone's reference, I was able to find out the root cause.
Reason was that the api url was not accessible to snaplogic pod running in our enterprise because of Zscaler firewall.
The confusing part here was the error message returned which says "SSL issue, connection was reset". So if you see issue saying "Connection was reset", assume that snaplogic is unable to access the url as the first problem. Only after making sure, it is not the case, go and look for what exactly the error says.
I would like to build an integration using the Acumatica REST API. However, before logging in or anything. I would like to know if there is a way to test that the server is up and running.
I've tried logging in and I looked at the swagger.json to look at all the endpoints but I think they require to be logged in.
I would expect a 200 response when the server is up and a 500 when the server is not. 5XX if there is server issues and an error if it is completely down.
There is no Test function that I know of. I would recommend doing a HTTP GET request on the endpoint URL. If the request succeeds it will return the WSDL schema with 200 success code.
I am using the embedded chat control to hook up to my Microsoft Bot Framework bot and I keep getting these errors:
(I'm using Node.js on AWS Elastic Beanstalk. None of these errors happen when I run the code locally)
jquery.min.js:11 POST https://webchat.botframework.com/api/conversations/null/messages 403 (Forbidden)
The bot doesn't respond and a few minutes later it shows this:
jquery.min.js:11 GET https://webchat.botframework.com/api/conversations/Bv3bkhOgxas/messages?watermark=131101401454109138 403 (Forbidden)
which is sometimes accompanied by a 500 (Internal Server Error)
I assume the null in the first message is a clue. Does anyone know what is going on or how I can fix it?
Thanks.
Hard to tell what you are doing w/o additional detail. But it's likely your header either doesn't contain an auth token or the incorrect one.
So I have a REST service setup with Jersey.
My POJO is simply annotated as #XmlRootElement
I send a POST request to my REST service and everything works fine.
1- I send malformed XML to the service I get back the containers default 400 Bad Request page. Using Glassfish 3 I can't remember exactly but I know I can change or tell my web app to map to my own 400 bad request right? Where can I look for docs on that specific subject.
2- I send valid XML but in one of the expected fields I put empty value. My service tries to do something and it throws a persistence exception. I get back the containers default 500 Internal Server Error page and it list the exception thrown. I guess I can map to my own custom error page as well, but I do not just want to show the exception message. This is considered a security issue.
I would basically like to validate the fields myself based on my business logic and return back to the client an error message such as "Field1 is invalid" Nothing more nothing less. And the client should be able to parse the error code and also know which field was wrong.
Also what can I do when my service has more then one type of bad request error? For instance, the field can expect an INT value between 1-3, but specific business request expects value of 2 and a 3 is sent.
So for type/value validation I want to simply say "Invalid field name here". But for specific business logic say for instance "Invalid account" or "Account Expired" or "Address Does Not Match" etc...
Or how about when I have more then 1 success code?
Basically I'm taking an old "xml" type service and converting to REST style for proof of concept and bring it up to standards. The old one pretty much is 100% POST even when "querying for results. I.e: GET. So basically you POST to it XML, it reads the XML, calls the business logic and logic returns appropriate code in the XML response. So everything is HTTP 200 OK and the business logic code is returned in an XML response. So the only time a client gets a 500 error is when there is hard failure where the service can't produce an XML response. Even invalid XML is returned as 200 OK, but the XML response back indicates this with my own errors codes.
A while back I was suggested I use SOAP for more "message" oriented services, but I still think it's to heavy and I can achieve with REST what my service does, even though I don't need most of REST?
You can map exceptions to HTTP responses using ExceptionMappers - see:
http://jersey.java.net/nonav/documentation/1.11/jax-rs.html#d4e433
http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/ext/ExceptionMapper.html
If you want to do validation before the request even reaches the resource method, you can try writing a ContainerRequestFilter for that and throw a WebApplicationException which takes Response as a parameter - jersey automatically maps that exception to the response it was initialized with.
I use JavaScript to post an Asynchronous Request to a Web Service. This works about 95% of the time. Sometimes, the request fails to be processed.
Below is the error message in the Trace file of IIS:
2009-02-24 06:14:40 W3SVC861612620
10.248.24.20 POST /TestWebService /TestWebService.asmx - 3112 -
10.250.201.45 Mozilla/4.0+ (compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.2032)
500 0 0 1148 954 124876
This shows that the internal Error 500 has occurred to the request. Is there any way that I can get to know this in the JavaScript where i have posted the request from? Any workarounds are also fine.
Since you don't provide information about your javascript library, this will be hard to troubleshoot. However, if you're running on IIS 7, you can enable Failed Request Tracing.
Troubleshooting the old school way: your web method is generating an error 5% of the time, meaning it works in certain cases but fails in others. This is likely caused by the parameters sent to your web method. Even if you're unable to trap any runtime requests to your webmethod, you can inspect your logic to see what parameter conditions would cause a failure. Better yet, build a battery of unit tests to call your web method, passing every possible combination of parameters that is feasible.