[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa-negot] Minutes of Mar. 20, 2002 conference call
Comments: > Dale wondered if the BPSS instance would be negotiable. > Marty suggested that agreement on one BPSS instance out > of several possibilities could be useful but we should > not get into negotiating the contents of a BPSS instance. I agree with Marty. Negotiation of the CPA overridable contents of a BPSS instance is done in the CPA and is thus done during the CPA negotiation. Some other team could develop the collaborative process for developing BPSS instances... does anyone want to form a BPSS Development Process TC??? :^) > Dale also wondered if roles are negotiable. For example, > there might be business processes where either party > could play either role. I think in this case, the CPA just simply has an entry(ies) for the party playing one role and for the party playing the other role. With the v0.06 CPA Simple Negotiation Business Process Model, there is an implied CPA where the two parties are signed up to play the roles of CPA Negotiator A (the initiator of the collaboration) and CPA Negotiator B. >Brian's initial draft has party A always sending offers and > Party B always sending counter offers. We will need to be > sure that this is sufficiently flexible. >The draft assumes that offer and counter offer have the same > structure, i.e. the same schema. In an email I sent earlier, I essentially confirm this. However, just to be more accurate, Party A always initiates the business transaction identifed as "Offer CPA" and Party B always initaties the business transaction identified as "Counter Offer CPA." The first "Offer CPA" transaction contains the initially offered CPA and all subsequent transactions are counter-offers regardless of the business transaction identification. > Jean pointed out that we will need some kind of metadata that > link a counter offer to the corresponding offer and to support > retry after message losses. I'm not convinced. Scenario A: 1) I don't recieve a reciept acknowledgement, acceptance acknowledgement, or CPA Offer Response with the specified time period (see sections 8.1.2 and 8.2.2 of the v 0.06 model). 2) The Business Transaction Property Value for the Initiating Business Activity Recurrence (retry) count is set to 0. Thus, the business transaction fails per UMM semantics (see UMM Patterns document). 3) The collaboration goes to FAILURE (Oops, this condition is not shown on collaboration diagram; but, is hopefully provided by UMM and BPSS semantics ;^). 4) I ponder why the other party ignored my offer after their system sent back a receipt acknowledgement and acceptance acknowledgement within the prescribed time. 5) If I want to do business with them, I call the other party on the phone. Note that this scenario applies with any business transaction instance at any time during the collaboration instance. Scenario B: We redefine the Business Transaction Property Value so the Recurrence (retry) count for the Initiating Business Activity is 3 (or some other non-zero value). 1) I don't recieve a reciept acknowledgement, acceptance acknowledgement, or CPA Offer Response with the specified time period. 2) I reinitiate the business transaction per the BPSS/UMM semantics. 3) If I don't recieve a reciept acknowledgement, acceptance acknowledgement, or CPA Offer Response with the specified time period, I go to step 2) unless I've already reached the recurrence/retry limit. If I hit the recurrence/retry limit, the business transaction fails and the collaboration subsequently fails. Scenario C: We redefine the Business Transaction Property Value so the Recurrence (Retry) count for the Initiating Business Activity is 3 (or some other non-zero value). I switch roles in this scenario: I recieved an CPA Offer and I respond with a CPA Offer Response. But, I notice that my CPA Offer Response never appears to properly make it to the destination because I never recieve an acknowledgement reciept or acceptance acknowledgement (see sections 8.1.2 and 8.2.2). I cannot resend the CPA Offer Response because the BPSS and UMM semantics do not allow it (my guess is that the ISO Open-EDI reference model doesn't allow it either). I can pick up the phone a call the other party or wait. Say I wait. Eventually, the other party will resend the CPA Offer (because the Recurrence/retry count is non zero). My CPA negotiation software will easily detect that the CPA Offer to be a duplicate or that the other party is acting out of turn. From there it can do what I command it to do like resend my original response. How does my software easily detect or consider the CPA Offer to be a duplicate? First, I keep a transaction log of all transactions against the CPA-Offer business object instance in my system. Second, if I assume that the other party did not get my CPA Offer Response, then the received CPA Offer should be a duplicate. If I assume that the other party did get my CPA Offer Response but their receipt acknowledgement or acceptance acknowledgement did not get to me, then I know they must be acting out of turn in the collaboration instance (recall that you can Accept, Reject, or Reject-With-Counter-Offer-Advice). If they recieved my rejection, they shouldn't be sending me anything unless they are trying to initiate a new negotiation. If they recieved my acceptance, they shouldn't be sending anything. If they recieved my reject-with-counter-offer-advice, they should be waiting for me to respond. Moral of the story: if you don't recieve an acceptance acknowledgement (or perhaps a receipt acknowledgement), call the other person up on the phone. > Jean said that we still need to decide whether to send > a complete draft CPA back and forth during the negotiation > process. I assume that by "draft CPA", you mean a non-binding CPA -- something you would exchange in a CPA Proposal collaboration and not in a CPA Offer collaboration. I appologize for missing the last conference call. I had a last minute 12:00 PST appointment. Best regards, Brian
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC