RE: Request for clarification - multiple payloads

[Charlie Fineman <fineman@arzoon.com>]

Comment from a lurker <cf>

 

DB, if I interpret PY's sentence before the one you quoted correctly, your example does not, well, exemplify his point. I *believe* he was talking about two seperate requests in one payload; not two responses to a single request. My guess is that the TRP could easily deal with this as long as there is a clear identification of the response with the request in the TRP.

 

IMHO, a more suitable example might be a series of batch requests being sent off in a single message.

 

PY, am I paraphrasing correctly?

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Monday, December 11, 2000 3:48 PM
To: Prasad Yendluri; ebxml-transport@lists.ebxml.org
Subject: RE: Request for clarification - multiple payloads

Prasad,

 

>I was suggesting that "when we apply this to the case of Synchronous exchanges, this would boil down to a simple straightforward extension of the model. That is, multiple responses (if any) would come back in the payload of the synchronously delivered  response message".

 

<db>

I think we are in agreement. A good example of this is when a party queries a catalog for information on a product and the return data contains a textual description of the product along with a separate JPEG image. I envision both of these being packaged in a single multipart/related payload of the response message.

</db>

 

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

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Monday, December 11, 2000 5:24 PM
To: ebxml-transport@lists.ebxml.org
Subject: Re: Request for clarification - multiple payloads

Dick,

Thanks for the example. My question was based on what David Marshall listed as an OTA requirement:

<requirement>In the OTA we need to send at least two payload documents
within each ebXML message envelope.</requirement>

I thought the answer that was offered to David was, yes you can pack these two (or more) payload documents in a MIME
multipart/* structure and send it out as payload in a single ebXML message.

Now, my question was based on the possibility that the two payload documents could generate two response documents, that could again comeback as payload in a single ebXML message.  I was suggesting that "when we apply this to the case of Synchronous exchanges, this would boil down to a simple straightforward extension of the model. That is, multiple responses (if any) would come back in the payload of the synchronously delivered  response message".

I take it,  there is no issue with it.

Prasad

Dick Brooks wrote:

Prasad,

The GISB profile of EDIINT AS2 contains an example of a multipart
acknowledgement, here is how I've envisioned the GISB
acknowledgement receipt appearing in an ebXML Acknowledgement Message using
HTTP binding:

HTTP/1.1 200 OK
Server: Group 8760 GISBAgent
Content-Length: 2739
Content-type: multipart/related; type="application/vnd.eb+xml";
boundary=-----------------------8760567890----

-------------------------8760567890----
Content-ID: ebxmlheader-8760-2081904539
Content-type: application/vnd.eb+xml; charset="UTF-8"

<?xml version ="1.0" encoding="UTF-8"?>
<!DOCTYPE ebXMLHeader SYSTEM "level1-10022000.dtd">
<ebXMLHeader xmlns = "http://www.ebxml.org/namespaces/ebXMLHeader"
Version = "0.21"
MessageType = "Acknowledgement">
<Manifest>
<DocumentReference>
<DocumentLabel>GISB-Acknowledgement-Receipt</DocumentLabel>
<DocumentId>cid:8760.com2081904536</DocumentId>
<DocumentDescription xml:lang="en-us">
GISB-Acknowledgement-Receipt</DocumentDescription></DocumentReference>
</Manifest>
<Header>
<From>
<PartyId context = "DUNS">059397184</PartyId>
</From>
<To>
<PartyId context = "DUNS">943561654</PartyId>
</To>
<TPAInfo>
<TPAId>/2059397184/943561654GCIPO-20000202</TPAId>
<ConversationId>8760.com2081904537</ConversationId>
<ServiceInterface>Nominations</ServiceInterface>
<Action>Process-850NMST</Action>
</TPAInfo>
<MessageData>
<MessageId>8760.com2081904538</MessageId>
<Timestamp>20001028094906310.000Z</Timestamp>
<RefToMessageId>Not Applicable</RefToMessageId>
</MessageData>
<ReliableMessagingInfo DeliverySemantics ="OnceAndOnlyOnce"/>
</Header>
<RoutingHeader>
<RouteInfo>
<SenderURI>8760.com/ebXMLHandler</SenderURI>
<ReceiverURI>enron.com/ebXMLHandler</ReceiverURI>
<ErrorURI>mailto:ebxmlerrors@8760.com</ErrorURI>
<Timestamp>20001028094906310.000Z</Timestamp>
<SequenceNumber>00001</SequenceNumber>
</RouteInfo></RoutingHeader></ebXMLHeader>
-------------------------8760567890----
Content-ID: 8760.com2081904536
Content-Type: multipart/report;  report-type="GISB-Acknowledgement-Receipt";
boundary="GISB7867"

--GISB7867
Content-type: text/html

<HTML><HEAD><TITLE>Acknowledgement Receipt Success</TITLE></HEAD> <BODY><P>
time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
</P> </BODY></HTML>
--GISB7867
Content-type: text/plain

time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
--GISB7867--
-------------------------8760567890------

Dick Brooks