The concept of a channel has been introduced to assist
in the construction of message flows in iWay Service Manager (iSM).
A channel serves as a container for all your components that simplifies
the integration design process and improves organization, versioning,
and troubleshooting.
Each message passes through a channel, and in many applications
through multiple channels. Messages can be XML or non-XML, based
on the demands of the application. Channels can be developed in
meaningful groups using iWay Integration Tools (iIT), which is beyond
the scope of this manual. Channels are named in iSM as "groupname":"inletname":listenername" as
configured in iIT. One or more channels constitute an application,
which can be configured and deployed as a single entity.
A channel contains the following elements that must be configured
and associated with that channel:
-
Inlet. Defines
the point at which a message entry point enters the channel, and
optionally, some preliminary steps in the message processing to
prepare for subsequent stages. Each channel must contain an inlet.
In the inlet, the message is received on a supported protocol and
may be decrypted and/or preparsed and then assigned to an appropriate
route for further processing. Inlets contain listeners, decryptors,
and preparsers. Generally, decryption using standard security algorithms are
simply configured, and decryption is simply built into iSM.
-
Route -
Defines the path a message takes through a channel. Each channel
must contain a reference to one or more routes. Along each route, transformations
and other forms of business logic are applied to the message. Routes contain
transforms, processes, and emitters. Conditional logic, expressed
using iWay Functional Language (iFL) is used to select the appropriate
route for each message. For more information on using iFL, see the iWay
Functional Language Reference Guide.
-
Outlet. Defines
how a message leaves a channel at the end of the process. Each channel
must contain one or more outlets. In the outlet, the message may
be transformed and/or encrypted, and finally emitted by the system.
Each message may be sent to multiple outlets of a channel. Outlets
contain preemitters, encryptors, and emitters. Outlet selection
can be performed through iFL expressions.
The components of a channel are shown in the following diagram.
Note: The components indicated with an asterisk (*) must
be configured for a channel (Inlet, Listener, Process, or Outlet).
The other exits are optional.
x
Document Flow Through a Channel
The document travels through the channel components
as follows:
-
Inlet Phase:
-
Listener. Protocol
handler that receives input for a channel from a configured source.
iSM offers a wide variety of standard protocols, include non-blocking
HTTP, File input, AS2, SQL, and so on.
-
Decryptor. Applies
a decryption algorithm, which must be supplied in a custom module.
-
Preparser. Offers
the first application-level examination of the message. Common preparsers
transform the message into XML, but this is not a requirement. You
can choose from several prepackaged preparsers or use a custom preparser.
Examples of several preparsers offered by iSM include comma-delimited values,
Excel conversion, EDI conversion, and so on.
-
Route Phase:
-
Optional Input Reviewer. Analyzes
the document. This agent is typically used to extract and handle
headers.
-
Input Validation Rules. Applies
validation using the rules validation engine. Rules are provided
when HIPAA, HL7, and SWIFT adapters are installed, or you can write
custom rules for input documents.
-
Input Transformation. Applies
iWay transformations or XSLT transformations to input documents
received by a listener. Transformations are more typically handled
in the process flow, but in some cases route transformations are
used to make diverse inputs common to use a standard process flow.
-
Process. Executes
the business logic of an application. Process flows are developed
using iWay Integration Tools (iIT), and are composed of services
that operate on the message, control elements such as conditional
tests, and the paths from one service to the next.
Processes can
take advantage of multiprocessor and multithread logic. You can choose
from a wide variety of services provided by iWay or you can use
custom-written agents that access third-party applications and systems.
You can use multiple services in series or in parallel.
Common
services include transformations, data enrichment, exchange of the message
with other channels running on the same application, another application potentially
on another machine, integration with other iWay products, such as
such as iWay Data Quality Server (DQS), and emitting messages to
external targets. Processes can be configured to be transactional.
-
Output Transformation. Applies
iWay transformations or XSLT transformations to all XML outbound
response documents.
-
Output Validation Rules. Applies
validation using the rules validation engine. Rules are supplied
for HIPAA, HL7, and SWIFT adapters, or they may be custom written
for output documents.
Note: Non-XML is allowed from here
on.
-
Output Reviewer. Analyzes
the document. This agent usually adds headers.
-
Outlet Phase:
-
Preemitter. Transforms
XML to non-XML. You can choose from several preemitters that are
provided or use a custom preemitter.
-
Encryptor. Applies
an encryption algorithm, which must be supplied in a custom module.
-
Emitter. Protocol
handler that drives the output of a channel to a configured endpoint.
Note: XML parsing is implied in channel execution and
occurs between the inlet and route phases. This step may be disabled
on your channel, depending on your needs.
x
Applying Business Logic to Messages
iWay Service Manager (iSM) executes
business logic based on the message that arrives and the protocol
on which it is received. To accomplish a task in iSM, you must apply
the appropriate business logic at the appropriate time. The business
logic that is applied relates to both the message being processed
and the processing stage. The task of iSM is to apply the configured
business logic at the appropriate stage of message processing.
Configuration determines the business logic to apply to a message.
Using the configuration, you can refer to built-in logic elements,
or you can supply your own.
To apply business logic, iWay Service Manager must know:
- How to locate
the logic, regardless of whether it is built-in or supplied externally.
- The stage at
which it is to be associated with the message.
- The logic elements
to apply in each case.
The major stages in the life of a message or document are:
- On arrival,
before it is parsed into XML.
- After parsing,
before execution of a business function.
- Execution of
a business function.
- Before it is
emitted to a specific end point on a protocol.
Business logic is associated with each of these stages.
You can define a business logic element from the Registry section
in the iWay Service Manager Administration console, or when you
add it to a channel or listener. After a business logic element
is defined, it can be applied to messages in a specific message
flow. Business logic can also execute iWay Designer process flows.
Business logic, in the form of document-content based routing,
may be performed by a listener or from within a process flow. For
more information, see the iWay Service Manager Programmer’s
Guide.