I am trying to receive a file without file extension via invoking service through FTP (eg. /ns/myproject/myservice).
I know that this file is just a text file, however unfortunately, the existing b2b integration already been using a file name without any file extension (eg. B2BPO instead of B2BPO.txt). I have tried to set “text/plain *” in the mime.types file, however it has no effect (maybe because * means anything but since no file extension is not included in anything), FTPing file without extension still giving me “unable to write” error.
Does anyone know how to set the mime.types to allow receiving file without extension? or maybe I should write my own content handler, althought i don’t think my own content handler will solve the problem as webMethods reject this type of file on the spot before call the content handler.
Thank you fred, but I am a little unsure about what you meant. Do u mean that the Partner need to:
put B2BPO ;text:plain
when they FTP to webMethods server? If so, this is not an option as the partner doesn’t know how to do that in their b2b software. I am looking for a solution on webMethods side to resolve this issue.
you have to somehow force your partner to send as (B2BPO.txt)i beleive every software have capabilities of setting the file extension its matter of some little effort at their side,this is the fast way of resolution rather than defining your own content handler,since this might be urgent work at your side.
Thank you for your assistance. I am still looking for a solution at webMethods side.
The reason is because although changing the filename at partner side is rather convenient, however, this is a migration project which means the current partner already had an existing exchange with many other partners which all using the same file format and filename. It is impossible to request filename change without the partner either making effort to duplicate another program just for us or to change the entire change which will effect all other at least 5 partners.
RMG, how do i write a content handler to cater this? as webMethods receive reject such file even before its pass the handling to content handler?
How about changing where you receive the file to.
For example receive the file to c:\inbound\filename
Have another service pick it put and ftp it back to IS as filename.txt.
That way nothing changes at the partner end.
Marc–specifying the content type on the file name overrides the default mime-type associated with the file’s extension. So put foo.xml:multi-part:related will set the content-type as multi-part and not xml. There’s a similar way to do it for HTTP, but most HTTP clients can now properly include the content type and encoding in the headers.
The Integration Server requires that there be a file extension for determining what content is received. You’ll get an error for files that have no extension.
Doesn’t the customer have some script setup to properly traverse the namespace to put the file for service execution? If so that would be the one area to modify that specifically interacts with your system only.
If you still cannot get the customer to change their ftp into the Integration Server, you could pursue having the customer ftp the file into the file system and setup a file polling listener with a default content-type. This overrides any file extensions, so you’ll need to make sure that the directory location is specific for this trading partner and always has the same content.
As to not effect the change on partner side,so let customer ftp that file to a specific shared directory and set up webMethods file polling listner and so that you will have choice of using default content-type and process to the receiving service.
Please follow the above suggestions all the changes are applicable on webMethods side only to resolve the problem.
This is really Terry’s thread, but I conducted a simple test to attempt to override the content type of a file transferred using an FTP put.
In the first test, I attempted to send “test.xml” to an IS 6.1 server overriding its content type to invoke a custom content handler I had created earlier. I used the FTP client that comes with Windows 2000. I tried naming the file “text.xml:application:mdc”, “text.xml;application:mdc;” and several other combinations with no success. The MS FTP client reported file not found each time. The file itself could be transferred successfully when there was no attempt to override the content type.
In the second test I attempted to send “test.mdc” which successfully invokes my custom content handler when sent by itself. I attempted to override its content type to text/xml using the same combination of filenames plus content types. No success here either.
In summary, I have not been successful using specially constructed filenames to override content types for FTP transfers using the Microsoft FTP client.
Perhaps we still don’t have the syntax just right or maybe this is an issue with the Win2K FTP client.
Dear All, it seems everyone suggested me what I initially thought but really don’t want to do, that is to use the original FTP server that they are trying to replace. One of the reason why webMethods was the choice of migration is that IS has the ability to be FTP, HTTP, File Pooled, and even POP client. Now how do I explain myself to the client that I need a FTP server simply because the partner wont’ sent us a file with extension? How should I explain myself … Any other suggestions?
Hi Terry, we struggled with the same problem you are having and found a solution without modifying the source file name.
We have a legacy app on a mainframe that FTP’s us a file and they don’t alter the name, the specify a destination file name and a content type.
When FTPing a file to the Integration Server FTP port, the syntax of the put is:
put <sourcefile> <destinationfile>;<filecontentype>
In our example, the sourceFile name on the mainframe is called:
TFRGD.WMFO.SALESUS.GL.OUT.A
The destinationFile is:
TFRGD.WMFO.SALESUS.GL.OUT.A
The fileContentType is:
text:plain
The FTP put command they use (after doing a cd to our interface namespace folder) is:
put TFRGD.WMFO.SALESUS.GL.OUT.A TFRGD.WMFO.SALESUS.GL.OUT.A; text:plain
This tells webMethods that the content of the file is: text:plain (and it already has a mime type defined and knows how to handle it).
This works fine for us.
So I think all that is missing from the other suggestions in this thread is to specify a destination file name followed by the content type.
Anyway, give it a try.
Note: this solution is documented in the webMethods Flat File Schema Developer’s Guide (v6.0.1.)
Hello Wayne, thanks for the suggestion, I am sure your suggestion and Chris’s suggestion will work. However, again, changing the put command will require modification of partner’s program. Since this is an migration project, the partner already have this same program running for multiple partners which included my client. The only parameter in partner’s system that can be modify is the FTP Server IP, Port, Directory, Username and Password. Therefore, modification of partner program is not an option. The detail reason please refer to my post on “October 03, 2004 - 08:44 pm”
I am still looking for a solution that there require no modification on partner side. Thank you.
I don’t understand something. Can the partner not change where they’re putting the file. Rather than ns/myproject/myservice to c:\inbound.
The you can use my suggestion from above of picking up that file with another service and putting it back into Is as file.txt where you can control what file extension you use.
Sorry Chris, I see what you meant now, I mistaken that webMethods can’t access other file directory other than itself’s. After a quick testing, I can’t believe I can actually access the entire server’s file directory!! I guess now I have to set proper directory permissions on our webMethods server. Thanks Chris and sorry about overlooking your suggestion!
Wew. Got some good learning from this old thread. Now my only concern is how to make Apache recognize MIME type of files without extension. It may be a diff topic, but I’m just wondering if anybody here has an idea how to do it?
Now my only concern is how to make Apache recognize MIME type of files without extension. It may be a diff topic, but I’m just wondering if anybody here has an idea how to do it?