NativeDataProvider vs. DefaultDataProvider

[Adam_Ryman]

The API Team often sees confusion with when a developer should utilize the DefaultDataProvider versus when they should utilize the NativeDataProvider. In certain scenarios, it is correct to utilize the NativeDataProvider where in other certain scenarios, it is correct to utilize the DefaultDataProvider. In this article, we will discuss some of these scenarios as well as how we can properly choose which data provider to leverage.

Data Provider Overview

The most common business case for utilizing a data provider in the API is to export a document out of the OnBase system. The different providers correspond to how we want to pull the document out of our OnBase System. For example, if I wanted to pull an image document as an image I would utilize the ImageDataProvider. If I wanted to export that same image document as a PDF, I would use the PDFDataProvider. So when would we want to use the DefaultDataProvider and NativeDataProvider? NativeDataProvider – The NativeDataProvider will attempt to pull the document exactly as it exists on the OnBase diskgroup. For example if we have a .jpeg file on the diskgroup, the NativeDataProvider will attempt to pull the document as .jpeg. DefaultDataProvider - The DefaultDataProvider will attempt to pull the document in whatever file format the document type is configured to handle. For example if we have a .jpeg file on the diskgroup but the FileType if the document is "Image File Format", the DefaultDataProvider will pull the document as if we were utilizing the "Image Data Provider" which will route the document through an external snowbound library. The document will be returned as .tif because of the snowbound library.

Limitations

The Default Data Provider has been fine-tuned to auto-detect what the best route for extraction should be for your given document, and therefore we should utilize the DefaultDataProvider whenever applicable. What this means is we should only use the NativeDataProvider in scenarios where we have to get the document exactly as it is on disk. There are scenarios in which you will not be able to use the Native Data Provider, and trying to do so will result with an exception advising you to use the DefaultDataProvider. Some of these scenarios include:

• Using the NativeDataProvider on html documents
• Using the NativeDataProvider on xml documents
• Using the NativeDataProvider with documents that have had a page deleted or a page deleted
• Using the NativeDataProvider with documents that have been altered such as being rotated in the OnBase System

If it has been determined that you need to get a document from the system exactly as it is in the diskgroup, there is a way that we can properly check to see if a document can utilize the NativeDataProvider. From the Rendition object we have a method called GetNativeFormatAllowed(). This method will return a boolean stating whether or not you can use the NativeDataProvider with that given Rendition.

Example

            Document document = app.Core.GetDocumentByID(101);            Rendition rendition = document.DefaultRenditionOfLatestRevision;            if(rendition.GetNativeFormatAllowed())            {                NativeDataProvider nativeDataProvider = app.Core.Retrieval.Native;                using(PageData pageData = nativeDataProvider.GetDocument(rendition))                {                    // Native Format Retrieved                }            }            else            {            	DefaultDataProvider defaultDataProvider = app.Core.Retrieval.Defaul;            	using (PageData pageData = defaultDataProvider.GetDocument(rendition))                {                    // Default Format Retrieved                }            }

In some scenarios, there are limitations of using the DefaultDataProvider. The main limitation is that if we have an image stored that is not .tif, the DefaultDataProvider will return the document as .Tif and therefore the document will increase in size. As a workaround, the ImageDataProvider as well as the PDFDataProvider will provide the developer more functionality for fine-tuning how a document is retrieved from the system.

In Conclusion

In most business cases, the DefaultDataProvider should be used if applicable. This will ensure that a proper retrieval is made and that the document is extracted from the system in a proper format. For scenarios where a document needs to be pulled from the system exactly as it exists on the OnBase Diskgroup, we will always want to verify that this is a document that we can properly utilize the NativeDataProvider. We can do this using the Rendition.GetNativeFormatAllowed() method. If you believe that, you need to utilize the NativeDataProvider but are unable to, please contact your first line of API Support.

Look forward to next Monday when we'll discuss Unity API Licensing Management!  Exciting!