OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ebBP] 7/29/2004: NOF Followup [RSD]


Discussion|OASIS.ebBP.WI36-39-52-60-NOF and General Exceptions;
Topic|;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00123.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00035.html;
Point|Scope of Notification of Failure;

mm1@
In the editors' F2F, we discussed NOF, general exception signals and 
signals in general (no pun intended) at length. In line with the team's 
input and editors here were the original parameters set for NOF 
(Notification of Failure):

    * Separate NOF message from general exception signal.
    * Specify a NOF could occur only if a timeout occurs for failure to
      receive a requesting or responding business document. In the case
      when there is reliable messaging which shows the receipt of
      request or response,the party should not be capable of sending
      NOF. If for example, a response is sent then a NOF by a responder.
      That is an anomaly; this is to be handled by the business
      agreement (UBAC).
    * Differentiate NOF from Neg AA.
          o Negative Acceptance Acknowledgment: You recognize you have a
            problem.
          o NOF: Allows us to clear the slate when the normal exception
            methods do not apply.
    * Add: Specify a NOF as a new BT pattern.

We've received feedback from signal author Hima Mukkamala asking about 
two conditions we may have not adequately considered:

    * Extraneous conditions may cause the responder or requestor to send
      NOF to invalidate the existing transaction or collaboration.

        e.g. If a requestor sends a purchase order and responder sends
        an AA, requestor may want to invalidate the current transaction
        cause some condition in his system caused the invalidation of
        the PO. This is not part of the reqular business process, however.

    * Could NOF be used as a general purpose exception handling
      mechanism or do we restrict it to conveying expiration of TTP?

I'd appreciate feedback from the editors' or team members. Thanks.
@mm1



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]