|Oracle8i Integration Server Overview
Release 3 (8.1.7)
Part Number A83729-01
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:
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:
The Enterprise Broker itself is made up of the Engine and four graphically based editors:
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:
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:
Type Trees must be defined for each source that provides input to the transformation, and for each target that receives output from the transformation.
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:
IN/OUTparameters become fields.
RAWtype, then the Type Tree is represented by a single binary string (
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:
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
lines. For each
ORDER, there are multiple iterations of
Output cards define:
You can define multiple iterations of multiple output cards within a step.
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:
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:
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.
CLOBsand regular Oracle data types, but you must use care in mapping to
RAWAQ queues because you must determine the length of the binary string before constructing the message.