Hi,
I have transmitted to my vendor who is using webMethods Trading Network. I’m using Seeburger AS2 to transmit a doc to them. However, they cannot processed the payload as they claim there are concatenation of strings after content-type
payloadMimeHeaders
text/plain; name=QATest.txt
*QATest.txt is the test file that I’m sending to them.
The vendor cannot process it…somehow they can only accept
text/plain
Please help how should I resolve this matter in webMethods or Seeburger AS2
While the use of the name parameter is “discouraged” for content-type in favor of the content-disposition header, it shouldn’t be causing a problem.
The complaint about “concatenation of strings” seems odd. Can you get the specific error messages or behavior they are seeing and post it? Also helpful would be the version of IS/TN they are using.
refer attached for the screenshots
Looking at the screen shots things appear to be fine. Can you post a screen shot with the payload line selected? Perhaps the entire EDIINT doc? Does the content shown for payload match what was sent?
What behavior are they not seeing that they are expecting to see? If the payload is not EDI then they need to set up a TN doc type and processing rule to do something with it.
They claimed that because of the additional strings “name=QATest.txt” in the content type text/plain; name=QATest.txt
cause it to be “unprocessable”. They are expecting it to be clean text/plain; without “name=QATest.txt”
I suspect they have reached an errant conclusion. To be able to troubleshoot can they provide additional info on “unprocessable”? Where in the process is it failing? Does the process work if the name parameter is not present?
Yes, they claim the process will work if the name parameter is not present. I did test using FreeAS2, the name parameter is not present but somehow theirs have name parameter appeared.
Without additional information I guess I’m unable to provide additional guesses as to what may be going wrong.
the incoming document is unable to “enter” the system - it has been ignored by the recognizing engine of webMethods Trading Networks 7.1. The only feeback from the system is Unknown Sender, Unknown Receiver and subsequent processing IGNORED (please see attached image).
They believe the problem is the Content-Type line does not conform to any MIME document standards that webMethods can recognize.
Is this a new standard that Software AG is not able to support? Please give the Industry standard for this type of message. Is there any reference to rfc types?
Thanks
The content-type with a name parameter is not a new standard. In fact, it is an old one that has been deprecated in favor of content-disposition.
Are they able to take the exact EDIINT document, remove the name parameter and submit it to TN and it works?
My best guess is that the attachment is unrecognized because a TN document type for the document that was sent (QATest.txt) was not defined in TN.
This should work. I have strong suspicions that the name parameter isn’t the problem.
Can you post the sample EDIINT doc that is failing? Also, what version of IS and TN are they using? I’ll try to duplicate the issue.
Or, it may be worth opening a ticket with wM tech support.
The sample document is just a simple string “This is just a test”
They are using webMethods 7.1 i.e. IS 7.1 and TN 7.1.
They insisted
They insisted that we had supplier the filename inside “Content-Type” although Seeburger claimed they did not pass the filename inside “Content-Type” and when we tested with freeAS2 it doesn’t show any filename in “Content-Type”
As claimed by them "The correct location is to place the filename in the Content Disposition header field. As far as RFC1521 standards is concerned, this NAME field should not appear in CONTENT-TYPE.
The incoming data cannot be recognized by the Trading Networks recognition engine. All subsequent processes such as assigning the document types cannot take place. The root cause is the incoming data does not adhere to any current standards."
I’ve provided as much insight as I can. I understand that they keep saying the name parameter is wrong but I’m not so sure.
Yes, the content-disposition header is the “right” place to put the filename, but 1) the content-type header used to be the “right” place (and depending on what you read, is still okay for backwards compatibility); 2) unrecognized parameters are supposed to be ignored.
IMO, the issue is on the TN side and is a configuration problem. They should open a ticket with wM tech support to help them resolve this. TN recognition isn’t magic–the configuration has to such that a TN administrator effectively tells TN how to do the recognition. The name parameter isn’t impeding nor enabling that, IMO.
If you can post the EDIINT document you’ve been sending them, I can do some checks of my own to see what is going on.
The EDIINT document is just a text file contains 1 line of string
“This is just a test”
I appreciate your feedback on this matter. I’ll update you on this matter once the partner has feedback to me on your comments which helps a lot in this matter
thanks
Can you provide the entire document, with headers, boundary markers and all? It may turn out that I’m wrong and I’d like to check things out with exactly the same data that they are using.
The file is supposed to be a csv file with no headers, boundary markers. It is pure csv file. They admitted that they can open the file manually
Sorry for the confusion. By document I meant all the MIME-related stuff that wraps the file, including the headers and content part boundaries. Something that looks like this:
[FONT=Courier][SIZE=1][FONT=Courier][SIZE=1]Content-type: multipart/signed; micalg=SHA-1; protocol="application/pkcs7-[/size][/font][SIZE=1][FONT=Courier]signature"; boundary="----=_Part_0_409673203.1011470256738"[/font][/size]
[LEFT]
[SIZE=1][FONT=Courier]Disposition-notification-to: [/font][/size][SIZE=1][FONT=Courier][URL]http://Administrator:manage@localhost:5555/invoke/wm.EDIINT/receive[/URL][/font][/size]
[SIZE=1][FONT=Courier]Disposition-notification-options: signed-receipt-protocol=optional, pkcs7-[/font][/size][SIZE=1][FONT=Courier]signature; signed-receipt-micalg=optional, SHA-1[/font][/size]
[SIZE=1][FONT=Courier]AS2-From: 123456789[/font][/size]
[SIZE=1][FONT=Courier]AS2-To: 987654321[/font][/size]
[SIZE=1][FONT=Courier]Message-ID: <1687657971.1011470256928.JavaMail.zhouz@zhenzhou>[/font][/size]
[SIZE=1][FONT=Courier]Content-Length: 2534[/font][/size]
[/LEFT]
[LEFT]
[SIZE=1][FONT=Courier]------=_Part_0_409673203.1011470256738[/font][/size]
[SIZE=1][FONT=Courier]Content-Type: application/edi-x12[/font][/size]
[SIZE=1][FONT=Courier]Content-Transfer-Encoding: binary[/font][/size]
[/LEFT]
[LEFT]
[SIZE=1][FONT=Courier]ISA*00*ssssssssss*00*rrrrrrrrrr*ZZ*123456789 *ZZ*987654321[/font][/size]
[SIZE=1][FONT=Courier]*961007*2013*U*00200*000000001*0*T**[/font][/size]
[SIZE=1][FONT=Courier]GS*PO*S1S1S1S1S1S1S1S*R1R1R1R1R1R1R1R*961007*2013*000000004*X*003050[/font][/size]
[SIZE=1][FONT=Courier]ST*850*000040001[/font][/size]
[SIZE=1][FONT=Courier]BEG*00*BE*2a*43324234v5523*961007*23tc4vy24v2h3vh3vh*ZZ*IEL*09*RE*09[/font][/size]
[SIZE=1][FONT=Courier]...[/font][/size]
[SIZE=1][FONT=Courier]SE*22*000040001[/font][/size]
[SIZE=1][FONT=Courier]GE*1*000000004[/font][/size]
[SIZE=1][FONT=Courier]IEA*1*000000001[/font][/size]
[SIZE=1][FONT=Courier]------=_Part_0_409673203.1011470256738[/font][/size]
[SIZE=1][FONT=Courier]Content-Type: application/pkcs7-signature; name=smime.p7s[/font][/size]
[SIZE=1][FONT=Courier]Content-Transfer-Encoding: base64[/font][/size]
[SIZE=1][FONT=Courier]Content-Disposition: attachment; filename=smime.p7s[/font][/size]
[SIZE=1][FONT=Courier]MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYIBuDCCAbQC[/font][/size]
[SIZE=1][FONT=Courier]AQEwXjBZMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOd2ViTWV0aG9kcyBJbmMxDzANBgNVBAsTBlBE[/font][/size]
[SIZE=1][FONT=Courier]IEVESTEgMB4GA1UEAxMXRURJSU5UIHNhbXBsZSBTZW5kZXIgQ0ECAQEwCQYFKw4DAhoFAKCBsTAY[/font][/size]
[SIZE=1][FONT=Courier]BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTcyMDM4MDhaMCMGCSqGSI[/font][/size]
[SIZE=1][FONT=Courier]b3DQEJBDEWBBQKbJZgrh/bit8BFmv1fuaWf40PjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG[/font][/size]
[SIZE=1][FONT=Courier]SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUr[/font][/size]
[SIZE=1][FONT=Courier]DgMCBzANBgkqhkiG9w0BAQEFAASBgKRrXO1tX3oFfLTgJwuoWKhygMQzdyNpX1Z4xU7kjDqYS8gs[/font][/size]
[SIZE=1][FONT=Courier]yvaRSl0s7d4wA3N1CLGQUk87yRCFqoJPygrXyCI0kaGh1Ny61GxkPHuQ2cP54m11Wzgq9OGhaRba[/font][/size]
[SIZE=1][FONT=Courier]TJu8HWB1ETFBML+wIBGunkRcR3s5mEpxINmflEYNZlxmf78ZAAAAAAAA[/font][/size]
[/LEFT]
[SIZE=1][FONT=Courier]------=_Part_0_409673203.1011470256738[/font][/size][/SIZE][/FONT]This is obviously an example with EDI payload and a signature so the example we’re trying to troubleshoot will differ, but this shows the data I’d like to see to be able to troubleshoot. Note that the “envelope” has a content-type as does the payload.
Maybe I can test with you? BTW, refer below for the content (before and after encryption)
before Encryption
Message-ID: 32391332140171361242872104234.SEEBURGER.Administrator@192.168.1.22
Subject: AS2 message (QATest.txt)
Disposition-Notification-To: TNEXRCV3QA
AS2-To: 9300607999B2B
Date: Thu, 21 May 2009 02:15:04 GMT
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1, md5
AS2-From: TNEXRCV3QA
AS2-Version: 1.1
Content-Type: multipart/signed; protocol=“application/pkcs7-signature”; micalg=sha1; boundary=“----=_Part_2_10766816.1242872104234”
------=_Part_2_10766816.1242872104234
Content-Type: text/plain; name=QATest.txt
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=QATest.txt
This is just a test
------=_Part_2_10766816.1242872104234
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=“smime.p7s”
Content-Description: S/MIME Cryptographic Signature
------=_Part_2_10766816.1242872104234–
after encryption
Message-ID: 7118607208914801242871569203.SEEBURGER.Administrator@192.168.1.22
Subject: AS2 message (QATest.txt)
Disposition-Notification-To: TNEXRCV3QA
AS2-To: 9300607999B2B
Date: Thu, 21 May 2009 02:06:09 GMT
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1, md5
AS2-From: TNEXRCV3QA
AS2-Version: 1.1
Content-Disposition: attachment; filename=“smime.p7m”
Content-Type: application/pkcs7-mime; name=“smime.p7m”; smime-type=enveloped-data
ublic Key
rosman71, I’ve sent a couple of private messages to you to see if we could troubleshoot this. Let me know if this is something that still needs attention.
The problem is on your customer side. They have to setting on Intergartion server. They can refer to User guide.
As I did , there is no problem here.