Understanding the BEA eLink Solution

 

This section discusses the following topics:

• BEA eLink Solution Overview

• BEA eLink Information Integrator Overview

 

---

BEA eLink Solution 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 many internal operations, such as financial, manufacturing, and 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 that leverage BEA's 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 Information Integrator and eLink Adapters fit into the process.

Figure 1-1 BEA eLink Solution Illustration

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 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. The terms, Tuxedo services/ servers and eLink services/servers can be used interchangeably. Because this document specifically addresses 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 Information Integrator translates data models used by different applications into a common data format. 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 Business Process Option (BPO) 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 Overview

The BEA eLink Solution combines key features from eLink Platform, eLink Information Integrator, and eLink Adapters. These key features include:

• Business process automation

• Message transport

• Data transformation

• Content-based routing rules

• Management tools

The BEA eLink Information Integrator provides three of the five key features: business process automation, data transformation, and content-based routing rules.

Architectural Framework

The BEA eLink Information Integrator architecture is based on functional layers providing rules-based message recognition, evaluation, and dynamic formatting. The BEA eLink Information Integrator design permits convenient portability to a wide range of hardware, operating systems, and DBMSs.

The BEA eLink Information Integrator framework includes the following components:

• Formatter

• Rules

• Tester

• MsgDefAdmin

• iiServer

Formatter

Formatter allows you to define a message format as a series of components. These components describe how to parse each piece of information in a message, how to output each piece of information, and how each piece of information relates to the message as a whole.

The Formatter components include the following:

• Literals

• Fields

• Input and output controls

• Flat and compound formats

For more information about Formatter, refer to Building Format Definitions.

Rules

Rules allows you to define processing rules used by the iiServer to evaluate an input message. A processing rule consists of a Boolean expression that is evaluated against the input message and one or more subscriptions. Subscriptions contain actions that are performed if a Rules expression evaluates to TRUE.

For more information about Rules, refer to Defining Rules.

Tester

Tester allows you to parse and reformat messages as a validation test. Tester uses the control tables built using Formatter to recognize and parse input and output messages. However, Tester parses and reformats messages directly on the desktop rather than adding them to the business process flow and parsing them using the iiServer.

For more information about Tester, refer to Testing Message Parse and Reformat.

MsgDefAdmin

The MsgDefAdmin importer utility lets you add, retrieve, delete, and list message format definitions that are stored in the iiDatabase. MsgDefAdmin allows you to define message formats in an XML language called Message Definition Format Language (MFL). You can then import these textual descriptions into the iiDatabase. Message definitions that exist within the iiDatabase can also be listed, retrieved, or deleted using this utility.

For more information about MsgDefAdmin, refer to Using MsgDefAdmin to Build Definitions.

iiServer

The iiServer translates messages from one format to another, simplifying message exchange between different systems and applications. The iiServer breaks complex messages into simple messages for processing, handling anything from formats containing fixed, tagged, or delimited fields to multi-part nested formats.

The iiServer uses control tables within the iiDatabase to recognize and parse input and output messages. These tables describe message formats and format components. The iiServer uses this information to interpret values from incoming messages and dynamically construct outgoing messages.

The iiServer supports the following basic message-passing models:

• Request/Response translation

• Data enrichment

• Content-based routing

• Message explosion

  Note: You can combine all or parts of these models into a single processing cycle.

Request/Response Translation

In this model, a client/requesting application sends a message to the iiServer for some type of transformation. A series of actions associated with a business service advertised by the iiServer is executed, and the resulting buffer is returned to the requestor.

Note: In this context, client refers to the generator of a request, even if the generator is a Tuxedo server.

The actions associated with this model include:

• Reformat (transforming the input message)

• Return (returning the transformed message)

The request/response translation process is shown in Figure 1-2.

Figure 1-2 Request/response Translation Process

Data Enrichment

This processing model is similar to Request/Response Transformation. The difference in data enrichment is that the message can be processed by an external service to provide data enrichments that are not possible with the iiServer. This external enrichment of the message is transparent to the requesting application.

The actions associated with this model include:

• Reformat (optionally transform the message to input for external services)

• Call (send message to external service and accept response)

• Reformat (optionally transform the message to meet the requestor's requirements)

• Return (return the transformed message to the requestor)

The data enrichment process is shown in Figure 1-3.

Figure 1-3 Data Enrichment Process

Content-based Routing

This processing model evaluates elements of the input message and determines how the message should be distributed.

Typical actions associated with this model include:

• Rule 1: IF Field 1 == SomeValue

  • Reformat (optionally transform message before distribution)

  • Enqueue (place message on a defined queue)

• Rule2: IF Field2 == AnotherValue

  • Reformat (optionally transform message before distribution)

  • Enqueue (place message on another defined queue)

The content-based routing process is shown in Figure 1-4.

Figure 1-4 Content-based Routing Process

Message Explosion

This model accepts a single input message, breaks it into component parts, and distributes selected components as individual messages.

Typical actions associated with this model include:

• Reformat (optionally transform the input message into component parts)

• Explode (parse message and execute the following action for each selected component)

• Enqueue (place the exploded message on a queue)

The message explosion process is shown in Figure 1-5.

Figure 1-5 Message Explosion Process