Adding a new EDIINT AS2 Trading Partner using version TN 4.6. I am simply trying to send a test EDI message to their server:

Type = Plain
Delivery Method = PrimaryHTTP
RequestMDN = none
RequestSignedReceipt = false

After I look into Transaction Analysis –> Activity Log the last step of Delivery is in ERROR:

Message Reads:
Task m1000r0v07f7lb0k0000004p failed with no more retries available. Reason for failure - 500 Internal+Server+Error

Any suggestions?

Chris,
Make sure that you are pointing to the correct URL to send to.

~tS

Tahira,

Thank you for your note. I did realize that there was an issue with the URL. The issue is fixed. Thanks.

I’m using WM6.5 to send an EDIINT with following input:



application/edifact

plain
false
PrimaryHTTP
none
false

MYAS2ID
EDIINT AS2


MYTRADINGPARTNER
EDIINT AS2

The EDIINT Delivery URI shown in the Attributes tab shows the correct URI and I am able to reach the URL in web browser. However, I got the error: Task m1e3ih0v33ncgsjc000002bv failed with no more retries available. Reason for failure - Delivery service for m1e3ih0v33ncgsjc000002bv failed with a status of fail and status message of 500 Server Error.

Please help. Thanks.

Hi Janietsy,

Check the all the ports open for your partner URI, check with your networkteam may be firewall is blocking the port.

Telnet you partner IP number from your server and check the response.

Thanks,
Jsree

“500 Server Error”

This is what is being returned by the remote server. The URL is fine and is being reached. The server you’re connecting to is erroring out and returning the 500.

Hi Jsree, Hi Rob

Thanks for your advice and guidance. The problem is resolved. There was some issue at the partner server. After they fix the issue, I managed to send the message over and receive MDN. Thanks again for your help

Hi Janietsy,

I am glad to hear your Problem is resolved.

Thanks Rob!

Cheers,
JSree

Thats the funny thing about web services. Our group was receiving a deluge of support calls because we were publishing the http response of the end points when there was a failure. In every case that didnt include a “Chainverifier” error, the error 500 or otherwise was from the internal business layer and not from our connection to the agreed upon end point.
Any time you see this, double check the actual text of the reply. you may see vendor specific information that will tell you its not your issue. Its great to send that to them as proof. Shuts them right up.

Ah, that’s the bane of the integration team’s existence: always must prove that the error wasn’t you before others will even investigate. Even then, the integration layer gets the reputation for being unstable.