RE: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure Question: section 4.6.8.1 and 4.8.3

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

I am not certain how the group has explained the use of these status
values, because a given event can be evidence for several status values.
I have assumed that RAE and AAE are technical failures. It seems
reasonable that GeneralException would be a technical failure also. When
an event occurs that makes multiple flavors of failure occur, and there
are distinct transitions defined that vary for those different status
values, I think the specification leaves it open exactly what a
monitoring application would require to verify that behavior was as the
BPSS instance specified. It is a case where the implementation is
expected to do something reasonable (after all, a failure has occurred
so in general it will be necessary to note the failures that have been
detected...)  If a NOF business message failed to be sent after an
exception, it would just be another protocol failure (choreography
violation) for that session. I think it would still be worth reporting
in a monitoring tool.

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Thursday, March 10, 2005 2:06 PM
To: Yunker, John
Cc: ebXML BP; Dale Moberg; himagiri@sybase.com; steve.c >> Steve Capell
Subject: Re: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure
Question: section 4.6.8.1 and 4.8.3


>Yunker: Let's look at the business case.
>
>AnyProtocolFailure is designed to allow the protocol to catch and
orchestrate behavior when the protocol fails.
>
>Any protocol failure includes general exception.  Any un-orchestrated
general exception should result in NOF (or other agreed setting aside of
the transaction)
>  
>
mm1: Thanks John, I'll take these comments for revisions in the General 
Exception text proposed. I have a question for Dale and Hima though. 
Hima, any concerns?
Dale, do we need to make any changes to the schema in line with 
associating AnyProtocolFailure with GeneralExceptionType? Updated text 
is provided at the end of this email.  I have one final question, isn't 
Failure actually an AnyProtocolFailure and Business Failure combined?  
This would be consistent with Success which is a Technical and Business 
Success? Trying to ensure correction of any typos or copy-paste errors 
(Section 4.8.3). Thanks.

>>mm1: 2/22/2005: Today, we discussed this question briefly. How do we
>>separate or compare the AnyProtocolFailure to general exception. There

>>are actually > 1 questions here. So I will attempt to articulate:
>>
>>   * Any protocol failure is one of the enumeration values of the
>>     ConditionGuardValue list that can apply to a substate (status)
>>     visibility or to condition guard. See Sections 4.6.8.1 and 4.8.3,
>>     that specify guards on transitions.
>>   * General exception is defined but is not part of the BT patterns
>>     defined (as it is unplanned). See Section 4.8.2.3.
>>
>>Therefore, is general exception an 'AnyProtocolFailure' other than the
>>other types specified? I ask this question because the use of the 
>>general exception is not articulated as a guard. ....
>>
>>So we have to answer:
>>
>>   * How do GeneralException and AnyProtocolFailure relate if at all?
>>     One is in the defined transition guards (the latter) and the
other
>>     is completely unplanned. ......
>>
mm1: See John Yunker's comment above.

>>   * After answering above question, what schema changes may be
>>     required. Tech spec language will follow.
>>
Updated
======

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. A general exception MAY result in

a state transition to a technical failure (AnyProtocolFailure).  Note,
state transitions and failures are described earlier in Section 4 and in
more detail in 
Section 4.8.3. If a general exception occurs and the party notifies the
other with a general exception signal, the parties transition to a known
state.
Whether further action is required or the technical failure results in
any business effect is subject to 
the agreement of the parties.

Under choreographed circumstances, if a party is unable to respond with
a choreographed receipt acknowledgement within the time specified, 
that party should exit and, if agreed by the parties, the requesting
party MAY issue an NOF or a business retry.
For the unchoreographed general exception, the parties MAY also agree to
subsequent actions that are choreographed. Whether the 
unchoreographed general exception follows the same path as the known
circumstances outlined is unspecified. 
More business requirements are sought to understand, if and when an NOF
should be issued, another business transaction may occur after the
return to initial state, or subsequent choreographed actions are
required.