Hi all,

I have an AS2 EDIINT (with xml payload) which is not behaving in the way I thought it should. The message is recognised as an EDIINT message, and its parts are logged against the transaction:

• ediintdata (application/xml)
• payload (application/xml)
• payloadMimeHeaders (text/xml)

I have the ‘Submit Payload to TN’ option enabled in the IS Admin Console and in the B2B Properties within MyWebMethods.

After processing the EDIINT message, I get a subsequent submission of the payloadMimeHeaders data, but not the payload. I need to further process the payload, not the mime headers.

Some things I’ve checked:

• There is no encryption or signing, so the Partner Profile’s SMIME Type is set as plain.
• The payload is successfully recognised as the correct Document Type if I test it via the Document Types / Advanced page.
• I don’t see any errors in the server logs or in the TN Activity Log (other than the mime headers falling through to our default processing rule for unknown documents)

Any ideas as to why the payload isn’t being submitted?

Thanks in advance,
Matt.

What is your IS/EDIINT module version for this issue?

Are you trying to stimulate the payload testing it via EDIINT:send and EDIINT:receive in your environment or is it coming from your TP?

HTH,
RMG

Thanks for replying.

Our EDIINT module version is 8.0.1.0.31 with WmEDIINT_8_0_SP1_Fix7 applied.

The message is coming from our TP.

Here are the headers that we received (I’ve anonymised certain parts but maintained structure) - is something wrong here?

Mime-Version: 1.0
AS2-Version: 1.2
AS2-From: tp-as2-id
AS2-To: our-as2-id
Subject: Document.XML transmission.
Message-Id: <AS2_123456xyz>
Content-Transfer-Encoding: binary
Content-Disposition: inline; filename="Document.XML"
Content-Type: application/xml
Content-Length: 33785
Expect: 100-continue

<!-- xml document starts here -->

Thanks,
Matt.

You mentioned that the default rule was triggered.
Do you have the rule: EDIINT Process Message
for doc type EDIINT?
it should call service: wm.EDIINT.rules:processMsg

Matt,

I believe the issue with the AS2-Version:1.2 that your current IS server is not supporting with that EDIINT Module fix level can you upgrade it to EDIINT 8.2 SP1?

If not your TP has to send AS2-Version:1.1.

So the payload processing can work.

HTH,
RMG

Hi Tong - thanks for responding. Yes, I have the EDIINT Process Message rule - this does pick up the EDIINT message and runs the processMsg service. It seems that it’s this service which is then submitting the header information instead of the payload. It’s this second submission that drops through to the default rule (since I don’t have a document type configured for the header data which is being submitted).

Hi RMG,

The TP has tried a message with AS2-Version: 1.1, and the problem is still there… Here are the new headers:

Mime-Version: 1.0
AS2-Version: 1.1
AS2-From: tp-as2-id
AS2-To: our-as2-id
Subject: Document.XML transmission.
Message-Id: <AS2_123457xyz>
Content-Transfer-Encoding: binary
Content-Disposition: inline; filename="Document.XML"
Content-Type: application/xml
Content-Length: 29558
Expect: 100-continue

<!-- xml document starts here -->

Does anything else need to change to make the message AS2-Version 1.1 rather than 1.2? I’ve mentioned to our TP that the Message ID doesn’t strictly conform to the spec. I’m wondering about the Content-Disposition, as I’ve read that AS2 content is generally sent as attachments rather than inline (though I’ve seen examples of both…)

Again, thanks for your time.

Matt.

No other clue I have and can they send AS2 with plain text message and see if the payload extracts or issue with XML payload only?

Is this issue only with this particular TP in your wM environment?

HTH,
RMg

check if you have a User Process Payload Service configured.
On Admin UI:
Solutions>EDIINT>Configuration
If there is one, that should be the service that is doing the payload processing

Hi all,

Apologies for the radio silence on this. After a bit of testing we discovered/noticed that the XML message was missing the XML preamble:

<?xml version='1.0' encoding='utf-8'?>

The TP added this to their content, and processing is now executing as expected

Just as an added note, the testing we did showed that the AS2-Version header is essentially ignored by TN for values other than 1.1 - our test messages with AS2-Version: 1.2 started to work once we added the XML preamble.

Many thanks for your time in responding to my questions.
Matt.

OK sounds good thanks for the update!