RE: Trading Partner Logical Identification based on EDIFA

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by INTERNET:dick@8760.com
>
- 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.