RE: Trading Partner Logical Identification based on EDIFA

[mwsachs@us.ibm.com]

I agree about the grey area.  In our prototyping work in IBM, we have found
cases where an existing business application protocol expects to see some
error reports on messaging-service-detected errors.  A possible rule to
follow is that if the error condition relates to an error in the document
payload, or even the header, the sender of the document needs to see the
error message so that it can make any needed corrections.  In the IBM tpaML
proposal, we define those error conditions as terminating the conversation
since human intervention or correction of software may be needed.

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



Dick Brooks <dick@8760.com> on 08/21/2000 11:26:35 PM

Please respond to dick@8760.com

To:   Nicholas Kassem <Nick.Kassem@eng.sun.com>, gvh@progress.com
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Trading Partner Logical Identification based on EDIFA



Nick,

> >This level of reliable messaging can be accomplished using:
> >- a SYNCHRONOUS "positive acknowledgement" issued by a receiver
> to a sender
> >at the completion of a message delivery
>
> I think the operative word is "positive acknowledgement" -
> whether this is
> done synchronously or asynchronously is a transport specific
> implementation
> issue. IMO. I think one of the key values of ebXML TRP is transport
> neutrality at the Business Process Level and I think keeping the
> programming model simple is key to adoption.
>

I agree, we shouldn't require functionality that may not be available on
all
the major transports people will most likely use to carry ebXML messages.

> >- A FINAL acknowledgement indicating acceptance for processing by an
> >application (e.g. a X12 997)
>
> Would you characterize this as a Business level ACK produced at
> the BP level ?

This is certainly a gray area and I think it's a matter of opinion.
Personally, I do not consider these BP level issues.  A 997 is used as an
ack to indicate "good" or "bad" format. IMO, the transport function has
completed its task when the data is delivered to the application for
processing. This means that the messaging service is responsible for
handling and reporting errors related to crypto functions and structure
validation (dare I say translation - oh boy this is going to start a war!).


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

>
> ..snip
>