Revisions, Renditions, and DefaultDataProviders...

[Chad_Eddy]

I'm trying to make sure I'm understanding the definitions of renditions and revisions and to verify I'm understanding the ImageDataProvider, DefaultDataProvider, and PDFDataProvider.Revisions - these are alterations to an existing document. So they may import a document and save it, then later alter it and resave it. Each of these is a Revision correct? A document can be configured to now allow multiple, in which case there is only ever one.Rendition - These are a version (Revision???) of a file saved as a different file format. Would this be PDF's, images, etc?XYZDataProvider - Converts a rendition from the saved file format to the format of the DataProvider? I've noticed that when I call DefaultDataProvider.GetDocument on a file that is a pdf, it returns immediately from the call and takes a while writing the file. Where if I call DefaultDataProvider.GetDocument and only a .tif file exists, it will time out if the file is too big as it waits on that result too long (where the pdf doesn't, so has never timed out for me.) So I'm trying to make sure I'm understanding these terms and what the objects do.Thanks for the assistance!Chad

[Tyler_Sorber]

Hi Chad

I definitely think you are on the right track. 

Renditions are more-or-less a different FileType of a Document.  For example, you can have an Image File Format Rendition, PDF Rendition, Text File Format Rendition, etc.

Revision are different edits to the same Rendition of a Document.  I would not necessarily use the term 'Versions" because that can be used in a completely different context in OnBase in regards to a Document.  An example of Revisions would be if there is an Image File Format Document.  The Original Document is a Revision; if you were to add a redaction or additional pages to the document, this will create a new Revision.

The tricky part of your question is in regards to the different DataProviders.  The DefaultDataProvider will take the Default FileType and export the Document as that Type.  I would be interested in what the Default FileType for that DocumentType is.  This may be attempting to make a conversion on the TIFF Document that is not supported.  Could you provide some additional information on this situation?  Do you have any issues with the ImageDataProvider or PDFDataProvider?

[Chad_Eddy]

Thanks! I play on the backend of this and am not sure what they have configured as the DefaultFileType for the documents - can I query the database for that info? I can always ask the main front end user as well and see what they say. I can see that when I query the database, some documents are pdf files, some are tif files, and some documents have both. When I use the DefaultDataProvider, it seems to give me the pdf document by default, and if that is not there it gives me the tiff file. We don't have any really large PDF's, but I have successfully retrieved a pdf that is around 300MB in size. As I said in my initial post the DefaultDataProvider.GetDocument() executes and goes to the next line immediately and never times out if there is a PDF file to get. If it's a tiff, the DefaultDataProvider.GetDocument() hangs until it has apparently retrieved the entire file, and times out around the 105 second mark. Other than that, I have been able to use the DefaultDataProvider, ImageDataProvider, and PDFDataProvider on all the files with the only difference being that the PDFDataProvider produces a much smaller file (5-10 times smaller). I was thinking of changing my code from using the DefaultDataProvider to the PDFDataProvider because of that, and sometimes it seems to get some larger tif files without timing out, but other times not (I have to test this more). Does the PDFDataProvider convert whatever file type is stored to pdf?Here is a query that I alter a bit as I try to find different file sizes and types:select distinct item.itemnum,item.filetypenum,item.imagetype,item.filepath,item.filesize/1048576 as item1MB, data.itemname,data.itemdate, item2.filetypenum,item2.filepath,item2.filesize/1048576 as item2MBfrom hsi.ITEMDATAPAGE itemjoin hsi.itemdata dataon data.itemnum = item.itemnumleft join hsi.ITEMDATAPAGE item2on item2.itemnum = item.itemnumand item2.filetypenum <> item.filetypenum

[Tyler_Sorber]

If the Default FileType is PDF, it makes sense that the conversion is almost instantaneous for PDF Documents, as the file would not go through any conversion since it already has a PDF extension. 

In OnBase14, control of the size of the file and quality of the file were given to the developer through the ImageGetDocumentProperties and PDFGetDocumentProperties with options such as the ImageContentType Enum and CompressionQuality Property respectively.  These properties would help minimize the size of the Document that is being converted or written to disk.  More information and details on these options are available within the OnBase SDK.

As far as the time to convert a TIF to a PDF, it should not be taking 100+ seconds to complete this conversion.  Diagnosing this issue is by far outside the scope of this forum, so I would suggest contacting your first line of support.  Some things to provide them would be the size and type of the initial Document, how the Document was imported into OnBase, as well as the code performing the conversion.

[Chad_Eddy]

Our front end user said that some are defaulted as pdf and others as Image. I can see the PDFGetDocumentProperties, but it only has the following properities (Overlay, OverlayAllPages, PageRanges), so we probably need an updated version to get the CompressionQuality. I'm assuming that if we upgrade at some point and have access to that property, that we state a compression quality and instead of getting the whole 50MB image (as an example), we could reduce that to something like 5MB by setting the CompressionQuality high (at the loss of quality) and retrieve the data substantially faster correct? I'm sure my manager would be interested in that possibility at some point, so I want to make sure I'm understanding the possibilities correctly.I guess I was assuming that it wasn't the conversion that was taking the time, but the actual transfer of data when retrieving the tif file, but that was just a guess. Thanks!