[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] RE: BSI retries question - further clarification
Let's see if I can weave my way through the starting discussion thread on a holiday (Thanks Sacha for the great followthrough while I was enjoying a fall day). See my additional comments inline (***mm1: .....***). I encoureage others to comment as well. Steve Capell wrote: >Capell: 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. > > ***mm1: My question would be how you would differentiate the trivial from the business substantive reason here. The reason being is that if the document is changed, this could trigger an open question if the business relationship is also. Some time ago pre-v1.1, we discussed that a warning could occur on an AA not exception but it was from the responding entity perspective. Perhaps we should investigate this further. We also have talked about starting / restarting a business process when alternate means are used [1]. [1] Where for example the order is done via fax and you need to engage the gateways to the automated processing. These two cases buttress on the same/similar set of questions / situations. See comments below. >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". > mm1: Hmm, that's a new term....Anyway, should we consider if the use of the extensions for the BT patterns could allow for such conditions. I still don't know how you could create a deterministic way to say this change is substantive or not, however. Perhaps, a notification could be sent in the extended pattern that allows for another order response (but this is purely an example to discuss the matter more fully than a well-thought out case). I'll bring it to the group's attention at our next meeting if we have time (special session with a presentation from an outside group already scheduled- sorry). >My position is that it is up to the business logic in the back-office system >to accept or reject business message. > mm1: Isn't that the reason that it was rejected in the first place is that it did not meet the expectations? >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. > mm1: The BSI is only communicating back to partners after processing occurs. Doesn't the BSI handle syntactic validation, handed over for processing/in process and monitoring response from the partner)? A distinction is made in the previous v1.1 spec (section 5.9): "A Business failure is any failure that is identified by an application during the processing of the business document(s) and based on information not available to the BPSS. For instance, a “reject purchase order” response document would be considered as a business failure." >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. > mm1: I think with the statement above (if it still holds true), the answer is yes. Let's get more responses this week. Steve, please think more on my suggestions as well. Thanks. > >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]