← Prev in month ← Prev in thread

PMode descriptions in ErrorHanding group seem to have unnecessary level

From
Dale Moberg <>
Date
2006-10-10T21:12:08+00:00
ID
Thread
PMode descriptions in ErrorHanding group seem to have unnecessary level
Notice that each one of the ErrorHandling descriptions has “Report”
in its path. Are there going to be other subgroups besides “Report”?

If not, we can just collapse the paths by deleting the “Report”
part of the path.

 

·        
PMode[1].ErrorHandling.Report.SenderErrorsTo:
this parameter indicates the address where to send ebMS errors generated by the
MSH that was trying to send the message in error. 

·        
PMode[1].ErrorHandling.Report.ReceiverErrorsTo:
this parameter indicates the address where to send ebMS errors generated by the
MSH that receives the message in error. E.g. this may be the address of the MSH
sending the message in error.

·        
PMode[1].ErrorHandling.Report.AsResponse:
this Boolean parameter indicates whether (case “true”) errors
generated from receiving a message in error are sent over the back-channel of the
underlying protocol, associated with the message in error or not.

·        
PMode[1].ErrorHandling.Report.NotifyConsumerLocalErrors:
this boolean parameter indicates whether (case “true”) the Consumer
(application/party) of a User Message should be notified when an error occurs
in the Receiving MSH, about the received User message.

·        
PMode[1].ErrorHandling.Report.NotifyProducerLocalErrors:
this boolean parameter indicates whether (case “true”) the Producer
(application/party) of a User Message should be notified when an error occurs
in the Sending MSH, about the User message to be sent.

·        
PMode[1].ErrorHandling.Report.NotifyProducerDeliveryFailures:
this boolean parameter indicates whether (case “true”) the Producer
(application/party) of a User Message must always be notified when the delivery
to Consumer failed or whether in some cases it is sufficient to notify the
Consumer only (Report.NotifyConsumerLocalErrors=”true”).
This assumes that Reliability.AtLeastOnce.Contract is “true”. This
also assumes that the Sending MSH implementation has the ability to determine
or to be made aware of all cases of non-delivery that occur after the message
has been received by Receiving MSH.
← Prev in month ← Prev in thread