Low-Speed Capture
Figure 1 describes how the Transaction Server fits
into a low-speed processing environment.
Figure 1. The Transaction Server in
a low-speed capture environment
Data Flow
To a large extent, the data flow for low-speed capture work is
dependent on the reject repair system being used by the client's
financial institution. The steps below describe only the data flow
from the reject repair system to the Transaction Server.
- The Archive Server is notified as a collection of documents is repaired on the reject-repair system. The repaired MICR data and images are read by the Archive Server.
- The images are stored by the Archive Server to a customer-defined location (refer to Archive Server User's Guide for information about ITSLOAD). At this time, the MICR data and the image index information for each document is sent across the network to the Transaction Server.
- Depending on the customer’s environment, this information may take two network hops -- the first hop from the Image Server to the Archive Server, and the second from the Archive Server to the Transaction Server. The total data size from the reject repair system to the Transaction Server is roughly 1K; this includes the MICR data and the image index. This is a bi-directional process, during which the Transaction Server sends acknowledgment data back to the Archive Server (approximately 100 bytes) as it receives each document.
- At the end of the reject repair process, the Transaction Server sends a 1K data record to CPCS and receives a 1K acknowledgment back. This transfer is not critical to the capture process.
To summarize, at the end of the low-speed processing, the Transaction Server contains both the MICR data and the necessary image indexes for the repaired items. At this point, the Transaction Server has no dependency on the availability of the reject repair system for repaired document image queries.