Sending applicationEDI Attachment

I want to send email (from MS Outlook) to IS with an “application/EDI” attachment. The subject line of the email contains the name of the wm service I want to run to process the attachment. The wm service tries to run but it does not recognize the attachment as “application/EDI” so it errors. My question, how do I state within the email that the attachment is “application/EDI”? Thanks for any input.

Rebecca - you would need access to the email headers to set the attachment mime-type. Outlook doesn’t support this this. So here is what you can do instead:

On your Integration Server, go to the IntegrationServer4\lib directory and edit the mime.types file. Add a line for your mime type (application/EDI) and assign a file extension (“edi” for example). Restart the server.

When you send your attachment, just make sure the file name has the correct extension (myFile.edi for instance).

Hope this helps,

Thanks, Theo. This is working now. I have another question about attachments. Just like the application/EDI puts ‘edidata’ in the pipeline, how do I find out the input stream for other kinds of files? Is this documented anywhere?

Rebecca - what appears in the pipeline is dependent on the content handler invoked. The only special one I can think of immediately is the XML handler, which places an object called node in the pipeline. The CGI handler (for HTML forms) places strings with the form input names unless the input is called $xmldata. $xmldata goes to the XML handler, and if it is XML ends up as node.

If you ever want to know for sure, there are some services in the WmPublic package that you may find helpful: pub.flow:savePipeline - save the pipeline to a named memory location
pub.flow:savePipelineToFile - saves the pipeline as a file in the IntegrationServer4/pipeline directory
pub.flow:restorePipeline - restores a pipeline from memory
pub.flow:restorePipelineFromFile - restores from the file

If you save to memory, the pipeline is local to your Developer session, and goes away when you close the session. The file system ones are available to anyone.

So you can save the pipeline as the first step in your flow, and then run the corresponding restore to view the actual contents at runtime. Then you’ll know exactly what to expect.

Hope this helps,