thanks for the quick reply! See my comments below.
#4 & #5: Will look into that, thanks for the tip.
#3: I mean Data Monitoring here. ESB Data alarm to be specific. When an error occurs in the processing, we generate a default ESB Exception fault and publish this to the Message Box. Then the fault gets registered in the EsbExceptionDb via the standard functionality. This way we don’t have any suspended instances, and we can resubmit the message from BizTalk360 If needed. Some of the errors are functional, and we want to inform the user (email group) directly, so he or she knows what he or she is confirming in system A does not get delivered in system B. How would you solve this problem then?
#1: See my comment on #3. It will be a low volume of messages which are triggered by the user. And so it will not clutter the users email, but will add efficiency to the daily tasks.
#2: And what about ESB Data monitoring? I have all the content and context for all the possible faults there.
Hi Saravana,
thanks for the quick reply! See my comments below.
#4 & #5: Will look into that, thanks for the tip.
#3: I mean Data Monitoring here. ESB Data alarm to be specific. When an error occurs in the processing, we generate a default ESB Exception fault and publish this to the Message Box. Then the fault gets registered in the EsbExceptionDb via the standard functionality. This way we don’t have any suspended instances, and we can resubmit the message from BizTalk360 If needed. Some of the errors are functional, and we want to inform the user (email group) directly, so he or she knows what he or she is confirming in system A does not get delivered in system B. How would you solve this problem then?
#1: See my comment on #3. It will be a low volume of messages which are triggered by the user. And so it will not clutter the users email, but will add efficiency to the daily tasks.
#2: And what about ESB Data monitoring? I have all the content and context for all the possible faults there.