RE: Trading Partner Logical Identification based on EDIFA

[mwsachs@us.ibm.com]

David:

See comment embedded in the appended fragment of your posting.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



David RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 08/21/2000
05:02:52 PM

To:   "INTERNET:dick@8760.com" <dick@8760.com>
cc:   Farrukh Najmi <Farrukh.Najmi@east.sun.com>, "ebXML Transport
      (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Trading Partner Logical Identification based on EDIFA



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.

MWS:  the tpaML proposal includes an "Exception Response" message for
reported message errors detected by the application process or by the
messaging service at the receiving party.

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.