Yunker (ebBP) 3/7/2005: Comment re: General Exception (wd 10)

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

Note: Forwarding to the team list.
========================

On 1 March 2005 around our TC call, several have been reviewing the 
specification. John Yunker indicated we should consider specifying what 
happens after a general exception occurs. Here is some proposed text to 
consider for the Tuesday call. John, your comments raise the question if 
planned events occur after unplanned ones. I've tried to briefly outline 
at least two cases in the suggested technical specification text. Please 
comment.

Section 4.8.2.3
[add at the end of this section]

As an unplanned event, a general exception MAY result in later actions 
of the parties that are choreographed. For example, the parties MAY 
agree to use a Notification of Failure after a general exception occurs 
to return to their initial state. It is also forseeable that a party MAY 
send the business document with changed content after a general 
exception occurs. Such an action MAY necessitate that the parties 
initiate another business transaction (i.e. returning to their initial 
state and initiating a new business transaction rather than issuing a 
business retry). These expectations are subject to the agreement of the 
parties.


Original post:
=========

> Yunker 1 March 2005: Today's brief discussion of general exceptions 
> caused me to look at the spec. We don't deal with what happens AFTER 
> general exception is sent/received.
>
> Current Treatment:
>
>       The general exception signal MAY be used under other conditions
>       such as: 2128
>       • IsIntelligibleCheckRequired exists and a Receipt
>       Acknowledgement has been sent, but 2129
>       something fails in processing. This is assuming that an
>       Acceptance Acknowledgement is 2130
>       required, processing has begun but not completed, and the AA has
>       not yet been sent. 2131
>       • isIntelligibleCheckRequired has not been defined and a RA has
>       been sent, but something 2132
>       fails in processing. An AA may or may not be required later. 2133
>       • No signals are required and the need exists to notify a
>       partner of a problem. This could 2134
>       support the known RosettaNet case of synchronous events. 2135
>       2136
>       The key is that the technical failure be visible for sufficient
>       state resolution. For example, an 2137
>       unexpected gateway shutdown may require a general exception
>       signal be issued. Under these 2138
>       circumstances, an event outside of the collaboration (gateway
>       shutdown) impacts it 2139
>       (collaboration).
>
> We may want to add the following for clarity (or we may want to not 
> open this particular can of worms):
>
>       Responses to receipt of a general exception MAY result in:
>       • Sending a NotificationOfFailure setting aside the business
>       transaction.
>       • Resend the business message with changed content to address
>       the exception. Note
>       that this requires that the party issuing the exception rolls
>       back its transaction state to
>       prior receipt of the business message upon generating a general
>       exception (so the
>       corrected business message is NOT treated as a retry).
>       • Receipt of a general exception behavior as agreed by the
>       parties (e.g. sets aside the
>       business transaction).
>