We have a windows service running on a server which picks up PDF documents from our website and saves them to SPImage. The code looks something like this:
//create a new doc image so this will get added to SPImage
IDocumentImage docSP = order.DocumentImage.CreateNew();
docSP.Trustee = order.CurrentUser;
docSP.OriginalLocation = new Uri(doc.FilePath);
docSP.Description = docName;
docSP.DocumentImageTypeID = SoftPro.OrderTracking.Client.DocumentImageType.Attached;
docSP.FileType = "PDF";
docSP.SubmittedDate = DateTime.Now;
The problem is that the “Images directory” specified in SoftPro uses a mapped drive (“P:\SoftPro”) and the mapped drive is not available when the win service is pushing docs through the api.
In my code above, I’d like to be able to specify the destination directory so that I can use the full UNC path instead of the mapped drive, but I couldn’t find any way to do this. Anyone aware of any way to control the destination directory?
You cannot programmatically set the SPImage storage directory from the API, since it is an administrative setting.
A couple ideas:
1. The per-profile images directory in Select supports UNC pathing. As long as a UNC pathed directory share points to the same physical location as P:\SoftPro you should be OK. You'll end up with a mix of file:///P:\SoftPro and file://SERVER/SoftPro$ resource locators in your attachment records, but both should resolve correctly from the Select client machines without requiring any sort of data store update.
2. You can implement your own storage system to replace our default file-based one, thereby assuming complete control of the physical location, the media type, etc. That "images directory" setting is only meaningful to our default storage system, so you could do whatever you want with the physical file when the order is saved, as long as you give us back a resource locator that we can use in the future when requesting that same file content back from you as a stream. One caveat: there is a migration issue to deal with here since we do not yet provide an automated migration path when switching providers. We would be able to assist with this. While this may be overkill here, just keep in mind that the option exists.