[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] State Alignment and Web Services
Kenji, OK - good clarification. I think V2 can support the RosettaNet example by allowing 'pending' as a return state - and then the beginsWhen / endsWhen can be controlled using the new variable mechanism with expressions that check for the conditions between each BTA. Since a guard condition checks for just succeed or failure, you would need to setup a signal for the pending, but of course - if you look closely - that signal can have a transaction associated with it - so not a problem - as with the RosettaNet case. Since you talk about this "happening several times" - there must be some kind of "fail" condition - that causes the whole to re-start again from the top. That would obviously need to be "linking and switching" logic that resides above the BPSS - in your implementation layer - that causes the BPSS to be initiated again (possibly with different requirements) to attempt a second or third time. Perhaps we could model the appropriate PIP using the new BPSS model I have to see how this can all be represented? Thanks, DW ----- Original Message ----- From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com> Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org> Sent: Friday, July 16, 2004 5:26 PM Subject: Re: [ebxml-bp] State Alignment and Web Services > Hi > > Sorry it was a slip of the finger to write "transport level". I meant > "pending" is not part of BT. > RosettaNet communicates "pending" through responding action, not through > signal. > > Buyer sends purchase order request to seller, and the seller sends > response message back with > line item status set to "pending", thus completing the first BT (PIP). > Later the seller initiates another BT to notify the buyer with new value > in line item status -- either positive or negative confirmation, or even > "pending" again. This could occur many times. > > I found some people see this modeling inconvenient and wanted to pack > those multiple transactions into one BT, > which is not possible with current BPSS. It might have something to do > with David's point. > > Is anybody really interested in this example? > > Kenji > > David RR Webber wrote: > > > Kenji, > > > > Yes - the 'pending' is part of the BTA. I guess in the > > case of a distributor - it confirms that an attempt is > > being made to find source(s) for product(s) requested. > > > > In that sense its a binding attempt to provide that, > > and as you say - the answer could be - 'no source found'. > > > > Thanks, DW > > > > ----- Original Message ----- > > From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com> > > Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org> > > Sent: Thursday, July 15, 2004 6:43 PM > > Subject: Re: [ebxml-bp] State Alignment and Web Services > > > > > > > >>Hi, > >> > >>This "pending" sounds like business level semantics, which should not be > >>handled at the transport level. > >>I can provide an example from RosettaNet which supports such "pending" > >>status response. While the response message itself is legally binding, > >>but you can say "no" later in update message. > >>There might be a confusion about "legally binding". "legally binding" > >>means that you're liable for what you said in the message ("pending" in > >>this case), not for selling something no matter what your downstream > >>supplier say...? > >> > >>Kenji > >> > >>David RR Webber wrote: > >> > >> > >>>Monica, > >>> > >>>I believe this came out of a scenario that Anders described - where > >>>he want to Ack the RFQ - but not confirm it until downstream suppliers > >>>had responded. > >>> > >>>Therefore 'pending' was offered as an additional status. Anders also > >>>wanted to make sure that the signal was *not* a legally binding > >>>response - hence 'pending' again avoids that connotation. > >>> > >>>It all made sense to me at the time - and I included this in the > >>>XML example I posted on signals - along with the additional > >>>two attributes - (BTW - signalType - agree that is not needed - > >>>and can be deferred to V3). > >>> > >>>Thanks, DW > >>> > >>> > >>> > >>>>mm1: David, I do not recall that we defin3ed a pending status in the > >>>>special sessions. Dale, can you confirm please. Thanks. > >>>> > >>>> > >>> > >>> > >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]