OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: FW: Business Transaction Control Parameters

I'm forwarding my comment related to the "timeToAcknowledgeAcceptance" to
the BP group's consideration per Karsten's suggestion. 

Larissa Leybovich
Vitria Technology
Supply Chain Solutions
Irvine         949-857-4233
Cell            949-836-2545
Sunnyvale  408-212-2716

-----Original Message-----
From: 	Karsten Riemer [mailto:Karsten.Riemer@East.Sun.COM] 
Sent:	Thursday, December 28, 2000 5:38 PM
To:	Larissa Leybovich
Subject:	RE: Business Transaction Control Parameters

my apologies, I never saw your previous e-mail.  I wasn't online during the
holiday week-end, and must have overlooked it as I was looking through my
mail yesterday. That is a very interesting comment.  Please send it to the
whole BP team.
* karsten

>Did you have a chance to review my comments?  Should I forward these to the
>whole BP team?
>Larissa Leybovich
>Vitria Technology
>Supply Chain Solutions
>Irvine         949-857-4233
>Cell            949-836-2545
>Sunnyvale  408-212-2716
> -----Original Message-----
>From:	Larissa Leybovich  
>Sent:	Friday, December 22, 2000 7:40 PM
>To:	'Karsten Riemer'
>Subject:	RE: Business Transaction Control Parameters
>Hello Karsten,
>I'd just started to monitor the ebXML correspondence of the BP team.
>Having worked with the RosettaNet team since 09-1999 as a modeler/business
>analyst, I became  familiar with the RosettaNet Business Process
>I would like to inquire about one specific parameter and a business
>transaction design pattern from your document.
>RosettaNet (RN) had defined a concept of Non-Substantive acceptance which
>was measured via the timeToAcknowledgeAcceptance since very early days.
>modelers at the RosettaNet workshops we were continuously educating RN
>supply chain partners about this parameter and it's applicability as a
>performance control constrain.   Every time we had a
>BusinesssTransactionActivity design pattern, we'd ask if there is a
>requirement to have a Non-Substantive acceptance before you get back a
>Substantive acceptance via the responding business document.  For every
>single PIP the response was "NO".  As a result NONE of RN PIPs have a
>requirement for the Non-Substantive acceptance and it turned out that the
>"acknowledgement of acceptance" concept was found to be a non practical and
>non-valuable parameter by the RN membership.   As a result, beginning with
>the RNIF v.2.0, the "acknowledgement of acceptance" was removed as a
>business requirement and a corresponding performance control parameter.
>Here is what RNIF v.2.0 is stating:
>" Action and Signal Messages 
>Note: In RNIF 2.0, RosettaNet eliminated the Acceptance Acknowledgement
>Signal, which had not been used in any of the PIPs."
>B.5 Acceptance Acknowledgement
>RNIF 2.0 no longer supports the use of the Acceptance Acknowledgement
>concept for non-substantive acknowledgements of initial business actions.
>The Time to Acknowledge Acceptance attribute in the Business Activity
>Performance Controls table in the Business Operation View and the Time to
>Acknowledge Acceptance Signal in the Functional Service View therefore
>should be omitted for newly designed PIPs."
>From what I understand the Acceptance Acknowledgement is the major factor
>that differentiates BusinessTransactionActivity from the RequestConfirm
>design pattern.
>If this is true, than my questions to the BP group are:
>1. Did ebXML BP team look at the RN conclusions related to the "Acceptance
>Acknowledgement" parameter's history, usage, and applicability?
>2. If there is the true necessity to have this parameter, which data
>elements have to be validated/accepted?  What is being returned in the
>"non-Substantive" signal to the initiating partner role? 
>3. What is the major differentiation between the
>from the RequestConfirm design patterns?
>4. What are the business requirements to have these 2 different design
>patterns?  Which the business scenarios are supported by each design
>pattern? How do you determine when to use one design pattern vs. the other?
>I'm sending this message to you only initially, because I don't know if
>these questions had been raised and answered already by the BP group.   If
>it is a closed item, then I don't want to waste the whole group's time on
>this subject (in light of your tight deadlines).
>Best regards,
>Larissa Leybovich
>Vitria Technology
>Supply Chain Solutions
>Irvine         949-857-4233
>Cell            949-836-2545
>Sunnyvale  408-212-2716
> -----Original Message-----
>From:	Karsten Riemer [mailto:Karsten.Riemer@East.Sun.COM] 
>Sent:	Thursday, December 21, 2000 9:02 PM
>To:	ebxml-bp@lists.ebxml.org; ebxml-=tp@lists.ebxml.org
>Subject:	Business Transaction Control Parameters
> << File: Word.Document.8 >> Hi,
>the TP team had asked for clarification of the control parameters on a
>business transaction (formerly known as commercial transaction),
>the security related ones.
>Attached is a write-up that I think is clear, but unfortunately I am not
>if it is correct in every little detail :-(
>It has some open questions, that I think we can use to resolve the concerns
>about what level the 'business' needs to specify security at. I am
>to Ralph Berwanger's recent mail to MaryAnn Hondo.
>We are in extreme time pressure, so we can only entertain feedback during
>Friday the 22nd. Anything after that may go into a next review cycle.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC