Chronic Document Import Processing (DIP) failures

[Hans_Priepke]

We have been working with our reseller but have been unable to resolve chronic failures of the DIP service since our adoption of Hyland OnBase over the last year. Our organization uses a third party batch scanning solution that delivers files to the DIP service in a network folder. Periodically the service will stop running until someone reports a problem. The service appears to be running, but it is not processing any documents, and we haven't yet identified a way to proactively monitor this condition yet either. By all reports no diagnostic / trace information can be gathered relating to this. 

Most unfortunately, this issue is highly visible and then translates into perceptions of "my documents didn't arrive in OnBase after scanning", "our records are missing", and "workflow is not working" within our organizations user base. Our analysts and our OnBase reseller have invested significant time, and even moved the DIP service to its own application server but the problem still occurs. 

I'm hoping someone else out there has seen this issue before and could offer some guidance or direction. 

[Greg_Ledford]

Not an answer to your issue, but all of our DIP processes run from an opened instance of client (not as a service). We use Schedule Management to poll the folder for the index file and process when present. Currently, we monitor the "Awaiting Commit" DIP queue to verify process completion, but one could create a workflow (if you have the module) to accept the 'SYS Import Indexes' document type and alert if the process did not complete.

[Thomas_Reu]

This is potentially a really complex problem (potentially only solvable by your FLOS and Hyland).    

This complexity is demonstrated by the amount of significant information missing from your question.  For example: do you have a dedicated server with the onbase client installed to run this process?  Optimally, this would be the only service running on the server.  Also, the onbase service account that is running this should only be used for this and nothing else.  What does the rest of your network look like?  How stable is it?  Are you bringing down the database server for updates?  This would break the connection in the service.  These are just examples, but hopefully you can see how challenging this would be to troubleshoot.  Also, we know nothing about the DIP file, it's size, etc.  It would be helpful to attach at least an example, of what an average DIP file might look like.  How big are the files being imported?  How is the DIP scheduled and how often is a new DIP file hitting the system.

[Hans_Priepke]

I appreciate this is a highly complex issue and my core question is really "has someone else who has experienced this issue and can they help us?" But we are desperate. I can provide you with more details.

We are running OnBase 15, Windows 2012R2 application servers (3...two running OnBase web servers and a new third one only running the DIP process to isolate it). We are not bringing down the database for updates when this occurs; this only happens during some pre-planned maintenance periods (this is true of all servers in our environment). In addition the SQL server is actually part of a SQL 2012 AlwaysOn high availability farm. The service account the "Hyland Import Process" is running under uses a domain account that is used by other Hyland application servers - I'm not sure why it would need to have a separate service account (we can try that). The DIP files are regular batch scanning deliveries; we ask users to limit the number of documents per patch to under 100 and usually in the 50-60 document size with the appropriate indexing information in the DIP file. I looked at a few in process right now and the text files were like 1-2k. I believe the DIP is scheduled to run every 5-10 minutes and import. New DIP files are arriving constantly throughout the work day - we have scanning stations in over a dozen major departments at our institution.

As for our network topology, that would be a long discussion. These servers all reside on the same VLAN and TCP communicate with each other. They do not have any firewall rules that would prevent files being delivered over SMB, nor is there IPSEC implemented on these servers. I'm curious, with this process running on one Hyland server, what network communications need to occur once the DIP files and documents are delivered besides to the database...it must ask one of the other application servers to write data into the database and go into the permanent...are you thinking communication problem at this layer?

[Justin_Fandl]

Hans,
This may be a shot in the dark so to speak, but for the DIP processing location, is this a UNC path or a mapped drive? I have seen some strange behavior when using a mapped drive before and had much better results with specifying the path as a true UNC path i.e. \\machinename\share vs. \\D$\Share.
Might be worth a try if you're currently using a mapped drive. Has your FLOS engaged Hyland by chance?