Mule API timing out for one path but works for fine for other path - mule

I have a Mule API which calls another system. The call to the another system are included in a common flow and parameters are set dynamically.
The high level API paths are:
GET /invoices
POST /workorder
Despite having a common configuration, the calls made to /workorder path are successful, but calls to "invoices" get request timed out error. I tried both requests in Postman too and it is the same behaviour.
Any idea how can this issue be resolved?

Like #aled mentioned the question is too broad,
What I understand there's a mule api (lets call it a proc) which calls another system api (sys).
Cause for this is that the target is taking more time than the source is willing to wait for the response.
The first things to do would be to increase the response timeout at proc requestor configuration, the default response timeout is 10s (10000 milliseconds), increase this value till it no more gives this error at proc.
If the error is returned from sys api when calling from postman, do the same for sys api for its request configuration.
Reference - Request Configuration
Hope this helps.

Related

application logs show 500 error from call Mulesoft web service

we have a application that makes a web service call to Mule ESB and the log shows mostly 500 error code during peak hours and 200 success code during off peak hours. I am not part of the Mule team, but when I talked with them they indicate that this may not be a problem on their side, they are saying nothing is received on their ends.
Now my question is if our application logs show 500 error code, won't that indicate the request has made it to the Mule ESB but was not able to process it or still possible to get 500 error code if the request is lost somewhere due to networking / router issues or similar to that?
The question is totally generic and doesn't provide any insight on the implementation. Then his answer applies to any HTTP response from any implementation and technology, be it Mule, Java Python, etc.
The answer depends on if the server is using the 500 response correctly. If they just answer 500 because it doesn't handle errors correctly then there is nothing you can imply from that.
If 500 is used correctly it is an internal error. If the issue is that they don't receive a proper response from another backend it be argued if there is not a better response code for that like 502 or 504. In any case is that team that manages the app who should troubleshoot the error.
What you can buy sure is that the request reached the application because it responded with an HTTP response.

Possible proxy issue with WSO2 API Manager

Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.

JMeter's ResourceLastAccessedTime GET request failed

I am trying to use JMeter to test our Web Application. We originally used LoadComplete to test our Web Application, but because LoadComplete is not able to run on a non-GUI mode, we were not able to use the max stat’s from our test server (strain our 8 CPU’s and 8GB’s of RAM). That is why I moving towards JMeter (https://blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui).
The test includes logging in, choosing a specific app, do a simple task through this app and then end the recording. The HTTP Requests, which are failing are printing Failed Access on their Response Data on the View Results Tree.
I used the HTTP(S) Test Script Recorder to record each HTTP request. My JMeter project is failing on a few different HTTP Requests, which includes oauthtoken Get Request that includes jessionid="item", a GET resourceLastAccessedTime Request, and a couple GET resourceLastAccessedTime Requests. I tried to follow blazementer's guidance for how to use JMeter for Login Authentication, because these requests seem to be involved with the authentication of each user after logging in and the problem I am getting on Response data for each of these requests on the View Results Tree it says Access denied. (https://docs.blazemeter.com/customer/portal/articles/1743663-how-to-use-jmeter-for-login-authentication-).
One of the steps is to "copy and paste" the Parameters from the Post request after you login to these requests. I can add these parameters to these requests right below where it says Send Parameters with the request, but our POST request only has two parameters (the login name and the password). Is there somewhere else to look for these parameters?
I tried a combination of a lot of different attempts, but I am still unsuccessful (meaning: I moved the Regular Expression Extractor to a few different HTTP requests and I moved which HTTP requests to put those parameters and I have not been successful yet).
Do you know of a URL that could be helpful for this?
Don't trust Test Script Recorder! It doesn't follow any logic while recording your requests. It just records requests processed through proxy as they are. In case you use parameters that can't be defined as constants, the best way would be to rewrite the script manually.
Be patient and spend some hours (only once!) to learn how to construct any test scenarios (even complex) manually using Jmeter GUI. It will save you a lot of time for debugging.
It seems like (just a guess) that your test scenario doesn't contain Cookie Manager item. Based on what you wrote above, it seems like after logging to serer (by sending POST with login and password) it sets some cookies by Set-Cookie HTTP header. These cookies should be included in every next request as a prove that you successfully logged in before (the most common logic for simple web applications). So, if you get Access Denied, means you didn't include appropriate cookies in test request. Use Cookie Manager for that.
Feel free to ping me in case you need any assistance.
Jmeter help manual is all you need to know about how each element works.
P.S.: Jmeter also can generate distributed load from multiple slave servers, in GUI and CLI modes both. So, in case you need to stress your server yout, Jmeter is the best choise.
And welcome to Jmeter users family! Good luck.

How to show the internal server errors to the user?

I am working in an API . I want to throw detailed error messages to the user. Now i am in a situation to decide what kind of error code should be sent or how to explain user if any error occurs in the application internally. For example if database connection fails , what kind of http status code i want to send to the user ?
Can anyone help ?
An HTTP status code generally refers to the status of the HTTP request itself, not the status of the application handling the request. Therefore, most server-side errors are covered by 500 Internal Server Error. Any additional info about the error should be described in the response body. For APIs, the response body will often be JSON or XML, so you can use those formats for your errors. Something like this:
HTTP/1.1 500 Internal Server Error
[headers]
{"status":"error", "message":"The request failed due to database connectivity."}
There are, however, two cases I can think of when you might want another status code. If the user has requested an API method that is not implemented, you might want a 501 Not Implemented, and when there is a temporary service outage, you can use 503 Service Unavailable.
More info about server-side status codes here.

Strategies to block an external webservice to simulate "down" during for a testing scenario?

I am working to integrate data from an external web service in the client side of my appliction. Someone asked me to test the condition when the service is unavailable or down. Anyone have any tips on how to block this site temporarily while we run the test to see how the service degrades?
For those curious we are testing against Virtual Earth, but Google Maps but this would apply to any equally complicated external service.
any thoughts and suggestions are welcome
Create some Mock-Webservice class or interface (and inject it). In there, you could test the response of your system to webservice failures and also what happens, if a web-service request take longer than expected or actually time-out.
DeveloperWorks article on mock testing: http://www.ibm.com/developerworks/library/j-mocktest.html
You need to be sure to test the most common failure modes for this:
DNS lookup fails
IP connection fails (once DNS lookup succeeds)
HTTP response other than 200
HTTP response incomplete or timeout
HTTP response 200 but RPC or document returned is invalid
Those are just a few common failure modes I could think of that will all manifest themselves with different behaviors that you may wish to have your application handle explicitly.
If you set up a computer between the caller and service that routes between them, you can simulate each of these failure modes distinctly and modify your application to handle them.
How about blocking the domain name(s) in question by putting a nonsense entry into the hosts file?