You will still want to do a save-attachment run-process to get it to the server, then once there you could execute a batch/script that executes the sftp for you....or, write a plugin that does all of it...there are many different ways to get it working, but server side script would be the simplest process.
We have a process on Windows where we create a .csv file and sftp it to a AIX server. So instead of creating the file you save the attachment like LJ LongWing mentioned. We are using Putty's pscp to perform the sftp file transfer. We have this all wrapped up in a Windows. .vbs script that we call from a filter.
What OS are you on?
For Unix/Linux you could also implement a Remote Mount of the directory on the remote server to a directory point on the local server. Then the standard PERFORM-ACTION-SAVE-ATTACHMENT will work.
Thanks All for your suggestions.
I'd like to give a chance to Fred one's.
Remote Server: Linux
Sounds nice but I've two questions:
- after creating this Remote Mount, no passwords will be needed? I mean, as a part of the Remote Mount configuration, and firstly, it must be guaranteed (via SSH, etc) that no password will be asked for, is it so?
- The standard PERFORM-ACTION-SAVE-ATTACHMENT will save the attachment directly on Remote Server?
2 of 2 people found this helpful
Correct... The connection to the remote server is all handled by the OS. To the user (or application) it is simply another directory so no password or login is needed.
I have worked with remote mounts from Linux to Linux and Linux to Sun Solaris for years with no issues
Any System Admin should be able to set it up with no trouble.
I guess you can use atrium integrator spoon as well for file transfer purpose.
Thanks, I need to explain that those attachments are retrieved automatically when a user consumes a "getUpdates" operation.
This is a WS operation that returns, for each assigned Incident, a lot of information, including all Work Infos, and for each WI, the attachments.
This can also be done directly, I mean return info and attachment (attachments 64 bit encoded), but Customer dislikes this solution.
Each integrated provider will have to ask periodically, using getUpdates, for updates (at Incident level or at WI level): the information will be returned but, for attatchments, they will have to retrieve them via sftp.
I'm not sure we could easily implement a "call" to a Spoon job to leave the attachments on sftp sever. Thus, this week, I'd like to give a try to Fred's suggestion.
Sounds to me the easiest solution (of course, with BAO, this could also be done... ;P)