All-
I am not sure how to deal with this situation. So, I am asking you all. Please help.
We are sending a EDI 858 to a trading partner and they are not using webM. Its a different system. When they send the FA 997 back to us, it passes through the ISA server in the DMZ and gets posted to a gateway service, which validates the sender and then submits the document to TN. This is where I am having problems.
The post looks like this
[url]https://server/invoke/...../validate?username=user&password=password[/url]
When this service is invoked, it submits the document to TN.
From my understanding, TN is ignoring this document because of its content-type. How to resolve this issue?
I have asked the trading partner to change the content type to application/edi, but I would like to get a solution to this issue. Any help will be appreciated.
Thanks in advance.

Shazafar,

which service are you invoking to submit the data to TN?it should be
https://yourserver:yourport/invoke/wm.tn/receive.if you set the Content-Type to application/EDI before making the https request, then everything should be OK.

ramesh.

Ramesh,
The service that the partner is posting to is
https://myServer:port/inoke/Folder.subFolder/validate?username=user&password=password
This service has two additional input parameters
username and password.
The validate service checks the username and password in the URL and validates it. Once validated it invokes the wm.tn.doc.xml:routeXml service which submits the document to TN. The partner is using Content-Type;application/octet-stream to post the data and when routeXml is invoked, TN is ignoring the data.
How to resolve this?
Regards,
-Z

Shazafar,

what options have you selected in the processing rule for this document?
after the validation is done,are you mapping the edidata to node of routeXml service?
explain in detail what you are doing in your Svc.

ramesh.

Shazafar,

You can do this after validation:
1.Invoke pub.xml:xmlStringToXMLNode and map the edidata to xmldata.
2.Invoke routeXml(map the previous step node to node of routeXml).

hope this helps.

ramesh.

Also, are you certain the document is actually being submitted to TN? Normally you would be seeing at least an unknown document if there was a problem with the content type. The exception is possibly being thrown before routeXML is invoked. The IS server log might be able to shed some light on this.

Tim

Ramesh,
I am not mapping the edidata to the node of routeXml.
When I use the IS Administrator page and submit a sample via the EDIForTN page, and submit the document to
https://myServer:port/inoke/Folder.subFolder/validate?username=user&password=password
The routeXml service routes the document to TN succesfully and it invokes the corresponding processing rule, which inturn invokes the custoMap for that partner.
On the other hand, when the partner posts the document to the service URL directly,(which is set for Anonymous execute), the service gets invoked, but no document in TN.
My question is, how to handle Content-Type:application/octet-stream

Tim,
Yes, the document gets posted to TN and sender,receiver is unknown and the document is ignored by TN.
I am attaching a snapshot of the data that gets submitted to TN.

This indicates that no exception is being thrown. Server and error log have no errors in them.

application/octet-stream is the culprit. Can you tell me how to handle this?

Thank you.
-Z

Please use MsPaint to open the attachment.

Both ‘application/x-wmidatabin’ and ‘application/octet-stream’ are indicators of an unknown binary content type. This is usually an indication that the sender is not setting up the MIME document correctly. If they’re not using one of the content types that WM supports, such as application/edi-X12, the only way I know of to handle this would be to write and register a custom content handler for application/octet-stream.

Tim

Tim,
The partner insists that they do the same with everyone else they send documents to.
Can you give me an idea hoe to write and register a custom content handler for this content type?
Thanks in advance!

If the partner is transmitting the same content to other systems, I would tend to suspect that the problem is not on their end. You might want to look at further troubleshooting before attempting to write a content handler for a content type you don’t even have a sample of.

Are any other partners successfully using this process, or is this the first one? Can you simulate the process yourself by submitting a transaction to the server in the DMZ from a laptop or other computer outside your firewall? If you have the partner directly invoke wm.tn:receive without username/password authentication (and set the ACL for that service to anonymous) instead of going through your gateway service, do you still have the problem? Have you tried saving the pipeline and different points in the process to try and pinpoint when things go wrong?

These are the kind of things you might want to try before going the content-handler route. I have not had to write such a service myself, but there is an e-zine article on this site about it: [url=“wmusers.com”]wmusers.com

HTH,

Tim

Hey Tim,
I got it to work. There is a mimes.types file in <integration>/lib folder and it was missing the application/octet-stream entry.
I added this to the file and used streamTobytes and bytesTostring as the first two steps in my flow.
This extracted the EDI string and viola!!!

Thanks for all your help.
-Z

Good news! Thanks for posting the solution. I’m sure this will save someone else a lot of trouble somewhere down the line.

Tim