x

Situation: EDI messages arrive at iSM to be processed. The inquirer wants to locate incoming messages with specific characteristics.

Solution: Configure the Audit Manager to store the incoming messages, and the Indexer to index those messages. Incoming messages are resolved through the Audit Manager copies.

x

Situation: The user wants to search every record in an RDBMS-based warehouse, with new records indexed as they are added. The warehouse records contain a field for date/time of update.

Solution: You do not want to duplicate the warehouse in the Audit Manager, so use Direct Indexing.

Configure the RDBHWM (Relational Data Base High Watermark) Listener to scan the warehouse, using the date/time of update value as the high water mark. As each record is read, pass it to the iEI Feeder agent to index it into the search engine (for example, Google). Set the feeder to add the key(s) required for retrieval of the record to the search engine URL.

Configure the listener to accept the query URLs from the search appliance and pass them into the XDSQLAgent. Configure this agent to use the incoming URL values (they will be in the incoming request document) to configure the SQL DML select statement to retrieve the record from the warehouse.

Pass the retrieved result to a transformation agent to format HTML to return the result to the user's browser in an appropriate format.

The following image illustrates how a query is processed and transformed in a simple usage scenario.

x

Situation: A SWIFT user wants to be able to review both the input SWIFT messages and the current status of the warehoused records.

Solution: Use both Audited Manager Indexing and Direct Indexing. Audited Manager Indexing enables you to locate the incoming SWIFT messages that were processed, while Direct Indexing enables you to check the data warehouse.

Configure the Audit Manager to store the incoming messages, and the Indexer to index those messages. Incoming SWIFT messages are resolved through the Audit Manager copies.

Ensure that the update service executed by the process flow maintains the keys of the records that are actually updated. It is recommended to store these in special registers (process flow variables) or have the update service construct an emitted document containing this information.

Pass the update keys to the iEI Feeder agent to index it into the search engine (for example, Google). Set the feeder to add the key(s) needed for retrieval of the record to the search engine URL. Also be sure to add the Transaction ID (TID) special register to the URL.

Configure the listener to accept the query URLs from the search appliance, and pass these into the XDSQLAgent. Configure this agent to use the incoming URL values (they will be in the incoming request document) to configure the SQL DML select statement to retrieve the record from the warehouse. Add the TID from the URL to the data.

Pass the retrieved result to a transformation agent to format HTML to return the result to the user's browser in an appropriate format.

The user can use the TID that is reported to access records in the Audit Manager to research any activity that affected this warehoused record.

x

Situation: The user wants to search a database for a record, but also wants to know if there are activities anticipated for the located records.

Solution: This situation is similar to the one in Researching Records Affected by an Incoming Message. However, assume that there is a correlation ID known when the record is originally indexed through the Direct Indexing mechanism. Add this correlation ID to the search engine URL (for example, Google).

When constructing the result of the query, divide the incoming query into two parallel edges (threads or operations). The first retrieves the data from the warehouse. The second uses the correlation ID taken from the query URL as input to the activity log driver.

Send both edges into the JOIN service, which makes a single document of the correlation inquiry and the retrieved warehouse record. Next, pass the joined information to the transform service to construct the final reply.

The following image illustrates how a query is processed and transformed in a usage scenario involving a SQL query and an ID lookup.