Direct Indexing

In this section:

Direct Indexing enables information stored during a transaction flow to be sent to the search appliance and associated directly with a lookup in the main database. It does retrieve from the iWay Audit Manager.

To use this service, you must specify context information that is sufficient to recover the data. An example might be storing the keys associated with updated or inserted relational information. The actual lookup can be performed later by an iWay-provided component or by a service developed specifically for this purpose.

Note: By default, security is provided in the message flow. Therefore, when using direct indexing, use of the security exit is not applicable.

Caution: Under this indexing option, if the indexed data changes, the index points to either missing data or data that may have changed between the time of the index and time of the search.

Unlike Audited Message Indexing, which relies on the Audit Manager, Direct Indexing is not performed automatically. Instead, you install a service into a process flow that organizes the index update based on information in the flow. Later the lookup is performed by a service that can use the saved index information to reconstitute the data.

In this method, the document and context reaching the Direct Index service is indexed and the context is stored.


Top of page

x
Lookup

You must configure your lookup service into the process flow run by the iEI listener. Any stored attributes are made available to the actual lookup as special registers in the name space iei. For example, if you can recover the indexed record by the simple SQL select statement "select * from database where key=<value>" and you have stored the <value> as look=<value> at the time of the index, then you might configure the standard iWay SQLAgent to substitute sreg(ibi.look) into the SQL statement.


Top of page

x
Direct Indexing Steps

The steps involved in indexing a document directly are as follows:

  1. Service Manager receives the message.
  2. Message flows through Service Manager.
  3. Message arrives at the iEI Feeder service. The feeder gathers the incoming message and context and, using its configuration parameters, formats a redisplay URI; it sends the message and the fabricated URI to the search appliance.
  4. Message continues through the flow and completes normally.

Top of page

x
Searching of Direct Index Messages

A search executed through iWay Enterprise Index configured with direct indexing passes through the following sequence of events:

  1. Inquirer brings up the search page (for example, Google) from the search appliance, as shown in the following image.

  2. The search appliance searches indexed messages, selecting candidates, as shown in the following image.

  3. For every candidate that contains a secure marker, the search appliance requests identification from the user, a standard 401 HTTP response, as shown in the following image.

  4. Secure candidates and user credentials are sent to the iSM via a dedicated link, as shown in the following image.

  5. If the security exit is configured, it will process the security request. Otherwise, the listener passes the URL to the flow as a standard request with an indication that the flow must handle it as a security request, as shown in the following image.

  6. Results of the security exit are sent back to the search appliance, as shown in the following image.

  7. The search appliance presents the filtered results to the user, as shown in the following image.

  8. User selects a candidate and this choice is posted to iSM via the stored URI, as shown in the following image.

  9. Post triggers a workflow on the listener. The listener formats the request into an XML document, which can be analyzed by the workflow to retrieve the information from the actual storage location, as shown in the following image.

  10. The process flow can reformat the retrieved information for display.
  11. iSM returns the result to the user, as shown in the following image.


iWay Software