Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Search   |   PDF Files   |   Contact   |   Glossary
eLink Information Integrator Doc Home   |   eLink Information Integrator User Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

This section discusses the following topics:

• BEA eLink Solution Overview

• BEA eLink Information Integrator Overview

BEA eLink^TM provides an open Enterprise Application Integration (EAI) solution that allows applications throughout organizations to communicate seamlessly. Using EAI, you gain the long-term flexibility and investment protection you need to keep up with today's ever-changing business environment.

Typically, companies use packaged applications to automate internal operations, such as financial, manufacturing, or human resources. While they successfully address the needs of these specific areas, these proprietary platforms often do not work together. To compete today, you need a much greater exchange of information. Systems need to communicate at a process level within your own organization, as well as with customer's and supplier's systems. BEA eLink Platform is the underlying basis of BEA eLink, a family of off-the-shelf enterprise application integration (EAI) products. BEA eLink leverages the BEA transaction platform to integrate existing legacy applications with customer-focused and business-to-business e-commerce initiatives.

BEA eLink Platform provides a proven infrastructure for integrating applications within the enterprise and across the Web. BEA eLink Platform ensures high-performance, secure transactions and transparent access to mission-critical applications and information throughout the enterprise and across the Web. Figure 1-1 illustrates the eLink logical architecture and shows where the eLink Adapters fit into the process.

The entire BEA eLink family (including all options and adapters) is highly scalable. Multiple instances of BEA eLink components can collaborate so that work is divided between eLink domains. BEA eLink includes Simple Network Management Protocol (SNMP) integration for enterprise management.

The current BEA eLink Platform leverages the BEA Tuxedo infrastructure because it is based on a service-oriented architecture. Both BEA Tuxedo and BEA eLink communicate directly with each other and with other applications through the use of services. Multiple services are grouped into "application servers" or "servers". The terms Tuxedo services/servers and eLink services/servers can be used interchangeably. Because this document is specifically addressing the eLink family, the terms "eLink service" and "eLink server" are used throughout.

The BEA eLink Platform complies with the Open Group's X/Open standards including support of the XA standard for two-phase commit processing, the X/Open ATMI API, and XPG standards for language internationalization. C, C++, COBOL, and Java are supported. The BEA eLink Platform connects to any RDBMS, OODBMS, file manager or queue manager, including a supplied XA-compliant queueing subsystem.

The following components operate with BEA eLink Platform:

• The eLink Information Integrator translates data models used by different applications. It provides a cost-effective alternative to writing or generating programs to perform this function. It also handles complex translation with great power and scalability.

• The eLink Business Process Option helps automate tasks in the distributed global business process and dynamically responds to business events and exceptions. The BPO is currently implemented by integrating eLink with technology based on InConcert workflow management software.

• An eLink Adapter provides the interface between the BEA eLink Platform and external applications with out-of-the-box functionality.

BEA eLink Information Integrator is an application integration component of eLink. It simplifies the daunting task of sharing data between applications and databases that run on different distributed computing environments within and beyond the enterprise. Information Integrator provides an easy to use set of tools that allow you to define how data will be interpreted and reformatted based on rules that you define. All format and rule configuration information is stored in a database allowing easy access to this information. When you actually deploy Information Integrator as part of an integration solution, a runtime server (IISERVER) uses the rules and format definitions stored in the database to process data transformation requests. The configuration information is cached by IISERVER insuring efficient processing.

BEA eLink Information Integrator consists of the following components:

• Formatter

• MsgDefAdmin

• Rules

• Tester

• IISERVER

These components are described in the following sections.

BEA eLink Information Integrator Formatter allows you to store the necessary information that enables Information Integrator to parse an input message into individual components based on a layout (format) for the data. With Formatter, you can define input formats that match input data, define output formats that determine the appearance of output data, and view and edit formats created either by MsgDefAdmin or the Formatter graphical user interface.

Using Formatter, you define the following:

• Fields - Named divisions of message data tied to either a parse or output control. Each field can be associated with both an input and/or output control within a format.

• Literals - Single characters or strings used to mark the end of a piece of data, as a prefix or suffix, or as a pad character.

• Input controls - Controls used to parse input messages. Input control information describes the characteristics for the data in a field.

• Output Controls - Controls used to format output messages. Output control information describes how to format a component field for an output message.

• Output Control Collections - Formatter and operations you have defined used within output controls to further affect output data after data type transformations occur. Collections enable sets of operations to be grouped in the order they are to be executed.

• Flat and Compound Formats (input and output) - Combinations of fields or other formats used to describe formatting for an entire input or output message. Formats come in two main types - flat and compound. Flat formats contain a series of defined fields and the associated information needed to parse or format them (input controls or output controls, depending on whether the format is for input or output). Compound formats contain series of flat or other compound formats.

• Field Mapping - Mapping input fields to fields with different names in the output format. By default, input fields are mapped to output fields by matching names.

MsgDefAdmin

The MsgDefAdmin tool is a command line utility that allows the definition of a message format to be specified in an XML language called Message Format Language (MFL). Using your favorite text or XML editor, you can specify fields and the grouping of fields, according to the Message Format Language Document Type Definition (mfl.dtd). This XML document can then be imported using the MsgDefAdmin Tool to define the message format and all components (fields, controls, and formats).

Rules are used by the IISERVER to evaluate the contents of a message and perform actions based on the evaluation results.

Using Rules, you define the following:

• Application Groups - A logical grouping used to organize rules. For example, you may want to split your rules by project. Each application group would contain the messages and rules pertaining to that project.

• Messages - Identifies the input format used to parse an input buffer for the purposes of rules evaluation.

• Rules - Each rule has evaluation criteria (called an expression) that consists of fields from the message and associated Rules operators linked together with Boolean operators. Fields, which are defined in the Formatter, can be compared against constant data or other fields within a message.

• Subscriptions - Groups of actions that are to be processed when a rule evaluates to true.

Tester

The Tester utility allows you to parse and reformat messages as a validation test. Using the Tester utility, you can make sure the message formats you built using the Formatter or MsgDefAdmin tool produce the expected results.

The IISERVER is a message format and routing server. It advertises available service names and their associated application names and input formats. The IISERVER translates messages from one format to another, simplifying message exchange between different systems and applications. The IISERVER breaks down complex messages into simple messages for processing. The IISERVER can translate formats containing fixed, tagged, or delimited fields, as well as multi-part nested formats.

The IISERVER uses control tables within the database to recognize and parse input and output messages. These tables describe message formats and format components. You create the data contained in these tables using the Formatter and MsgDefAdmin tools described earlier (see Formatter and MsgDefAdmin for more information). The IISERVER uses this information to interpret values from incoming messages and dynamically construct outgoing messages.

The following sections summarize the steps necessary to use Information Integrator to solve a business problem.

One of the first things you need to do prior to using Information Integrator is to analyze your data. This analysis consists of the following steps:

1. Determine the structure of the input data, including:

   • fields and their names

   • field data types

   • delimiters and/or field length

   • tags

   • repeating fields

2. Determine the input message type. Supported message types are as follows:

   • STRING - A data structure that is an array of non-null characters terminated by the null character.

   • CARRAY - A data structure that is an array of characters any of which can be the null character.

   • FML - Attribute-value pairs called fields, in which the attribute is the field's identifier and the associated value represents the field's data content.

   • FML32 - Similar to FML, but FML32 uses 32-bit values for the field lengths and identifiers.

   • FMLVO - Similar to a STRING buffer, but put into FML format to accommodate data-dependent routing. FMLVO is an FML buffer where the message data is stored in the value of only one filed. It may contain other fields that describe how to process the data.

3. Determine the structure of output data, including:

   • fields and their names

   • field data types

   • delimiters and/or field length

   • tags

   • repeating fields

4. Determine the output message type. Supported output message types are the same as the input message types described in Step 2.

5. Determine the data mapping you want to use, including:

   • How the data structure maps from input to output

   • How you want to translate the field delimiters and field length

   • The data concatenation or partitioning you want to use during mapping

6. Determine the services you want to invoke and the message routing procedures you want to use. This analysis includes the following:

   • What services are to receive the transformed data?

   • What are the return values, if any?

   • What events are to be posted, if any?

   • What method of service invocation should be used?

   • Is any additional reformatting necessary?

   • What are the routing characteristics for data defined actions?

Once you have completed the data analysis, you are ready to configure and use BEA eLink Information Integrator to translate your data.

Before data translation can occur, the following high level process must be followed to configure the Information Integrator Server (IISERVER) for the desired conversion process:

1. Define message formats in the format database.

2. Define mapping between message formats.

3. Define rule-based actions to take for defined message formats. Examples of actions include reformat, send message to another application, or enqueue a message.

4. Edit the IISERVER configuration file.

There are two phases involved in translating data using BEA eLink Information Integrator: the Design phase and the Execution phase.

• Design - During this phase, you create the formats and rules you want to use for processing your data.

• Execution - During this phase, your data is translated, using the formats and rules you created during the Design phase.

The following sections further explain the steps involved in the configuring data translation using Information Integrator.

Message formats define the layout of data that is to be processed by IISERVER. This layout defines the actual "wire format" of the data that is communicated between collaborating applications. Each data item, such as a person's name, is defined as a field. For example, if a message consists of an employee's name and a employee's Social Security Number, the message contains two fields. For each defined field, an input control and an output control must be defined that indicate how to parse the field (input control), and how to output the field (output control). Groups of fields are called flat formats. Groups of flat formats are called compound formats. By defining fields, controls, and formats, the layout of the data is made available to the IISERVER component, so that it can perform the defined translation and actions during the execution phase.

Two utilities are provided with Information Integrator to define message formats:

• Formatter - GUI tool that allows the definition of all components of a message format. Using the Formatter component, you can visually define each field, control, and format.

• MsgDefAdmin - Command line utility that allows the definition of a message format to be specified in an XML language called Message Format Language (MFL). Using a text or XML editor, you specify fields and the grouping of fields, according to the Message Format Language Document Type Definition (mfl.dtd). This XML document can then be imported using the MsgDefAdmin utility to define the message format and all components (fields, controls, and formats).

Defining Field Mapping

After you define message formats, you can define field mapping to indicate how to map data from one message format to another. You do this using the Formatter component. You simply associate an output field of one message format with an input field of another message format, for each field that is to be mapped.

After you define message formats and translations, you use the Rules component to specify the actions you want the IISERVER component to perform at run-time. Examples of these actions are: reformat a message, call an eLink Platform service with a message, explode a message into multiple messages, and enqueue a message to a queue. Using the Rules component, you can specify the actions to take if a specific message type is received, and additional rules that have to hold true before these actions are taken.

For example, suppose we have a message that contains payroll information for all employees in our company. We want IISERVER to explode this message into several messages, each containing payroll information for only one employee. Once we define the message formats, we use the Rules component to define a name for our set of rules and actions. In this example we define the set as "TRANSFORM_PAYROLL". We then define a set of rules to evaluate when the payroll message is received. In our example we always want the IISERVER to perform our actions, so we define a single rule that is always true. We then define an explode action that explodes the larger payroll message into several messages for each employee.

The last step is to edit the IISERVER configuration file. This can be done manually, using any text editor, or using the Rules application. In the configuration file, you specify the eLink Platform service name that is to be advertised for the previously defined set of rules. For example, we defined a set of actions called "TRANSFORM_PAYROLL". In the IISERVER configuration file, we give this set of actions an eLink Platform Service Name. Then at run-time, when this service is invoked, the configured actions are performed.