Re: [ebxml-bp] User Inputs Requested 10/4/2004: Use of Notification ofFailure

["Monica J. Martin" <Monica.Martin@Sun.COM>]

A reminder about today's call at 9 a.m. PDT, 8 October 2004 after the 
CPPA bi-weekly teleconference.

Subject: User requirements for NOF and general exceptions.
Time: 9 a.m. PDT 8 October 2004
Call details: 866 882 3998, international 865 525 0769, passcode 9081038
Duration: 1 hour

PLEASE SEND YOUR INPUTS IF YOU CAN'T JOIN!

Other references:
http://www.oasis-open.org/archives/ebxml-bp/200410/msg00011.html 
(compare NOF and general exceptions).

As one additional input (with an update because I missed it) of 
substance. This answers some of my previous questions. I will try to 
summarize the overall boundaries in more detail after today's 
discussion.  The additional input includes:

    * If you look deeper into the historical information, general
      exception (business control failure) by the responder and NOF
      (stop transaction) by requester are actually used in tandem.  The
      Notification pattern (Chapter 8, UMM, R10) talks about the
      notification of failed business control and its use to supplement
      other patterns such as Commercial Transaction. Therefore we
      already have the NOF pattern defined, not the semantics detailed.
    * On a previous question I had, Chapter 8/9 (in different ways and
      at times conflicting) requester exits a transaction, and uses a
      business control failure. This equates to a Negative RA or AA, or
      general exception. The requester in turn, issues the NOF. The
      Notification pattern is a formal exchange and requires
      non-repudiation. The responder is responsible to send back an RA
      on the NOF.
    * NOF business document requires a Receipt Acknowledgement. A
      separate communication channel is recommended.

Therefore for v2.0, we need to discuss what boundaries we place around 
what already exists, understanding more semantics and boundaries will be 
described in a later version.  ***I hope that BT, financial services, 
RosettaNet and others will attend!***

Thank you! Regards.

Monica J. Martin wrote:

> In ebBP, we'd had more discussions on the relevance and use of 
> Notification of Failure. Reviewed the RNIF asynchronous messaging. 
> We've also discussed what differences may apply because BPSS allows 
> Acceptance Acknowledgment signals.  We are also trying to enable the 
> business process, realizing there may be limitations between front- 
> and backend systems.  If you review RosettaNet, we see the use of NOF 
> in these cases:
>
>    * If a response business document cannot be processed by the
>      Requesting Party after an Receipt Acknowledgment is sent: Note
>      that RosettaNet does not use the Acceptance Acknowledgment.
>    * If a timeout occurs and no/no more retries are available.
>    * If a timeout occurs waiting for response. Note that RosettaNet
>      does not use Acceptance Acknowledgment.
>
> We recognize several criteria and business requirements feed into 
> providing a well-defined NOF capability and its impact on retries. It 
> has been recommended we separate a logical path forward between v2.0 
> and a subsequent v3.0.  For v2.0, we have discussed:
>
>    * Allowing the definition of an NOF via extension of the defined BT
>      patterns. v2.0 allows the extension of a BT pattern. Provide an
>      example in the specification (action David Webber with team review).
>    * Retain the business retry count for backward compatibility and
>      understanding (although technically it is redundant).
>    * Allow use of a variable to allow specification of the retry count
>      (action David Webber with team review).
>
> Understandably there are several open questions because the previous 
> guidance talks about failed business control (on either requester or 
> responder), transaction exit by a responder, and timeout with NOF by 
> requester (More work is required as revocation of offer is indicated 
> in UMM R10. This requires more definition than is currently evident in 
> R10. Other efforts like UBAC may provide guidance in the future). We'd 
> like to review the overall issue with you to determine if this phased 
> plan is in line with your needs. Several open questions exist that 
> perhaps you as user communities can provide experience on:
>
>    * Could NOF be precluded under some circumstances where an AA is
>      required (most often the case)?
>    * If an NOF is a separate BT pattern in the future, preconditions
>      may be required for its use. This may dictate significant
>      constraint on the collaboration and the implementation. Are the
>      tradeoffs understood and acceptable?
>    * Would a simple notification request to a partner be sufficient to,
>      at times, circumvent an unnecessary NOF? (Tell calls this a gentle
>      reminder).
>    * If a retry occurs and the response occurs (cross one another), how
>      do we achieve a consistent state?
>
> I realize these may filter into new functions in a later version, but 
> your feedback is crucial to our understanding the scope of this work. 
> We encourage you to attend Friday's call at 9 a.m. PDT, 8 October 2004.
>
>    866 882 3998
>    International 865 525 0769
>    Passcode 9081038
>
> Here are some summaries that explain some of the UMM guidelines, 
> inputs from various communities include yours, and historical 
> discussions about how to manage the use of NOF. If you are not an 
> OASIS member, each of these references can be found in the email 
> archives for ebBP and are publicly available (reference below):
> a. Summary 10/4/2004 (Martin): 
> http://www.oasis-open.org/archives/ebxml-bp/200410/msg00002.html
> b. Meeting notes, see Kavi Documents under Meeting Notes for 9/27/2004 
> and 10/4/2004:
>    9/27: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00000.html
>    10/4: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00006.html
> c. Working session on general exceptions and NOF 9/10/2004:
>    Agenda and details: 
> http://lists.oasis-open.org/archives/ebxml-bp/200409/msg00065.html
>    Session notes: 
> http://lists.oasis-open.org/archives/ebxml-bp/200409/msg00057.html
>
> Open archives for September and October are found at: 
> http://lists.oasis-open.org/archives/ebxml-bp/.
>

umm-r10-chapter9-nof-highlights.pdf