We have a strange phenomenon on our webMethods Server.
A trading partner of us sends a EDIINT message via AS2 requesting a synchronous MDN. This process works well. Message is ok and MDN sent back.
If I check in the Trading Network, I see the sent MDN:
[B]AS2-From: AS2MMK
AS2-To: AS2ARCID
[/b]AS2-Version: 1.1
Message-ID: <2686804.3631259143921068.JavaMail.webmethods@blabla.com>
Content-Type: multipart/report; Report-Type=disposition-notification; boundary="----=_Part_71_31394696.1259143921065"
------=_Part_71_31394696.1259143921065
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MDN for -
... [I][Rest of the message cut][/i]
And now the problem: Although the MDN contains AS2-From and AS2-To in its first two lines, the partner does not receive them (The partner uses a BizTalk server if that is of any help).
The error-message on his side is:
It seems that the first to lines are cut/removed when sending the MDN to the partner (over HTTP).
Since the whole process uses flows/services provided by webMethods, I cannot (and don’t want to) modify anything.
Does anyone have an idea how I can force webMethod to also provide AS2-From and AS2-To “over the wire”?
Not likely its issue on WM side.
increase the logging level and do a test, make sure it’s not WM that’s removing the From and To field.
Also turn on logging on bizTalk side, it may be removing it.
Thanks for you answer!
However, I fear that it is somehow a wm issue. We sniffed the HTTP response from wm on network level.
As opposed to what is shown in the MDN in the trading network, the HTTP response starts with:
HTTP/1.1 200 OK
Set-Cookie: ssnid=; path=/;
Content-Type: application/EDIINT; charset=UTF-8
Content-Length: 888
------=_Part_54_32303598.1258452976896
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MDN for -
[I]<rest of response omitted>[/i]
I will try with increasing the log level. Let’s see if we can get a hint out of that.
No, we neither know the root cause, nor was the webMethod support able to tell us what the problem is (and how to solve it). The only advice the wM support could give us, was to use asynchronous MDN instead of synchronous.
For testing, I even wrote an extra sendMDN service (based upon wm.EDIINT.rules:sendMDN) and explicitly added AS2-To and AS2-From headers to the response by means of the java API. At the end of the service the headers were there but afterwards, they magically disappeared again.
This is really annoying.
It seems that the library/package whatever, which constructs the HTTP response does what it wants and is not really controllable. We even had another issue, where the HTTP response of wM contained problematic cookie information (something like: Set-Cookie: ssnid=317bc000931a11de8e518db04e3e3dbf; path=/; HttpOnly
)
See: [URL]wmusers.com Unfortunately, the service in question was wm.EDIINT:receive, which we did not want to modify in any way.
Thanks for the reply. Just a FYI… we use biztalk on our side and the partner uses webMethods… we recently learnt that the partner had a WM update that strips the AS2 headers randomly. The partner had since then rolled back the WM update and things were back to normal. Hope you get your issue resolved soon.
Hi!
Thanks for that info. I’m still in contact with the support regarding this issue. Maybe we can still solve it. If so, I’ll post the solution.
Could you tell please me whether the update on your partner’s side was an update from one version to the next, e.g. from wM 6.5 to 7.1 or just some minor updates/patches in some modules?
We are having similar issue, after we upgraded from wm 6.1 to 7.1.2. I am still not sure if that is something with biz talk. The reason for this thought, is it is working fine when i sent some transaction from our development system to UAT system. So looking at above descriptions, when you sniff the packates; like to know if this for every transaction that is being posted to trading partner and all the MDN are having this issue or only MDN going back to biztalk. We trade with several trading partners and no one had this problem, except the trading partner using biztalk.
There is finally a solution to the problem discussed in this thread (tracked down and solved by the software-ag support and R&D in collaboration with wireshark and me ).
The problem is described as follows:
After this conclusion from the R&D department of s-ag, we got an inofficial patch. We installed that patch and with it the problem no longer occurred, in other words, with this patch also documents sent from a BizTalk server can handle the synchronuous MDN sent back by webMethod.
The support informed as that
(Bold accentuations in last quote by me).
If you cannot wait until the fix, try to ask your partner to send you their request without the “Expect: 100-continue” header in the request.
).