[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebbp] 9/26/2004: Starting Summary on Business Level Retries
During our discussion about real-world examples from BT on last week's
call, we touched on business level retries. This point had also been
raised by Steve Capell Red Wahoo. I've provided a synposis below to
start the discussion on the points raised. Expected specification
clarifications identified 20 Sept 2004 were:
* Clarify the retry counts including original message.
* Specify resetting timers.
* Specify how to specify TTP, TTAR, TTAA when retries are used.
* Specify checkpoint semantics for state alignment and, in v3.0, for
transactional specifics for multi-party.
* Specify front- and backend-system differentiation.
I encourage your comments and discussion in tomorrow's call. Dale will
be officiating tomorrow as I will be stuck in another airport. Thanks.
==========================================================================================================
Summary:
* In the UMM, a retryCount attribute exists on the Requesting
Business Activity, which indicate the number of business level
retries, in case there is a business protocol failure. Chapter 8
R10 specifies, in one example, that a requester must do a business
retry for a business transaction if a responder's business
document is not received, receipt verified or request accepted
(not by a response but an Acknowledgment of Acceptance) within the
timeToPerform (given which one you are referencing).
o The overall timeToPerform is the elapsed time to complete
the collaboration for the Requestor. Total elapsed time
would be the timeToPerform plus the number of retries. In a
system, total allotted time is less than for the time of the
transaction and its retries (such as timeToPerform, service
level, CPPA). Backend systems may need to be aligned. Retry
is a reset to the backend criteria.
o Time to process for timeToPerform is based on a governing
business agreement and an agreed upon time source. However,
the point has been raised that the mutual parties could
agree on the time source or it could be based on the
originating source.
o The business agreement could influence the technical agreement.
o (UMM R10) Both partners agree to the number of times to
retry a transaction when a time-out-exception condition is
signaled. This parameter only applies to time-out signals
and not business process controls or document content
exceptions. [see Capell question below]
o (UMM R10) If any of the time out parameters are exceeded, a
time out exception must be thrown. If the retryCount
property on the responding business activity is greater than
zero then the business transaction must be re-initiated (or
a notification of failed business control – possibly
revoking a contractual offer – must be sent). All business
signals and business documents returned after the
transaction was initiated and up until the time out
exception must be discarded. The recurrence property
specifies the number of times a business transaction must be
initiated. If the recurrent property value is 3 then the
business transaction can be initiated a total of 4 times
(the first initiation plus 3 retries). The time to perform
property specifies the time to perform a single business
transaction. [see Capell question below]
o (UMM R10) If any business exceptions (includes negative
receipt and acceptance acknowledgements) are signaled then
the business transaction must terminate. The business
transaction must not be re-initiated even if the retryCount
parameter is not zero. Business transactions must only be
retried if a timeout exception is thrown. [see Capell
question below]
* Historically, the interpretation of retryCount and timeToPerform
on the Responding Business Activity has been a bit
confused/confusing. Before the release of the BPSS v1.05, the TMWG
(now CEFACT TMG) indicated that the timeToPerform on a
RespondingBusinessActivity defines the time in which some
subsequent business transaction must be initiated (per Brian
Hayes). This interpretation has not been re-evaluated or validated
at least to my knowledge (which may be limited). It is inferred
that the RespondingBusinessActivity supports timeToPerform. At one
time it was questioned if this created an unenforceable constraint
on the processing of the response message. Note that the UMM
RespondingBusinessActivity via inheritance from BusinessAction
supports timeToPeform (as well as timeToAcknowledgeReceipt and
timeToAcknowledgeAcceptance).
o If a timeToPerform exception occurs, it is higher priority
than both the time to acknowledge receipt and the time to
acknowledge business acceptance. If it expires then all
other timers are cancelled and the transaction ends in
failure at the requesting side. If a responder does not
receive a receipt acknowledgement or acceptance within its
timer period then the transaction fails on the responder
side. However, this last point was heavily debated prior to
the v1.1 development. Different schools of thought existed
as to the signals' use and any impact on the terms and
conditions. At that time, it was agreed that synchronization
could occur as long as the terms and conditions were not
changed from the Request. For example, substitution could
occur within parameters of the catalog that parties are
operating under – substitution of products, deliveries,
number of items – where you modify business objects not
terms and conditions [see Capell question below].
* When a business level retry occurs, a new message, associated with
the same interaction, will be generated at the lower level
(application transport). During the development of v1.1, detailed
discussions occurred that clarified that each message id is
different when retried and the receiving application will be
responsible for detecting for business level duplicates using the
unique id (like a purchase order number) in the business
information. This separates business from message level retries.
Receiving side needs to know how much to wait before a retry.
o Each BUSINESS message will have a timestamp (correlate
retries). Resend (of business message) should have the same
identifier. What happens on Requester side if the Responder
sent a response, and in the interim a retry occurs (two
messages, one service)? The last understood state should be
consistent between the two parties.
o Similarly Steve Capell asked about a business level retry
being allowed when a correction of logical errors is
required for the business document, such as when a Negative
ACK Acceptance was received. [2] Capell and JJ Dubray
discussed if the BPSS retry count is about protocol
reliability and, if so, it could be dropped. The business
transaction already has an attribute
"isGuaranteedDeliveryRequired" and so reliable delivery
might be achieved through a completely different mechanism
(eg JMS / MQ). However, the business retry has been defined
above the protocol.
+ Capell suggested the retry occur on the BTA. JJ Dubray
indicated a transition "to self" could be used on that
particular BTA. The state boundaries exist at the BTA
level. Any legal boundary exists atop the
collaboration layer. Dubray indicated it may not be
appropriate to specify retry count on the BTA as
Capell had suggested.
Thanks.
[1] This summary combines our discussions, those during v1.1 and any
references in the BPSS or UMM.
[2] See ebBP email archives the first week of September (~2-7 September
2004).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]