Overview of iWay Enterprise Index
Data flows throughout an enterprise in numerous ways.
Organizations communicate with external entities using EDI messages,
XML documents, and flat files; and many organizations are beginning
to use Web services to communicate internally or externally to achieve
a service-oriented architecture (SOA).
iWay Enterprise Index makes all of this data easily available
to end users. To do this, it employs iWay Service Manager (iSM)
to transform the data into a uniform XML-based format, and employs
the search appliance to index and prepare that data for secure searching
by authorized end users.
The result is a platform that enables users to execute free-form
text searches for criteria in iSM messages while regulating the
access of information.
By indexing all the values in every data field, iWay Enterprise
Index makes all content, that has passed through iSM, searchable.
Users seeking information need no longer be constrained by prescribed
systems or syntaxes, but can instead apply today's standard Web-searching
techniques — typing specific criteria such as name, product ID, customer
ID, and so on — to retrieve hits.
iWay Enterprise Index offers two approaches to indexing. Either
or both can be applied to create a complete indexing solution for
an enterprise. The two approaches, Audited Message Indexing and
Direct Indexing, are complimentary, and each is appropriate for specific
requirements.
-
Audited Message Indexing. In
Audited Message Indexing, all or specific messages flowing through
the server are preserved in the iWay Audit Manager. All or a subset
of the preserved messages are indexed, and query results are served from
the Audit Manager.
-
Direct Indexing. Messages
passing through the server may affect data in an enterprise data
warehouse. Direct Indexing can index the affected data in the warehouse,
and queries are resolved from the warehoused data.
x
Relationship of the Components
The following image shows the relationship between iWay
Service Manager and a search appliance.
In a basic search, the user, called the inquirer, types
text criteria into a standard search screen (for example, Google)
using a Web browser, as shown in the following image.
The search appliance then requests user authentication for the
inquirer, and forwards search-result candidates and user credentials
to iWay Service Manager for authorization. The search appliance
then returns a list of valid results to the inquirer. When the inquirer clicks
on the hyperlink of a valid result, iSM verifies the inquirer's
security rights. If iSM authenticates the inquirer's access rights,
then the search appliance displays the requested information.
x
The Index Filter is a standard component, configured
by the iSM administrator to send selected information to the search
appliance. Depending upon configuration, these messages can be designated
as secure or unsecure. When the search appliance encounters a secure
message in the course of performing a search, it invokes the Security
Exit.
For example, you might elect to index input and emit messages,
but not parse or to propagate encryption events. The security indicator,
whether or not the indexed item falls under security control, is
part of the configuration, and is a parameter of the listener on
which the message arrived unless specifically reset during the flow
by a provided flow object.
Every message sent to the search appliance includes redisplay
URI. This consists of the host:port of a configured listener,
along with recovery information, such as Transaction ID and message
type. If so configured, the URI will use HTTPS for the post.
x
The Security Exit used the credentials of the inquirer
and candidate message to determine which messages should be displayed
in search results. In effect, a security exit is an adapter to a
security system. Each result presented to the inquirer contains
an access URL of a Inquiry Listener HTTP service.
Each installed and configured exit is interrogated in turn. The
exit itself determines whether or not it is responsible for handling
a given user/message type combination. The first exit that accepts
responsibility will receive all requests prompted by an occurrence
of the current inquirer and message type. For example, one exit
might handle messages regarding financial information while another
might handle flows through a justice system.
x
Each inquiry is posted to a listener. This is a specialized
HTTP or HTTPS listener that accepts the post defined by the passed
inquiry URI. It uses the IEI rendering agent or a workflow to locate
and format the information. The page presented may facilitate drill-down
into specific fields, such as context and message text.
The administrator may elect to add a workflow that might, for
example, send an e-mail message every time a specific user requests
hard copy of a document. Also, the information produced by the Recovery
Agent can be tailored to local needs, for example, a search for
all records for a given trading partner or for all records that
have a particular correlation ID.