Retek Integration Bus

11.1
Technical Architecture Guide

Corporate Headquarters:
Retek Inc.
Retek on the Mall
950 Nicollet Mall
Minneapolis, MN 55403
USA
888.61.RETEK (toll free US)
Switchboard:
+1 612 587 5000
Fax:
+1 612 587 5100
European Headquarters:
Retek
110 Wigmore Street
London
W1U 3RW
United Kingdom
Switchboard:
+44 (0)20 7563 4600
Sales Enquiries:
+44 (0)20 7563 46 46
Fax:
+44 (0)20 7563 46 10

The software described in this documentation is furnished

under a license agreement, is the confidential information of
Retek Inc., and may be used only in accordance with the
terms of the agreement.
No part of this documentation may be reproduced or
transmitted in any form or by any means without the express
written permission of Retek Inc., Retek on the Mall, 950
Nicollet Mall, Minneapolis, MN 55403, and the copyright
notice may not be removed without the consent of Retek Inc.
Information in this documentation is subject to change
without notice.
Retek provides product documentation in a read-only-format
to ensure content integrity. Retek Customer Support cannot
support documentation that has been changed without Retek
authorization.
The functionality described herein applies to this version, as
reflected on the title page of this document, and to no other
versions of software, including without limitation subsequent
releases of the same software component. The functionality
described herein will change from time to time with the
release of new versions of software and Retek reserves the
right to make such modifications at its absolute discretion.
Retek Integration BusTM is a trademark of Retek Inc.
Retek and the Retek logo are registered trademarks of Retek
Inc.
This unpublished work is protected by confidentiality
agreement, and by trade secret, copyright, and other laws. In
the event of publication, the following notice shall apply:
2005 Retek Inc. All rights reserved.
All other product names mentioned are trademarks or
registered trademarks of their respective owners and should
be treated as such.
Printed in the United States of America.

Retek Integration Bus

Customer Support
Customer Support hours
Customer Support is available 7x24x365 via email, phone, and Web access.
Depending on the Support option chosen by a particular client (Standard, Plus, or Premium), the
times that certain services are delivered may be restricted. Severity 1 (Critical) issues are
addressed on a 7x24 basis and receive continuous attention until resolved, for all clients on active
maintenance. Retek customers on active maintenance agreements may contact a global Customer
Support representative in accordance with contract terms in one of the following ways.
Contact Method

Contact Information

E-mail

[email protected]

Internet (ROCS) rocs.retek.com

Reteks secure client Web site to update and view issues
Phone

+1 612 587 5800

Toll free alternatives are also available in various regions of the world:
Australia
France
Hong Kong
Korea
United Kingdom
United States

+1 800 555 923 (AU-Telstra) or +1 800 000 562 (AU-Optus)

0800 90 91 66
800 96 4262
00 308 13 1342
0800 917 2863
+1 800 61 RETEK or 800 617 3835

Mail

Retek Customer Support

Retek on the Mall
950 Nicollet Mall
Minneapolis, MN 55403

When contacting Customer Support, please provide:

Product version and program/module name.

Functional and technical description of the problem (include business impact).

Detailed step-by-step instructions to recreate.

Exact error message received.

Screen shots of each step you take.

Contents

Contents
Chapter 1 Introduction .................................................................. 1
Additional resources ..................................................................................................... 2
Retek 11.0 integration documents ...................................................................................... 2
SeeBeyond Technology Corporation documents ............................................................... 3

Chapter 2 The RIB messaging model .......................................... 5

RIB Message Families and Message Types.................................................................. 5
Model drivers and concerns .......................................................................................... 5
Message life cycle......................................................................................................... 7
Sample RIB Message.................................................................................................. 14

Chapter 3 Messaging system component overview ................ 19

SeeBeyond components .............................................................................................. 19
Registry ............................................................................................................................ 19
Schemas............................................................................................................................ 19
Control brokers and participating hosts............................................................................ 20
Events and event type definitions..................................................................................... 20
Collaborations .................................................................................................................. 20
e*Ways ............................................................................................................................. 21
Intelligent Queues and JMS Intelligent Queues ............................................................... 21
JMS IQ Managers............................................................................................................. 21
e*Way Connection Points ................................................................................................ 22

J2EE components........................................................................................................ 22
Java Message Service Usage ............................................................................................ 22
JMS Selectors and Durable Subscribers........................................................................... 23
Enterprise Java Beans (EJBs)........................................................................................... 25
Message Driven Beans (MDBs)....................................................................................... 25
Deployment Descriptors................................................................................................... 25
Transaction Managers ...................................................................................................... 26

Retek Integration Bus

Integrated Store Operations (ISO) components.......................................................... 26

RIB components.......................................................................................................... 27
Old and New Stored Procedure Interfaces ....................................................................... 27
RIB Database Objects ...................................................................................................... 27
RIB_XML database package............................................................................................ 28
RIB_SXW database package............................................................................................ 28
RIB_SETTINGS and RIB_TYPE_SETTINGS ............................................................... 29
Application message publishing triggers using RIB Objects ........................................... 31
RIB Objects: an in-depth view ......................................................................................... 32
RIB Object to XML Translation....................................................................................... 36
Non-trigger PL/SQL publishing ....................................................................................... 36
Message Family Manager API ......................................................................................... 37
General Publisher and Subscriber Component Architecture for PL/SQL Applications... 41

Publishing application adapters using PL/SQL interfaces.......................................... 45

TAFR Adapter Process ............................................................................................... 47
Subscribing Adapter Overview................................................................................... 48
Subscribing PL/SQL Stored Procedure Message Family Manager Packages.................. 51

Error Hospital Overview............................................................................................. 52

PL/SQL API Publisher Error Hospital Processing ........................................................... 53
Pl/SQL API Subscriber Error Hospital Processing .......................................................... 54

Customized Post-Processing....................................................................................... 55
Hibernate and the Retek Platform............................................................................... 56

Chapter 4 RIB Message Families ............................................... 57

Event types and Message Families ............................................................................. 57
Message Family References ....................................................................................... 58

Chapter 5 External application message interfaces ................ 59

Direct JMS interfaces for non-Retek applications ...................................................... 59
Character Encodings ................................................................................................... 60
RIB Messaging Paradigm concerns ............................................................................ 60
SeeBeyond application-specific adapters ................................................................... 61

ii

Contents

Chapter 6 Batch job integration ................................................. 63

Motivations for replacing FTP transfers ..................................................................... 63
Transfer file data using a batch application e*Way.................................................... 64
Fixed configuration....................................................................................................... 64
Message mode............................................................................................................... 66

Transferring data directly from/to a database ............................................................. 66

Using connection points and developing the logic within a collaboration....................... 67
Using an application specific e*Way adapter................................................................... 67

Chapter 7 J2EE RIB Architecture............................................... 69

J2EE Solution Overview............................................................................................. 69
J2EE Application to JMS solution ................................................................................... 69
J2EE Application to PL/SQL Application solution.......................................................... 70

RIB J2EE Processing Overview ................................................................................. 70

RIB Payload Objects ........................................................................................................ 71
RIBMessageSubscriberEJB (MDB)................................................................................. 72
RIBMessageTafrEjb (MDB) ............................................................................................ 74
ErrorHospitalRetryEjb (Stateless Session Bean).............................................................. 75

J2EE Application Overview ....................................................................................... 76

InjectorEJB....................................................................................................................... 76

RIB Binding Overview ............................................................................................... 77

Subscriber Overview ........................................................................................................ 78
Publisher Overview .......................................................................................................... 80
RIB Binding Classes ........................................................................................................ 81
Properties Files ................................................................................................................. 83

Appendix ......................................................................................... 85
Sample payload.properties file.................................................................................... 85

iii

Chapter 1 Introduction

Chapter 1 Introduction
Welcome to the Retek 11.0 Integration Bus Technical Architecture Guide. This guide describes
the technical architecture of the Retek Integration Bus (RIB). The goal is to illustrate the
capabilities and issues an enterprise may encounter when integrating applications with the RIB.
The intended audience for this guide includes system designers and project managers. It assumes
that you are familiar with Enterprise Application Integration terms and concepts. If not, see the
Additional resources section for more information.
Chapter 2 introduces the RIB message model. Important conceptual topics are presented such as
the business event relationship to the message, the message family, and message structures.
Because the sequence of events that occur on a table reflect business processes, this chapter
discusses the association of message structure and sequencing to systems and their availability on
the RIB. Error handling, performance, and the synchronization of participating systems are topics
touched on here. Finally, Chapter 2 presents the message lifecycle, or how messages flow through
the system. Described are simple flows of messages that do not require additional transformation,
filtering, or routing logic (known as a TAFR) to occur on the RIB, and those flows that depend
upon a further TAFR operation prior to another applications subscription of the message.
The components of both SeeBeyonds e*Gate Integratorthe RIB itselfand Retek applications
on the RIB are described in Chapter 3. Here you learn about SeeBeyond components like the
registry, schema, event type definitions, e*Ways, intelligent queues, collaborations, and more.
Because certain Retek applications have moved to the J2EE environment, this chapter also
introduces the J2EE Enterprise Java Bean and Message Driven Bean components. Non-J2EE
based Retek applications are characterized by the use of Oracle-based triggers and XML and
Message Family manager packages for publishing messages through application adapters. Retek
applications also share common message subscription processes for message and error handling.
TAFR processing is presented too.
Learn about Retek Message Families in Chapter 4 where the event type and Message Family
concept is discussed. Here you can see a list of Message Families for each application leveraging
the RIB for message-based integration. If you are considering the interface of additional
applications on the RIB, read Chapter 5. The successful coupling of third-party applications to the
RIB (and, as a result, to Retek applications) hinges on understanding the importance of the single
event-message relationship. These concerns are addressed here, along with descriptions of
SeeBeyond proprietary e*Gate adapters that a client can select for applications to be deployed on
the RIB.
Chapter 6 introduces batch file transmission on the RIB. Batch job integration involves the
movement of files across the RIB. Currently, implementation of these processes involves further
definition, and these chapters discuss the relevant issues.
Chapter 7 highlights the RIB architecture that supports Reteks J2EE products.

Retek Integration Bus

Additional resources
Read the following Retek 11.0 and SeeBeyond documents for additional information.

Retek 11.0 integration documents

The following resources should be used for further understanding the Retek Integration Bus:
Retek 11.0 Integration Guide Descriptions of Retek applications on the RIB and the
functional areas in which they share data. The guide also contains all data descriptions, including
the message catalog; XML document type definitions of messages; and mapping documents that
specify a messages source application, table, column, and data type.
Retek 11.0 Integration Bus Installation Guide Descriptions of:

SeeBeyond e*Gate Integrator installation of its registry host and all participating host
software, plus Graphical User Interface hosts for development and system monitoring.

How to import the RIB schema into the e*Gate Integrator product.

Configuring database connection points and JMS topics, updating CLASSPATH

configuration values, and deleting unused adapters.

Instructions for RIB components for applications using ISO or J2EE platforms.

Retek 11.0 Integration Bus Operations Guide Provides a basic understanding of RIB
components, how messages flow between them, and operational activities surrounding the
components. Included are templates for using the RIB as an alternative to FTP batch jobs to
transfer files from one system to another.
Retek 11.0 Data Model Provides Relational Integrity Diagrams and Data Dictionary Language
(DDLs) for the RIB.

Chapter 1 Introduction

SeeBeyond Technology Corporation documents

See the resources listed in this section to learn more about the RIB as it is deployed through the
SeeBeyond e*Gate Integrator EAI platform:
SeeBeyond Business Integration Suite Deployment Guide Information to use in analyzing,
planning, and managing an EAI deployment.
SeeBeyond Business Integration Suite Primer An introduction to all SeeBeyond e*Gate
products, including e*Ways for external financial applications.

Chapter 2 The RIB messaging model

Chapter 2 The RIB messaging model

This chapter presents the RIBs messaging model. It describes how RIB messages are structured
and the rationale behind this structure. It also describes the types of messages used.
Not presented in this chapter are the specifics of each message. The Retek 11.0 Integration Guide
details information about message contents and transformations.

RIB Message Families and Message Types

Each RIB message belongs to a specific Message Family. Each Message Family contains
information specific to a related set of operations on a business entity or related business entities.
The publisher is responsible for publishing messages in response to actions performed on these
entities in the same sequence as they occur. One example of a Message Family is the Orders
Message Family used to contain information about Purchase Order events.
Descriptions of each Message Family are found in the Retek 11.0 Integration Guide. Although a
generalized format exists, each Message Family varies in the specifics of the information it
contains the business entities and events the message captures. Furthermore, each Message
Family contains a set of sub-formats specific to the business event triggering message
publication. The term message type embodies this specific sub-format. For example: the Order
Message Family is published for events such as Create PO Header, Create PO Detail,
Update PO Header, or Delete PO Detail. Examples of these events are published using the
specific Message types of OrderHdrCre, OrderDtlCre, OrderHdrMod , and OrderDtlDel.

Model drivers and concerns

An architect chooses the type, structure, and other characteristics of the messages within an EAI
system based upon many factors. One major factor is how the message contents encapsulate a
business event. Different characterizations are available within a single EAI system. The RIB is
no exception. The RIB contains many messages characterized as Hierarchical snapshots and
synchronously produced. On the other hand, there are also flat synchronous delta RIB
messages associated with update operations. The factors determining which characterization to
use include:

Publisher/subscriber/bus availability: One major goal in the design of the RIB is to insure
that no tight coupling exists between Reteks applications and the RIBs availability. That is,
if the RIB is unavailable, the publishing and subscribing applications can still function. This
means that there may be a delay before the transmission of a message occurs over the RIB
network. It also means that database updates needed for message publishing must occur
outside of the same transaction containing the business event.

Retek application locking on sub-business entities: Many of Reteks applications allow for
simultaneous updates to sub-business entities. An example of such an entity is a line item
found within a Purchase Order. The Retek Merchandising System allows multiple concurrent
changes to multiple items, header, or summary information for a single PO. Many times the
PO is used for replenishment purposes and multiple people are constantly updating the PO.
Situations such as these tend to produce flat messages containing only the changes to the
line items. Producing a hierarchical message would risk locking the PO for an unacceptable
amount of time.

Retek Integration Bus

Concurrency of message contents production and business event: A desire for a loose
coupling between the RIB and the business application suite drives some EAI architectures.
In many cases, message information is staged before publication. A delay exists between
when the business event occurs and when the message corresponding to this event is created
and published. This delay presents a window of opportunity for multiple similar business
events to occur on the same entity before publication of any of the messages. For example,
multiple users may make changes to the same Purchase Order header within a short time
period.
There are two strategies for staging business event information: record only enough
information to denote that the event occurred (for example: an update occurred on PO line
item #123) or record all information about that event (for example: an update occurred on PO
line item #123 and the new quantity is 4, the new location ID is 8,). If only some of the
information is staged, the message published may not correspond to the triggering business
event. In this case, the publisher assumes that the subscriber is interested only in the resultant
business object and has little or no interest in data such as the number of times a change has
occurred.

Transactional considerations: Some business events require multiple database transactions

to complete. One example of this is the creation of a new vendor. In this case, all of the
surrounding foundation data must be present before the vendor specifics. This foundation
data includes information such a valid country code identifying the vendors country of
origin, one or more valid currencies, and other specific terms, conditions or other policy
identifiers used to conduct transactions with the vendor.

Sequencing and error handling: Many business processes are stateful. That is, only certain
actions can occur at certain times. A subscriber must process messages concerning a specific
business entity in the same order they were published. This has implications regarding error
handling: once an error occurs on one message, subsequent messages referring to the same
business object should be held and not processed until the error has been resolved. However,
other messages concerning other business entities should continue to be processed.

Deployment and software lifecycle: The applications producing and subscribing to

messages need separate deployment between themselves and the RIB. In effect, each Retek
application can be plugged into the RIB based on the needs of the retailer. If the retailer
decides to not use the RIB, then no noticeable performance degradation occurs. In other
words, the RIB is not required for any Retek application to function in a stand-alone manner.

Performance: Updates to some business sub-entities happen frequently on a single business

entity. Take the example of a retailer creating a single replenishment PO per supplier. Users
may update the same PO many times during the day. When one analyzes the volume of
updates and the cost of creating a full PO message, it may be a significant performance
bottleneck to publish the full PO snapshot for each update.

Chapter 2 The RIB messaging model

Another performance consideration is the granularity of a message and the requisite overhead
to process the contents of a message. This includes the following factors:

Per-message overhead the amount of processing needed to simply retrieve a message

from the associated message server and to perform a two-phase commit operation.

Retrieval of referenced data the external data needed to process a message that is
referenced, but not contained, within the message.

Aggregation of contents the number of logical units and their contents contained in a
message. Aggregation is a performance enhancement technique that allows more data to
be processed in a single physical unit of work by spreading overhead among many logical
units of work.

Scalability: Associated with performance is how well the system can scale. Scaling
concerns come to the forefront when a single thread of processing cannot perform well
enough to process a required amount of data. Ideally, a scalable application will perform in a
linear manner according to the available resources doubling the number of processing
instances and resources should double the throughput of the application. The main concern
for scalability is inherent in the resource contention between threads. These concerns can
only be addressed by the message definition and the associated database locks held while
processing a message. In certain circumstances, a message may be processed by an
application in multiple database transactions to insure scalability.

Data synchronization risks: Many messages seek to replicate data across multiple systems.
Sometimes, the data on two systems may differ due to a variety of possible situations. When
one uses a delta type of message, there is a risk that the subscriber cannot process these
messages due to the data differences.

Message life cycle

The Retek Information Bus (RIB) uses the Pub/Sub message model for all of the messages
produced and consumed within the EAI system. The publishing application is responsible for
creating the initial message contents. The RIB publishing adapter will publish it to the RIB and
make it available to any subscribers. The RIB knows what subscribers are to receive the message
due to the RIBs configuration -- this configuration associates a set of subscribers to each
publisher / Message Family combination.
Database tables associated with the publishing application typically stage message information.
On the SeeBeyond platform, one or more RIB Publishing Adapter collaborations poll the
application via a stored procedure call. A collaboration is a single thread of control within the
adapter. On the J2EE platform, the application calls a Retek developed Enterprise Java Bean
(EJB) with the payload information to be published.
The message resides on a Java Message Service (JMS) topic 1 immediately after publication. The
JMS topic provides stable storage for the message in case a system crash occurs before all
message subscribers receive and process it.

A JMS topic is a queue of messages that can be shared between multiple subscribers and each
subscriber can independently access every message on the topic. A JMS queue is a queue of messages
which, if shared between multiple subscribers, allows for only one subscriber to see any specific message.
7

Retek Integration Bus

One system requirement is that a message must be delivered to and processed successfully
exactly once by each subscriber. Furthermore, all work performed by the subscriber and the RIB
must be atomically committed or rolled back, even if the JMS server is on a remote host. The
standard way to perform this is by using an XA 2 compliant interface and two-phase commit
protocol.
After initial publication, a message may undergo a series of transformation, filtering, or routing
operations. A RIB component that implements these operations is known as a Transformation and
Address Filter/Router (TAFR) component. A transformation operation changes the message data
or contents. A filter operation examines the message contents and makes a determination as to
whether the message is appropriate to the subscriber. For example: those subscribers that do not
process all Message Types found in a Message Family require filter operations to weed out the
unsupported types. A router operation examines the message contents and forwards the message
to a subset of its subscribers. A filter operation can be considered a special case of a routing
operation. Although logically separate operations, for performance reasons TAFR components
usually combine as many as is appropriate.
TAFR operations are specific to the set of subscribers to a specific Message Family. Multiple
TAFRs may process a single message for a specific subscriber and different specific TAFRs may
be present for different subscribers. Different sets of TAFRs are necessary for different Message
Families.
If all subscribers to a message can process all messages within a Message Family without any
TAFR operations, then no TAFR components are needed, as seen in Figure 2.1.

XA is a standard specification that details the interface between multiple Resource Managers and a
Transaction Manager. It insures that distributed transactions are performed correctly within a
heterogeneous environment.

Chapter 2 The RIB messaging model

Publishing
Adapter
RIB messsage

Payload

Application
Triggers

Payload

Message Family
Manager
Staging Tables

RIB message

Subscriber
Adapter 1

App 1 DB

Subscriber
Adapter 2

App 2 DB

JMS
Topic

RIB message

Figure 2.1 Simple Message Flow

The publish adaptor in the diagram is optional in the diagram, not valid for J2ee.
Multiple TAFRs may be needed depending on the types of subscribers. This is seen in Figure 2.2,
where one TAFR routes the information among different remote sites and then another TAFR
transforms the data further for an additional subscriber.

Retek Integration Bus

RIB Message

Publishing
Adapter

Payload

Message
Family
Manager
Staging
Tables

Payload

Application
Trigger

RIB
message

RIB
meessage

JMS
Topic
2A

Sub Adapter 1

App1 db

JMS
Topic
2B

Sub Adapter 2

App 2 db

JMS
Topic
2C

TAFR 2

RIB
Queue
3

TAFR1

JMS
Topic
1
RIB Message

RIB Message

Sub Adapter 3

App 3 db

Figure 2.2 Message Flow with TAFR

The publish adaptor in the diagram is optional in the diagram, not valid for J2ee.
Another type of RIB component that may process a message is a bridge component. These
SeeBeyond e*Ways, queues, or connection points allow messages to traverse different
administrative domains. The type of bridge component used is site specific. A deployment of
bridge components is dependent on how the network bandwidth and topology, the administrative
specifics of the publisher and subscriber applications, and the availability of specific RIB
resources. Bridges are very useful when remote sites that belong to different organizations and
operations staff need to exchange messages and a central controlling authority is non-existent.
Figure 2.3 is a modification of Figure 2.2, where one of the remote systems uses a bridge.

10

Chapter 2 The RIB messaging model

Remote RIB Installation

RIB Message

Publishing
Adapter

Payload

Message
Family
Manager
Staging
Tables

Payload

Application
Trigger

RIB
message

RIB
meessage

JMS
Topic
2A

B
R
I
D
G
E

B
R
I
D
G
E

Remote
JMS
Topic

Remote Sub
Adapter

Remote
App db
TAFR1

JMS
Topic
1
RIB Message

JMS
Topic
2B

Sub Adapter 2

App 2 db

JMS
Topic
2C

TAFR 2

JMS
Topic
3

RIB Message

Sub Adapter 3

App 3 db

Figure 2.3 Message Flow with TAFRs and Bridge

Within RIB components, message processing continues until a subscribing adapter successfully
processes the message or determines that no subscriber needs this message. These components
will perform application specific database updates for the specific message encountered.
When a message is processed, the adapter checks to see if the Error Hospital contains any
messages associated with the same entity as the current message. If so, then the adapter places
the current message in the hospital as well. This is to insure messages are always processed in the
proper sequence. If proper sequencing is not maintained, then the subscribing application will
contain invalid data.
If an error occurs during message processing, the subscribing adapter notes this internally and
rolls back all database work associated with the message. When the message is re-processed
(since it has yet to be processed successfully), the adapter will now recognize this message is
problematic and checks it into the hospital.
After a message is checked into the Error Hospital, a retry e*Way extracts the message from
the hospital and re-publishes it to the integration bus. The message remains in the hospital during
all re-tries until the subscribing adapter successfully processes it. RIB message structure

11

Retek Integration Bus

RIB Messages are XML formatted. Multiple business events may be aggregated or bundled into
a single message. The outer tag, <RibMessages> may contain multiple <ribMessage> tags, each
of which represents a separate business event. The <RibMessages> tag may also contain a single
<publishetname> tag. When the source of data is a file, certain collaborations use this tag to
determine the correct event type (JMS Topic) to publish the message to. It is only valid when a
file must be loaded as a single message using the RIBs generic file loading collaboration rule.
Each <ribMessage> tag is a two-tiered structure consisting of a set of envelope tags and a
single payload. The envelope tags contain routing, message type, and other non-business entity
information. The payload is specific to the message type and contains the business entity
information.
As of the RIB 11.0 release, the message envelope contains the following tags:
<RibMessages>

root message tag. This tag contains one or more <ribMessage> tags.
<publishetname>
This is an optional tag that is used for Legacy interfaces using files. It determines the topic this
message should be published onto. Messages published from application adapters do not use this
tag.
<ribMessage>

tag delimiting information regarding a single event that has occurred on a business object. This
tag contains all of the elements below:
<family>

Message Family message belongs to

<type>

message type message belongs to

<id>

Optional ID string that identifies the message. Composite primary keys will require multiple IDs.
For example, a line item within a Purchase Order would contain the PO number and line item
number as part of the ID. For example:
<id>PONumber=12345</id>
<id>ItemID=321</id>

Some IDs are simple and the value of the ID is specific to the Message Family. In this case, a
single ID tag may be present and consist of merely a single identifier, such as
<id>FT_ITEM_12</id>.

12

Chapter 2 The RIB messaging model

<routingInfo>
Optional tag that contains elements used to route or filter messages for specific subscribers.
Multiple <routingInfo> tags may be present. Within the <routingInfo> element, the following
sub-elements must exist:
<name>
name of routing field. A message may have multiple routing fields.
<value>
value of the routing field.
<detail>
optional tag containing additional qualification of the name/value. There may be up to two
<detail> tags found within each <routingInfo> tag. Sub-elements of <detail> are:
<dtl_name>
name of the detail field.
<dtl_value>
value of the detail field.
The values of the <name>, <value>, <dtl_name>, and <dtl_value> are specific to the message
family.
<publishTime>

Date/timestamp the message was published. Must be in the form,

yyyy-MM-dd HH:mm:ss.SSS z
where:
yyyy is the year
MM is the numeric month (1 12)
dd is the day of the month
HH is the hour of the day (0 23)
mm is the minutes of the hour (0 59)
ss is the seconds of the minute (0-59)
SSS is the milliseconds of the second (000 999)
z is the three character time zone specification
<hospitalID>

This is an optional element. It contains the ID of the Message within the Error Hospital. Must be
set when the message has been resubmitted or retried.
<failure>

Optional tag that contains elements used to identify a specific processing error. Multiple
<failure> tags may exist. Every time the message is checked into the Error Hospital, a <failure>
tag is created. This tag contains the following sub-elements:
<time>

Date/timestamp of failure.
<location>

Location or name of the Error Hospital.

<description>

Textual description of the error.

13

Retek Integration Bus

<messageData>

The message type specific payload containing data describing the message triggering event.
The payload is XML, but the XML varies within each message type. The DTDs describing this
data are stored in a table within the RIB_MESSAGE database table.
<ribmessageID>
This field uniquely identifies the message based on the publishing adapter. It may be used to
track or correlate problems associated with a specific message.
<customData>
Optional field reserved for client specific additions to RIB message payloads.
<customFlag>
Reserved for future use. Must be set to F.
<HospitalRef>
This is an optional field. This field references a hospital record used by custom post-processing
an application may desire. One implementation of the custom post-processing allows the
successful completion of a message to cause a change in a status of a message in the error
hospital, so that potentially it can be retried. The hospitalRef tag contains 4 components:

MessageNum (Unique hospital ID)

Message Family of referenced record.

Old Reason Code existing REASON_CODE value of referenced record

New Reason Code optional field containing new REASON_CODE to apply to the
referenced record.

Sample RIB Message

The sample RIB Message below contains a <RibMessages> tag containing two <ribMessage>
nodes. The <messageData> tag contains data for a warehouse create and modification messages.
Routing information has been added for this example; this message does not normally contain
routing information.
Also in the example, one difference between each <ribMessage> node is the format of the
<messageData> string. This tag contains XML tags itself. Tag delimiters and quotation marks
within an XML tag must be changed or surrounded by a CDATA declaration in order for it to be
well-formed. The first node uses a CDATA declaration. Using the CDATA declaration is more
efficient than replacing the XML reserved characters. However, it requires that the string itself
never contains the ending delimiter for a CDATA string, >>]. The second changes the
reserved XML characters using the &lt;, &gt;, and &quot; for <,> and (double
quotation), respectively 3. Either format may be used in a <messageData> element.
White space between different XML elements is optional. However, white space should not be
found immediately following the <messageData> tag and the message payload itself.

There are two additional reserved characters in XML, & (ampersand) and (apostrophe or single
quotation mark). Their replacement strings are &amp; and &apos;.
14

Chapter 2 The RIB messaging model

<?xml version="1.0" encoding="UTF-8" ?>

<RibMessages>
<ribMessage>
<family>WH</family>
<type>WHCre</type>
<id>22</id>
<ribmessageID>11.0|ewWHFromRMS|colWHFromRMS|2003.05.26
13:43:29.123|78</ribmessageID>
<routingInfo>
<name>to_phys_loc</name>
<value>9901</value>
<detail>
<dtl_name>to_phys_loc_type</dtl_name>
<dtl_value>S</dtl_value>
</detail>
</routingInfo>
<publishTime>2003-05-26 18:06:29.809 CDT</publishTime>
<messageData><![CDATA[<!DOCTYPE WHDesc SYSTEM
"http://www.retek.com/dtd/rib/WHDesc.dtd">
<WHDesc>
<wh>22</wh>
<wh_name>WH1</wh_name>
<wh_add1>19 Pruneridge Ave</wh_add1>
<wh_add2/>
<wh_city>Cupertino</wh_city>
<county/>
<state>CA</state>
<country_id>USA</country_id>
<wh_pcode>95014</wh_pcode>
<email/>
<stockholding_ind>Y</stockholding_ind>
<channel_id/>
<currency_code>USD</currency_code>
<duns_number/>
<duns_loc/>
<physical_wh>1</physical_wh>
<break_pack_ind>Y</break_pack_ind>

15

Retek Integration Bus

<redist_wh_ind>N</redist_wh_ind>
<delivery_policy>NEXT</delivery_policy>
</WHDesc>]]></messageData>
<customFlag>F</customFlag>
</ribMessage>
<ribMessage>
<family>WH</family>
<type>WHMod</type>
<id>22</id>
<ribmessageID>11.0|ewWHFromRMS|colWHFromRMS|2003.05.26
13:43:29.123|79</ribmessageID>
<routingInfo>
<name>to_phys_loc</name>
<value>22</value>
<detail>
<dtl_name>to_phys_loc_type</dtl_name>
<dtl_value>S</dtl_value>
</detail>
</routingInfo>
<publishTime>2003-05-26 18:06:29.834 CDT</publishTime>
<messageData>&lt;!DOCTYPE WHDesc SYSTEM
&quot;http://www.retek.com/dtd/rib/WHDesc.dtd&quot;&gt;
&lt;WHDesc&gt;
&lt;wh&gt;22&lt;/wh&gt;
&lt;wh_name&gt;WH1&lt;/wh_name&gt;
&lt;wh_add1&gt;20 Pruneridge Ave&lt;/wh_add1&gt;
&lt;wh_add2/&gt;
&lt;wh_city&gt;Cupertino&lt;/wh_city&gt;
&lt;county/&gt;
&lt;state&gt;CA&lt;/state&gt;
&lt;country_id&gt;USA&lt;/country_id&gt;
&lt;wh_pcode&gt;95014&lt;/wh_pcode&gt;
&lt;email/&gt;
&lt;stockholding_ind&gt;Y&lt;/stockholding_ind&gt;
&lt;channel_id/&gt;
&lt;currency_code&gt;USD&lt;/currency_code&gt;
&lt;duns_number/&gt;
&lt;duns_loc/&gt;
16

Chapter 2 The RIB messaging model

&lt;physical_wh&gt;1&lt;/physical_wh&gt;
&lt;break_pack_ind&gt;Y&lt;/break_pack_ind&gt;
&lt;redist_wh_ind&gt;N&lt;/redist_wh_ind&gt;
&lt;delivery_policy&gt;NEXT&lt;/delivery_policy&gt;
&lt;/WHDesc&gt;</messageData>
<customFlag>F</customFlag>
</ribMessage>
</RibMessages>

17

Chapter 3 Messaging system component overview

Chapter 3 Messaging system

component overview
This chapter details the major components of the RIB that create, process, or consume messages.
The 11.0 release of the RIB has a diverse set of application interfaces. For some Foundation Data
interfaces, the 11.0 RIB release uses Character Large Object Binaries to communicate with the
Oracle Stored Procedures. For high-volume messages, the interfaces to Oracle Stored Procedures
use a RIB specific set of Oracle Objects. The RIB infrastructure is also implemented within the
Java 2 Platform, Enterprise Edition (J2EE) environment to work with Retek Applications
deployed within the J2EE environment.

SeeBeyond components
When running on the SeeBeyond EAI platform, the RIB leverages the SeeBeyond Schema
Runtime Environment (SRE). The SRE is the latest implementation of the eGate Integrator
application. It currently does not use any of the SeeBeyond Integration Server components. The
appropriate method to integrate applications running in each subsystem is via the SeeBeyond
JMS implementation.
The RIB deployed on the SeeBeyond e*Gate platform uses an Oracle Stored Procedure interface
to process incoming message payloads or to create payloads for new messages. In this
environment, the RIB components execute within the context of SeeBeyonds e*Gate e*Way
framework. This section presents a brief overview of the associated components.

Registry
The e*Gate Registry is a SeeBeyond proprietary database containing all entities used within a
running e*Gate system. There is at least one registry available to SeeBeyond components at all
times. A system designer designates one registry as the master. Other, secondary registries
replicate the master for increased performance and system availability.

Schemas
A schema is a logical grouping of SeeBeyond EAI components. Each registry contains at least
one or more schemas. Typically, schemas are designed for the end-to-end processing of a set of
related messages. The design of a Schema within a deployed RIB system is dependent on many
site-specific factors. Specific design or configuration options are discussed in the RIB
Deployment Guide.

19

Retek Integration Bus

Control brokers and participating hosts

The control broker is responsible for maintaining the operational control and status of its attached
components. Another goal of a control broker is to minimize the number of network connections
to the registry and to provide a central point of control for a set of components. Each control
broker connects to one registry but can also fail over to other registries if needed. The control
broker and all of the attached components must belong to a single e*Gate schema.
There is one control broker per participating host per SeeBeyond e*Gate schema. A
participating host is a logical construct used. The control brokers TCP/IP address and the
participating hosts name are associated with each other within the registry.
Control Brokers and participating hosts are transparent or not involved in the processing of RIB
messages.

Events and event type definitions

SeeBeyond events include both messages passing to and from JMS, and stored procedure calls
to external application APIs. An events type determines its logical name, but the rules for
parsing are determined by an event type definition (ETD). Hence, the ETD can have a strong
coupling with the message structure. Different event types may share the same ETD to allow
message with identical structure to flow to different recipients. The RIB uses a single ETD for all
messages while they are inside the RIB.

Collaborations
Collaborations define message processing logic on a per Message Family/message source/
component combination. This logic is triggered or executed when the adapter pulls a message
with the correct event type from the specified source. The RIB uses Java to define the message
processing logic. All collaborations require one or more triggering conditions in order to execute.
This condition may be any of the following:

A file appearing in some directory

A certain time period has elapsed

A message appearing on a queue

Some application specific condition

20

Chapter 3 Messaging system component overview

A collaboration works on a collection of input and output events, which may be messages going
to or from queues, or passing to or from an applications RIB APIs.
In general, the logic within a collaboration may perform any number of operations. It may update
a database, simply collect statistical data, write information to a file, or some other operation. It
may produce zero or hundreds of output events, depending on the application.

e*Ways
There are two basic types of e*Gate components used to create, process, and/or consume
messages on the RIB: e*Ways. These are specific implementations of the generalized concept
known as an Integration Bus Adapter. E*Ways contain one or more Collaborations that are
triggered from some event. A collaboration works on a collection of input and output events,
which may be messages going to or from queues, or passing to or from an applications RIB
APIs.
e*Ways are multi-threaded and can process multiple messages simultaneously, but are singlethreaded for a particular event type.
e*WayThe RIB, only uses a specific type of e*Way, the Java Multi-mode e*Way, which can
function as both an external source or sink and an internal connector. The Multi-mode e*Way is a
grouping of logical collaborations into a single physical process or program.

Intelligent Queues and JMS Intelligent Queues

Intelligent Queues (IQs) hold published messages and maintain a record of what subscribers have
received the messages. Many types of Intelligent Queues either wrapper the message storage
mechanism or bridge to another queuing system. The SeeBeyond e*Gate system installed with
the RIB includes a Java Messaging Service (JMS) IQ. JMS Intelligent Queues are queues that
may be accessed using the Java Message Service API.

JMS IQ Managers
The JMS Intelligent Queue Manager serves two roles. The first is the same as any other IQ
manager: to control a set of Intelligent Queues for any SeeBeyond e*Way. The second (which the
RIB uses) is to act as a Java Message Service (JMS) provider, accessible through JMS
Connection Points. The RIB uses the IQ Manager this way because it requires the use of the XA
two-phase commit protocol to guarantee exactly once successful message processing. This
protocol is available with a JMS implementation. However, a JMS Intelligent Queue is not used
because the existing IQ Manager service interface does not support the XA protocol. Instead, RIB
e*Ways use SeeBeyond JMS Connection Points. Connection Points connect to a JMS IQ
Manager such that the XA protocol is supported. For more information regarding JMS connection
points and Intelligent Queues, see the SeeBeyond JMS Intelligent Queue Users Guide.
The RIB is designed to only retrieve and publish messages to a JMS compliant server. The
preferred JMS implementation is the SeeBeyonds standard JMS implementation. As of the 11.0
release, Retek has not certified other JMS implementations or interfaces.

21

Retek Integration Bus

e*Way Connection Points

An e*Way Connection or Connection Point defines a session between the e*Way and an
external system. The following types of connections are available:

Java Message Service a connection to a JMS Server or JMS Service.

A relational database, such as Oracle

A TCP/IP connection to a remote application using the HTTP or HTTPS protocol.

E-mail (uses standard SMTP for outbound and POP3 interfaces for inbound messages)

A database connection point defines the login, password, and server address for database
operations. It also may define the frequency triggering events are fired off, allowing the
collaboration to define a polling operation. Within collaboration, connection points are assigned
to Event Types that are assigned to Event Type Definitions.
A connection point made to a JMS implementation can be used to publish or subscribe to external
applications. JMS connection points can also be used to bridge between e*Gate schemas.

J2EE components
The Java 2 Platform, Enterprise Edition (J2EE) is a multi-tiered client/server architecture that
allows an application to be deployed as a set of reusable components within a distributed
processing environment. Client tier components run on a client machine and business tier
components run on the J2EE server and database components run on a database server.
Retek applications that are deployed on the J2EE platform and integrating using the RIB will
require the Retek Binding, Retek Message Driven Bean (MDB), and Enterprise Java Bean (EJB)
components. Retek applications deployed using Oracle Forms do not have J2EE dependencies,
except for a Java Message Service provider.
Please see Chapter 8 for more information on the RIB J2EE architecture.

Java Message Service Usage

The J2EE Java Message Service (JMS) specification provides a standard API used by RIB
components for publishing and subscribing messages. This section details what parts of the
specification are used.
In the e*Way environment, sending messages to and retrieving messages from the JMS is
wrappered by a set of SeeBeyond proprietary classes. However, it could be possible to
circumvent these classes, at the cost of additional program complexity. This means that the
actual implementation is still JMS compliant.
For the RIB, all messages are published to a JMS Topic. The specific topic used is dependent on
the Message Family the message belongs to and the current stage in the processing of the
message. For example, the name of the topic used to hold messages pulled from RMS with
vendor information is etVendorFromRMS. TAFR adapters may both subscribe to and publish
messages in the same Message Family. In these cases, the re-published messages are put onto
another topic.
The list of JMS topics used by RIB components is detailed in the RIB Integration Guide Reports.

22

Chapter 3 Messaging system component overview

JMS Selectors and Durable Subscribers

All RIB adapters that subscribe to Rib Messages use JMS Durable Subscribers. A Durable
Subscriber is a holding point for messages such that the subscribing application does not have
to be running when a message is published Therefore,, as long as the JMS is running, messages
can be saved for processing later. This allows the publisher and the subscribing applications to
become decoupled from each other.
Another aspect of the JMS usage is the attachment of message properties to published messages
and the use of selectors by message subscribers. Message Properties are used to convey
information about the message outside of the actual message data. i.e. metadata or external
processing information. Message selectors are used by the RIB to distinguish the desired
subscribers for a message. In other words, using the message properties, selectors act as a filter to
weed out messages a subscriber should not process. The standard set of message properties set
and used on RIB Messages are:
threadValue the logical thread value associated with the multi-threading of a message
stream. All messages for a specific business object will always contain the same threadValue
property. This, combined with the standard FIFO message ordering on the topic, is integral
to message sequencing. Messages with different threadValue properties are not guaranteed to
be processed in the same relative order as publishing.
retryLocation -- This identifies a specific subscriber that is to retry this message. This
property is only set when a message is currently in the Error Hospital and is scheduled for
another attempt to be processed. It insures that messages being retried are only picked up by
the original subscriber for those topics having multiple subscribers.
groupKey This property identifies a group of subscribers for processing the message. The
value of this property is an identification of a level within a hierarchy that is to receive this
message. It is present for compatibility with the Retek Integrated Store Operations (ISO)
platform.
Note: All Message Properties above are string values
Messages published without any selectors present will not be picked up by the standard RIB
adapters. By default, the RIB creates a selector that subscribes to messages:

with a threadValue of 1 and

a retryLocation of <e*WayName>.<collaborationName> or null (not present).

RIB message selectors are used for two purposes. The first is to establish a logical channel of
messages on a per-thread basis. One requirement a RIB publisher must fulfill is to always
publish messages for a specific business object with the same ThreadValue. The second function
of a selector is to use retryLocation property so that messages re-published from the Error
Hospital are only re-processed by the adapter that put the message into the Error Hospital.
Remember, in the pub/Sub model, multiple subscribers may read the same message.

23

Retek Integration Bus

Message Selector Check

Because these message selectors help guarantee sequential, exactly once message processing, we
need to make sure that message selectors are properly set on each durable subscriber. Upon
starting each subscriber e*Way (Subscribers and TAFRs) checks its own selector. If the selector
isnt set correctly the e*Way will check to see if any messages are queued for itself, and if no
messages are waiting the durable subscriber is recreated with the proper message selector. There
must not be any messages queued on the JMS Topic, because re-creating the Selector
automatically marks all queued messages as consumed.
But, if messages are waiting to be consumed the e*Way will write log file entries and shut itself
down without consuming any messages. The RIB Log entries tell the user to extract the
messages, fix the selector, and then re-publish the messages to ensure that the e*Way can make
sure the messages are to be processed or if it should be filtered out. Alternative procedures,
documented in the RIB Operations Guide, are also available.
This check and termination of the e*Way can be bypassed by changing a setting in the
rib.properties file:
default.MessageSelectorCheck=true (change to false if you want to skip this validation).
Subscriber Check
In JMS, a publisher can publish a message without a durable subscriber defined and no nondurable subscriber active. In this case, the JMS will silently throw away the message. This goes
against the RIB requirement that no messages are lost. The JMS API specification does not
contain anything regarding querying current subscribers and is considered an administration
activity. Our solution is to utilize the administrative commands available in the JMS
implementation to query subscribers at initialization for publishers and runtime for TAFRs.
When a publishing e*Way is started a JMS utility command is run (e.g. stcmsctrlutil for
SeeBeyond). The output for the command is then parsed looking for the number of subscribers.
If this number is non-existent or 0, the publisher then proceeds to shut down so that no messages
can be published. A corresponding exception is thrown to halt execution of collaboration logic.
The logic is the same for a TAFR, but this occurs at run-time (during a message publish), because
the topic to verify subscribers for is not known until a message is published. To aide in
performance, TAFR's maintain a cache of topics already verified and only runs the JMS utility
command only if it is publishing to a new JMS Topic.
This check and termination of the e*Way can be bypassed by changing a setting in the
rib.properties file:
default.SubscriberCheck=true (change to false if you want to skip this validation).

24

Chapter 3 Messaging system component overview

Enterprise Java Beans (EJBs)

Enterprise JavaBeans are a means to deploy application components without the developer
necessarily worrying about low-level implementation details such as threading, transaction
control, and load balancing.
EJBs are deployed within a J2EE Server container. It is the containers responsibility to
instantiate an EJB, provide a thread of execution and perform load balancing. Depending on how
the EJB is deployed and used, it may also be the containers responsibility to provide the
transactional context of calls made to the EJB.
There are two characteristics of EJBs: Session versus Entity and Stateless versus Stateful. All
RIB EJBs are Stateless Session Beans. This means that these Beans are not associated with a
specific database entity, but maintain a session with the client. It also means that no state is
preserved between bean activations.

Message Driven Beans (MDBs)

Message Driven Beans are used to process messages from one or more Java Message Server
Providers. The J2EE server is responsible for reading the message from the JMS provider and
delivering it to the MDB onMessage() procedure. The Application developer creates the
onMessage() method of the bean to implement all application specific logic.
For the J2EE deployment of the RIB, all of its MDBs begin by implementing the same code.
This is because a) the MDBs deployment descriptors describe the RIB interface enough for
Message Family specific processing and b) the Retek Binding Code enables the means for Retek
application specific processing. The Retek Binding code is discussed later.

Deployment Descriptors
The deployment of EJBs and MDBs are through XML files known as Deployment Descriptors.
Deployment Descriptors describe the attributes of a J2EE component in regards to what the
component is, the number of instances allowed and the transactionality of a request made to the
component.
Each application server has unique variances from other application servers in the available and
required XML tags found in its deployment descriptors. Hence, JBoss deployed EJBs use a
slightly different deployment descriptor than WebSphere specific deployment descriptors.
Fortunately, tools exist to easily create application server specific deployment descriptors.
Deployment descriptors also specify the selector a MDB is using. Standard RIB messages will
have a JMS message property, threadValue, set to a value defining a logical processing thread.
By default, threadValue has a value of 1. For messages being retried from the Error Hospital,
an additional property, retryLocation, is set to make sure only the original subscriber will receive
the message. Hence, most MDBs will have a selector of the form:
threadValue=1 and (retryLocation is null or retryLocation =
<mdbID> )

Where <mdbID> is the so-called locationID found in the location column of the error message.

25

Retek Integration Bus

One very important aspect of the deployment descriptors for RIB MDBs is the control of the
number of MDB instances and the number of messages retrieved from the JMS server at a single
time. The J2EE specification allows multiple MDB instances to retrieve multiple messages at a
single time from a specific JMS topic. The reason for this is to improve performance. However,
if one simply increases the number of MDBs reading from a topic or the number of messages
retrieved from the JMS, windows of opportunity arise for messages to be processed out of order.
To preserve sequencing, the RIB requires that each and every MDB deployed has exactly one
instantiation. Multi-threading the message processing must be done using separate deployment
descriptors which specify different JMS Selectors for each deployed MDB for a single Message
Family. Each JMS Selector then has a different threadValue value specified (e.g. threadValue
= 2 or threadValue = 3).

Transaction Managers
All RIB publishers and subscribers use an XA compliant two-phase commit operation to insure
that

A message is published if and only if the associated database transaction is successfully

committed.

A message is considered processed by the subscriber if and only if the associated processing
is successful.

An integral part of this is a J2EE component known as a Transaction Manager (TM ).

Transaction Managers have been around for at least as long as the XA specification and are an
integral part of three-tier client/server computing. The purpose of a TM is to start, end, and
control a transaction involving multiple resources such as databases or JMS Servers.
EJBs and MDBs for the RIB are configured to use container managed transactions. This means
that the J2EE container which hosts the bean controls the transaction. The container uses an
internal TM or by using a TM implemented elsewhere in the application server.
It should be noted that all RIB Bean components must require the use of a global transactions.
For MDBs, the transactionality of requests should be set that a Transaction is required and for
RIB EJBs, the transactionality of method calls should be set to Mandatory. Otherwise, a window
of opportunity exists whereby either a message is published twice to the JMS topic or the
message is lost.

Integrated Store Operations (ISO) components

The ISO platform is a low-cost Retek application server available for use in store systems.
Although this platform is not J2EE compliant, it is extremely similar to J2EE. Although some
differences in terminology exist, such as the use of the term ISO component versus EJB or
MDB, the same basic paradigm is used to describe the architecture. A critical component is the
usage of an XA compliant two phase commit. This insures that messages are removed if and only
if a successful processing has occurred.
For those applications using the ISO platform, the Java Open Transaction Manager is used to
control the two phase commitment operations. For more information on JOTM, see
http://jotm.objectweb.org .

26

Chapter 3 Messaging system component overview

RIB components
The SeeBeyond components listed above build and process RIB messages. This section lists the
subsystems deployed within these components and within other Retek application software. Each
RIB component has a dedicated task and is generally specific to one Message Family.

Old and New Stored Procedure Interfaces

In the initial RIB releases, all adapters used the same interface structure to the database. The
main facets of this design involved the use of Oracle CLOBs (Character Large Object Binaries)
as the means to pass information to and from an Oracle Stored Procedure. The stored procedure
was responsible for encoding and parsing the message payload.
Subsequent releases changed this API for interfaces requiring a high-level of performance. XML
creation and parsing is performed in the SeeBeyond e*Way adapter. The means to communicate
data to/from the stored procedure is performed via the use of Oracle Objects. These objects
provide a hierarchical container to store the XML and map one-to-one with all attributes and
elements found in the payload of a RIB message. There are also other changes to these interfaces
concerning the number and types of the parameters. Because of efficiencies gained by this and
other techniques, all new interfaces are developed using this technology. Furthermore, most
CLOB interfaces were retrofitted into using Oracle Objects as well. However, some CLOB
interfaces remain.
Additionally, the RIB must interface with Retek applications developed on the J2EE platform.
For this platform, the interface to the RIB is via a Message Driven Bean (MDB) for subscribers
and by using an Enterprise Java Bean (EJB) to publish messages to the RIB. This architecture
uses Payload Beans to communicate event information from the general purpose RIB code to
the application specific messaging processing logic.

RIB Database Objects

As mentioned above, some adapters and application interfaces use Oracle Objects to pass
information to and from the stored procedure. All of the Oracle Objects used to pass payload
information are created under the same base object, RIB_OBJECT. In other words, these payload
objects extend RIB_OBJECT or inherit from RIB_OBJECT. Because of this, they are
generically known as RIB Objects.
RIB Objects are used as both input and output parameters to the GETNXT() and CONSUME()
stored procedures. Because Oracle Objects are polymorphic, a single stored procedure may
accept or produce different RIB Object types, depending on the desired message to be published
or consumed.
One aspect of RIB Objects is that they are hierarchical in nature. Each RIB Object corresponds to
the DTD that defines the RIB Message payload. Oracle Objects do not provide support for
optional attributes or elements defined as a CHOICE, so a RIB Object will contain all possible
attributes or elements contained in a DTD.
RIB Objects use nested tables and nested objects to provide the hierarchical container. The
determination of whether a nested table of RIB Objects is used is determined on the cardinality of
the XML sub-node. If the sub-node has a cardinality of zero or one possible instantiations, then
a nested RIB Object is used. If the sub-node has a cardinality of zero or many, a nested table of
RIB Objects is used.

27

Retek Integration Bus

Database Schema Owner Requirements

The ownership of a RIB Object is critical to the correct functioning of the RIB. The owner of a
RIB Object must be the same as the owner of the packages in which these Database Objects are
used. If the application is installed under a different Oracle user-id than the RIB uses, then the
owner of the RIB Objects must be fully specified by the RIB adapter. When this scenario is
present, the owner of the package containing the GETNXT() or CONSUME() stored procedure is
determined and the assumption is that this user-id also owns the RIB Objects as well.
The implication of this is that when installing a Retek application under a different user-id,
synonyms for all of the packages containing GETNXT() and CONSUME() must also be present
for the RIB user-id. Furthermore, these appropriate privileges for accessing the RIB Objects and
executing the stored procedures must also be granted to the RIB user-id. Most often, the two
privileges needed for a separate RIB user-id above those normally granted are 'CREATE ANY
TYPE and 'EXECUTE ANY TYPE'.

RIB_XML database package

In previous releases, application specific Stored Procedures created or parsed XML strings stored
in CLOBS. Retek developed the RIB_XML PL/SQL Package to contain utility and helper
procedures for this.
Message validation: The RIB_XML package can perform message payload validation against a
Document Type Definition (DTD). This DTD is stored as a CLOB within the database. If the
publishing or subscribing application requests validation, the RIB_XML package API contains
parameters to extract the DTD from rib_doctypes table, parse the DTD and then validate the
message payload using the DTD.
The rib_doctypes table stores the DTD as a CLOB and associates the CLOB with a
message name. This table must be accessible within the user ID used to create or consume RIB
messages. Loading the rib_doctypes table may be performed using the DocTypeInserter java
application.

RIB_SXW database package

Another Oracle package has been developed for creating XML payloads in CLOBs, the
RIB_SXW package. This package provides no validation facilities, but better performance than
RIB_XML. It also does not contain any parsing functions.
This package also contains restrictions in how a message may be created, such as fully populating
an XML element with fields and sub-elements before moving to another node on the XML tree.

28

Chapter 3 Messaging system component overview

RIB_SETTINGS and RIB_TYPE_SETTINGS

PL/SQL stored procedures may use two tables to refine their behavior: RIB_SETTINGS and
RIB_TYPE_SETTINGS.
The columns in the RIB_SETTINGS table describe, on a per Message Family basis:

The number of threads to use when publishing. This is used by database triggers for
determining the thread value to use for scalability purposes. Not all application triggers will
use this value, but those that do (typically RMS interface points) will also implement and
verify that the RIB adapter also is configured to use the same value.

The maximum number of details to publish within a create, update, or delete message. Retek
applications typically do not have a limit to the number of details a specific business object
can have. Hence, a Purchase Order may be created containing tens of thousands of detail
lines each line a specific item/location combination. A single PO Create message
containing 30,000 or so lines will require a vast amount of resident memory to parse. This
column limits the PO Create and subsequent PO Detail Add messages to a set number of
details.

The number of minutes a publishing application may wait before publishing incomplete
business object create messages. This becomes important for business object publication that
is dependent on manual processes. The purpose of this is to limit the latency between an
actual business event and the publication of a message, when the message publication is
delayed. For example, recording items received at a warehouse within a specific shipment
may be performed by employees using hand scanners. For performance reasons, aggregating
all of these item receipts into a single RIB Message is desired. However, these employees
may be interrupted by a variety of disturbances (lunch, quitting time, a higher priority
shipment) and the complete shipment may not be scanned for some time. In this case, the
MINUTES_TIME_LAG column insures that all recorded items have a known maximum
latency between the scanning operation and the message publication. Note: not all
applications make use of this parameter.

The columns in the RIB_TYPE_SETTINGS table describe, on a per Message Family / Message
Type combination, whether informational and debugging log entries using the DBMS_OUTPUT
Oracle package and/or written to a log file. These entries are not used by all applications and
may in fact be only used by Retek Warehouse Management System (RWMS) interfaces.
Typically, they should only be used to debug performance or bugs found within an application.

29

Retek Integration Bus

Application message publishing triggers using CLOBsOracle Forms based or PL/SQL based RIB
applications use triggers to initiate the message publishing process. These triggers are RIB
specific and should be enabled only when an enterprise is using the RIB for integrating its
applications. These triggers are fired when a specific database table is modified. There are two
types of these triggers used by the RIB: those that create a CLOB to store the XML data
associated with the triggering business event and those that do not.
CLOB creation triggers assume that the application is responsible for the modified data. The
trigger retrieves all of pertinent information to create a specific type of message and inserts it into
a staging table using an application specific Message Family Manager (MFM) API.
The message information is usually stored as an XML string and is known as the RIB message
payload. The payload is contained in an Oracle Character Large Object Binary (CLOB). The
database table that holds the payload data must also maintain the following:

The order that messages are created

The CLOB containing the payload XML

Any routing or filtering key values

The message type associated with the business event that created the message. The message
type is specific to the Message Family and a single business event may produce multiple
messages of differing types within different families.

By storing all of the data within the same transaction as the business event, all RIB messages are
considered as being published synchronously with the business event even though the
message has not been processed by any EAI system deployed component.

Start

Application
Database
Table mod

Trigger
Collects
info

Create XML
payload
using
RIB_XML or
RIB_SXW
Package

Write XML,
routing info
to staging
table using
MFM

Figure 3.1 Trigger Processing -- XML CLOB

30

Trigger
Returns

Stop

Chapter 3 Messaging system component overview

Figure 3.1 displays the application trigger processing. The following steps are followed:
1

An insert/update/delete operation on a table causes a RIB application trigger to be executed.

The trigger was installed and enabled as part of the RIB installation.

The trigger collects any information it needs to continue. This may involve additional
database operations.

The trigger leverages either the RIB_XML or RIB_SXW package to build the XML payload
for this message type. An Oracle CLOB is created to store the XML payload.

The trigger calls the Message Family Manager package to store the message into a staging
table. The specific API that is called is the ADDTOQ() procedure.

The trigger returns.

Note: CLOB creation triggers insure that all available data needed for creating the final
XML is available within the same transaction as the triggering event. Because of this,
there are no windows of opportunity for data to become out of sync with the published
message.

Application message publishing triggers using RIB Objects

One problem with CLOB based triggers is the per-detail overhead required. Part of the overhead
involves the performance characteristics creating a CLOB. Furthermore, if a Purchase Order
contains thousands of detail lines, then the detail table trigger needs to be fired thousands of
times. Compounding this problem is the fact that many times a Retek application will fire the
same trigger multiple times within a single transaction for the same data row. Because of
problems with triggers maintaining context information, this implies that the same logic is
implemented multiple times. This leads to performance problems either to maintain the correct
version of the business object in the MFM staging table or requiring extra messages to be
published.
For high-volume interfaces, CLOB creation triggers are not used. Instead, detail table triggers are
implemented that perform a minimum amount of processing. Many times these triggers simply
check to see if the business object containing the detail has been published or does not require an
approval to be performed. If so, the data required to create a Detail Add, Detail Update , or
Detail Delete message is inserted into a staging table. Because XML strings are not created
and CLOBS are not used, these operations are very efficient. If the business object requires an
approval operation to be performed before it can be published, it is assumed that the correct data
will be made available when the approval takes place.
When a message is ready for publication, the Message Family Manager GETNXT() Stored
Procedure examines its staging tables and creates the appropriate RIB Object for publication. In
many cases, these staging tables contain columns that are themselves declared a specific type of
RIB Object. Once the complete RIB Object is ready, the GETNXT() Stored Procedure returns
this to the adapter, which then converts the information into an XML string. This XML string is
then placed into a RIB Message payload
Note that one implication of these triggers is that multiple staging tables may be needed for a
single Message Family: One to hold Header level information and one for detail level
information. Furthermore, the lifecycle of the Header table must map to the lifecycle of
application business object itself header information must be maintained for all periods of time
that operations are valid against that business object. In other words, the header information must
be kept until the business object is either deleted or considered closed.
31

Retek Integration Bus

RIB Objects: an in-depth view

RIB Objects use the Oracle Objects type introduced into the Oracle Database in the Oracle 8i
release. This is an object-based technology that allows a developer to create database types that
are hierarchical in nature and can leverage type inheritance and polymorphism. Furthermore,
methods may be defined for each type similar to C++ and Java objects.
RIB Objects all inherit from a single base object type, RIB_OBJECT. A new RIB object type is
created for each node on a messages XML DTD. An example of a script used to create a
simple, flat RIB Object is seen below:
CREATE OR REPLACE TYPE RIB_FrtTermDesc_REC UNDER RIB_OBJECT (
freight_terms
term_desc

VARCHAR2(30),

VARCHAR2(240),

enabled_flag

VARCHAR2(1),

start_date_active DATE,
end_date_active

DATE,

overriding member procedure appendNodeValues( i_prefix in

varchar2)
);
/
CREATE OR REPLACE TYPE BODY RIB_FrtTermDesc_REC AS
overriding member procedure appendNodeValues( i_prefix in varchar2)
IS
tbl RIB_object_tbl;
l_new_pre varchar2(4000);
begin
rib_obj_util.g_RIB_element_values(i_prefix||'freight_terms') :=
freight_terms;
rib_obj_util.g_RIB_element_values(i_prefix||'term_desc') :=
term_desc;
rib_obj_util.g_RIB_element_values(i_prefix||'enabled_flag') :=
enabled_flag;
:=

rib_obj_util.g_RIB_element_values(i_prefix||'start_date_active')
TO_CHAR( start_date_active, RIB_obj_util.g_date_format)

;
rib_obj_util.g_RIB_element_values(i_prefix||'end_date_active') :=
TO_CHAR( end_date_active, RIB_obj_util.g_date_format)
;
END AppendNodeValues;
END;
/

32

Chapter 3 Messaging system component overview

The first block of code creates the type specification. This defines the attributes stored by the
RIB_OBJECT and declares that this object type inherits from the RIB_OBJECT type. The
second block of code creates the type body containing the method, appendNodeValues(). This
method is used only for debugging purposes.
For hierarchical structures, the leaf or child RIB Objects must be created before the trunk
or parent objects. The script below creates a hierarchical structure that contains a single header
and many details:
CREATE TYPE RIB_Detail_REC UNDER RIB_OBJECT (
varchar_detail VARCHAR2(20),
number_detail

NUMBER(4,0),

date_detail

DATE,

overriding member procedure appendNodeValues( i_prefix in

varchar2)
);
/
CREATE TYPE BODY RIB_Detail_REC AS
overriding member procedure appendNodeValues( i_prefix in varchar2)
IS
tbl RIB_object_tbl;
l_new_pre varchar2(4000);
begin
rib_obj_util.g_RIB_element_values(i_prefix||'varchar_detail') :=
varchar_detail;
rib_obj_util.g_RIB_element_values(i_prefix||'number_detail') :=
number_detail;
rib_obj_util.g_RIB_element_values(i_prefix||'date_detail') :=
TO_CHAR( date_detail, RIB_obj_util.g_date_format);

END AppendNodeValues;
END;
/
CREATE TYPE RIB_Detail_TBL AS TABLE OF RIB_Detail_REC;
/

CREATE TYPE RIB_Header_REC UNDER RIB_OBJECT (

Varchar_header VARCHAR2(10),
Number_header
Date_header
Detail_tbl

NUMBER(12,4),
DATE,
RIB_Detail_TBL,

33

Retek Integration Bus

overriding member procedure appendNodeValues( i_prefix in

varchar2)
);
/
CREATE TYPE BODY RIB_VendorHdrDesc_REC AS
overriding member procedure appendNodeValues( i_prefix in varchar2)
IS
tbl RIB_object_tbl;
l_new_pre varchar2(4000);
begin
rib_obj_util.g_RIB_element_values(i_prefix||'varchar_header') :=
varchar_header;
rib_obj_util.g_RIB_element_values(i_prefix||'number_header') :=
number_header;
rib_obj_util.g_RIB_element_values(i_prefix||'date_header') :=
TO_CHAR( end_date_active, RIB_obj_util.g_date_format);

l_new_pre :=i_prefix||'detail_TBL.';
FOR INDX IN detail_TBL.FIRST()..detail_TBL.LAST() LOOP
detail_TBL(indx).appendNodeValues(
i_prefix||indx||'detail_TBL.');
RIB_obj_util.g_RIB_table_names(l_new_pre) := indx;
END LOOP;

END AppendNodeValues;
END;
/

34

Chapter 3 Messaging system component overview

In the hierarchical example, three types are created: RIB_detail_REC, RIB_Detail_TBL, and
RIB_Header_REC. The RIB_header_REC type contains a table of Details. Since the size of this
table is unbounded, it must be declared as a nested table type (RIB_Detail_TBL). The resultant
object types created have a one-to-one mapping to the following DTD:
<!ELEMENT header (
varchar_header
, number_header
, date_header
, details+
)>
<!ELEMENT details (
varchar_detail
, number_detail
, date_detail
)>
<!ENTITY % varchar2 "(#PCDATA)">
<!ENTITY % number "(#PCDATA)">
<!ELEMENT year %number;>
<!ELEMENT month %number;>
<!ELEMENT day %number;>
<!ELEMENT hour %number;>
<!ELEMENT minute %number;>
<!ELEMENT second %number;>
<!ENTITY % date "( year, month, day, ( hour, minute, second )? )">
<!ELEMENT varchar_header %varchar2; >
<!ELEMENT number_header %number; >
<!ELEMENT date_header %date; >
<!ELEMENT varchar_detail %varchar2; >
<!ELEMENT number_detail %number; >
<!ELEMENT date_detail %date; >

Note: Dropping Oracle Object types must use the FORCE keyword if there any types
or tables that are dependent on that type. Once an Oracle Type is dropped, all dependent
types and table columns are marked has invalid and must be recompiled or re-created.

35

Retek Integration Bus

RIB Object to XML Translation

Parsing the XML to create a RIB Object and creating XML from a RIB Object are performed
using different Java classes. A basic overview of these techniques is listed here.
For publishing, the adapter uses a class that implements the
com.retek.rib.collab.OracleObjectPublisherTranslator interface. A class that implements this
interface is known as a PubTrans class. A PubTrans class is coupled to the DTD of the
resultant XML and the structure of the RIB Object. As such, each Message Family publisher
must have its own PubTrans class. When an Rib Object is returned by a call to a GETNXT()
PL/SQL Stored Procedure, The correct PubTrans class is instantiated and used to create the
correct XML payload text.
For subscribing adapters calling the CONSUME() PL/SQL API, translation is performed by
examining the structure of the RIB Object and pulling out XML attributes with the same names as
the RIB Object attributes. The process followed is:
1

During the collaboration rule initialization, a mapping is created that associates the correct
Oracle RIB Object type name, the correct CONSUME() parameter list and a message type for
all message types known by the collaboration rule.

The mapping process will involve examining and storing the Oracle RIB Object structure
definition. The characteristics of each RIB Object attribute whether it is a scalar value, a
date, a nested RIB Object or a table of nested RIB Objects is also stored.

A SAX parser is created to parse the XML payload. A parameter to the handler for the parser
is the OracleObjectDescriptor mappings.

For each RibMessage node payload, the SAX Parser is invoked and the appropriate JDBC
driver STRUCT object is created. Then, the CONSUME() method is called.

Non-trigger PL/SQL publishing

Some applications may not use triggers to start the publishing process. Some alternatives used
are:

Using an insert into the MFM staging table directly from Oracle Forms. In this case, the logic
to create the CLOB and insert it into the MFM staging table is found in a stored procedure
referenced directly by the Oracle Forms based application.

Using upload tables to stage the information until ready to publish. In this scenario, the
message is not bound to the XML format until the Message Family Manager GETNXT()
stored procedures invoked. GETNXT() is described in the next section.

Using a file to create the RIB Messages. This would typically be used for interfaces from
external systems.

Using a RIB Publishing EJB within the J2EE platform.

Using a RIB Publishing Component within the ISO platform.

In first two cases above, the information contained in the message published to the bus is stored
within the same transaction as the business event. The actual technique used to kick off a
messages publication is described in more detail in the Retek 11.0 Integration Guide.

36

Chapter 3 Messaging system component overview

Message Family Manager API

Each PL/SQL based application uses a Message Family Manager (MFM) specific API for
publishing all messages within a specific Message Family. This API is the interface to a stored
procedure package and wrappers the staging table and additional business logic surrounding the
message publication. A single application is responsible for publishing all messages within a
single MFM.
Because the same application can publish multiple Message Families, it could use multiple MFM
specific packages, one per MFM.
There are two procedures typically included in an MFM package:
ADDTOQ()
The purpose of ADDTOQ() is to store message state, routing / filtering keys, message type, XML
Payload, and other information needed to create a RIB Message. This procedure has the following
format for its parameter footprint for CLOB creation based publishers:
PROCEDURE ADDTOQ( O_status_code
OUT
VARCHAR2,
O_error_text
OUT
I_message_type
IN
I_message
IN
I_msg_1
IN

VARCHAR2,
VARCHAR2,
CLOB,
tbl.msg_spec_1%TYPE,

);
where
O_status_code

Denotes the status of the call. The value of this is found

in the RIB_CODES package. Possible values include:
MFM_FATAL_ERROR cannot insert a message due
to an error.
MFM_SUCCESS successful message insertion.

O_error_text

This is text associated with an error or warning

occurring in the call to ADDTOQ.

I_message_type

Type of the message payload. A specific type is

associated with one or more business events. This type is
a further subdivision of the Message Family.

I_message

The message payload formatted as an XML string.

I_msg_1

A Message Family specific facility type, key, or other

information that is supposed to be present in the message
envelope. This is an optional parameter and may not be
present. The type of this parameter is specific to the
Message Family.

Additional optional parameters. These are dependent on

the Message Family in use.

37

Retek Integration Bus

For RIB Object based publishing, the ADDTOQ() is dependent of the Message Family, the RIB
Object required, and the trigger used to publish. The parameter list is thus extremely specific to
the business object or business detail involved. An example of a RIB Object ADDTOQ() is seen
below for the RMSMFM_ORDERS package:
ADDTOQ(O_error_message OUT VARCHAR2,
I_message_type
IN ORDER_MFQUEUE.MESSAGE_TYPE%TYPE,
I_order_no
IN ORDHEAD.ORDER_NO%TYPE,
I_order_header_status IN ORDHEAD.STATUS%TYPE,
I_supplier
IN ORDHEAD.SUPPLIER%TYPE,
I_item
IN ORDLOC.ITEM%TYPE,
I_location
IN ORDLOC.LOCATION%TYPE,
I_loc_type
IN ORDLOC.LOC_TYPE%TYPE,
I_physical_location IN ORDLOC.LOC_TYPE%TYPE)

In this case, only the minimum amount of information is available in the API for ADDTOQ().
Additional information will be queried either within ADDTOQ() or within the GETNXT() Stored
Procedure.
GETNXT()
Retrieves the record from the staging table for publication. This procedure uses the following
parameter signature for CLOB creation based publishers:
PROCEDURE GETNXT( O_status_code
OUT
VARCHAR2,
O_error_text
OUT
VARCHAR2,
O_message_type
OUT
VARCHAR2,
O_message
OUT
CLOB,
O_msg_1
OUT
tbl.msg_spec_1%TYPE,

);
where
O_status_code

Denotes the status of the call. The value of this is found

in the RIB_CODES package. There are for possible
values:
MFM_FATAL_ERROR cannot retrieve a message due
to an error. Publisher should exit.
MFM_WARNING the next message cannot be
published because of a sequencing problem.
MFM_SUCCESS successful message retrieval.
MFM_NO_MSG no messages are waiting to be put
onto the integration bus.

38

Chapter 3 Messaging system component overview

Text associated with an error or warning.

O_error_text
O_message_type

Type of the message payload. A specific type is

associated with one or more business events.

O_message

The message payload formatted as an XML string.

O_msg_1

A Message Family specific facility type, key, or other

information that is supposed to be present in the message
envelope. The Type of this parameter is specific to the
Message Family.

Additional optional Message Family specific parameters.

For RIB Object publishers, the minimum signature of a Stored Procedure is shown below. Note
that for a given GETNXT(), there may be additional parameters. The values of these parameters
are typically specified in the RIB Properties file.
PROCEDURE GETNXT( O_status_code
O_error_text
O_message_type
O_message
O_bus_obj_id
O_routing_info
I_num_threads
IN
I_thread_val
IN
where
O_status_code

OUT
OUT
OUT
OUT
OUT
OUT

VARCHAR2,
VARCHAR2,
VARCHAR2,
RIB_OBJECT,
RIB_BUSOBJID_TBL,
RIB_ROUTINGINFO_TBL,
NUMBER DEFAULT 1,
NUMBER DEFAULT 1)

Denotes the status of the call. The value of this is found

in the RIB_CODES package. There are for possible
values:
MFM_FATAL_ERROR cannot retrieve a message due
to an error. Publisher should exit.
MFM_SUCCESS successful message retrieval.
MFM_NO_MSG no messages are waiting to be put
onto the integration bus.
MFM_HOSPITAL put the message into the error
hospital

O_error_text

Text associated with an error or warning.

O_message_type

Type of the message payload. A specific type is

associated with one or more business events.

O_message

The message payload as a RIB Object. The actual type

used is dependent on the Message Family and Message
Type for this RIB Message. Note that many Message
Types may use the same RIB Object to convey data.

39

Retek Integration Bus

40

O_bus_obj_id

An identification of the ID of the business object

associated with the message. This ID is unique to the
Message Family. The Business Object ID may be a
composite entity for example a combination of an
ASN and a distribution center ID. RIB sequencing
automatically insures that all messages for a specific
Business Object ID are delivered in the correct order.

O_routing_info

Certain Message Family messages require routing

operations by TAFR adapters. The information used to
route these messages is found in the RIB Message
envelope. In the CLOB creation interface, each Message
Family had its own set of specific parameters it returned
to populate these fields. In the RIB Object creation
interface, the O_routing_info parameter contains this
information.

I_num_threads

The total number of threads used in publishing. This

value comes from the rib.properties file and should
match the same entry in the RIB_SETTINGS table.

I_thread_val

An identification that this call is made for publishing

messages specific to a specific thread. This value will be
attached as the threadValue property associated with
the published RIB Message.

Chapter 3 Messaging system component overview

General Publisher and Subscriber Component

Architecture for PL/SQL Applications
In the 11.0 release of the RIB, the interface to PL/SQL applications within the SeeBeyond
environment became driven more by configuration file entries than by Java code exposed in a
SeeBeyond Collaboration Rule. This reduces the need to write new code for new interfaces.
Instead, one configures a new e*Way to contain the correct RIB existing Collaboration Rule and
then describes the PL/SQL API to the Collaboration Rule. There is one Collaboration Rule for
Publishers (crGeneralPublisher) and one for subscribers (crGeneralSubscriber).
For customers with Legacy interfaces written using earlier versions of the RIB, most of the earlier
classes exist and still work. However, if migrating to the 11.0 RIB, these collaboration rules may
need to be recompiled. Furthermore, many of these classes have been declared as Deprecated.
Component Configuration File
The RIB Collaboration Rules must be able to handle a variety of specific PL/SQL
implementations of the GETNXT() and CONSUME() Stored Procedures. Although most have
exactly the same parameters, many differences are found due to the business logic needed to
efficiently process the incoming or outgoing message.
The first major variation is the mechanism used to communicate message payload information:
CLOBs versus RIB Objects. Another variation is some CONSUME() procedures return data that
should be published to the JMS for scalability or other reasons. Within the CLOB versions of
GETNXT(), some versions have output parameters used for Business Object IDs or other
purposes. To handle these variations, an XML configuration file is used named component.xml.
This file must exist in the class path of the e*Way and usually contains entries for all e*Ways.
The standard location for this file is directory $EHOME/client/classes.
Sample section of Component.xml file for a single eway is found below. Note: the example
describes a fictional subscriber to a fictional Message Family known as an Audit Notice. This
subscriber may publish an outgoing message that is a PanicCre Message Type The AuditNotice
Message Family contains the AuditNoticeCre, AuditNoticeMod, AuditNoticeDel, and PanicCre
Message Types.
<eway name="ewAuditNoticeToRMS">
<collaboration name="colAuditNoticeToRMS">
<adaptorComponent>
<class>com.retek.rib.collab.general.OracleObjectSubscriberCompone
ntImpl</class>
<messageFamily name="AuditNotice">
<translatorClass>com.retek.rib.pubtrans.AuditNoticeTranslator</trans
latorClass>
<rePubMessageType>PanicCre</rePubMessageType>
<rePubOracleObjectType>RIB_PANICDESC_REC</rePubOracleObjectType>

41

Retek Integration Bus

<storedProc>
<signature>{call
RMSSUB_AUDITNOTICE.CONSUME(?,?,?,?)}</signature>
<outParameter index="6">
<type>
<value>ARRAY</value>
<name>RIB_ERROR_TBL</name>
</type>
<toJavaField>ID</toJavaField>
<toJavaField>ROUTING_INFO.TO_LOCATION</toJavaField>
</outParameter>
</storedProc>
<messageType name="AUDITNOTICECRE">
<oracleObject>RIB_AUDITNOTICEDESC_REC</oracleObject>
</messageType>
<messageType name="AUDITNOTICEMOD">
<oracleObject>RIB_AUDITNOTICEDESC_REC</oracleObject>
</messageType>
<messageType name="AUDITNOTICEDEL">
<oracleObject>RIB_AUDITNOTICEREF_REC</oracleObject>
</messageType>
</messageFamily>
</adaptorComponent>
</collaboration>
</eway>

eway -- name of e*Gate e*Way (or module name).

collaboration -- name of collaboration (or sub-module name) within the e*Way.

adaptorComponent this tag delimits the adaptor configuration used by the collaboration.

class -- Class name of the actual AdaptorComponent implementation to use. This class
controls the variances needed for CLOB versus RIB Object payload data communication or
other major variation in processing.

messageFamily The processing specifics for the Message Family this AdaptorComponent
will process messages for. Currently, only a single Message Family is supported.

42

Chapter 3 Messaging system component overview

storedProc stored procedure to call. This tag may be found either under the
<messageFamily> tag or under the <messageType> tag, depending whether different PL/SQL
stored procedures must be called for different Message Types.

outParameter this optional tag contains any additional parameters used as output from
the Stored Procedure. The minimal parameter set is determined by the payload
communication mechanism (CLOB versus RIB Object) and if CONSUME() or GETNXT() is
called.

type(within outParameter) encapsulates the tags that define the Oracle type of out
parameter.

value(within outParameter/type) possible values are

VARCHAR or VARCHAR2

INT, INTEGER, BIGINT or NUMERIC

STRUCT or ARRAY

name(within outParameter/type) used only if value is STRUCT or ARRAY, is the

RIB_OBJECT or Array Type name. This must be a valid Oracle Collection or Oracle Object
type.

toJavaField - mapping for out parameter value to a Rib Message tag, possible values are ID,
or ROUTING_INFO.<routing_info_name>

messageType Message type within MessageFamily name of valid message type.

oracleObject Oracle Object type name used to contain the payload data for the message
type. This tag is only used for RIB Object subscribers. (Remember, a RIB Object is a RIB
specific Oracle Object database type.)

translatorClass class to use to republish a RIB_OBJECT out object. This is only used by
the OracleObjectSubscriberRePublisher for publishing RIB Objects output by a CONSUME()
Stored Procedure. This class must be a valid PubTrans class.

rePubMessageType message type to set on outgoing message. This is only used by the
OracleObjectSubscriberRePublisher for publishing RIB Objects output by a CONSUME()
Stored Procedure.

rePubOracleObjectType Oracle database type name of RIB Object used as the out
parameter. This is only used by the OracleObjectSubscriberRePublisher for publishing RIB
Objects output by a CONSUME() Stored Procedure.

43

Retek Integration Bus

How to use Adaptor Components

To take advantage of this architecture all that is required is to create a new e-way with a new
collaboration using one of the following collaboration rules accordingly.
Collaboration
Rule

AdaptorComponent
Impl

Functional Description and typical

configuration needs

crGeneralPublisher

OracleObjectPublisherComponentImpl

Standard OO publisher, very straight

forward config, usually no additional out
parameters.

crGeneralPublisher

CLOBPublisherComponentImpl

Standard CLOB publisher, uses additional

out params for Routing Info and ID fields
on RibMessage.

crGeneralSubscriber

OracleObjectSubscriberComponentImpl

Standard OO subscriber, needs mapping

for message types to Oracle Object
names.

crGeneralSubscriber

CLOBSubscriberComponentImpl

Standard CLOB subscriber, very straight

forward, usually very little custom params
needed.

crGeneralSubscriber

OracleObjectSubscriberComponentNonXAImpl

NonXA OO subscriber, configured same

as regular OO subscriber, does DB
commit within code is main difference.

crGeneralSubscriber- OracleObjectSubscriberRePublisher
RePublisherComponentImpl

44

OO subscriber, with an Oracle Object out

parameter, that is to be republished onto a
different topic. Requires extra out param,
rePubMessageType,
rePubOracleObjectType, and
translatorClass properties.

Chapter 3 Messaging system component overview

Publishing application adapters using PL/SQL

interfaces
Oracle PL/SQL based applications publish messages using at least two separate database
transactions, as seen in Figure 3-2. The first transaction consists of the application specific
insert/update/delete operations that perform some business functionality. These operations occur
independently of the RIB. However, when the RIB is active, additional triggers are enabled on
these tables that insert information into staging tables for later publication. This data may be a
CLOB, or as stored within a standard SQL type.
The second transaction is controlled by the publishing adapter. A RIB Publishing Adapter polls
the staging table by calling another routine in the MFM called GETNXT(). This type of
operation is known as a Pull, since the adapter pulls the data from the database. The MFM
GETNXT() PL/SQL stored procedure may contain simple or complex logic that is specific to
the Message Types published. For example, a simple Create Vendor message may involve
merely selecting and then deleting a single record from the vendor staging table. On the other
hand, a Create Purchase Order message requires fairly complex logic to create because of the
business process dependencies. Many changes may be made to a PO before it is approved.
When the call to the MFM GETNXT() returns the data to the publishing adapter, a RIB Message
is created from the payload (and other) GETNXT parameters. This message is then published to
a Java Message Service (JMS) Topic (sometimes called a RIB Queue).

Note: In the Java Message Service nomenclature, one puts a message onto a JMS
Topic for Pub/Sub operations. One puts a message onto a JMS Queue when only a
single subscriber will ever receive the message. The RIB assumes that any published
message may have multiple subscribers and hence only uses JMS topics.

The publishing adapter may call the GETNXT() Stored Procedure multiple times within the same
database transaction. When message data is returned, the associated XML String is created and
placed within the <messageData> tag. (See Chapter 2 for more information on the message
structure). <messageData> is a sub-element of <ribMessage>.
In each published message, the <RibMessages> tag wrappers one or more <ribMessage> tags.
Under normal circumstances, GETNXT() is called until either a configured maximum number of
times or until GETNXT() returns a No Data Found status. Note that a single database
transaction maps one-to-one with the publication of the <RibMessages> tag.
An XA compliant two-phase commit operation is then performed to insure that all operations on
the database and the JMS Topic are performed atomically. I.e. either the data is deleted from the
database and published to the JMS Topic, or neither deletion nor publication occurs.

Note: XA is a Distributed Transaction Processing specification originally developed in

1991. It is now available from The Open Group. Copies of this standard (C193
Distributed TP: The XA Specification ISBN 1-872630-24-3) are available from The
Open Groups website, http://www.opengroup.org.

As long as the GETNXT() procedure returns data to populate at least one <messageData> tag, the
publishing adapter will immediately publish the message and repeat the process. If GETNXT()
only returns a No message available status, the publishing adapter will sleep a configured
amount of time before it tries to call GETNXT() again. A rollback operation will be performed if
no messages are published.
45

Retek Integration Bus

The message resides in a network queue immediately after publication. This queue provides
stable storage for the message in case of a system crash occurring before all message destinations
receive and process it.

Table
Trigger

Oracle
Forms or
Batch
Application

(1) Application
updates , deletes or
inserts into table

Publishing adapter (e*Way).

(3) Trigger
identifies
operation. For
CLOBs, creates
XML String

(7) Adapter
Polls calling
MFM GetNxt()
Stored
Procedure

(2) SQL
operation
Fires Trigger

Application
Database
Table

(10) Creates RIB message from

Payload and other data. For RIB
Object interfces, payload XML is
created.
Steps 7 - 10 repeated as per
message availability and
adapter cofiguration.
(12) Adapter Commits all database
and message operations

(4)Trigger calls
MFM addToQ()
"Payload", Bus. Obj.
ID, Threading, and
Routing Info

Message Family Manage (MFM)

(Oracle PL/SQL Package)

Retek Application
controlled
Transaction

(5) AddToQ() Inserts

Payload, other data into
Staging Table

Staging
Table
(aka Msg.
Family
Queue)

(8) GetNxt()
Selects, updates,
aggregates, deletes
data from Staging
Table

(9) GetNxt()
Returns
Payload, Bus.
Obj ID, other
data

Publishing Adapter
Controlled Transaction
(2 Phase Commit
involving Oracle and
JMS Provider)

Sucessful Message Publication Process

Figure 3-2

46

(11) Adapter
Publishes
RIB Message
to JMS Topic

JMS Topic

(6) Application
commits all changes

Chapter 3 Messaging system component overview

TAFR Adapter Process

A Transformation Address Filter/Router (TAFR) adapter is another e*Way adapter that is used to
process data. It contains one or more collaborations that perform TAFR operations on all
messages from a single Message Family. The specific activities performed are dependent on the
needs of its subscribers.
Figure 3.3 illustrates the activities associated with a TAFR adapter. These include:

The TAFR performs its needed filtering and transformation processing on the message.

If the message is to be routed to one or more destinations, the message contents are copied
into a new SeeBeyond Event Type. This event type is specific to the destination. Hence, if an
Advance Ship Notice Inbound message needs to go three different warehouses, then the full
contents of the message is published to the integration bus as three different events using
three different event types. This allows for each of these messages to be published to different
queues.

T A F R A dapter (e*W ay)

(2) T ransform ations are
perform ed, if any
(3) destination JM S
T opics are determ ined. If
no destinations are
found, the m essage is
disc arded

JMS Topic

T A F R A d ap ter
C ontrolled transaction
(2 phase com m it
invo lvin g m u ltip le JM S
P roviders)

(4) R IB M essage
published to
appropriate
des tination topic(s)

...

(1) T A F R pulls m essage from

JM S T opic

JMS Topic

JMS Topic

A message is delivered to the TAFR adapter collaboration after it has been placed onto a JMS
topic. This triggers the collaboration logic.

JMS Topic

T A F R P rocess
Figure 3-3

47

Retek Integration Bus

Subscribing Adapter Overview

Subscribing adapters are responsible for insuring that messages are processed in the correct
sequence for a given business entity. For a specific Purchase Order, its Create Purchase Order
message must always be processed before an update or delete message. Furthermore, all updates
must be processed in the correct order to insure that two systems are correctly synchronized. But
no such guarantee exists when comparing messages concerning different business entities. If no
errors occur, messages are processed in a First-In, First-Out (FIFO) order. Alternatively, if an
error occurs processing a message for one business object (PO #123), then other messages that
apply to other business objects (POs #124, #125) should still be processed. Furthermore, all
messages for the problem business object (PO #123) will be held in the Error Hospital.
If an error occurs during message processing a two-step process is followed: First, the subscribing
adapter notes this internally (NOT in the database) and rolls back all database work associated
with the message. Next, the JMS server re-sends the message to the adapter (since it has yet to be
processed successfully), the adapter will now recognize this message is problematic (sick) and
checks it into an Error Hospital database.
A subscribing adapter always checks the hospital database to see if there are any messages in the
hospital that act on the same business entity (such as a PO) that the current message does. If so,
then the adapter immediately places the current message in the hospital as well. This is to insure
that all messages for a given business entity are processed in the correct order. Without manual
intervention, the RIB will always process the Sick messages for a business object before any
subsequent messages that act on the same business object.
After a message is checked into the Error Hospital, a Hospital Retry adapter/e*Way/Daemon is
used to re-post the message to the JMS in order to retry its processing. The assumption here is
that the error is a transitory one records locked or there is an external dependency that has not
been met. The number of times a message is retried is configurable.

48

JMS Topic

Chapter 3 Messaging system component overview

(1) Subscriber pulls

message from JMS
Topic

(4)Subscribing Adapter
calls correct MFM
Consume() procedure

Subscribing
Adapter
(2) Checks if message
should immediately go into
the Error Hospital. If so,
puts it into the hospital
and returns success.

Message Family
Manager (MFM) (Oracle

(3) Determines correct

MFM Consume() PL/SQL
Stored Procedure to
handle message type
(8) If failure, mark
message to go into
hospital, return failure. If
success, return success.

PL/SQL Package)
(5) Consume procedure
parses XML payload
(7) MFM
Consume()
procedure
returns succss
or failure

Subscribing Adapter
Controlled transaction
(2 phase commit
involving JMS Provider
and Oracle)

Application
Database
Tables

(6) Consume
procedure
updates, inserts,
and/or
manipulates
application tables

Subscription Process for PL/SQL

Interfaces
Figure 3-4

49

Retek Integration Bus

Figure 3.4 illustrates the processing involved for these messages handled by a normal PL/SQL
CONSUME() Stored Procedure:
1

The appropriate collaboration is triggered by a message from a JMS provider. This message
may arrive on the JMS topic from the Error Hospital, from a publishing adapter, or from a
TAFR adapter.

The Error Hospital Java code is called to see if this message should immediately be placed
into the Error Hospital. This logic will check
a

To see if any previously processed messages for the same business entity is in the
hospital. If so, then this message needs to be put into the Error Hospital to preserve
message sequencing.

If this is the second time this message was processed because the stored procedure
returned an error the first time. If so, then the expectation is that the message needs to
wait a while before it is retried. The message is placed into the Error Hospital to allow
other messages to flow through during this time.

If the message is placed into the Error Hospital in this step, the database work is committed
and the message is removed from the JMS topic. Steps 3-6 are not executed.
3

The correct Message Family Manager stored procedure is called. The specific stored
procedure called is based on the message type of the message.

The stored procedure executes the appropriate application specific logic. This may involve
direct updating of application logic or simply inserting the data into staging tables.

If step 4 returns an error, the message is flagged as bad (see step 2), and the transaction will
be rolled back. The message is kept on the JMS topic. The next time the message is
processed, it will be put into the Error Hospital.

If step 4 returns success, the collaboration returns success: all database updates are committed
and the message is removed from the JMS topic.

At the end of each attempt to process a message, it is found in exactly one of three locations: Still
on the JMS topic (because of a stored procedure problem), in the Error Hospital, or successfully
consumed by the subscribing application.

50

Chapter 3 Messaging system component overview

Subscribing PL/SQL Stored Procedure Message Family Manager Packages

The concept of a Message Family Manager (MFM) is also used with message subscriptions
within the RIB. As in the publishing side of processing, the subscribing MFM is only concerned
with the XML Payload and not the entire RIB Message XML.
All MFM packages that parse and process the payload within a RIB message have the same
procedure name (CONSUME) and the same basic parameter list. An example is seen below:
PROCEDURE CONSUME(O_status_code
O_error_message
I_message

IN OUT
OUT
IN OUT

VARCHAR2,
VARCHAR2,
CLOB);

where
O_status_code is the success/failure status of the procedure call. The

values of this parameter that are standard across all subscribing packages
are found in the RIB_CODES package. Currently, these include:
SUB_FATAL_ERROR A fatal error was encountered processing the

payload.
SUB_XML_PARSE_ERROR The payload could not be parsed due to a

validation error.
SUB_SUCCESS The payload was processed successfully
O_status_code may also contain values that are application
specific. These values must not conflict with those listed above.
These values should be listed in the Retek 11.0 Integration Guide.
O_error_message is text associated with any error condition.
I_message is the payload XML text used as input to the stored

procedure.
For RIB Object subscribing applications, the I_message parameter is
declared to be of the type RIB_OBJECT.

Additional parameters may be present, depending on

the specific MFM/Message Type that is processed.

whether the CONSUME procedure also returns a RIB Object to be published.

Also note that MFMs using CLOB based APIs use multiple PL/SQL packages, one per Message
Type, while RIB Object based APIs use a single PL/SQL package for all Message Types within
an MFM.

51

Retek Integration Bus

Error Hospital Overview

The Error Hospital is a set of Java Classes and database tables that are designed to segregate and
trigger re-processing for messages that either:

Had some error with their initial processing.

or

Update the same business entity with messages already in the Error Hospital.
As of the RIB 11.0 release, some publishers will return an H status to denote a problem
creating a new message for a specific business object. This status may be due to database
locks being held by on-line users of an Oracle Forms application. It could also be due to
some data incompatibility found in the GETNXT() procedure. In any case, whenever a
publisher recognizes that a message for a business object cannot be published due to one of
these conditions, the message must go into the Error Hospital.
Of course, if a subscriber encounters any errors processing a message, it will also put
messages into the Error Hospital.

Each time the message is re-processed, a record is kept of the event along with the results. The
intent is to provide a means to halt processing for messages that cause errors while allowing
continued processing for the good messages.
If a message is to be inserted into the Error Hospital because of an error during processing, it is
sent to the subscribing collaboration twice. This is because subscribing collaborations are
executed within the context of a distributed transaction, using the XA two-phase commit
protocol. This transaction is controlled by the e*Way infrastructure: If the collaboration returns
success, the message is removed and all database work committed. If the collaboration returns
failure, the message never leaves the integration bus queue and the database work is rolled back.

Note: The XA interface is a standard protocol between a Transaction Manager and a

database or Resource Manager. In a SeeBeyond e*Way, the Transaction Manager is
part of the e*Way software that is involved in executing the collaboration. Note that both
the JMS topic connection and the database connection must support the XA protocol. For
more information regarding the XA standard, see the URL http://www.opengroup.org.

When the initial failure occurs while processing the message, the error is flagged within the Error
Hospital software, the collaboration returns failure so that the database transaction is rolled back,
and the message is kept on the integration bus queue. Because the message has not been
successfully processed, it is re-submitted to the hospital retry Adapter or e*Way. This re-try will
now cause the message to be inserted into the Error Hospital tables.
The Error Hospital assumes that each Message Family has a single unique ID for all business
object entities its messages are associated with. This ID must be the same for the same entity
across all Message Types within the Message Family. If any message for a specific business
entity is admitted to the Error Hospital, then the Error Hospital will automatically insert
subsequent messages for the same business object. This helps maintain correct message
sequencing and guaranteed exactly once successful message processing. Otherwise, multiple
update messages for a business object may be processed in an incorrect order and create
incompatibilities between applications.

52

Chapter 3 Messaging system component overview

PL/SQL API Publisher Error Hospital Processing

For a publishing adapter, the following logic is performed to publish messages to the RIB or
place messages into the Publishing Error Hospital:
Start

Publishing
Collaboration calls
GETNXT()

GETNXT
returns fatal
Error Status?

Yes

Shutdown the
e*Way

Yes

create ribMessage
for payload

Yes

create ribMessage
for payload

Stop all
e*way
processing

No

GETNXT
returned 'Put
message into
Hospita?"

No
Copyright
2002
GETNXT
Retek, a
returned
Incorporat
message
ed
payload?

do other
messages exist in
Error Hospital for
this Business
Object?

Yes

put
ribMessage
into Hospital

No
put ribMessage into
RibMessages

No

More
ribMessage
Nodes to put
into
RibMessages?

Yes

No

GETNXT
returned any
message
payloads?

Yes

Publish
RibMessages to
JMS Topic

Return,
Success,
perfrom 2
Phase
Commit

No
Return
non-succes,
perfrom
Rollback

Publisher Message Processing flow using

GETNXT()
Figure 3-5
53

Retek Integration Bus

Pl/SQL API Subscriber Error Hospital Processing

For a subscribing adapter, the following logic is performed regarding placing messages in the
Error Hospital:

Start

Subscribing
Collaboration
delivers message
from queue

message marked
as Failed, put
into hospital?
Yes

Does Business
Object ID have
other messages
in Hospital?

return
success from
collaboration

message put
into hospital

No

Yes

No
Copyright
call
message
type2002
specific
Retek,
Consume()
Incorporat
stored
ed
procedure

Consume()
Success?

message work
committed

Yes

If message is being
retried, mark
message for
deletion

No
mark
message as
Failed, to be
put into
hospital

return failure
from
Collaboration

message work
rolled back.
message will
be retried

Stop

Subscriber Processing Logic using

CONSUME()
Figure 3-6

54

Chapter 3 Messaging system component overview

Also associated with the Error Hospital for an application is a subscriber Retry adapter or
e*Way. This adapter is responsible for re-creating and re-publishing messages, which have had
problems previously. There must be one subscriber retry Adapter responsible for republishing all
messages from the Error Hospital tables in a specific database to a single JMS Server. This
adapter is also responsible for deleting all messages marked for delete in the Error Hospital.
Under certain circumstances, messages are placed in the Error Hospital due to problems in
publication. In the SeeBeyond environment, this is may be due to locked records. In the J2EE
environment, this may be due to the JMS becoming unavailable.
Messages are selected for retry based on the Business Object ID, the Hospital ID (a sequence
number used to insure message sequencing is maintained), and whether the maximum number of
automatic retries has been reached.
Error Hospital Database Tables
The following tables are used to store messages in the Error Hospital:
RIB_MESSAGE contains the message payload, all single-field envelope information, and a

concatenated string made from <id> tags. Also contains a unique hospital ID identifying this
record within the hospital.
RIB_MESSAGE_FAILURE contains all failure information for each time the message was

processed.
RIB_MESSAGE_ROUTING_INFO contains all of the routing element information found in

the message envelope.

RIB_MESSAGE_HOSPITAL_REF contains all of the hospital reference information found in

the message envelope.

Additionally, a sequence, rib_message_seqRIB_MESSAGE_SEQ, is used to maintain a unique
Hospital ID associated with each message placed into the Error Hospital.

Note: The hospital retry Adapter or e*Way is responsible for maintaining state
information for hospital records what has happened to the record or message
information. One element of this information is whether the message has been queued to
the JMS topic for re-try processing. Thus, manually deleting messages from the hospital
database using SQL directly may produce severe processing problems. Similarly, deleting
messages directly from the JMS provider may result in a message that is never retried
again, as the logic in the republisher will assume the message is queued within the JMS.
The RIB is supplied with a command-line and GUI interface to the Error Hospital
database for administrative message control. These facilities also allow one to manually
change the payload data for the next retry attempt.

Customized Post-Processing
Certain adapters use a feature known as Customized Post-Processing to add additional
processing after a message has been processed or created. This feature uses properties in the
rib.properties file to create and execute a plug-in for additional or special error handling .

55

Retek Integration Bus

Hibernate and the Retek Platform

The 11.0 RIB release leverages a new set of class libraries generically termed the Retek
Platform. Part of the overall architecture of the Retek Platform is the use of the Hibernate open
source code to provide access to a relational database. Hibernate provides a database independent
Object to Relational Mapping subsystem.
The RIB uses Hibernate for access to Error Hospital tables. Although Hibernate has the ability to
control and manage its own pool of database connections, this facility is not used on the
SeeBeyond e*Gate SRE platform. Instead, the database connections are established and managed
by the SeeBeyond framework and supplied to the Hibernate sub-system. One reason for this is
that the e*Gate subsystem does not expose a J2EE compliant transaction manager, so connections
established by Hibernate cannot be included in an XA two phase commit with the SeeBeyond
managed JMS connection.
Because connection information is irrelevant to how Hibernate is used in the SeeBeyond
environment, there is normally no need to update the hibernate configuration file,
$EHOME/client/classes/hibernate.cfg.xml.

56

Chapter 4 RIB Message Families

Chapter 4 RIB Message Families

This chapter presents an overview of the RIB Message Families. Each Message Family contains
information specific to a related set of operations. Processing by Message Family insures that a
sequence of messages for a given Business Entity (for example, a PO) is maintained throughout
the message lifecycle. In the RIB 11.0 release, a single thread of processing insures this
sequence. The RIB infrastructure maintains a FIFO ordering for messages on all of its queues.
A Message Family may contain multiple Message Types. Each message type encapsulates the
information specific to a business entity within one or more business events. A single business
event, such as updating a Purchase Order, may involve multiple business entities, such as a line
item within the Purchase Order. Furthermore, because a single business event may involve
multiple business entities, the application may publish messages for this event from multiple
Message Families for a single business transaction. More than one message type within a
Message Family may also be created.
Messages published from different Message Families or messages acting on different business
objects do not have the same sequential guarantees. It is possible for two Purchase Orders to be
processed by a subscriber in the reverse order they were created. Many times the cause of this is
due to an error or locked record discovered by the publishing adapter.
Dependencies between Message Families are more problematic. For Example, an Item must be
created before it is used in a Purchase Order. If the Item publisher or subscriber is not available,
then the Purchase Order may arrive at the subscriber before the Item it uses does. When it does,
the PO is put into the Error Hospital. The Error Hospital retry logic then attempts to automatically
correct this situation by re-publishing the PO a configurable number of times.

Event types and Message Families

Each Message Family uses a single SeeBeyond Event Type Definition to define the publishing
format for all Message Types within the Message Family. Because of this, the SeeBeyond e*Gate
Integrator infrastructure sees all messages from a Message Family as belonging to a single
type, known as the Event Type. The RIB message processing logic sub-divides the messages
according to the message type field found in the RIB message envelope. The Event Type is the
SeeBeyond ID associated with the type of the message. Event Types may use the same internal
format. As such, Event Types may also be specific to how much processing has occurred on the
data.
The SeeBeyond Event Type used for a Message Family may be changed if TAFR components are
part of the processing stream. This is required when a single message needs to be routed to
multiple destinations. In this case, each destination is associated with a distinct queue and each
queue is associated with a distinct Event Type.

57

Retek Integration Bus

TAFR components may also change the Event Type messages when a mere transformation or
filter operation is performed. This is done for two reasons:
1

It allows flexibility for the RIB topology. All messages may be put into the same queue on
the integration bus if they have different types. For simple topologies, one can monitor the
number of messages In progress on the RIB by looking at the statistics from a single queue.

It provides greater clarity when configuring a subscribing adapter or TAFR collaboration.

Triggering events for a collaboration are fully specified by the Event Type and the source of
the Event Type. When the source is an upstream collaboration, the Queue containing the
event is hidden within the upstream collaborations configuration. Specifying the output
event type using a different name insures that any components requiring the TAFR operation
gets only TAFR processed messages.

Message Family References

An excellent resource summarizing the Message Families is the RIB_FAMILIES.pdf report
supplied with each RIB installation. This document lists the available Message Families, their
Message Types, and the names of the DTDs that document the message payload.

58

Chapter 5 External application message interfaces

Chapter 5 External application

message interfaces
This chapter presents a brief overview of interfacing with external applications using defined RIB
messages.

Direct JMS interfaces for non-Retek applications

Legacy and other applications should directly connect to the SeeBeyond JMS provider using
standard JMS interfaces. For implementation specific details, see SeeBeyond e*Gate API
Developers Guide.
Connecting directly to the JMS provider allows an application to decouple its implementation
from the Retek application. Changes made to the Retek application will not affect this interface
as long as the message format remains the same.
All message publishers should publish to the JMS using JMS Text messages. This insures that
character encoding issues are minimized. Messages published as Bytes messages could run into
character encoding issues, depending on the default encodings of the Java Virtual Machines used
to publish and subscribe to the message.
All message publishers must also ensure that a message is published with the JMS Message
Property threadValue set to an appropriate value. When only a single subscribing thread is used,
the value of threadValue should be 1. This is the default for all RIB adapters. When multiple
threads are used, messages should be published with a value of threadValue that specifies the
logical processing channel to use.
Furthermore, all subscribers must use selectors to insure that they do not process retried messages
destined for other subscribers. Retried messages are queued onto the same topic that they
originally were published to. The Error Hospital Retry publisher will set a retryLocation property
to specify that the message is being retried and that only one specific subscriber should receive it.
A typical selector used for RIB Messages has the following form:
threadValue=1 and ( retryLocation is null or retryLocation =
<adapterName> )

Where <adapterName> is an identification of the subscriber. For those adapters running on the
SeeBeyond eGate platform (an e*Way), it is the name of the e*Way and the name of the
collaboration separated by a period. E.g. ewItemToRDMWH1.colItemToRDMWH.

59

Retek Integration Bus

Character Encodings
The RIB fully supports the UTF-8 character encoding. This encoding allows for multi-byte
Unicode characters to be contained in RIB messages.
At this time, Retek only fully supports UTF-8 as the Oracle database natural language. However,
some implementations have used other character sets. In these cases, translation from Unicode
UTF-8 to another character encoding is performed within the Oracle JDBC driver and PL/SQL
interface.

RIB Messaging Paradigm concerns

The following tenets of the RIB Messaging system are of interest to external (non-Retek)
publishers and subscribers:
1

During a business transaction, one or more Create messages may be published. These
messages consist of all header and detail information for the composite entity created.
External applications may require that these messages be coalesced into a single composite
message.

Conversely, an external application may not have the same data model as the Retek
application and require that a composite message be divided into multiple messages. These
may need to be along the lines of a header and one or more details.

When a business entity is modified, a message specific to the modification is published. The
message may be specific to a sub-entity. For example, if a line item is added to a Purchase
Order, a PODTLCre message will be published. If multiple items will be added, multiple
PODTLCre messages will be created. This means that a single database transaction may
result in multiple messages within the same or multiple Message Families.
Non-Retek subscribing applications may not associate a single message with a single
database transaction. Another problem is that some non-Retek applications require a
complete snapshot of the changed business object, not just a snapshot of the changed detail or
header. In this case, a TAFR must be developed to create the desired information.

In terms of non-Retek (external) publishing applications, the application must publish using
Reteks canonical form (as specified in the Retek Integration Guide) or convert to this format.
Besides converting field names or code values, this may also mean splitting up a single
message into multiple messages.

Deletion messages may be applicable to an entire composite business entity. Different

Message Types distinguish between the deletion of a sub-entity and the composite entity. For
example, a Delete Supplier message will delete the supplier and all of its addresses, while a
Delete Supplier Address will only delete a suppliers address.
Non-Retek subscribers that cannot accept a single delete message for these entities will need
to have additional processing to specify the sub-entities to delete.

60

The full create/modify/delete/detail update/detail modify/detail delete Message Types are not
available for all Message Types. Non-composite business entities do not contain detail
operations. Some messages, such as a Stock Order Status, reflect only an adjustment to an
entity that will never be deleted (or created) by the publishing application.

Chapter 5 External application message interfaces

RIB published messages may require modification or transformation to satisfy the external
application APIs. These modifications and transformations may involve additional database
operations. For example, the complete vendor name may be needed in a message as opposed
to a vendor ID found in the RIB message. Once the data requirements of the subscriber
have been determined, the available RIB messages should be inventoried for their
applicability and the specific transformations that need to be applied to them.

SeeBeyond application-specific adapters

When integrating with an existing non-Retek application, development time may be shortened
considerably using a SeeBeyond e*Gate Application Adapter designed for that specific
application. These application adapters are either:

e*Ways that surface an applications interface via a set of event type definitions: For these
types of e*Ways, one must develop a set of subscribing collaborations that accept RIB
messages as input events and a set of publishing collaborations that handle application
specific events and publish RIB Messages.
Because of deployment limitations and performance concerns, it may be necessary to locate
the message event type transformation logic within a different e*Way from the application
specific e*Way. Because the conversion is already done, no transformation is needed at the
application specific e*Way and pass-through collaborations are configured as part of the
e*Way.

A library of event type definitions or wizards used to create these ETDs: An example of this
is the EDI ETD library. The purpose of these libraries is to reduce the time creating, parsing,
and/or validating the message format. For example, one could use the event type definitions
for EDI. In this case, the ETD library aids parsing of the EDI document and reduces the
amount of development needed to convert these into messages used on the RIB.

61

Chapter 6 Batch job integration

Chapter 6 Batch job integration

Retek recommends that integration to Legacy applications use JMS as the means to integrate with
Retek applications. The methods to do this may include a new messaging component or may be
by via a file loaded to the RIB. This section describes using the SeeBeyond Batch e*Way to
load a file to and from the RIB.
The main characteristic of a batch job is the reliance on a file as the means for input and output.
In point-to-point solutions, this file is typically FTP'd between systems. To integrate with the
RIB, the batch file is converted to one or multiple messages published to theJMS Topic. The
SeeBeyond e*Gate Integrator infrastructure allows files to be used as sources or sinks for
messages. However, an e*Way collaboration does exist that can be used to load files if these files
have been already created in the correct XML format.
The RIB is designed to work with specific Retek application integration interfaces. These
interfaces typically involve complex business logic to create XML representations of the
appropriate Business Objects. Hence, extending the RIB to legacy systems typically involves an
analysis of the existing interfaces of both Retek and legacy applications. The requirement of
using Business Objects as the basis for the message payload implies that simply extracting a set
of records from the database is usually not sufficient for correct integration. The RIB may be an
alternative to using FTP or in conjunction with FTP file transfers. The mechanism currently used
to FTP existing batch jobs may be replaced completely RIB based mechanisms.
Retek does supply a batch e*Way which takes an XML file and publishes it to a JMS. The file
must contain a valid <RibMessages> formatted message. The topic the message is published to
must be specified in the <publishetname> tag.

Motivations for replacing FTP transfers

FTP is a common method for transferring files between systems. It uses a stable, well-specified
protocol and mature products are available that implement it. RIB integration with batch files
involves taking the file information and publishing it to the RIB. The reasons why one would
want to replace an FTP transfer with this method include:

Reduced number of FTP jobs that transfer the same file from place to place.

With FTP, both hosts need to be available. When an adapter publishes data to a JMS topic,
only the RIB and one of the hosts need to be available. Because of the distributed processing
available on the RIB and the ability to move components physically within a network, there is
an increased flexibility for operations personnel to perform system maintenance.

Subscribers or publishers can move from a batch-oriented method to a message-oriented

mode in an incremental fashion. After publication, file data exists as one or more messages
and can be transformed, filtered, and routed as such. If the same data is needed by multiple
subscribing applications, then some of the subscribers can remain relatively unchanged and
still use a file as input while others can read the data as messages directly from an integration
bus queue.

63

Retek Integration Bus

Transfer file data using a batch application e*Way

The first and simplest available option for using the RIB in this respect is to use the SeeBeyond
e*Gate Batch application e*Way to transfer file information to and from the RIB. This e*Way
can be used to copy files to or from hosts without installed e*Gate components. The Batch
e*Way is fully documented in the SeeBeyond Batch e*Way Intelligent Adapter Users Guide.
This manual presents a brief overview of its capabilities.
Do not use the SeeBeyond e*Gate File e*Way. This is a development tool not robust enough for
deployment in a production environment.
A batch e*Way is created by creating new e*Way in the e*Gate Enterprise Manager, selecting
stcewgenericmonk.exe as the Executable file, and then, when creating the new configuration
file, selecting the batch e*Way configuration template.
The Batch e*Way works in one of two modes:
1

A fixed configuration that publishes data to the RIB based on the presence of a file in a
directory or creates/appends a file based on the presence of a message on a queue.

A message based configuration where the batch e*Way subscribes to messages that contain
the specifics of the file transfer.

Fixed configuration
Publication of data to the RIB
A batch e*Way is configured to poll for the existence of files (either on the local system or on a
remote system). Once found, the e*Way copies the files to a local temporary directory. For files
found on remote systems, FTP is used to copy it to the local temporary directory. Configuration
options determine the polling interval, where the file is located, file masks to determine which
files to transfer, FTP parameters, whether the file should be renamed or archived after
publication, and if the contents of the file should be published as a single message or if each line
in the file corresponds to a single message. This is all performed in the application side of the
e*Way.
Once a message is ready on the application side of the e*Way, the message is sent to the
collaborations configured with the e*Way. A collaboration must be created that can handle the
messages published whose source is <external>. In the simplest case, this collaboration could
merely pass through the data without modification or validation. In a more complex case, the
collaboration could validate and transform the data before publishing it as an event.
If the entire file is to be published as a single message, the entire file will be read into the memory
of the batch e*Way. The memory allocated for this may never be relinquished by the e*Way,
depending on its scheduling. Severe problems may result when the amount of memory needed
exceeds the maximum available for a single process or when the virtual memory of the machine
is exhausted. Retek internal test systems successfully transferred files 100 megabytes large; your
results may vary according to the specific operating system and its configuration.

64

Chapter 6 Batch job integration

Subscribing to data from the RIB

A batch e*Way is configured with a collaboration that is triggered from events (messages)
published by another collaboration or are available on a JMS topic. The processing order of these
events is the reverse of publication. First, the subscribing collaboration is executed and performs
any needed transformations or validations. Then the message is passed over to the application
side of the e*Way by publishing the message to the <external> destination.
The configuration of the application side determines the final disposition of the data. As in the
publication scenario, the data stages through a temporary file and before copied to its final
destination. FTP is used when the final destination is a remote system. Configuration options for
this processing include the following:

The name of the file to put the message in.

Whether messages are appended to this file or new files are created.

Whether the file is uniquely named via a time stamp or sequence number.

How often new files are created (if the append mode is used) and copied.

Pre- and post- file copy activities.

FTP session parameters.

Import notes: When the append messages to a file is used, file boundaries are not
necessarily maintained from the source file. One or more source files could be put into a
single destination file or, if the source file was published record-by-record, half of the
source file could be appended to a single destination file and half to the next. It all
depends on a set of interacting configuration parameters. Furthermore, if a batch e*Way
was used to publish the file using a fixed configuration, no intrinsic mechanism exists
for communicating the name of the source file.

65

Retek Integration Bus

Message mode
In message mode, the batch e*Way receives an XML message detailing the file transfer details.
This message contains one or more operations or commands to execute. There are two types of
commands:
1

receive find one or more external files and publish them to the integration bus. The
message published by the e*Way is formatted using XML. It contains an identifying
return_tag plus a payload tag containing the data found in the file.

send the subscribed message is used to create or append to a destination file. The message
contains a payload tag with the file contents. Other tags in the message detail other
specifics of the file, such as the destination file name, and what to do if the destination file
exists, and local/remote file copy details.

One advantage of the message mode FTP configuration is that send commands specify the
name of the destination file. Hence, it is possible to maintain file names across the file transfer.
However, this method requires additional development and processing.

Transferring data directly from/to a database

Another method for implementing batch transfers is to create an e*Way and a set of
collaborations to read from a database table and publish the information to the RIB. This involves
using the e*Gate Enterprise Manager to create the event type definitions, collaboration rules,
collaborations, e*Ways and queues. This strategy replaces a batch mode of processing with a
message-based mode. It directly uses new development specifically for the integration bus.
SeeBeyond offers many types of e*Ways. Some of these are specific to a single application or
suite of applications. The RIB leverages the Multi-mode e*Way. It is recommended that the
logic of an existing RIB e*Way be examined and leveraged for new interfaces. If so, then the
same Error Hospital paradigm of operation may be used for legacy application interfaces as with
the Retek application interfaces.

66

Chapter 6 Batch job integration

Using connection points and developing the logic within a collaboration

This strategy is useful if the data is available via a simple SQL statement or with little added
processing. (Actually, the wizard generates events based on table structure, SQL statement, or
Stored Procedure API.) The e*Gate Enterprise Manager contains a database wizard that can
generate an event corresponding to the SQL statement.
Publication: One defines an e*Way connection with a polling parameter determining how often
these events will trigger the collaboration. No data or SQL statement will populate the event
(message) when the collaboration triggers. The SQL statement executes as part of the
collaboration rule logic and each row of any result set needs publishing as a separate event.
Subscription: One configures a collaboration that includes the defined event as an output event
with a destination specified as a database connection point. The collaboration transforms the input
data into the SQL specific event and then executes the SQL statement.
Note that database transaction boundaries depend on XA interface usage and an events
destination or source. If the XA interface is used, all work within each invocation of the
collaboration is within a single transaction. If not, the collaboration can execute multiple
transactions per single invocation. RIB collaborations typically use XA to insure exactly once
successful message processing.

Using an application specific e*Way adapter

Application specific e*Way Adapters are built with the application side of the e*Way already
developed. The event types (message formats) the application can publish or parse are typically
defined already (or at least an easy way to create them is available) along with the application
processing logic. Hence, the main work here is to develop the correct collaborations to convert
RIB events (messages) to or from this set.
There is a rich set of application specific adapters available. A complete list is available on the
SeeBeyond web site, http://www.seebeyond.com.

67

Chapter 7 J2EE RIB Architecture

Chapter 7 J2EE RIB Architecture

J2EE Solution Overview
This document will explain the architecture behind a J2EE application interface to the RIB. The
diagram below shows the interface between the J2EE application and JMS.

J2EE Application to JMS solution

J2EE Application
Payload

RIB
XML

JMS

A J2EE application interfaces with the RIB through Java Payload objects, which consist of simple
Java beans that store the application event data. RIB Payload object hold the same information
as is defined in the XML DTDs or XML Schemas defining the <messageData> contents. The
Castor Open Source project is used to generate the bean code and bind the XML values to a
payload bean object. The same message payloads are supported in the J2EE environment as in
the ISO and SeeBeyond environments.
The diagram below shows the configuration for integrating a non-J2EE application (RMS), with a
J2EE application.

69

Retek Integration Bus

J2EE Application to PL/SQL Application solution

RMS connects to the RIB using PL/SQL through e*Ways. The J2EE application connects to the
JMS using Message Driven Beans (MDBs) and Enterprise Java Beans (EJBs). Message Driven
Beans are called from the J2EE container with message data from a configured JMS Topic.
Enterprise Java Beans may be called from the MDBs to process the payload information. The
RIB also deploys an EJB as the interface to publish messages to the JMS Server.
Each Message Family a J2EE subscribes to must have a deployment of the
RIBMessageSubscriberEJB. This MDB parses the XML in the message, determines whether the
application should process the information and/or if the message should be put into the Error
Hospital. The MDB then creates the appropriate payload bean, fills it with payload data, and
calls the application supplied code to process this data.

RIB J2EE Processing Overview

In the J2EE environment, publishing to the RIB is performed via a deployed Enterprise Java Bean
(EJB). Subscribing from the RIB is performed through deployment of a Message Driven Bean
(MDB) that subscribes to a specific JMS topic with an appropriate selector. In both cases, the
container manages the transaction and both the JMS and database resources are included in a twophase commit XA compliant transaction.
The RIBs J2EE code is contained in an application EAR file named for the J2EE application that
it interfaces (e.g. rib-rcom.ear). The application name is also derived in a similar manner:
RIBfor<App> (e.g. RIBforRCOM).
Currently the application server used for deployment of J2EE applications is the WebSphere
Application Server. In this environment, the RIBfor<App> application needs to be deployed on
the same server instance as the J2EE application EAR, and must use the same application class
loader to avoid Class Cast exceptions for shared objects between applications.

70

Chapter 7 J2EE RIB Architecture

RIB Payload Objects

The RIB currently uses the Open Source Castor XML Binding tool for converting XML to/from
Java Payload objects. The RIB performs the conversion of these objects:

On a subscribe operation, the RIB takes the XML message from JMS (RibMessages) and
converts it to a Payload object to pass on to the J2EE application (e.g. unmarshal).

On a publish operation, the RIB takes the Payload object passed in from the J2EE
application and converts it into an XML Message (RibMessages) to publish to JMS (e.g.
marshal).

RIB payload objects are contained in the retek-payload.jar. This jar needs to be in the class path
for both the J2EE application and the RIB application (i.e. RIBfor<App>).

71

Retek Integration Bus

RIBMessageSubscriberEJB (MDB)
An MDB is responsible for listening to a JMS topic for a message to arrive and processing it
through the logic contained in its onMessage() method. There is a different deployment of the
MDB for every subscribing message family, as each MDB listens to a different topic on JMS.
Part of an MDBs deployment is the specification of the MDBs durable subscriber selector. In
order to guarantee sequencing, only one copy of each MDB is configured for a Message Family
and selector threadValue combination. If multiple copies are needed, then multiple deployments
of the MDB is needed, each one with a different threadValue value.
The MDB is responsible for calling the appropriate RIB Error Hospital code and RIB Binding
code for processing each XML message. The RIB Binding code is responsible for calling the
J2EE applications InjectorEJB. The InjectorEJB applies the business logic to determine how the
data is entered into the application database. If an Exception is returned from the J2EE
application, the transaction will be rolled back and the XML message will be sent to the RIB
Error Hospital.
Subscribing Workflow
For the subscriber process, the process is as follows. It is very similar to the SeeBeyond e*Way
process.
1

The Message Driven Bean (MDB) is deployed with a deployment descriptor detailing the
JMS topic the bean will use to listen for messages.

After the MDB is activated, a J2EE global transaction is started.

When a message arrives on the JMS Topic, it is then delivered to the MDBs onMessage()
method.

The MDB checks to see if this message is flagged for insertion into the Error Hospital.

If so, it creates a set of new entries in the Error Hospital and returns success. There will
be one new entry per RIB Message Node. Proceed to Step 6.

For each RIB Message Node found in the message, the MDB

Checks the Error Hospital to see if there is an entry in it for this message, if so, this
message is currently being retried.

Checks the Error Hospital to see if there are entries in it for the same Message
Family/Business Object ID combination.

If so, and this message is not being retried, this message is placed into the Error
Hospital and a successful return is made. Proceed to Step 6.

The MDB invokes the RIB Binding subsystem to create an injector object. The Injector object
is specific to the Message Family and Message Type. The RIB Binding subsystem first creates a
RIB Payload object from the RIB Message Payload XML, which it then passes to the Injector
through the inject() method. This method performs the required application specific logic to
process the message. The inject() method returns the status of the message back to the MDB.

72

Chapter 7 J2EE RIB Architecture

The MDB examines the status. If a failure has occurred, the transaction is marked rollback
only. The message is marked as failed and control is returned to the MDB.
a

On a failure,

The MDB throws an exception to the MDBs container.

A rollback of all database work is performed, and the message remains on the JMS
Topic.

The message is re-delivered to the MDB and steps 2, 3, and 4 are repeated.

The MDB now recognizes that this is a re-delivery of a failure (retry message). It
performs the actions detailed in Step 5 above and returns.

On a successful return,

The MDB checks the Error Hospital to see if this is a message being retried. If so,
and the message is successfully processed by the injector bean, the MDb removes the
message from the Error Hospital.

The MDB returns success to its container and the message is removed from the JMS
Provider. A two-phase commit operation is performed with both the database(s) and JMS
Provider committing all work. Steps 2-7 are repeated for each new message on the JMS
Provider Topic.

RIBMessagePublisherEJB (Stateless Session Bean)

This EJB provides an interface into the RIB for converting a Payload into XML and publishing
that message to JMS. The stubs and reference files needed to call this method are contained in
the rib-client.jar provided by the RIB to the J2EE application.
The publish() method has the following signature for publishing a RIB Message with a single
<ribMessage> tag:
public void publish(String family, String type, Payload payload,
ArrayList ids, ArrayList ris) throws PublishException{}

The message family and message type are passed in as Strings, along with the Payload object
that contains the business data. The ids parameter is an ArrayList of Strings containing the
business object ID, which is used for sequencing in the RIB. The ris parameter is an ArrayList of
RoutingInfo objects, which are used for routing messages in the RIB.
Additional overload versions of the publish() method exist. The version above uses a set of
parameters to publish a single <ribMessage>. Another version uses a
com.retek.rib.app.messaging.service.RibMessageVO parameter to perform the same function.
The RibMessageVO is a bean containing the family, type, payload, business object id, and
routing information.
Publishing RIB Messages containing a single <ribMessage> tag incurs the overhead of a Two
Phase Commit for every event published. If multiple events within the same Message Family are
available to be published, it makes sense to multiple <ribMessage> tags within a single message.
A version of the publish() method allows this by accepting an array of
com.retek.rib.app.messaging.service.RibMessageVO objects.

73

Retek Integration Bus

Publishing Workflow
An overview of the publishing process is as follows:
1

The J2EE application determines that a message is to be published to the RIB. It creates a
RIB Payload object to hold the business data. RIB Payload objects are message type specific
and map directly to the RIB Message Payloads.

The J2EE application invokes the RIB Publishing EJBs publish() method. The RIB
Publishing EJB is a stateless session bean. Parameters to this method include the RIB
Message payload object, the Message Family, the Message Type, an array of Routing Infos,
and an array of Business Object Ids.

The RIB Publishing EJB creates a new RIB Message from this information.

The RIB Error Hospital is checked for dependencies between the new message and the
records in the Hospital. If dependencies are found, an exception is thrown, and the message
is inserted into the Hospital.

The RIB Publishing EJB invokes the appropriate RIB Binding subsystem to create the XML
Message Data for the RIB Message. The RIB Binding code also determines the correct JMS
topic to use for publishing the message.

The RIB Publishing EJB publishes the RIB Message to a configured JMS Provider.

If the publish fails, an exception is thrown. The RIB Publishing EJB tries to insert this
message into the RIB Error Hospital, using the JMS REASON_CODE. If the insertion
to the Hospital fails, an EJB Exception is thrown, and the transaction is rolled back. A
PublishException is returned to the J2EE application, indicating that the publish was
unsuccessful.

If the publish succeeds, no PublishException is returned to the J2EE application.

The J2EE application determines if a PublishException was thrown from the RIB Publishing
EJB.

If so, an error appears in the application, and the database work is rolled back.

If not, it completes its unit of work and a 2-phase commit operation is performed between
any database(s) and the JMS server.

RIBMessageTafrEjb (MDB)
If messages have a requirement to be filtered, transformed or routed before ultimate consumption,
these types of MDBs will be deployed.
This MDB is responsible for listening to a JMS topic for messages, and upon finding a suitable
message (based on the message selector), processing it through the onMessage() method. There
is a different deployment of the MDB for every subscribing message family, as each MDB listens
to a different topic on JMS. Also, in a multi-threaded environment, there could be a different
deployment of the MDB for every thread for a specific message family.
The MDB passes the inbound message through the appropriate Java TAFR class. These TAFR
classes have the ability to Transform, Filter and Route messages using the RIBs Java TAFR
framework. If an Exception is returned from the TAFR class, the transaction will be rolled back
to JMS.

74

Chapter 7 J2EE RIB Architecture

TAFR Workflow
In the 11.0 release, TAFR MDBs are introduced to perform Transformation, Address Filtering
and Routing operations on behalf of a J2EE application. Previous releases used SeeBeyond
TAFR e*Ways. TAFR MDBs can filter unwanted messages, transform the contents of a
message, or route the message to alternative JMS Topics. All actions are performed within a XA
compliant two phase commit framework.
1

The Message Driven Bean (MDB) is deployed with a deployment descriptor detailing the
JMS topic the bean will use to listen for messages and a Java TAFR class to use.

After the MDB is activated, a J2EE global transaction is started.

When a message arrives on the JMS Topic, it is then delivered to the MDBs onMessage()
method.

The MDB calls Tafr Helpers convertMessage() method to process the message. This then
passes the message through the following methods in this order. These methods have default
implementations that do nothing. They should only be implemented if work needs to be done
on the message.

filterRibMessage() allows the Java Tafr class to drop unwanted messages. Messages can
be dropped by evaluating any data in the RibMessage envelope or the message payload
itself.

transformRibMessage() allows the message data to be manipulated in any manner, such

as translating one message (DTD) to another.

routeRibMessage() allows the message to be routed to a particular JMS Topic based on

evaluating some data in the RibMessage envelope or the message data itself.

If any failure occurs during this processing, a TafrException is thrown back to the TAFR
MDB and the message is ultimately rolled back to JMS.

If successfully processed by the Java Tafr class, the RIB Tafr Framework will then publish
this transformed message to the appropriate JMS Topic.

The MDB returns success to its container and the message is removed from the JMS
Provider. A two-phase commit operation is performed with the JMS Provider committing all
work. Steps 2-7 are repeated for each new message on the JMS Provider Topic.

ErrorHospitalRetryEjb (Stateless Session Bean)

The RIB guarantees that no published messages will be lost in the integration process. The RIB
ErrorHospital is the mechanism that allows for message persistence. See Chapter 3 for more
information on the RIB Error Hospital.
The ErrorHospitalRetryEjb is a stateless session enterprise bean that retries any messages that
were put into the ErrorHospital. A timer triggers the ErrorHospitalRetryEjb to retry the messages.
The timer can be configured and monitored by a servlet, ErrorHospitalRetryAdmin (http://<your
host >:<port>/ribhospitalretry/ErrorHospitalRetryServlet). Initially when the rib EJB application
starts, the timer also starts along with it. The initial timer interval duration can be configured by
the property, hospital.attempt.delay in the rib.properties file. The timer can be started/stopped
through the ErrorHospitalRetryAdmin. The status and interval duration time can also be
changed/monitored through the ErrorHospitalRetryAdmin.

75

Retek Integration Bus

J2EE Application Overview

A J2EE Application that interfaces with the RIB provides an EJB interface in order to pass along
application data through a Payload object (i.e. inject messages). This is required for a J2EE
application to subscribe to messages from JMS.

InjectorEJB
The J2EE application defines an InjectorEJB based on the two remote classes provided by the
RIB, InjectorEJBRemote and InjectorEJBRemoteHome. The RIB accesses the JNDI name for
the application injector based on a property set in the rib.properties file.
(e.g. app.jndi.injector=pkg.InjectorEJBName )
The J2EE application receives a jar file (rib-client.jar) from the RIB for referencing shared
objects, such as the remote InjectorEJB objects, the stubs and reference files for the
RIBMessagePublisherEJB, and other classes used on the interface signatures. The J2EE
application needs to have access to this jar in their classpath.
The RIB J2EE application also requires the stubs and other reference files created for the
InjectorEJB API in order to call its methods. These classes should be contained in a jar file that
the J2EE application produces and provides to the RIB.

76

Chapter 7 J2EE RIB Architecture

The signature of the InjectorEJB should be as follows:

public void inject(String msgFamily, String msgType, Payload
payload)
throws RetekBusinessException {}

In the inject() method, the InjectorEJB should find the appropriate injector class used to inject
the Payload data into the database. These classes should be referenced using a properties file
(injector.properties), and should be based on the message family and message type passed in.
Each injector class should extend the RIBs ApplicationMessageInjector interface provided in the
rib-client.jar. This injector class will implement the inject() method from the
ApplicationMessageInjector, and provide the business logic to inject the data to the database.
If an exception occurs during this processing that requires the transaction to be rolled back, the
InjectorEJB should throw an InjectorException with a detailed error description. This description
will be shown in the RIB Error Hospital when the message has been rolled back.

RIB Binding Overview

The RIB Binding code performs the necessary subscribing and publishing logic for XML Binding
conversion between Java and XML, and for subscribing also calls the J2EE application injector
logic.
The RIB Binding code contains commands that can be used for publishing and subscribing. The
CommandFactory is called to either retrieve a SubscribeCommand or PublishCommand, and then
the execute() method is called on the Command to perform the intended operations. The
PublishCommand is used to marshal a Payload into an XML Message. The SubscribeCommand
is used to unmarshal an XML message into a Payload, and inject that payload into the application
code.
Properties files are used to determine the mapping between the message family and type, and the
Java Payload object (and Castor Mapping file if used). See the section below on the properties
files used by the Binding code for more information.

77

Retek Integration Bus

Subscriber Overview

XML is converted into a Java Payload object, and passed in to an application using the
InjectorEJBs inject() method.
Subscriber Workflow
1

RIBMessageSubscriberEJB.handleMessage()
Calls the Subscriber.consume(family String, type String, xml String, and the threadID
String ) method to consume the XML Message.
Subscriber.consume()
Calls the CommandFactory.getSubscribeCommand() to retrieve the Command object.

78

CommandFactory.getSubscribeCommand()
a

A new SubscribeCommand object is created.

CommandFactory.createPayload(): looks up the Java Payload class to use for the

unmarshalling of the XML message. This value is retrieved using the BindingProperties
class.

SubscribeCommand.setPayload(): called with the instantiated Java Payload object.

SubscribeCommand.setPayloadXML(): called with the message data XML String.

Chapter 7 J2EE RIB Architecture

Subscriber.consume()
The Command object is returned back to Subscriber.consume(), where it calls the execute()
method on the Command object. This method subsequently calls the
SubscribeCommand.doExecute() method.

SubscribeCommand.doExecute()
The doExecute() method first looks up the implementation of RibBinding to use for
unmarshalling the XML into a Java Object. The implementation is derived using a property
in the rib.properties file. The unmarshal() command is called on the RibBinding
implementation.

RibBinding.unmarshal()

Unmarshals the XML using a pre-defined XML Binding tool.

5

SubscribeCommand.doExecute()
The doExecute() method looks up which RibInjector class to use, using the
RibInjectorFactory. This factory derives the correct implementation based on a setting in the
rib.properties file. The inject() method is called on the RibInjector implementation.

RibInjector.inject()

Calls inject(family String, type String, and Payload payload) on the applications injector
class.

79

Retek Integration Bus

Publisher Overview

A Java Payload object is marshaled into an XML message. A RibMessages wrapper is created
using the Payload XML message as the Message Data element. The XML message is published
to JMS. On failure, the message is inserted into the RIB Error Hospital. If the message is not
successfully inserted into the database, an Exception is thrown to the J2EE application.

80

Chapter 7 J2EE RIB Architecture

Publishing Workflow
1

RIBMessagePublisherEJB.publish()
Calls the CommandFactorys getPublishCommand() method, which returns a Command
object.

CommandFactory.getPublishCommand()
The value found in the payload.properties file is instantiated, and used in the
setPayload(Payload payload) method. This value is retrieved using the BindingProperties
class.

RIBMessagePublisherEJB.publish()
Calls the Command.execute() method, which in turn calls the PublishCommands
doExecute() method.

PublishCommand
The doExecute() method marshals the Payload object into XML, and sets the
setPayloadXML() method with the resulting XML String.

RIBMessagePublisherEJB.publish()
The RIBMessagePublisherEJB then creates the RibMessage XML. It uses the
getPayloadXML() method to set the messageData, along with the other elements such as
message family, message type, ris (routing info), ids (business object ids), etc. This
RibMessage is wrapped in a RibMessages element, and is published to JMS. If the publish to
JMS fails, the message is inserted into the RIB Error Hospital. If for any reason the insertion
into the database fails, the J2EE container rolls back the transaction, and sends a
PublishException back to the J2EE application.

RIB Binding Classes

ApplicationMessageInjector
Interface used for the applications injector classes. Contains the inject() signature that must be
implemented by each injector.
BindingFactory
The createRibBinding() method looks up the ribBindingImpl property from the rib.properties
file that determines which implementation of the RibBinding interface to instantiate. This object
is returned back to the calling method.
BindingProperties
This is a singleton class that looks up values in the payload.properties and binding.properties
files. A value for a property is returned by calling the following static method:
BindingProperties.getInstance().getProperty(messageFamily,messageTyp
e)

81

Retek Integration Bus

CastorBindingImpl
This class contains the unmarshal() and marshal() methods for the Castor XML Binding tool.
This is the default implementation of the RibBinding interface.
This class also looks for a value in the binding.properties file, using the BindingProperties class.
If a value is found for the message family and type, the Castor Mapping file defined by the value
is used in the unmarshal and marshal operations. If no value is found, the Castor Descriptor files
are used. By default, no properties appear in the binding.properties file, as the Descriptor files are
used.
Command
The Command class is the superclass for the SubscribeCommand and PublishCommand classes.
CommandFactory
The CommandFactory class creates either a SubscribeCommand or a PublishCommand, and
populates the classes with the required values. It is responsible for using the BindingProperties to
determine the Java Payload associated with a message family and type, which the Command
objects subsequently use in the unmarshal and marshal methods.
InjectorException
The InjectorException is used by the application InjectorEJB to return an exception to the RIB
Binding code. This creates a rollback of the EJB transaction, and the message is sent to the RIB
Error Hospital.
Payload
This is the common interface for all Java Payload objects. A Payload object used in RibBinding
must extend this class, or the processing will fail.
PublishCommand
The PublishCommand holds the necessary information to call the RibBinding implementations
marshal() method, which transforms the Java Payload object to XML. This processing is
performed inside of the doExecute() method.
PublishException
A PublishException is returned to the application upon failure of publishing a message to both
JMS and the RIB Error Hospital. This will create a rollback of the EJB transaction.
RibBinding
This class is the interface for the RibBinding implementations. It allows for XML Binding tool
independence, as the specific RibBinding implementation is the only place (besides the Java
Payload objects) where Binding tool dependent code (such as code for Castor, JAXB, etc.) is
referenced.
RibInjector
The RibInjector implementation allows for different implementations of the RibInjector class to
be used for injecting a message into the application. This allows for J2EE and non-J2EE code to
use the RibBinding code.
82

Chapter 7 J2EE RIB Architecture

RibInjectorFactory
Determines which implementation of the RibInjector class to use, based on the value of the
ribInjectorImpl property in the rib.properties file. It instantiates the class and returns the object.
RIBIntegrationException
Any exception occurring in the RIB Binding code is generally a RIBIntegrationException.
SubscribeCommand
The SubscribeCommand holds the necessary information to call the RibBinding implementations
unmarshal() method, which transforms the XML into a Java Payload object. It then determines
the implementation of the RibInjector to use for application message injection. This processing is
performed inside of the doExecute() method.
Subscriber
This class is called by the MDB for subscribing messages.

Properties Files
payload.properties
The payload.properties file maps the message family and message type Strings to a Java Payload
class. This class is a Castor-generated Java object used for binding Java to XML. The key is the
message family and the message type in uppercase characters, with a . separator between the
two. The equals sign, =, is used to separate the key from the value. The value is the full class
name (with package) of the Castor Java object. An example of this is shown below:
ASNOUT.ASNOUTCRE=com.retek.rib.binding.payload.ASNOutDesc
See the appendix for a sample payload.properties file.
binding.properties
The binding.properties file maps the message family and message type Strings to a Castor
mapping XML file. This file can be used in place of the Castor Descriptor files that are generated
in Castor for processing the XML binding between Java objects and XML. The Castor mapping
file contains the rules for binding such as the ordering of elements or datatypes, etc. The key is
built in the same way as the payload.properties file above, but the value will be the relative path
to the Castor mapping file. This path can be seen in the jar file that contains the mapping files
(retek-binding.jar). The relative path to the Castor mapping files is by default
com/retek/rib/binding/payload/ plus the filename. The file names are typically the same as the
Java Payload object name, but with Map at the end of the name and an XML file format. An
example of a binding.properties file entry is shown below:
ASNOUT.ASNOUTCRE=com/retek/rib/binding/payload/ASNOutDescMap.xml

83

Retek Integration Bus

rib.properties
The rib.properties file holds properties entries for configuring RIB code. This file is initially
configured upon installation of the RIB application. See the RIB Installation Guide for more
information on this file.

84

Appendix

Appendix
Sample payload.properties file
ASNOUT.ASNOUTCRE=com.retek.rib.binding.payload.ASNOutDesc
BANNER.BANDLVSCDCRE=com.retek.rib.binding.payload.WSBanDlvScdDesc
BANNER.BANNERCRE=com.retek.rib.binding.payload.WSBannerDesc
BANNER.BANNERDEL=com.retek.rib.binding.payload.WSBannerRef
BANNER.BANNERMOD=com.retek.rib.binding.payload.WSBannerDesc
BANNER.CHANNELCRE=com.retek.rib.binding.payload.ChannelDesc
BANNER.CHANNELMOD=com.retek.rib.binding.payload.ChannelDesc
COBORES.CORESCANCRE=com.retek.rib.binding.payload.COResCanDesc
COBORES.CORESCRE=com.retek.rib.binding.payload.COResDesc
COCOGS.COGSCRE=com.retek.rib.binding.payload.WSCogsDesc
CODSRCPT.DSRCPTCRE=com.retek.rib.binding.payload.WSDSRcptDesc
CORETURN.CUSTRETSALECRE=com.retek.rib.binding.payload.CustRetSaleDesc
CORRESPONDENCE.CUSTCORRESCRE=com.retek.rib.binding.payload.CustCorresDesc

COSALE.CUSTSALECRE=com.retek.rib.binding.payload.CustSaleDesc

CUSTORDER.COCRE=com.retek.rib.binding.payload.CODesc
CUSTORDER.CODEL=com.retek.rib.binding.payload.CORef

CUSTRETURN.CORETCRE=com.retek.rib.binding.payload.CustRetDesc
CUSTRETURN.CORETDTLCRE=com.retek.rib.binding.payload.CustRetDesc
CUSTRETURN.CORETHDRCRE=com.retek.rib.binding.payload.CustRetDesc
CUSTRETURN.CALLTAGCRE=com.retek.rib.binding.payload.CallTagDesc

DIFFGRP.DIFFGRPDTLCRE=com.retek.rib.binding.payload.DiffGrpDtlDesc

85

Retek Integration Bus

DIFFGRP.DIFFGRPDTLMOD=com.retek.rib.binding.payload.DiffGrpDtlDesc
DIFFGRP.DIFFGRPHDRCRE=com.retek.rib.binding.payload.DiffGrpHdrDesc
DIFFGRP.DIFFGRPHDRMOD=com.retek.rib.binding.payload.DiffGrpHdrDesc
DIFFS.DIFFCRE=com.retek.rib.binding.payload.DiffDesc
DIFFS.DIFFMOD=com.retek.rib.binding.payload.DiffDesc
DSPO.DSPOMOD=com.retek.rib.binding.payload.DSPODesc
DSPO.DSPOSTATCRE=com.retek.rib.binding.payload.DSPOStatDesc
GIFTREG.GIFTREGACKCRE=com.retek.rib.binding.payload.GiftRegAckDesc
GIFTREG.GIFTREGUPDMOD=com.retek.rib.binding.payload.GiftRegUpdDesc
INVADJUST.INVADJUSTCRE=com.retek.rib.binding.payload.InvAdjustDesc
ITEMS.ISATTRCRE=com.retek.rib.binding.payload.WSISAttrDesc
ITEMS.ISATTRMOD=com.retek.rib.binding.payload.WSISAttrDesc
ITEMS.ISDLVBLKCRE=com.retek.rib.binding.payload.WSISDlvBlkDesc
ITEMS.ISDLVBLKMOD=com.retek.rib.binding.payload.WSISDlvBlkDesc
ITEMS.ISHIPRSDTLCRE=com.retek.rib.binding.payload.WSIShipRsDtlDesc
ITEMS.ISHIPRSHDRCRE=com.retek.rib.binding.payload.WSIShipRsHdrDesc
ITEMS.ISPERATTRCRE=com.retek.rib.binding.payload.WSISPerAttrDesc
ITEMS.ISPERATTRMOD=com.retek.rib.binding.payload.WSISPerAttrDesc
ITEMS.ISPERFNCLCRE=com.retek.rib.binding.payload.WSISPerFnClDesc
ITEMS.ISPERFNCLMOD=com.retek.rib.binding.payload.WSISPerFnClDesc
ITEMS.ISPERMXCHRCRE=com.retek.rib.binding.payload.WSISPerMxChrDesc
ITEMS.ISPERMXCHRMOD=com.retek.rib.binding.payload.WSISPerMxChrDesc
ITEMS.ITEMATTRCRE=com.retek.rib.binding.payload.WSItemAttrDesc
ITEMS.ITEMATTRDEL=com.retek.rib.binding.payload.WSItemAttrRef
ITEMS.ITEMATTRMOD=com.retek.rib.binding.payload.WSItemAttrDesc
ITEMS.ITEMBOMCRE=com.retek.rib.binding.payload.ItemBOMDesc
ITEMS.ITEMBOMMOD=com.retek.rib.binding.payload.ItemBOMDesc
ITEMS.ITEMCRE=com.retek.rib.binding.payload.ItemDesc
ITEMS.ITEMHDRMOD=com.retek.rib.binding.payload.ItemHdrDesc
ITEMS.ITEMLOCCRE=com.retek.rib.binding.payload.WSItemLocDesc
86

Appendix

ITEMS.ITEMLOCMOD=com.retek.rib.binding.payload.WSItemLocDesc
ITEMS.ITEMLOCSCRE=com.retek.rib.binding.payload.WSItemLocsDesc
ITEMS.ITEMLOCSMOD=com.retek.rib.binding.payload.WSItemLocsDesc
ITEMS.ITEMSUPCRE=com.retek.rib.binding.payload.ItemSupDesc
ITEMS.ITEMSUPCTYCRE=com.retek.rib.binding.payload.ItemSupCtyDesc
ITEMS.ITEMSUPCTYMOD=com.retek.rib.binding.payload.ItemSupCtyDesc
ITEMS.ITEMSUPMOD=com.retek.rib.binding.payload.ItemSupDesc
ITEMS.ITEMUDAFFCRE=com.retek.rib.binding.payload.ItemUDAFFDesc
ITEMS.ITEMUDAFFMOD=com.retek.rib.binding.payload.ItemUDAFFDesc
ITEMS.ITEMUDALOVCRE=com.retek.rib.binding.payload.ItemUDALOVDesc
ITEMS.ITEMUDALOVMOD=com.retek.rib.binding.payload.ItemUDALOVDesc
ITEMS.ITMCARRSVCCRE=com.retek.rib.binding.payload.WSItmCarrSvcDesc
ITEMS.ITMCARRSVCMOD=com.retek.rib.binding.payload.WSItmCarrSvcDesc
ITEMS.ITMLOCATTRCRE=com.retek.rib.binding.payload.WSItmLocAttrDesc
ITEMS.ITMLOCATTRMOD=com.retek.rib.binding.payload.WSItmLocAttrDesc
MEDIA.DROPCODECRE=com.retek.rib.binding.payload.WSDropCodeDesc
MEDIA.DROPCODEDEL=com.retek.rib.binding.payload.WSDropCodeRef
MEDIA.MEDIACRE=com.retek.rib.binding.payload.WSMediaDesc
MEDIA.SOURCECODECRE=com.retek.rib.binding.payload.WSSourceCodeDesc
MEDIA.SOURCECODEDEL=com.retek.rib.binding.payload.WSSourceCodeRef

ORDER.ORDDATECRE=com.retek.rib.binding.payload.WSOrdDateDesc
ORDER.ORDDATEDEL=com.retek.rib.binding.payload.WSOrdDateRef
ORDER.ORDDATEMOD=com.retek.rib.binding.payload.WSOrdDateDesc
PAYMENTS.REFDPAYSTLMTCRE=com.retek.rib.binding.payload.RefdPayStlmtDesc

PENDRETURN.PENDRETCRE=com.retek.rib.binding.payload.PendRtrnDesc
PENDRETURN.PENDRETDTLCRE=com.retek.rib.binding.payload.PendRtrnDtlDesc
PENDRETURN.PENDRETDTLMOD=com.retek.rib.binding.payload.PendRtrnDtlDesc

87

Retek Integration Bus

SEEDDATA.CODEDTLCRE=com.retek.rib.binding.payload.CodeDtlDesc
SEEDDATA.CODEDTLMOD=com.retek.rib.binding.payload.CodeDtlDesc
SEEDDATA.CODEHDRCRE=com.retek.rib.binding.payload.CodeHdrDesc
SEEDDATA.CODEHDRMOD=com.retek.rib.binding.payload.CodeHdrDesc
SEEDDATA.DIFFTYPECRE=com.retek.rib.binding.payload.DiffTypeDesc
SEEDDATA.DIFFTYPEMOD=com.retek.rib.binding.payload.DiffTypeDesc
SOSTATUS.SOSTATUSCRE=com.retek.rib.binding.payload.SOStatusDesc
STORES.STORECRE=com.retek.rib.binding.payload.StoreDesc
STORES.STOREMOD=com.retek.rib.binding.payload.StoreDesc
UDAS.UDAHDRCRE=com.retek.rib.binding.payload.UDADesc
UDAS.UDAHDRMOD=com.retek.rib.binding.payload.UDADesc
UDAS.UDAVALCRE=com.retek.rib.binding.payload.UDAValDesc
UDAS.UDAVALMOD=com.retek.rib.binding.payload.UDAValDesc
VENAVL.VENCONIDSCRE=com.retek.rib.binding.payload.WSVenConIDsDesc
VENAVL.VENCONIDSMOD=com.retek.rib.binding.payload.WSVenConIDsDesc
VENDOR.VENCONTSCHCRE=com.retek.rib.binding.payload.WSSupContSchDesc
VENDOR.VENCONTSCHMOD=com.retek.rib.binding.payload.WSSupContSchDesc
VENDOR.VENDLVBLKCRE=com.retek.rib.binding.payload.WSSupDlvBlkDesc
VENDOR.VENDLVBLKMOD=com.retek.rib.binding.payload.WSSupDlvBlkDesc
VENDOR.VENDORADDRCRE=com.retek.rib.binding.payload.VendorAddrDesc
VENDOR.VENDORADDRMOD=com.retek.rib.binding.payload.VendorAddrDesc
VENDOR.VENDORCRE=com.retek.rib.binding.payload.VendorDesc
VENDOR.VENDORHDRMOD=com.retek.rib.binding.payload.VendorHdrDesc
VENDOR.VENDSATTRCRE=com.retek.rib.binding.payload.WSSupDsAttrDesc
VENDOR.VENDSATTRMOD=com.retek.rib.binding.payload.WSSupDsAttrDesc
VENDOR.VENPERFNCLCRE=com.retek.rib.binding.payload.WSSPerFnClDesc
VENDOR.VENPERFNCLMOD=com.retek.rib.binding.payload.WSSPerFnClDesc
VENDOR.VENPERRESCHACRE=com.retek.rib.binding.payload.WSSPerResChaDesc
VENDOR.VENPERTYPECRE=com.retek.rib.binding.payload.WSSupPerTypeDesc
VENDOR.VENPERTYPEMOD=com.retek.rib.binding.payload.WSSupPerTypeDesc
88

WH.WHATTRCRE=com.retek.rib.binding.payload.WSWHAttrDesc
WH.WHATTRMOD=com.retek.rib.binding.payload.WSWHAttrDesc
WH.WHCRE=com.retek.rib.binding.payload.WHDesc
WH.WHMOD=com.retek.rib.binding.payload.WHDesc

WOINT.WOINTCRE=com.retek.rib.binding.payload.WSWOIntDesc

89