Video Summary: This video demonstrates error propagation techniques between API layers, specifically focusing on handling errors in the system layer and propagating them to the experience layer. It also covers converting error messages into user-friendly responses in the experience layer. - 00:00 This section discusses how to handle errors between API layers, specifically focusing on propagating errors from the system layer to the experience layer. - 03:55 This section demonstrates the successful invocation of both the experienced APA and the system APA, which are two different APIs deployed in different environments. - 07:50 The speaker explains the importance of having consistent error handling and introduces a canonical standard for schema transformation. - 11:45 This section discusses how to investigate and understand error structures in detail. - 15:40 The video discusses error propagation techniques between API layers. - 19:27 In order to propagate HTTP error codes in a meaningful way, you can set the status code in the HTTP listener response. - 23:22 The video discusses error propagation techniques between API layers. - 27:14 The video discusses error propagation techniques between API layers, including how to handle errors in the system layer, propagate them back to the experience API, and convert them into user-friendly messages. Generated by Monica AI. Get yours now! 👉 monica.im?r=495123
So error continue should be used if I want to pass the exact error back to Experience API. If I use error propogate I will not get exact message from system API back to exp api
Thanks a lot .. its really helped me in defining the error handling in my first project where i am writing a processing System/Processing API and i have AWS Redshift , Sharepoint , Couple of lookup files in Excel format . I thought that i need to write error handling for each of these connectors separately but this one error handler will take control of showing the error when ever it is occurred. Can you suggest me the best practice to error handling in this scenario
Hi - Of course, yes. The error handling is exhaustive and you need to map every single type of error that you want to handle. Its a big and overwhelming task and thats why you need a framework for the whole enterprise, to streamline things. Its useful once implemented and you can use it for the rest of the lifetime. Cheers !!
hi. How should we handle the error if we face db connectivity error in ETL operation. e.g. If we are reading a file and inserting the content in DB after in middle of the job we get the error. how should we handle it and report the error. Consider the application is deployed in production. What should be the ideal way ?
Hi Rahul - In general, the ETL is avoided in MuleSoft API with the preferred tool like Informatica. However, having no other option, you can please go with 'Batch processing' where you can do controlled way of insertion and you have the ability to separate out the failed records. I have published the specific video on Batch processing 'handling failed records'. Please refer that and let me know your feedback.
@@sivathankamanee-channel Ok. I have seen it. But what if we can only use the ftp and DB connector. Since batch is used when we have millions of records to process.
Ideally the response from system api which has the error type and msg should be retrieved in the proc api via sys api response payload and should be used in constructing the error response of EXP API
Siva, i am learning Mule soft to explore my ability in technology and i am very new to this. I am having one question: you defined same variable name in both layers and used it both layers . if system layer sets 500 and exp layer sets 400 then user can see only 400 right as it is overriding 500. is that right understanding? comming to feed back it is really good and better if you reduce little speed .Overall very good demo.
Video Summary:
This video demonstrates error propagation techniques between API layers, specifically focusing on handling errors in the system layer and propagating them to the experience layer. It also covers converting error messages into user-friendly responses in the experience layer.
- 00:00 This section discusses how to handle errors between API layers, specifically focusing on propagating errors from the system layer to the experience layer.
- 03:55 This section demonstrates the successful invocation of both the experienced APA and the system APA, which are two different APIs deployed in different environments.
- 07:50 The speaker explains the importance of having consistent error handling and introduces a canonical standard for schema transformation.
- 11:45 This section discusses how to investigate and understand error structures in detail.
- 15:40 The video discusses error propagation techniques between API layers.
- 19:27 In order to propagate HTTP error codes in a meaningful way, you can set the status code in the HTTP listener response.
- 23:22 The video discusses error propagation techniques between API layers.
- 27:14 The video discusses error propagation techniques between API layers, including how to handle errors in the system layer, propagate them back to the experience API, and convert them into user-friendly messages.
Generated by Monica AI. Get yours now! 👉 monica.im?r=495123
Hi siva...let you possible to explain deep dive to Runtime manager in anypoint platform.Tq
@siva thankamanee Is it possible to get the error message in system API to be printed in Experience API?
This was very useful video 😊
So error continue should be used if I want to pass the exact error back to Experience API. If I use error propogate I will not get exact message from system API back to exp api
Thank you for your explanation and Can you please explain about Raise Error please
Thanks a lot .. its really helped me in defining the error handling in my first project where i am writing a processing System/Processing API and i have AWS Redshift , Sharepoint , Couple of lookup files in Excel format . I thought that i need to write error handling for each of these connectors separately but this one error handler will take control of showing the error when ever it is occurred. Can you suggest me the best practice to error handling in this scenario
Hello...but what if another error comes from flow and you only have db connectivity....do you need to map every error
Hi - Of course, yes. The error handling is exhaustive and you need to map every single type of error that you want to handle. Its a big and overwhelming task and thats why you need a framework for the whole enterprise, to streamline things. Its useful once implemented and you can use it for the rest of the lifetime. Cheers !!
Sir , why no videos during this pandemic?
hi. How should we handle the error if we face db connectivity error in ETL operation. e.g. If we are reading a file and inserting the content in DB after in middle of the job we get the error. how should we handle it and report the error. Consider the application is deployed in production. What should be the ideal way ?
Hi Rahul - In general, the ETL is avoided in MuleSoft API with the preferred tool like Informatica. However, having no other option, you can please go with 'Batch processing' where you can do controlled way of insertion and you have the ability to separate out the failed records. I have published the specific video on Batch processing 'handling failed records'. Please refer that and let me know your feedback.
@@sivathankamanee-channel
Ok. I have seen it. But what if we can only use the ftp and DB connector. Since batch is used when we have millions of records to process.
Ideally the response from system api which has the error type and msg should be retrieved in the proc api via sys api response payload and should be used in constructing the error response of EXP API
Siva, i am learning Mule soft to explore my ability in technology and i am very new to this. I am having one question: you defined same variable name in both layers and used it both layers . if system layer sets 500 and exp layer sets 400 then user can see only 400 right as it is overriding 500. is that right understanding? comming to feed back it is really good and better if you reduce little speed .Overall very good demo.