Document Life Cycle
|
Topics: |
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.
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. Transforms an external format to a suitable internal format. You can choose from several preparsers that are supplied with iSM or use a custom preparser.
- 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 so as 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.
- Output Reviewer. Analyzes the document. This agent usually adds headers.
- Outlet Phase:
- Preemitter. Transforms internal formats to a suitable external format for transport.
- 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: 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 requirements.
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, iSM 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 an internal format (XML or JSON).
- 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 iSM 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.
Process flows are usually deployed on the server on which they will be executed. However, process flows can also be housed in an external/remote library and checked out for use as needed. This allows the process to be carried as a named exit that might, for example, be identified in an external data storage, such as iWay Trading Partner Manager (TPM). Similarly, transforms can also be carried in libraries and called by name. This includes iWay and XSLT transforms.