HB2B 7.0.0 sends all payloads with the same data

[kimmerin]

Hi,

I've tried to "update" to release 7.0 (downloaded the release from here, yesterday) and now have failing test cases where I'm sending myself a message containing two parts infos. Here is the MMD:

<?xml version="1.0" encoding="UTF-8"?>
<MessageMetaData xmlns="http://holodeck-b2b.org/schemas/2014/06/mmd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://holodeck-b2b.org/schemas/2014/06/mmd ../repository/xsd/messagemetadata.xsd">
  <MessageInfo>
    <MessageId>TestMessageID</MessageId>
    <Timestamp>2009-02-13T23:31:30Z</Timestamp>
  </MessageInfo>
  <CollaborationInfo>
    <AgreementRef pmode="23456_push_outbound"></AgreementRef>
    <ConversationId>TestMessageID</ConversationId>
  </CollaborationInfo>
  <PayloadInfo deleteFilesAfterSubmit="false">
    <PartInfo containment="attachment" mimeType="image/jpeg" location="payloads/~hd6609370668905011355image.jpg"></PartInfo>
    <PartInfo containment="attachment" mimeType="application/octet-stream" location="payloads/~hd9774306338944612781somedata.dat"></PartInfo>
  </PayloadInfo>
</MessageMetaData>

$ cat \~hd6609370668905011355image.jpg
jpegdata
$ cat \~hd9774306338944612781somedata.dat
some data

The sending and receiving itself works and after a while I get the following inbound MMD:

<MessageMetaData xmlns="http://holodeck-b2b.org/schemas/2014/06/mmd">
   <MessageInfo mpc="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC">
      <Timestamp>2009-02-13T23:31:30.000Z</Timestamp>
      <MessageId>TestMessageID</MessageId>
   </MessageInfo>
   <PartyInfo>
      <From>
         <PartyId>remote:id</PartyId>
         <Role>Sender</Role>
      </From>
      <To>
         <PartyId>local:id</PartyId>
         <Role>Receiver</Role>
      </To>
   </PartyInfo>
   <CollaborationInfo>
      <AgreementRef/>
      <Service type="org:holodeckb2b:services">DataTransfer</Service>
      <Action>StoreMessage</Action>
      <ConversationId>TestMessageID</ConversationId>
   </CollaborationInfo>
   <PayloadInfo>
      <PartInfo containment="attachment" uri="TestMessageID-1791095796" mimeType="image/jpeg" location="pl-testmessageid-testmessageid-1791095796.jpg">
         <PartProperties/>
      </PartInfo>
      <PartInfo containment="attachment" uri="TestMessageID-1900454907" mimeType="application/octet-stream" location="pl-testmessageid-testmessageid-1900454907.bin">
         <PartProperties/>
      </PartInfo>
   </PayloadInfo>
</MessageMetaData>

$ cat pl-testmessageid-testmessageid-1791095796.jpg
jpegdata
$ cat pl-testmessageid-testmessageid-1900454907.bin
jpegdata

soap-in and soap-out logs don't show the attachment so I've fired up Wireshark were it seems that the confusion happened on the sending side (this is a trace of another test, so the IDs are different from above):

POST /holodeckb2b/as4 HTTP/1.1
Content-Type: multipart/related; boundary="MIMEBoundary_27ede36b6174147220311e7278188449c58ebcd270783578"; type="application/soap+xml"; start="<[email protected]>"
User-Agent: HolodeckB2B/7.0
Content-Length: 1827
Host: 127.0.0.1:8080
Connection: Keep-Alive
Accept-Encoding: gzip,deflate

--MIMEBoundary_27ede36b6174147220311e7278188449c58ebcd270783578
Content-Type: application/soap+xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:eb3="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance/"><soapenv:Header><eb3:Messaging xmlns:mustUnderstand="http://www.w3.org/2003/05/soap-envelope" mustUnderstand:mustUnderstand="true"><eb3:UserMessage><eb3:MessageInfo><eb3:Timestamp>2009-02-13T23:31:30.000Z</eb3:Timestamp><eb3:MessageId>TestMessageID</eb3:MessageId></eb3:MessageInfo><eb3:PartyInfo><eb3:From><eb3:PartyId>remote:id</eb3:PartyId><eb3:Role>Sender</eb3:Role></eb3:From><eb3:To><eb3:PartyId>local:id</eb3:PartyId><eb3:Role>Receiver</eb3:Role></eb3:To></eb3:PartyInfo><eb3:CollaborationInfo><eb3:Service type="org:holodeckb2b:services">DataTransfer</eb3:Service><eb3:Action>StoreMessage</eb3:Action><eb3:ConversationId>TestMessageID</eb3:ConversationId></eb3:CollaborationInfo><eb3:PayloadInfo><eb3:PartInfo href="cid:TestMessageID-1175990047"/><eb3:PartInfo href="cid:TestMessageID-1900454907"/></eb3:PayloadInfo></eb3:UserMessage></eb3:Messaging></soapenv:Header><soapenv:Body/></soapenv:Envelope>
--MIMEBoundary_27ede36b6174147220311e7278188449c58ebcd270783578
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <TestMessageID-1175990047>

jpegdata
--MIMEBoundary_27ede36b6174147220311e7278188449c58ebcd270783578
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <TestMessageID-1900454907>

jpegdata
--MIMEBoundary_27ede36b6174147220311e7278188449c58ebcd270783578--

I've tried to find the error on my side (I always assume it to be a PEBKAC) but I don't see where that possible could be the case.

[sfieten]

This indeed is a bug in HB2B where it duplicates the first payload to the other payloads when they have not been assigned a URI on submission.
As a workaround for this issue you can add the uri attribute to each PartInfo element in the MMD and assign it a unique value.

[sfieten]

I updated the issue title to better reflect what is happening.

[kimmerin]

This indeed is a bug in HB2B where it duplicates the first payload to the other payloads when they have not been assigned a URI on submission.

All the examples in examples/msgs don't use the uri attribute so I expect the MMDs "out there" to look similar to the one I've used in my tests.

[sfieten]

That the examples don't include the uri attribute is because the expected behaviour of HB2B is to assign a unique identifier when none is specified. So a MMD with multiple payloads without explicit identifiers are expected to work.

@kimmerin, you're probably right that most MMDs don't include the uri attribute. But as the most common usage is to have just one payload, it won't cause a problem as this issue will only occur when multiple payloads are included in a single message.