I have a partner who is sending multiple XML documents via AS2 within seconds of one another. Some make it some don’t. It seems the second document always has problems. In the scenario below DocID3, 4 and 5 are processed as they should be. My partner promises all MDNs and Security is passed back and forth as it should be per there side. They insist when they send the document alone it works and it does seem to work.

Looking at the transaction log I will see
DocID1 ProcessMsg
DocID2 ProcessMsg:PAYLOAD
DocID3 ProcessMsg:ERROR
DocID4 ProcessMsg:PAYLOAD
DocID5 ProcessMsg:PAYLOAD

I only see three xCBL_Order that process

Attributes log for DocID1 has a user status of ProcessMsg and I do see EDIINT message doPayload value = yes.
Activity log stops short of recording the activity when compared to a normal transaction that processes as it should.

Attributes log for DocID3 has a user status of ProcessMsg:ERROR
I do NOT see EDIINT message doPayload
Activity log give a type=ERROR
Brief message=Security check failed, Payload is not processed.

Any help would be very welcomed. I did read that savefiletoPipeline can cause simular problems and I do have it disabled.

Thanks in advance
CHill

Hi CHill,

I’m not familiar with this particular error, but we have a similar situation in which a trading partner sends many documents. Occasionally, for no apparent reason, we will get a ProcessMsg:ERROR with “authentication-failure”, except this occurs before the payload is extracted.

We have asked the trading partner to request asynch MDN’s and are waiting on them to make this change to see if it has any impact.

If you are receiving synch MDN requests from your trading partner, you may want to ask your partner to switch to async to see if that helps.

Thanks for the quick response. My failures do come before the payload is extracted also. I am not sure how flexible my partner can be. How would I find out if we were sync or async. I thought it was in the partner information.

Hello,
I just had a similar issue today. What I referenced to solve it was the EDIINT User Guide. It was that the Sender of the EDIINT (my interconnect or VAN (value added network)) did not have the Extended Field set for S/MIME under my partner profiles. I set mine to “plain” and that was enough.

It had nothing to do with the internal content nor the receiver of the message. Thank you. Good day.

Yemi Bedu

Hi Yemi and Chill,

The partner set the MDN request to asynch, but this did NOT resolve the issue.

Regarding the suggestion to set the profile extended field to plain. Are you expecting signed/encrypted data from the partner? If so, and you set the extended field to plain, will the verification/decryption still occur?

It seems there are two potential issues with this approach. One, if you’re expecting S/MIME data from the partner and they send something else, it seems that you would want the error to be issued. Secondly, if you’re using the wm.EDIINT:send service to send outbound to the trading partner and the “type” input variable is “getFromProfile”, setting the extended field to plain will result in outbound EDIINT docs being sent to the partner without signing or encryption.

Thanks for your input. I would appreciate any other information as we do still have the “authentication-failure” error occasionally.

Hello,
I was only referring to the sender partner profile of inbound messages to be set to plain for s/mime. I think my wording may have been misleading. This is also only for the internal content (payload), the whole message communicated is still signed and/or encrypted. If there is expected data that is encrypted, it will still be accepted with “plain”, only the other way won’t work.

For the async and sync, you will have to negotiate with the sender what they have setup. It is a part of the message to request an MDN and if it should go out on the same channel (sync) or a new one (async). I don’t think the MDN change would help that much, but I prefer the async when possible (less processing load per session).

As is any case, I only recommend a way to troubleshoot how to consistently receive information. You should increase your security choice as needed and still find out if advantage or WM support has a better possibility for a final solution. Good day.

Yemi Bedu

Yemi! Good to see you on wMUsers again! Thanks for dropping by.

Mark