UPDATE: Please pay attention to the new Intelligent Workflow Runner API. There can be cases, when an application requires a functionality, which
- runs in the background;
- runs for a long or unlimited time;
- usually do not have an interactive UI;
- do not have anyone to intervene in case of a problem.
In such a case a possible solution can be a 24/7 module integrated into the main application. Below there are some recommendations to build such a module. In general the following architecture can fulfill the requirements:
- It is crucial to put the OCR functionality (the worker module) into a separate executable, which can be run in a separate process.
- This worker module can be controlled through a small amount of high-level commands, e.g. getting page count, recognizing a page, recognizing a document.
- A thin 24/7 primary layer can control the worker module and can restart it if it is necessary using interprocess communication (e.g. pipe, shared memory and semaphores, TCP/IP, .NET remoting).
- It can be useful to add a watchdog (monitoring) functionality to the primary layer. The timeout handling of the CSDK alone might not be enough.
- Even detected errors may leave the process in an unstable state. Even a warning may be a sign of an unstable internal state. So a restart can be reasonable:
- at a timeout,
- after errors,
- after warnings,
- regularly (after a few thousand pages).
- It can be useful to implement a Quit command on the secondary layer in order to terminate the worker process in a clean way. On the primary side the function
TerminateProcess()should be called only as a last resort. - After restarting due to an error, or timeout it can be useful to try the recognition again for the latest page or document causing the error.
More details can be found in 24x7Guide.pdf.