Question / Problem:
Between doing Image Processing in an import source or as a process activity, are there reasons to choose one over another?
Answer / Solution:
Yes, it is generally preferred to do image processing in the actual process, rather than the import source. The high level reason is that it is better to have a less complicated import with the least possibility of error, and then do any additional work within the actual KTA process.
Image Processing in an Import Source
One of the places that a Scan/VRS profile can be used for image processing is within the settings of an import source:
When image processing is configured this way, the image processing occurs before a job is created in KTA, and this has a number of implications.
Note that setting a Scan/VRS profile to be used for mobile/MFD devices (process properties > Capture > Device) works in the same way as a profile set in an Import Source, and thus has the same downsides.
Transformation Servers must be configured for synchronous requests
The Transformation Servers need to be configured for synchronous requests. This is enabled by default but is important to note. The Transformation Servers also need to allow access to the port used for synchronous requests, which is 9001 by default. It is possible to configure individual Transformation Servers to handle:
- Synchronous requests in addition to processing activities (default, EnableSynchronousCalls=True, SynchronousOnlyProcessing=False)
- Activities only (EnableSynchronousCalls=False, SynchronousOnlyProcessing=False), or
- Synchronous requests only (EnableSynchronousCalls=True, SynchronousOnlyProcessing=True)
Transformation Servers must be available at the moment the import occurs
The import process will make a synchronous request to one of the available Transformation Servers in the environment. So they need to be available and have capacity for immediate requests. If the Transformation system needs to answer a synchronous request while already processing a full load of Capture activities, it may have subpar performance, or even lead to a timeout error.
If no Transformation Servers configured for synchronous requests are available at time of import, then import will fail with the error: “No instances of transformation server are registered with TA or running at this time”
Because image processing configured this way is happening before a KTA job is created, troubleshooting will require looking at the messages in any one of the Message Connectors in the environment. This is a tedious process compared to working with a suspended job within KTA, especially if there are multiple instances of the Message Connector that need to be searched.
Use an Image Processing Activity Instead
This extra complexity can be avoided by taking the VRS profile off of the import source and instead use an Image Processing activity in the process. That way it happens as part of the job and does not require a synchronous request. This is generally the preferred configuration.
For example, imagine all Transformation Servers in an environment were temporarily unavailable. At this point all documents for import sources using image processing would start to show errors in the Message Connectors. If the “Keep failed” option is enabled, and volume is high this could even mean that the Message Connector eventually runs out of space, leading to even more errors. Users in KTA would only know that they are not seeing new jobs, but not know the reason. Once Transformation Servers are available again, new imports would start to work. However administrators would need to know to either reactivate messages in the Message Connectors (if “Keep Failed” option is enabled), or to send these documents again from the original source.
In the same scenario when using an Image Processing activity in the process, no errors occur. Users in KTA would be able to see that the jobs exist, but are waiting for the Image Processing activity to be processed. Once the Transformation Servers are available again, jobs start processing with no other work.