[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Reporting EBMS:0301 and EBMS:0302 to Receiver
Hi,The following came up in discussion with a developer of a new implementation of AS4:
Assume: - MSH A sends an AS4 message to MSH B.- MSH B successfully decrypts the message, validates the signature, delivers the payloads, and returns a receipt to A. - MSH A validates the receipt and finds it invalid (e.g. the signature is invalid or there is some other error). This results in an EBMS:0302 InvalidReceipt error of severity failure.
MSH A may report the error to the producer if PMode.ErrorHandling.Report.ProcessErrorNotifyProducer is set to true.
The vendor thinks MSH A should also report the error to MSH B, so that B is aware that the message, from the point of view of A, has failed. This ensures their views on the transaction are consistent. In their implementation MSH A stores the error and bundles it with the next message to B, so B is aware of the discrepancy like A.
The concept of consistent transaction views is attractive. But I don't see a requirement in ebMS3 Core or AS4 that prescribes the behavior proposed by the vendor and I'm not aware of other implementations taking this approach. In general errors on receipts seem as bad as errors on errors.
Also, EBMS:0302 is a NRR failure message, it has no information about whether or not MSH B has not delivered the message. (Probably yes, but B can in theory repudiate this as the receipt was not valid). AS4 receipts are not a two-phase commit protocol controlling message delivery. From discussion with Dale in the past I remember the usual approach (also with AS2) is to address any of these failures outside the B2B protocol.
Note that even in the vendor's proposal, the message has been delivered and that delivery cannot be undone, unless MSH B delays delivery, which in general is not desired. Neither A nor B can control when the next message from A to B is submitted, if there is a next message at all.
What do you think? Kind Regards, Pim