Can we handle Error Event by using External tasks?
as third party program used to solve or log errors raised from error event.
You can use the failure rest API call to report a failure to execute an external task back to Camunda.
Documented here Handle External Task Failure
Related
I'm developing an application with authentication, and i need to provide a appropriate status code if there is any error when registering an user, for example a database-related error.
I've been researching but i haven't found an appropriate status code.
The purpose of all HTTP errors is to communicate the operation failed. To pick the right HTTP error, you need to know why it failed.
"database-related error" sounds like a server-side bug or problem, so this is likely just a 500.
I have been using this package (https://github.com/maxbanton/cwh) to setup logging in my laravel 8 app.
I can already send the logs properly and see them in Cloudwatch and what I am trying to do is to log the API calls (request and response). I was able to do this by doing it by adding it in the middleware. My only question is that how can you do this asynchronously? I have found this discussion posted as an issue and this was the suggested solution (https://github.com/maxbanton/cwh/issues/25#) but I couldn't figure out how to implement it.
Has anybody able to send API logs to Cloudwatch asynchronously? Thank you.
What you can try is sent the call to a queued job or listener (beanstalkd preferably as using DB as storage will probably take the same time as sending the log to AWS) that is not running on the sync queue.
This way you can fire the call off to something else, and that can deal with it without you waiting for it.
I have a validate action in the OSB request pipeline which raises an error if the request is not according the schema.
In the error handler, I remove the header info and add some required header info before replying with a failure. However the response I get is the request body and not the fault which is in $fault. Is there a way to have OSB generate a standard soapFault using the $fault variable instead of having to manually create the error response body?
I'm having the same issue with the general error handler defined for the business service and the pipeline error handler when internal errors are raised.
Additionally, Is there a best-practice on how this is usually done for normal services and in case of passthrough services?
thanks
This question is on Mule CXF error handling. I have a soap based web service basically this is a validation service that validates an incoming file and reports on any errors in the file. Once validation is unsuccessful i have a catch-exception-strategy which logs the error and sends a email to Prod support team. After validation is unsuccessful i need not call the subsequent steps in the flow. And only the logging and sending an email alert should happen. Shouldn't using a catch-exception-strategy solve the problem ( similar to a try/catch block in Java). But what i notice is the caller is sent a response back and subsequent flow steps are executed
In your catch exception strategy put an asynchronous flow and in that put your logger and smtp to send the mail ... I guess it will solve your problem ...
Since you will be using asynchronous flow response shouldn't be there ... Pls let me know if it solve your issue
What does this logs meant which is given below when making a call to adapter. This logs we are getting on Xcode console while testing on IOS5,IOS6,IOS7. I noticed that Whenever we make a call to adapter and if it get success this logs never comes in console.
And if we are not getting any failure and success from adapter after making call to adapter, this wl_antiXSRFRealm challenge handler's waiting list logs comes on Xcode console and it stuck over there. Now this time we are not even getting failure and success for adapter call and same logs will remain on Xcode console till we make a another call to adapter.
2014-01-23 16:06:13.953 MyApp[78767:a0b] WLRequestBuilder.initWithRootUrl else_url: https://IPADDRESS:443/MyApp/apps/services/api/MyApp/ipad/0/query
2014-01-23 15:40:45.018 MyApp[78116:a0b] Adding request to wl_antiXSRFRealm challenge handler's waiting list
2014-01-23 15:40:45.018 MyApp[78116:a0b] Adding request to wl_deviceNoProvisioningRealm challenge handler's waiting list
Please let me know , what does that logs means in worklight.
Checked with one of our developers, who said the message is indicating the request requires antiXSRF authentication, but there is already another request that require antiXSRF authentication being processed therefore the second request is added to waiting list.
This should happen only if the developer fires multiple request simultaneosly, however it shouldn't be an issue and SDK should work. According to what you are reporting above, it sounds like the SDK stops firing success/failure events. If so, we can work with you offline on the recreate steps.