IDocumentStorage Attachment and Published

Discussions concerning general integration topics.

Moderator: Phil Barton

Post Reply
muhsmann
Posts: 54
Joined: Thu Jan 15, 2009 5:41 pm

IDocumentStorage Attachment and Published

Post by muhsmann »

We are experiencing some issues w/ common file names for documents that Select users are saving via the 'Attachment' method. The Publish and Save method doesn't present a problem because it appears that temporary generated file name is unique (looks like it's using a GUID or something to name the phyiscal file).
I would like to do the same kind method when a user 'Attaches' a document thru the 'Attachments & Documents History' tab. I have implementation for the interface IDocumentStorage which specifies the method SaveDocument w/ parameter of IDocumentStroageItem. What I think I need is determine if the document is being saved as an attachment. Using reflection I see the documentStorageItem of type IDocumentStorageItem - has a base of SoftPro.BusinessObjects.Core.DocumentImage which as a member DocumentImageTypeID which is has a Name of either "Published" or "Attachment" - can I get access to this information? Is there maybe another way I can determine if the document was saved using the attachment method?
Mark McKenna

Re: IDocumentStorage Attachment and Published

Post by Mark McKenna »

Could you detail the naming issues you are running into? If you've implemented your own storage system, you can "name" it anything you want in your SaveDocument method before handing us back a resource locator that is meaningful and non-ambiguous to your system. Our default file-based storage system does just that by obfuscating the name and storing that pointer/locator in the database.

Otherwise, currently the only thing that is publicly noteworthy is that an attachment would most often have a real file name as part of its OriginalLocation property since the user is navigating a file dialog and selecting one or more files. Published documents, in contrast, are auto-attached by way of the print pipeline and currently have a guid-derived name. The problem with using that sort of approach is that you're relying on an implementation detail of our print pipeline that is always subject to change over time.

Before you go down the path of picking apart our OriginalLocation data, let's see if we can better understand your use case and see if there's a preferred solution. Please provide some basic detail about what your storage implementation is doing when it receives the save call.
muhsmann
Posts: 54
Joined: Thu Jan 15, 2009 5:41 pm

Re: IDocumentStorage Attachment and Published

Post by muhsmann »

Mark,
I think all I really want to know is where the document originated in the Select client - 'Attachement' or 'Published'. Our users are using common names for files that contain completely different information when they 'Attach' documents. I could simply rename every document that passes through my storage dll but since - as you mentioned - SP already uniquely names the physical file why expend the resources to rename the 'Published' files.
Also, right now I can visually determine a Ready Doc document from an attached document in our storage system simply by the file name and renaming every document would destroy that visual aide.
As you pointed out - I also don't want to rely on the SP current file naming scheme because it could change.
Mark McKenna

Re: IDocumentStorage Attachment and Published

Post by Mark McKenna »

I still think it would be helpful for me to understand what your storage system is doing so that I can suggest the best option (especially since we don't expose the piece of data you're looking for). We already record the name of the file and its extension in the database so no matter what you do to it, we can recreate it with the same name inside Select.

Take a basic DMS implementation. The customer creates their own storage system (IDocumentStorage) and registers it. When we call SaveDocument on their implementing class, they will take the physical file being attached and stream its content into, say, a byte array that they store off in a data warehouse somewhere. They then create and return from the method a URI that contains whatever locating information is meaningful and non-ambiguous to them (perhaps a primary key guid in the URI form of dms://d4e59fc1-ca3d-df11-bda5-001ec967b471). Whatever we get in return we just store along with the original name of the file, its original extension, etc.

Later, when a user wishes to view the document, we simply call LoadDocument on their implementing class and pass it the same URI that we originally got back from SaveDocument. The customer's DMS system reverses the process and uses the locating data in the URI (the embedded guid, in this case) to find the byte storage and stream it back to us for presentation.

So... if user A has a document called "Hello.pdf" and user B has a document called "Hello.pdf" they'll exist fine side-by-side since their IDocumentStorage implementation was written in such a way as to disregard the actual name of the original file completely. The locations of the original files being attached are not retained - in fact, the attachment process can be configured to automatically delete the original file after it has been attached.
Post Reply