I am implementing a GET request which needs to interact with an ERP and extract employee details .
Now the interaction with ERP is not using HTTP so it does not return status codes such as 400 etc
Any error if present is returned in the XML payload response .
Example:
<?xml version="1.0" encoding="utf8" ?>
<Output>
<Error>
<Status>0</Status>
<Details>No errors</Details>
</Error>
</Output>
So I have implemented it this way - where after calling ERP and receiving response I check if response contains any error ( errorCode = 0 means an error otherwise all good )
If not an error normal processing , if an error I simply set the http status to 400 and populate response with error details.
Question:
In the error flow I am NOT throwing any exception / error and simply returning a response with 400 response status and error details .
My gut feel is in this case there is no need to Raise error ( throw ) and then again catch it in error handler.
I thought it is unnecessary in this case but was looking for some feedback ?
Note - the exception handler below is meant to catch errors such as ERP is down / unavailable etc
Note - as this is more a design / approach question , am only pasting screen print of the flow and not the actual code
Please do share your feedback and suggestions
There is no mandate to use Mule Error handling to return an HTTP status, if that's your question.
Note that Mule 4 uses error handling, not exception handling, though it looks similar.
Unrelated, it is strange that you are using HTTP status 400 for a server error, when 400 is meant for bad client request. You may want to use a more proper status.
Related
The system API throws an error - ERROR:TYPE_1 with status code 401.
The process API should give the same error.
The experience API should give the same error.
How can this be achieved?
In the the process API you can write something like this
<flow name="error_flow">
<raise-error doc:name="raise-error" type="ERROR:TYPE_1" description="401 error ocurred">
<error-handler>
<on-error-continue enableNotification="true" type="ERROR:TYPE_1" doc:name ="on error continue" doc:id="on-error-continue">
// here you can write a dwl which gives you a payload like
// {
"errorCode" : 401
"errorType" : "ERROR:TYPE_1"
}
<on-error-continue>
</error-handler>
This payload will reach to your experience layer.
i would like to route my http:request to my main ( or secondary ) error handler in Anypoint Studio 7
i does not seem to have a clear way of doing it.
And the documentation does not have guideline for this specific case.
in my case is necessary, i need to know and send a signal to another service and communicate the error response, like: connection_timeout
You can catch the errors you want using an error-handler in your flow where you are executing the http:request. if you do not catch the error, it will bubble up to the calling flow and so on. If no error-handler is configured, the default mule one will be used which just logs the message basically.
In Mule 4 you can catch all errors in your flow like so:
<flow name="retrieveMatchingOrders">
<http:request config-ref="customersConfig" path="/customer">
</http:request>
<error-handler>
<on-error-continue>
<!-- error handling logic -->
</on-error-continue>
</error-handler>
</flow>
An on-error-continue will execute and use the result of the execution, as the result of its owner (as if the owner had actually completed the execution successfully). Any transactions at this point would be committed as well
So in there, you can set the payload to your desired message to be returned etc.
There also an on-error-propogate handler and a try scope, more information on those are available here: https://docs.mulesoft.com/mule-runtime/4.1/intro-error-handlers
All errors thrown in Mule contain meta-data including a TYPE. If you need to catch specific HTTP Errors you can configure your error-handler like so:
<error-handler>
<on-error-continue type="HTTP:TIMEOUT">
<!-- error handling logic -->
</on-error-continue>
</error-handler>
Here is a list of all specific HTTP: errors thrown by the HTTP module:
HTTP:UNSUPPORTED_MEDIA_TYPE
HTTP:CONNECTIVITY
HTTP:INTERNAL_SERVER_ERROR
HTTP:METHOD_NOT_ALLOWED
HTTP:NOT_ACCEPTABLE
HTTP:TOO_MANY_REQUESTS
HTTP:SERVICE_UNAVAILABLE
HTTP:CLIENT_SECURITY
HTTP:FORBIDDEN
HTTP:UNAUTHORIZED
HTTP:RETRY_EXHAUSTED
HTTP:NOT_FOUND
HTTP:BAD_REQUEST
HTTP:PARSING
HTTP:TIMEOUT
HTTP:SECURITY
Each module's documentation should contain all specific error types thrown by that module. Here is the HTTP one example:
https://docs.mulesoft.com/connectors/http/http-documentation#throws
And here is a full list of core error types you can catch like EXPRESSION for example:
https://docs.mulesoft.com/mule-runtime/4.1/mule-error-concept
Recently I was developing a project that relied on the softlayer interface. I want get the invoice details about the bare metal server. But I keep getting a 500 error when I call the SoftLayer_Billing_Invoice::getItems interface. And other interfaces are normal.
regards~
code show as below:
client = SoftLayer.create_client_from_env(username="username",
api_key="api_key",
proxy="proxy")
sl_billing_invoice = client['Billing_Invoice']
try:
result = sl_billing_invoice.getItems(id=id)
print result
except SoftLayer.SoftLayerAPIError as sl_exc:
msg = 'result:(%s, %s)' % (sl_exc.faultCode, sl_exc.faultString)
print msg
Return error message as blow:
result:(500, 500 Server Error: Internal Server Error)
The issue is likely that your request is returning a big amount of data, this case commonly happens with invoices and billing items. In order to solve that issue you have the followings options:
Reduce the amount of data through object-masks or using object-filters.
Use pagination (result limits) in order to fetch less data in the request.
result = sl_billing_invoice.getItems(limit=50, offset=0, id=id)
Softlayer doc and similar questions:
https://softlayer.github.io/blog/phil/how-solve-error-fetching-http-headers/
https://softlayer-python.readthedocs.io/en/latest/api/client.html?highlight=limit#making-api-calls
Softlayer getAllBillingItems stopped working?
Getting 500 Internal Server Error from Account.getVirtualGuests()
getInvoices method failing
Getting "error": "Internal Error" on Postman and getting error Can not deserialize instance of java.util.ArrayList out of START_OBJECT token
I am trying to build a simple asynchronous web service with Apache and mod_perl. But every time I try to return HTTP status 202 (Accepted), I get an error.
Below a very simple example (non-asynchronous):
package MyHandler;
use Apache2::Const '-compile' => qw 'OK HTTP_ACCEPTED HTTP_OK';
use Apache2::RequestRec;
use CGI;
sub handler {
my $r = shift;
print "Hallo";
$r->content_type('text/plain');
$r->status(Apache2::Const::HTTP_ACCEPTED);
return Apache2::Const::HTTP_ACCEPTED;
}
1;
I get the error
calling the handler in my browser on localhost, I get the output but also an error:
Hallo
Accepted
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
I also get an error with Apache2::Const::HTTP_OK, the only one that works without error is Apache2::Const::OK.
My apache error log makes no mention of this error.
With mod_perl2 you do not return HTTP status codes (this is why it is necessary to use $r->status() so set the HTTP status code.
Instead, you return a value depending on what you want the server to do. The most common would be Apache2::Const::OK. This tells the server your handler has finished successfully. This constant, if I recall correctly, has an integer value of 0, not 200.
Returning an HTTP status code from a mod_perl handler will be interpreted as an error.
https://perl.apache.org/docs/2.0/user/handlers/intro.html#Handler_Return_Values
Different handler groups are supposed to return different values.
Make sure that you always explicitly return a wanted value and don't rely on the result of last expression to be used as the return value -- things will change in the future and you won't know why things aren't working anymore.
The only value that can be returned by all handlers is Apache2::Const::OK, which tells Apache that the handler has successfully finished its execution.
Apache2::Const::DECLINED is another return value that indicates success, but it's only relevant for phases of type RUN_FIRST.
HTTP handlers may also return Apache2::Const::DONE which tells Apache to stop the normal HTTP request cycle and fast forward to the PerlLogHandler, followed by PerlCleanupHandler. HTTP handlers may return any HTTP status, which similarly to Apache2::Const::DONE will cause an abort of the request cycle, by also will be interpreted as an error. Therefore you don't want to return Apache2::Const::HTTP_OK from your HTTP response handler, but Apache2::Const::OK and Apache will send the 200 OK status by itself.
Try NOT printing anything BEFORE you set your content-type header.
I try to get information from Yodlee API.
I have a test user where I've implemented adding an account and I got refresh OK from the site:
{ siteRefreshStatus: {
siteRefreshStatusId: 8
siteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"
}
- siteRefreshMode: {
refreshModeId: 2
refreshMode: "NORMAL"
}
- updateInitTime: 0
nextUpdate: 1391603301
code: 403
noOfRetry: 0
}
}
Now when I try to perform search and get the actual transactions I get this error:
{
errorOccured: "true"
exceptionType: "com.yodlee.core.IllegalArgumentValueException"
refrenceCode: "_57c250a9-71e8-4d4b-830d-0f51a4811516"
message: "Invalid argument value: Container type cannot be null"
}
The problem is that I have container type!
Check out the parameters I send:
cobSessionToken=08062013_2%3Ad02590d4474591e507129bf6baaa58e81cd9eaacb5753e9441cd0b1ca3b8bd00a3e6b6a943956e947458307c1bb94b505e2eb4398f890040a3db8c98606c0392&userSessionToken=08062013_0%3A8e8ef9dd4f294e0f16dedf98c1794b96bf33f2e1f2686eda2f35dfe4901dd3a871eed6d08ce52c99a74deb004c025ebf4bf94c7b17baf8ba18aacb331588f5f5&transactionSearchRequest.containerType=bank&transactionSearchRequest.higherFetchLimit=1000&transactionSearchRequest.lowerFetchLimit=1&transactionSearchRequest.resultRange.endNumber=500&transactionSearchRequest.resultRange.startNumber=1&transactionSearchRequest.searchClients.clientId=1&transactionSearchRequest.searchClients.clientName=DataSearchService&transactionSearchRequest.ignoreUserInput=true&transactionSearchRequest.searchFilter.currencyCode=USD&transactionSearchRequest.searchFilter.postDateRange.fromDate=01-01-2014&transactionSearchRequest.searchFilter.postDateRange.toDate=01-31-2014&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425&transactionSearchRequest.searchClients=DEFAULT_SERVICE_CLIENT
There is an error occurred while adding the account, which can be interpreted by this parameter code: 403 and hence you will not be seeing that account when you call the getItemSummary API. An account is successfully linked if the code has zero as value. E.g.code:0 . 403 is an error which is show if Yodlee's data agent has encountered an unhandled use case. Hence for any such error you should file a service request using Yodlee customer care tool.
To know more about error codes please visit -
https://developer.yodlee.com/FAQs/Error_Codes
The status is show as completedsiteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"because addition of any account is followed by a refresh in which Yodlee's data agent logs into the websites of FIs and try scraping data. Hence completion of this activity is denoted as REFRESH_COMPLETED even when there is an error occurred.
TranasctionSearch issue -
I can see two of the parameters with a "+" sign. Since transactionSlipttype and containerType are dependent on each other the error is thrown.
&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425
The right parameters are -
&transactionSearchRequest.searchFilter.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId.identifier=10008425