A
Mercator Enterprise Broker and OIS

Mercator Software is a vendor of a set of enterprise application integration tools including the Enterprise Broker. The Enterprise Broker provides a rich set of data transformation services that you can use with the Oracle Integration Server, particularly for non-XML data transformations in a legacy systems environment. This appendix provides an overview of how to use Mercator Enterprise Broker with Oracle Integration Server. This appendix contains:

Introduction

The Enterprise Broker performs application-to-application integration and is particularly useful for transforming data and messages. The software is designed around a transformation flow in which an object is transformed from one form or state to another by one or more transformation steps.

Each transformation step has these properties:

A trigger or triggering event
An input object or objects
Transformation rules
An output object or objects

The Enterprise Broker itself is made up of the Engine and four graphically based editors:

System Editor

The System Editor defines transformation flows. It links together a number of transformation steps to model the multistep transformation of a message from one form or state to another.

You can use the System Editor to define a trigger or a triggering system event that precipitates a transformation. Typical triggers include:

Arrival of a message in a queue
Creation of a file in a directory
Insertion of a row in a table
Changing of a last-modified timestamp of a file

Type Tree Editor

Mercator Software products use a construct called a Type Tree to internally represent the data structures of external objects. A Type Tree takes one of three forms:

Predefined: Mercator provides a set of predefined Type Trees that represent common standard message formats (such as EDI and HL7) and the public interface objects of common ERP packages (such as SAP/R3).
Imported: You can generate Type Trees to represent database objects in most relational databases using the Database Editor.
Definable: You can define Type Trees manually by using the Type Tree Editor.

Type Trees must be defined for each source that provides input to the transformation, and for each target that receives output from the transformation.

Database Editor

Use the Database Editor to generate Type Trees for given database objects in a relational database. The Editor must connect to the database as a database user. The Editor thus assumes the privileges, permissions, and view of the objects defined for that user.

In Oracle, Type Trees can be generated for:

Tables: Columns become fields in the Tree Type.
Procedures: IN, OUT and IN/OUT parameters become fields.
Queues: If the payload of the queue is defined as an object type, then each attribute becomes a field in the Type Tree. If the payload is of RAW type, then the Type Tree is represented by a single binary string (BLOB).

Mapping Editor

Use the Mapping Editor to configure individual transformation steps by defining input cards, output cards, and maps.

A transformation step is analogous to a phase in a manufacturing process:

Input cards define suppliers and the specification of raw materials.
Maps define the manufacturing process.
Output cards define the product specification and the delivery addresses of customers.

Input Cards

Input cards define:

Rules for collection, such as the type of connection to the source, transactional behavior, number of rows per fetch, and retry rules
Format for the incoming messages by specification of all or part of a Type Tree

You can define multiple input cards in a single step, and multiple iterations of an input card are possible. For example, you define an input card for order and an input card for order lines. For each ORDER, there are multiple iterations of order lines.

Output Cards

Output cards define:

Rules for delivery, such as the type of connection to the destination, transactional behavior, number of rows per push, and retry rules
Data format for the outgoing messages by specification of all or part of a Type Tree

You can define multiple iterations of multiple output cards within a step.

Maps

Maps are the mechanisms that tie the input and output cards together. They define the rules for transforming data from one form or state to another. Maps defined to perform a particular function on a defined subset of data are called functional maps and can nest within other maps.

The basic objective of the map is to transform the data from the input cards to the output cards. Maps achieve this in a number of ways:

Dragging and dropping a field from the input card to another field on the output card
Defining a static value for a field on the output card
Defining the field in the output card as null
Setting the field on the output card to a system value, such as a date/time stamp
Providing input card fields to procedural logic, functions, or SQL lookups and then applying the result to the output card

Enterprise Broker Engine

After you configure the transformation processes using the editors, use the Engine to execute the transformation steps. These steps can be instantiated from the command line, from the System Editor, or from within programs written in C or Java (through the Mercator C and Java APIs).

The Engine provides logging and tracing facilities that capture information about each transformation step. This helps you debug errors, but it incurs a performance overhead.

The Engine has a number of performance-enhancing features that improve its scalability:

It treats large messages as a data stream. This enables the Engine to start processing a message without waiting for the whole message to arrive.
It reuses maps and database connections.
It switches off logging and tracing.

Uses of Enterprise Broker in the Oracle Integration Server

Oracle Corporation recommends that you use the Mercator Enterprise Broker as the transformation engine for particularly complex transformations. It is especially useful when you require an "XML to anything" or an "anything to XML" transformation.

The AQ adapter implementation eases transformation between AQ queues in the same database if the input and output cards use the same connection string. This implementation enables the Oracle commit model to deliver the dequeue-transform-enqueue process as a single transaction, thereby guaranteeing that messages are retained.

Defining the data transformation as a distinct step in the process is consistent with the component-based approach we recommend.

Hints and Tips

You can use Mercator Enterprise Broker to transform messages between AQ and MQSeries. However, you must track transactions to ensure that messages are not lost.

The AQ adapter supports CLOBs and regular Oracle data types, but you must use care in mapping to BLOBs/RAW AQ queues because you must determine the length of the binary string before constructing the message.

Note:
Release 2.1 of the Enterprise Broker includes no functionality to assist you with interpretation of JMS messages. You must understand the interrelationship of the OJMS and OMB AQ drivers before you attempt this, and must define the Type Trees for the JMS messages with care.

A Mercator Enterprise Broker and OIS