23-6 Oracle® Fusion Middleware Connectivity and Knowledge Modules Guide for Oracle Data Integrator
Part III
Part III
Other Technologies
This part describes how to work with other technologies in Oracle Data Integrator. Part III contains the following chapters:
■
Chapter 24, JMS
■
Chapter 25, JMS XML
■
Chapter 26, LDAP Directories
■
Chapter 27, Oracle TimesTen In-Memory Database
■
Chapter 28, Oracle Changed Data Capture Adapters
■
Chapter 29, Oracle GoldenGate
■
Chapter 30, Oracle SOA Suite Cross References
24
JMS 24-1
24
JMS
This chapter describes how to work with Java Message Services JMS in Oracle Data Integrator.
This chapter includes the following sections:
■
Section 24.1, Introduction
■
Section 24.2, Installation and Configuration
■
Section 24.3, Setting up the Topology
■
Section 24.4, Setting Up an Integration Project
■
Section 24.5, Creating and Defining a JMS Model
■
Section 24.6, Designing an Interface
■
Section 24.7, JMS Standard Properties
24.1 Introduction
Oracle Data Integrator provides a simple and transparent method to integrate JMS destinations. This chapter focuses on processing JMS messages with a text payload in
batch mode. For XML payload processing, refer to Chapter 25, JMS XML
.
24.1.1 Concepts
The JMS Knowledge Modules apply to most popular JMS compliant middleware, including Oracle Service Bus, Sonic MQ, IBM Websphere MQ, and so forth. Most of
these Knowledge Modules include transaction handling to ensure message delivery.
24.1.1.1 JMS Message Structure
This section describes the structure of a message in a JMS destination. A JMS Message consists of three sections:
■
Header
■
Properties
■
Payload
Header The header contains in the header fields standard metadata concerning the message,
including the destination JMSDestination, Message ID JMSMessageID, Message Type JMSType, and so forth.
24-2 Oracle® Fusion Middleware Connectivity and Knowledge Modules Guide for Oracle Data Integrator
Properties The properties section contains additional metadata concerning the message. These
metadata are properties, that can be separated in three groups:
■
JMS-Defined properties which are optional JMS Headers. Their name begins with JMSXJMSXUserID, JMSXAppID, etc..
■
Provider-specific properties. They are specific to the router vendor. Their names start with JMS_vendor name.
■
Application-specific properties. These properties depend on the application sending the messages. These are user-defined information that is not included in
the message payload.
The Header and Properties sections provide a set of header fields and properties that:
■
Have a specific Java data type Boolean, string, short, and so forth,
■
Can be accessed for reading andor writing,
■
Can be used for filtering on the router through the JMS Selector.
Payload The payload section contains the message content. This content can be anything text,
XML, binary, and so forth.
24.1.1.2 Using a JMS Destination
Oracle Data Integrator is able to process JMS Text and Byte messages that are delivered by a JMS destination. Each message is considered as a container for rows of
data and is handled through the JMS Queue or JMS Topic technology.
With JMS QueueJMS Topic technologies, each JMS destination is defined similarly to a flat file datastore. Each message in the destination is a record in the datastore.
In the topology, each JMS router is defined as a JMS TopicQueue data server, with a single physical schema. A JMS router may be defined therefore twice to access its
topics using one data server, and its queues using another one.
Each JMS destination Topic of Queue is defined as a JMS datastore which resource name matches the name of the JMS destination name of the queue or topic as defined
in the router. A model groups message structures related to different topics or queues.
The JMS datastore structure is defined similarly to a flat file delimited or fixed width. The properties or header fields of the message can be declared with JMS-specific data
types as additional pseudo-columns in this flat file structure. Each message in the destination is processed as a record of a JMS datastore.
Processing Messages JMS destinations are handled as regular file datastores and messages as rows from
these datastores. With these technologies, entire message sets are produced and consumed within each interface.
Message publishing as well consumption requires a commit action to finalize removingposting the message fromto the JMS destination. Committing is
particularly important when reading. Without a commit, the message is read but not consumed. It remains in the JMS TopicQueue and will be re-read at a later time.
Both the message content and pseudo-columns can be used as regular columns in the integration interfaces for mapping, filter, etc.. Certain pseudo-columns such as the
JMS 24-3
one representing the MESSAGE_ID property are read-only, and some properties of header fields are used or set through the Knowledge Module options.
Using Data Integrator you can transfer information either through the message payload - the columns - , or through the properties - pseudo-columns - application
properties, for example.
Using the properties to carry information is restricted by third-party applications producing or consuming the messages.
Filtering Messages It is possible to filter messages from a JMS destination in two ways:
■
By defining a filter using the datastore’s columns and pseudo-columns. In this case Data Integrator performs the filtering operation after consuming the messages.
This implies that messages rejected by this filter may also be consumed.
■
By defining a Message Selector MESSAGE_SELECTOR KM option. This type of filter can only use the properties or header fields of the message. The filter is
processed by the router, and only the messages respecting the filter are consumed, reducing the number of messages transferred.
24.1.2 Knowledge Modules
Oracle Data Integrator provides the Knowledge Modules KM listed in Table 24–1
for handling JMS messages.
24.2 Installation and Configuration
Make sure you have read the information in this section before you start using the JMS Knowledge Modules:
■
System Requirements and Certifications
■
Technology Specific Requirements
■
Connectivity Requirements
Table 24–1 JMS Knowledge Modules
Knowledge Module Description
IKM SQL to JMS Append Integrates data into a JMS compliant message queue or topic in text
or binary format from any SQL compliant staging area. Consider using this IKM if you plan to transform and export data to
a target JMS queue or topic. If most of your source datastores are located on the same data server, we recommend using this data
server as staging area to avoid extra loading phases LKMs.
To use this IKM, the staging area must be different from the target. LKM JMS to SQL
Loads data from a text or binary JMS compliant message queue or topic to any SQL compliant database used as a staging area. This
LKM uses the Agent to read selected messages from the source queuetopic and write the result in the staging temporary table
created dynamically.
To ensure message delivery, the message consumer or subscriber does not commit the read until the data is actually integrated into the
target by the IKM. Consider using this LKM if one of your source datastores is a text or
binary JMS message.
24-4 Oracle® Fusion Middleware Connectivity and Knowledge Modules Guide for Oracle Data Integrator
24.2.1 System Requirements and Certifications
Before performing any installation you should read the system requirements and certification documentation to ensure that your environment meets the minimum
installation requirements for the products you are installing.
The list of supported platforms and versions is available on Oracle Technical Network OTN:
http:www.oracle.comtechnologyproductsoracle-data-integrator index.html
.
24.2.2 Technology Specific Requirements
The JMS destinations are usually accessed via a JNDI service. The configuration and specific requirements for JNDI and JMS depends on the JMS Provider you are
connecting to. Refer to the JMS Provider specific documentation for more details.
24.2.3 Connectivity Requirements
Oracle Data Integrator does not include specific drivers for JMS providers. Refer to the JMS Provider documentation for the connectivity requirement of this provider.
24.3 Setting up the Topology
Setting up the Topology consists of:
1. Creating a JMS Data Server
2. Creating a JMS Physical Schema
24.3.1 Creating a JMS Data Server
A JMS data server corresponds to one JMS providerrouter that is accessible through your local network.
It exists two types of JMS data servers: JMS Queue and JMS Topic.
■
A JMS Queue data server is used to access several queues in the JMS router.
■
A JMS Topic data server is used to access several topics in the JMS router
24.3.1.1 Creation of the Data Server
Create a data server either for the JMS Queue technology or for the JMS Topic technology using the standard procedure, as described in Creating a Data Server of
the Oracle Fusion Middleware Developers Guide for Oracle Data Integrator. This section details only the fields required or specific for defining a JMS Queue or JMS Topic data
server.
1.
In the Definition tab:
■
Name: Name of the data server as it will appear in Oracle Data Integrator.
■
UserPassword: Not used here. Leave these fields empty.
2.
In the JNDI tab:
■
JNDI Authentication: Set this field to None.
■
JNDI User: Enter the username to connect to the JNDI directory optional step.
