DefaultDataProvider and Unity Forms

[Marcus_Christi6]

OK.

So I wrote a Unity Automation API script for document exports to meet a requirement.  Ran into a weird issue with certain documents which I think might be something strange with the Stream property, dealt with that by removing its using statement.  But now that everything is executing, I've encountered a problem with the Unity Forms and just need to see if there's a clean way of dealing with the problem.

Since Unity Forms are not image based, you can't use PDF Provider to export them.  Default Data Provider works fine, but if you intend to export other documents that are TIFFs as PDF, that option isn't viable.

Looking for a clean way to dynamically select the right provider to export the documents based on whatever.  I've tried file type name, file type ID, file format ID, document type ID, document type name...in every instance it essentially ignores my IF...ELSE and tries to process it as a PDF every time.

Any ideas?

[Ian_Cordova]

Hi Marcus,

I curious to see why removing the using statement caused your first issue to work.  Was this something that you could reproduce everytime with any type of document?  Could you provide more details include the version you are testing on?  I would like to see if there is an bug in the software and address it if needed. 

In regards to selecting the right provider, how were you checking the file type for the document?  Were you checking the file type off of the Unity DocumentType object or off of the rendition of the current document?  If you were checking the file type off of the DocumentType object, you are going to get the file type as it was configured in OnBase configuration.   By doing the following, you will get the actual file type of the document you are working on.

Rendition rendition = document.DefaultRenditionOfLatestRevision;FileType fileType = rendition.FileType;

Thanks,

Ian Cordova

[Marcus_Christi6]

Hey Ian,

So I initially had my code written almost perfectly identical to the Programmer Guide.  Core 12.0.1.101.

What was happening was that on certain documents the client would just immediately time out.  So in a batch of 60 it would throw a timeout  once it hit a certain document but I could never tell which without process of elimination.  The document that would fail had nothing odd about it except that it was fairly larger in file size and page count than others in the batch.  Standard text files, nothing special about them.  I was actually testing on SYS Verification Reports to make sure there was nothing funky about them, but other document types did the same thing.  I'm thinking that based on the way Rob explained it at TQ, that Unity was disposing something before finishing out the batch.   

     using (Stream stream = pageData.Stream)
     {
      try {
       // Check to see if this file has already been exported
       if (!File.Exists(fullPath)){
      Utility.WriteStreamToFile(stream, fullPath); // Write the file as constructed
       }
      } 

I was working with Dan Quill on it and he provided sample code that worked where the using statement wasn't even applied.  Instead of using his I just modified my own code to remove that statement, and it works flawlessly.  One other thing was that he wrapped his entire code in the try...catch where in my case I only did it for the file write, so I changed that as well.  I don't know for a fact that it's the Stream that was the problem, but that's the line number that was choking in the Unity error.  Now that I've got it working I may go back and toy around with re-introducing the using statement with the try...catch where it is and see if I can drill down.

To the file type evaluation, I guess my question is this.  Would I need to define both the PDFDataProvider and the DefaultDataProvider, plus define two separate PageData classes (since PageData is off of the providers), plus two different path strings (Since the path uses the PageData to get the extension of the file)?  That's where it gets clunky.  It would be nice if PDFDataProvider wasn't constrained to image based documents.  I was trying to see if there's a way I could make a single call to get PDFs of everything in the batch OR somehow tell it to skip over ones that it can't export without complex evaluation (i.e. "try to do it, if you get an error, skip it, don't throw an error, and go to the next").

[Marcus_Christi6]

Update on it choking - so it seems there may be a problem with how the Programmer Guide suggests to do it - which I wrote explicitly to match.

It has:

using ( PageData pageData = imageProvider.GetDocument(rendition))

{

    // use extension from page data object

    string fullPath = String.Format("{0}.{1}", @"C:\ Test.tif", pageData.Extension);

   // Create file

   using (Stream stream = pageData.Stream)

   {

         Utility.WriteStreamToFile(stream, fullPath);

   } } 

Dan's of the opinion that the code may be  tripping over itself with the nested using statement - that somehow on larger documents it's pulling a copy of the pageData to then get a copy of its Stream, and may be having issues with it.  Haven't had time to do more testing to verify that, but it's clear the Unity Client doesn't like one of those.