OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Trading Partner Logical Identification based on EDIFA


See comment embedded in the appended fragment of your posting.



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
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
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
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC