[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] RE: BSI retries question - further clarification
Sacha, Thanks for your feedback. From an academic perspective what you say makes sense but I'm just thinking about market acceptance of BPSS based BSI infrastructure and what reasonable human expectations would be in a real practical scenario. The problem is that it is hard to define to what extent a "changed payload" could be permitted in the context of a retry. The original basis for my question was that we often encounter the situation where a business acceptance fails for a fairly trivial reason. Consider the following simple scenario: 1 ACME sends a purchase order to their supplier Widget Co. All business signals (receipt & acceptance ACK) are positive. 2 Widget Co generates an order response. Their system uses arbitrary internal UOM codes that are transformed to EDIFACT UOM codes before sending to external parties. However in this case the transformation is missing so the order response goes out with a line item UOM of "each" instead of "EA". 3 The ACME system expects EDIFACT UOM and so rejects the order response and the AVME BSI creates an acceptance NACK. 4 The Widget Co administrator receives a notification from the Widget Co BSI, quickly identifies the problem and makes a new entry in the Widget Co UOM mapping tables for "Each" to "EA" mapping. Now, should Widget Co who is the supplier in this relationship be able to re-send the Order Response in the context of the same business process or should the whole collaboration be rolled back - which leaves two options: 1 The two parties have to do manual processing 2 Widget Co has to ask their customer to re-send the original order. I suspect that the adminsitrator at the Widget Co end would expect to be able to re-send the corrected POR and that if he can't then he would be escalating an issue to his management about failure of "this crappy BSI thingy". My position is that it is up to the business logic in the back-office system to accept or reject business message. Therefore whether it is a trivial change (like the UOM issue) or a huge change to the payload in the context of a business retry - it simply does not matter. It is not the job of the BSI to determine the business validity of the content in a payload. Therefore the question simply boils down to whether we accept the concept of BUSINESS retry at BSI level as a separate thing to a TECHNICAL retry at messaging level. Regards, Steve Capell Red Wahoo Pty Ltd +61 410 437854 -----Original Message----- From: Sacha Schlegel [mailto:sacha_oasis@schlegel.li] Sent: Tuesday, 7 September 2004 8:55 AM To: Steve Capell Cc: ebXML BP; anthony.ellis@redwahoo.com Subject: Re: [ebxml-bp] RE: BSI retries question - trying again Hi Again Some corrections. Sorry about that. Regards Sacha Am Dienstag, den 07.09.2004, 00:46 +0200 schrieb Sacha Schlegel: > Hi Steve > Hi Anthony > > I assume you are referencing BPSS 1.1 > > There is an optional retry attribute in the RequestingBusinessActivity > of type xsd:int > > The comment on this attribute is: > > "The BSI must retry to send a request n number of times, > in case no signals are returned by the responding activity." > > If I understand you right, the requesting business document has been > sent and a Receipt Acknowledgment (Reqeust.ACK.Receipt in 1.1) has been > received. OLD: > You then received Then you are waiting for either an NEW: You then receive an > Acceptance Exception (Request.NACK.Acceptance in 1.1) and now is the > question whether you can start the requesting business activity again, > with a "new" requesting business document, eg changed payload? or > whether this BPSS instance just fails. > > I do not know what others think but I would understand that the business > process fails. You did recieve a signal, just a negative one. The specification says in case no signals are returned, but in this example a signal is returned (a negative one). > > In my eyes this is information the business analyst can model and is > then propagated down to the CPA where you have the retry count, which I > think is how many times you have to try to send the original business > request document. > > I would not interpret it that the BSI can change the payload of the > message "retry" times and try and see if the other party likes the > changed request better. > > Question would be: what happens if this is the last message exchange in > a long running process (eg over several days)? It could be a pain to > have the process start from the beginning again. Could indicate that the > collaborative business better has to be modelled differently (eg process > 2 follows one process 1, so two parties can continue with process 2 once > process 1 succeeded). > > Maybe a good case for BSI interoperability test cases... > > Intersted what others think. > > Regards > > Sacha > > PS: I just found out in Figure 17 "Computation of the Status of a > Business Transaction Activity" of the BPSS 1.1 that the responding > business activity ALSO has an Acceptance Acknowledgment/Exception (eg > Response.ACK.Acceptance, and Response.NACK.Acceptance) messages. PSII: There is no optional retry count attribute in the responding business activity. Is this inconsistency or is there is reason? > > Am Dienstag, den 07.09.2004, 07:53 +1000 schrieb Steve Capell: > > Hi all, > > > > > > > > Nobody responded to this one. It is an important clarification > > because if different BSIs take a different interpretation of retry > > count then one side might terminate the process after an acceptance > > NACK whilst the other attampts a retry.. > > > > > > > > Any comments? > > > > > > > > Steve Capell > > > > Red Wahoo Pty Ltd > > > > +61 410 437854 > > > > > > > > > > > > ______________________________________________________________________ > > > > From: Steve Capell [mailto:steve.capell@redwahoo.com] > > Sent: Thursday, 2 September 2004 7:26 PM > > To: 'ebXML BP' > > Cc: 'anthony.ellis@redwahoo.com' > > Subject: BSI retries question > > > > > > > > > > Hello all, > > > > > > > > I have a question about exception handling in the context of a BSI > > that is "managing" a BPSS process. The BSI aggregates all the > > different events that might lead to a protocol failure into one > > "protocol success/ protocol failure" signal to the next layer > > (typically a BPM executing a BPEL?). > > > > > > > > Is it correct to assume that the "retry count" attribute of the > > "requesting business activity" element represents the maximum number > > of BUSINESS retries and is entirely separate from any technical > > retries at the reliable messaging layer? For example, if send a > > message that is successfully received from the message handler > > perspective (eg I get a receipt ACK from the other side) but fails > > from the business perspective (eg I get an acceptance NACK) then I can > > modify the document and retry the request in the context of the SAME > > business process instance? > > > > > > > > However in the context of a time to perform timeout we assume that we > > cannot retry because a mutually agreed maximum time to perform a > > business operation has been exceeded. In this case the transaction > > needs to be rolled back and tried again in the context of a NEW > > business process instance (or handled manually). > > > > > > > > Hoping someone can confirm our understanding.. > > > > > > > > Regards, > > > > > > > > Steve Capell > > > > Red Wahoo Pty Ltd > > > > +61 410 437854 > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]