OASIS ebXML Messaging Services TC
  1. OASIS ebXML Messaging Services TC
  2. EBXMLMSG-59

AS4 support for Errorhandling DeliveryFailuresNotifyProducer

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Component/s: AS4 Profile
    • Labels:
      None
    • Proposal:
      Amend section 2.1.3.4 PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer stating that support is not required.

      Description

      Section 2.1.3.4 indicates that support is required for
      PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer

      However, these errors appear to only relate to Reliability. Ie. bullet point 'PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer' of section D.3.4 of the core spec states the following

      This assumes that Reliability.AtLeastOnce.Contract is "true".

      And Section 2.1.3.5 of the AS4 Profile states that support is not required for PMode[1].Reliability

        Activity

        Hide
        Sander Fieten added a comment -
        Proposal accepted by TC.
        Show
        Sander Fieten added a comment - Proposal accepted by TC.
        Hide
        Pim van der Eijk added a comment -
        The use of this parameter came up in a project:

        It is true that the core specification relates this parameter to reliable messaging assumed to be provided by WS-RM or WS-R. A difference of AS4 reception awareness is that a reception awareness receipt is generated in the R-MSH (i.e. not in a separate RM module) so the situation that there is a WS-RM ack but still a delivery failure is unlikely. This is because in AS4, according to the semantics of receipt specified in section 3.4, an R-MSH must finish processing the message before returning the receipt, so if that processing includes delivery (whatever delivery precisely means), a receipt indicates delivery.

        But for non-delivery, it would make sense if the R-MSH returns an error and the EBMS:0202 DeliveryFailure seems the obvious one, and the generation and reporting of that error is controlled by this parameter.

         
        Show
        Pim van der Eijk added a comment - The use of this parameter came up in a project: It is true that the core specification relates this parameter to reliable messaging assumed to be provided by WS-RM or WS-R. A difference of AS4 reception awareness is that a reception awareness receipt is generated in the R-MSH (i.e. not in a separate RM module) so the situation that there is a WS-RM ack but still a delivery failure is unlikely. This is because in AS4, according to the semantics of receipt specified in section 3.4, an R-MSH must finish processing the message before returning the receipt, so if that processing includes delivery (whatever delivery precisely means), a receipt indicates delivery. But for non-delivery, it would make sense if the R-MSH returns an error and the EBMS:0202 DeliveryFailure seems the obvious one, and the generation and reporting of that error is controlled by this parameter.  

          People

          • Assignee:
            Unassigned
            Reporter:
            Theo Kramer (Inactive)
          • Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: