Subject: RE: Trading Partner Logical Identification based on EDIFA
Message text written by INTERNET:firstname.lastname@example.org > - Successfully passed authentication/access control - Successfully sent the bits to the other end - Successfully checked the packaging - Successfully checked the header structure - Successfully checked the header data - Successfully checked the signature on a header - Successfully decrypted the payload - Successfully verified the signature on a payload - Successfully checked the structure of a payload - Successfully "translated" the payload (from XML, X12, EDIFACT) - Successfully passed the translated payload to a backend system/application for processing - Backend application successfully processed the payload In addition to all the "successful" cases above there are a significant number of error conditions that can occur at each of these points. My question to the group was, which of these "checkpoints" are within scope for the phase 1 reliable messaging deliverable? <<<<<<<<<<<<<<< Dick - one way of resolving this is to define things at the Business Process layer. What I'm thinking is the ability to define a "Fail" action. A single "Fail" action could be associated with TRP header, which then details the item, as above, that caused the fail. For a given transaction (OK that should be communicationID?) the BP folks can define what FAIL entails from the business process side. On the EDI side we had this hideously overloaded 997 - we want to avoid that! Notice "fail" in the BP context could be an "out-of-stock" or a "rain-check" response, as well as an "error" or "not processable" type response. Anyway - my point here is that the approach I am seeing is using the RegRep to hold these BP definitions. If you look in the GUIDE classification layer you'll notice we've made a start on providing how the hooks into this would work. Obviously this needs refining - but this appears to be the right approach and the right layer for this stuff to happen. It gets it out of transports hair - as there is one single consistent behaviour and interface, while allowing BP to do their thing in terms of extending the interaction. If you think of RosettaNet PIP's you can see that this is an excellent fit, where the PIP goes into the BP classification layer. Notice also you can define a default layer that can be used when there is not one available - and this can be defined again in the RegRep. Separation of function into layers is a powerful approach that allows clear delination of the behaviours and the interfaces. Once again we also have a minimalist approach - if you are at Level 1, you have full access to BP, RegRep and responsive behaviours, thru down to level 6 where you have a simple static RegRep emulation, that only has one builtin default "fail" behaviour for transport or payload handling. DW.
Powered by eList eXpress LLC