GlobalSearch Connectivity
- Brian Banet
Version 3.0 introduces a new communication model between GlobalCapture and GlobalSearch which tracks document state and controls the availability of GlobalSearch documents for import into GlobalAction workflows.
When GlobalAction processes are created, deleted, or updated with queue information, GlobalSearch is notified of the state. GlobalSearch uses this state information to control its own user behaviors, and leverages it to control a document's “lock state”.
GlobalSearch 6.3.108 is required for proper operations between products. Customers should upgrade GlobalSearch prior to upgrading GlobalCapture to version 3.0.
Registration
When GlobalCapture is upgraded, or installed in an environment where GlobalSearch is present, it will attempt to register itself with GlobalSearch. Alternately, when a GlobalSearch API portal is created, the portal will trigger a registration event with the targeted GlobalSearch instance.
When Capture first registers with a search instance, it will create a link to the Capture instance’s Batch Portal in the Links menu.
Lock Synchronization
When GlobalCapture 3.0 starts for the first time, it will synchronize process data with GlobalSearch. The data/time of this event is recorded in the GlobalCapture system database, SSSystem table.
GlobalCapture and GlobalSearch, under normal circumstances, should remain aware of each other and actively communicate about documents going in and out of processing status in workflows. As a fail safe, the GlobalSearch API Portal, configured in GlobalCapture Admin > Portals, has an option to “Resynchronize GlobalAction”.
This button clears all GlobalAction document locks and regenerates them based on an internal understanding of which GlobalAction documents are actively processing within engines. If users suspect that there is a desynchronization, symptomized by incorrectly locked processes within GlobalSearch, or documents failing to import, they should click this button.