Re: [ebxml-bp] [12/12/03]: BPSS Signals

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

I think these additional sementics poise to two potential issues.
1) It will be more difficult to do conformance and interop testing.
2) It adds more complexity without unique functionality to the spec in which
cost vs. value need to be considered. We should not forget about the
simplicity side of the spec for SME sakes.

- serm


----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: <Lars.Abrell@teliasonera.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, December 14, 2003 2:06 PM
Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals


> The discussion can begin on this during the learning session on Monday.
>
> I will add this as a potential work item to our list as well.
>
> Thanks, Lars.
>
> Lars.Abrell@teliasonera.com wrote:
>
> >Hi,
> >As input to the learning session coming Monday about BPSS signals I want
to share with you some thoughts and experiences we have found trying to use
the BPSS spec.
> >
> >We want to be informed of receipt errors discovered by our trading
partner validating business Requests coming from us. We also want to be
informed of acceptance errors discovered by our trading partner. We
therefore enable both the (negative) Receipt Exception signal and the
(negative) Acceptance Exception signal by setting a value > 0 in the
timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance attributes.
> >
> >But at the same time with the current BPSS spec we are also enabling the
(positive) Receipt Acknowledgment signal and the (positive) Acceptance
Acknowledgment signal. This means that we receive these positive signals,
from our trading partner when he did *not* discover any receipt or
acceptance errors, prior to receiving a substantive business Response (in
response to our business Request) soon after.
> >
> >For a business transaction activity that includes both a Requesting
business activity (ReqBA) and a Responding business activity (RespBA), and
when the business document in the Request is correct in every sense, this
means that we have to receive three messages - two Signals and one
substantive Response. In some situations, for example in business
transaction activities with short response time ("timeToPerform") this seems
to be too many "unnecessary" messages. We think that if we receive a
(positive or negative) substantive business Response document it also tells
us that there were no (Receipt or Acceptance) errors of any kind in our
business Request document.
> >
> >When there are no errors, we should receive only the (positive or
negative) substantive Response and no positive Receipt or Acceptance
Acknowledgment signals, even if we do receive the negative Receipt and/or
Acceptance Exception signals when something is in error.
> >
> >We believe that if we receive a business Response in response to the
business Request, it will imply both a positive Receipt Acknowledgment
signal and a positive Acceptance Acknowledgment signal. This means that if
the BPSS spec is changed according to our proposal, it will be possible to,
in some situations, "save" (not to send) two signal messages.
> >
> >Of course the positive signals may still be needed in other situations.
> >
> >We want the BPSS specification to allow us separately for the Requesting
business activity (ReqBA) express that we only want to be informed about
receipt or acceptance errors discovered by our trading partner. And we want
to be able to express that we *not* want a positive signal, when he did
*not* discover any receipt or acceptance errors.
> >
> >We want the possibility of separately telling our trading partner that we
want to be informed, by a negative signal when he discovers any errors
because we think that is something different from telling our trading
partner that we want him to inform us, by a positive signal, if he did *not*
find any errors.
> >
> >Even though we sometimes not want the positive Receipt Acknowledgment
signal and the positive Acceptance Acknowledgment signal for the Requesting
business activity (ReqBA) we still might want to enable these signals for
the Responding business activity (RespBA). Otherwise our trading partner
might have to wait until the time-out of the receipts until he can proceed
the state of the collaboration because he will never know otherwise if the
response was not processed properly. If not, there will always be the
ambiguity if our receiving system had been jammed and never got to send that
it did effectively process the response message.
> >
> >
> >* Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080
> >* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden
> >
> >
> >
> >
>
>
>
>
>
>