Re: [ebxml-cppa] View about assingned issues [RosettaNet RetryParameter ]

[Yukinori Saito <y-saito@ecom.jp>]

Marty, Arvola, and Pallavi,
Thank you very much for your comments.

[Question about RosettaNet Retry Parameter]
What is a typical cause of Business level Retries imaged by RosettaNet group
and BPSS project group?
(When the transaction would be failed, the originating business document
would be delivered again under RosettaNet Retry count control.)
Which are suitable examples followings?
(1) The originating business document is 'Purchase Order Request', but the
responding business document would be 'Quote'. This case is that the
responding business message is not matched to the originating business
document. (Business Process level failure) In this case, The Receipt
Acknowledgement signal would be delivered correctly.
(2) The originating business document is 'Purchase Order Request', and some
products codes in the business document would not be accepted by the Seller.
This case is that the contents of the originating business document is
mistaken. (Business Process level failure) In this case, the Receipt
Acknowledgement signal would be delivered correctly also.
(3) The content of ConversationId element of the responding business
document is not matched to the content of ConversationId element of the
originating business message. This case may be messaging level failure. But
The Receipt Acknowledgement signal would be delivered.
(4) The Receipt Acknowledgement signal did not be received to originator
because of Internet trouble. This case is typical messaging level failure.
(5) or any other else

I judged RosettaNet Retry count issue is messaging level failure, because
Arvola said "Asynchronous PIPs have a Retry parameter that governs how many
additional retries a sender will send a message, if it has not received a
Receipt Acknowledgement signal from the other party" by original issue. I
thought if the Receipt Acknowledgement signal would not be sent, this would
be messaging level failure, not a business level failure.  And because
RosettaNet PIP Specification Guide categorizes Retry count as FSV level, not
as BOV level.

[Another question and recommendation]
I am sorry that I did not noticed there already is 'retryCount attribute'
under BusinessTransactionCharacreristics element in CPPA V1.10.

But I have another question and recommendation.
"8.4.13.12 retryCount attribute" says "Such retries MUST not be used when
ebXML Reliable Messaging is employed to transport messages in the Business
Transaction."
I think this expression is unsuitable. I think the consensus is that this
Business level retryCount is another function other than Reliable Messaging
retries. Therefore there will be possible to use Business level retries even
if the business document would use ebXML Reliable Messaging.

The word is different each other between Business process level retries and
Reliable messaging retries.
'retryCount' attribute  [under BusinessTransactionCharacreristics element]
'Retries' element        [under ReliableMessaging element]
How about matching the word of 'Retry'?
For example,
(1) Change the name 'Retries' element to 'RetryCount' element to mach the
word of 'retryCount' attribute of BusinessTransactionCharacreristics
element.
(2) Or change the name 'retryCount' attribute to 'retries' attribute to mach
the word of 'Retries' element of ReliableMessaging element.
I think (1) is much better, because RosettaNet specification and BPSS
specification uses the word 'Retly Count'.

Regards,
Yukinori Saito


----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "Martin W Sachs" <mwsachs@us.ibm.com>; "Yukinori Saito"
<y-saito@ecom.jp>
Cc: <ebxml-cppa@lists.oasis-open.org>; "EDIgr)K.Mizoguchi"
<mizoguchi@ecom.or.jp>; "EDIgr)H.Sugamata" <sugamata@ecom.or.jp>;
"EDIgr)K.Wakaizumi" <waka@ecom.or.jp>
Sent: Thursday, March 21, 2002 1:41 AM
Subject: RE: [ebxml-cppa] View about assingned issues


Saito-san:

All RosettaNet PIPs currently have a retry parameter. When RosettaNet PIPs
are expressed as BPSS instances, it is possible to map the RosettaNet retry
parameter to the BPSS business transaction level retryCount parameter (which
the BPSS team has recently decided to add to the spec in order to be
consistent with the UMM), or to specify the use of Reliable Messaging. I
think there is general agreement that either business level retry or
Reliable Messaging should be used, but not both. We have not yet come to the
conclusion that all RosettaNet PIPs when transported over ebMS must use
Reliable Messaging, so it may be up to the individual PIP designer to decide
which one of these two retry mechanisms should be used.

-Arvola

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, March 20, 2002 6:07 AM
To: Yukinori Saito
Cc: ebxml-cppa@lists.oasis-open.org; EDIgr)K.Mizoguchi;
EDIgr)H.Sugamata; EDIgr)K.Wakaizumi
Subject: Re: [ebxml-cppa] View about assingned issues



I have a reply below to Saito-san's  discussion.

****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



                      Yukinori Saito
                      <y-saito@ecom.jp>        To:
ebxml-cppa@lists.oasis-open.org
                                               cc:       "EDIgr)H.Sugamata"
<sugamata@ecom.or.jp>, "EDIgr)K.Mizoguchi" <mizoguchi@ecom.or.jp>,
                      03/19/2002 08:17          "EDIgr)K.Wakaizumi"
<waka@ecom.or.jp>
                      PM                       Subject:  [ebxml-cppa] View
about assingned issues






Followings are my view about assigned issues.

87: RosettaNet Retry Parameter not Expressible in BPSS or CPP/A

I studied some RosettaNet PIPs (PIP2A1, PIP3A1, and PIP3A4) and PIP
Specification Guide.
These PIPs specify 'Retry Count' under 'Business Process Activity Controls'
section. And the value of Retry Count of these PIPs is '3'. '3' is
RosettaNet default value for asynchronous execution.
Retry count means that if the Acknowledgement signal would not be received
against originating business activity, the originator would send the
originating business document again within the specified Retry count.
I think this function means a kind of reliable messaging.
The PIP Specification Guide categorizes Retry count as FSV parameter, not
as
BOV parameter.

I think that RosettaNet PIPs had better just use ReliableMessaging element
in CPP/CPA usually, like the recent CPP example.
The recent CPP example (CPP-example-companyA-016.xml) is supposed to adopt
RosettaNet PIP3A4 as Service and Action, and is adopting ReliableMessaging
element.
There are other subelements (RetryInterval element and
MessageOrderSemantics
element) other than Retries element under ReliableMessaging element of
CPP/CPA. As the value of these subelements, CPP/CPA might adopt default
value, e.g. PT2H and Guaranteed.

In view point of BPSS, BPSS is a specification about business process
level,
not a specification about messaging level. Therefore I think it is
reasonable for BPSS not to have Reliable messaging parameters, e.g. Retry
parameter.

MWS:  Retries at the BPSS level relate to transaction failures, not to
reliable messaging.  In other words, the transaction failed although the
message was delivered.  This is a business process matter.  Arvola can
correct me if necessary but I understand that some RosettaNet PIPs do
provide for business process level retries.

221: nonRepudiationOfreceipt attribute concerns business level ack

I think this issue was resolved, as Marty mentioned by e-mail on March 18.

230: ds:Keyinfo subelement structure handled implicitly by deployment tool?

The disposition indicates "Maybe resolved: Add "deployment software"".
The following NOTE is already explained at '8.4.17.2 ds:KeyInfo element' in
CPPA specification V1.10.
"NOTE: Software for creation of CPPs and CPAs MUST recognize the ds:KeyInfo
element and insert the subelement structure necessary to define the
certificate."
I think this NOTE explains about deployment software. If my understanding
is
insufficient, someone please add some suitable NOTE.

Regards,
Yukinori Saito
---------------------------------------------------
Yukinori Saito
Electronic Commerce Promotion Council of Japan (ECOM)
E-mail: y-saito@ecom.jp
Tel: +81-3-3436-7542    Fax: +81-3-3436-7570
---------------------------------------------------





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>