Kris Lachor

Subscribe to Kris Lachor: eMailAlertsEmail Alerts
Get Kris Lachor: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Systems Integration with Openadaptor

Business system integration with little or no custom programming

The reader is implemented by a FileReadConnector class, shipped as part of the Openadaptor package. After opening the file it will read the first line, which, represented as a Java String, will constitute an Openadaptor message that will flow to subsequent components in the pipeline. Here it is:

<bean id="fileReader" class="org.openadaptor.auxil.connector.iostream.reader.FileReadConnector">
     <property name="filename" value="input/delim.txt"/>

The only property set is the file name. Other properties could be set to, say, change the way the file is read - the default is a LineReader (which reads one line of the file in a single read operation). Overridding it with a StringReader would mean a single read operation equates to reading the whole file.

Occasionally it may be desirable to read data in batches, with a certain time interval between every batch. This can be achieved by using a throttling reader to wrap the "concrete" fileReader. In this example the batch size is set to two messages and the time interval to one second:

<bean id="throttlingReader" class="org.openadaptor.core.connector.ThrottlingReadConnector">
    <property name="delegate" ref="fileReader" />
    <property name="pollIntervalSecs" value="1"/>
    <property name="pauseOnlyAfterMsgs" value="2"/>

To filter out records that do not meet the criteria, a filter processor will be used (ScriptFilterProcessor). The processor manipulates fields using a simple JavaScript syntax. Let's assume all data where a user's first name is "Terry" needs to be discarded. Note that the discarded data could optionally be written to a dedicated file or processed further through a dedicated branch.

<bean id="jsFilter" class="org.openadaptor.auxil.processor.script.ScriptFilterProcessor">
    <property name="script" value="oa_data.get('fullname').indexOf('Terry') ==0"/>

The script processor expects an ordered map as input, whereas the reader bean will produce lines of file as Strings with comma-delimited fields. To convert those strings into ordered maps, the DelimitedStringToOrderedMapConvertor will be used.

<bean id="toOrderedmap" class="org.openadaptor.auxil.convertor.delimited.DelimitedStringToOrderedMapConvertor">
  <property name="fieldNames">

In addition to its role of a data convertor, the toOrderedMap processor will also turn up records with incorrect format, such as the one starting with chapmang that is missing the last field - uniqueid.

The next step is to define a connection to the relational database that will be used by the enrichment processor. The task of the enrichment processor is to find a date of birth for each user record. The jdbcConnection bean holds the data necessary to establish a connection with the Hypersonic database (see Listing 3). This connection bean will subsequently be set as a property on the dbReader that represents a database reader. Note: a Hypersonic script with the USER table definition (which the enrichment processor relies on) and sample data can be found in standard Openadaptor distribution.

The dbReader will connect to the database and execute an SQL SELECT query. It will form part of an enrichment processor, defined in the next step.

The enrichment processor uses the input data to extract certain parameters, which the framework will pass on to the underlying read connector (dbReader) to substitute parameters in its SQL query (replace the "?" with a concrete value). The parameterNames property indicates that the value of input field called uniqueid should be used to parameterize the SQL in the underlying reader (dbReader).

An exception processor will handle situations when something goes wrong, for example, when data is sent to a component in a wrong form (expects IOrderedMap, received plain String), the record has a wrong format (expects a comma-delimited String with three elements, receives only two), etc. The exception handler in this case is implemented by FileWriteConnector. In more sophisticated scenarios it could be made up of any number of nodes and do things like write errors to an audit database table or feed them back to the source system to notify it of errors.

<bean id="exceptionWriter" class="org.openadaptor.auxil.connector.iostream.writer.FileWriteConnector">
    <property name="filename" value="output/errors.txt"/>

One of the IWriteConnector components will publish the message to a JMS destination. The jmsPublisher is implemented by JMSWriteConnector, which uses a jmsConnection and connectionFactory names to look up the correct destination in the JNDI tree. The definitions of the relevant beans are shown in Listing 4.

And finally, the definition of the adaptor bean that assembles all previously defined beans into one unit (see Listing 5) is shown in Figure 5.

Note, that to define a fan-out, a processMap is used instead of processList property on the Router (a map allows for defining more than one output component). The adaptor's console output should be similar to the example2output.html.

Openadaptor is essentially a messaging-oriented technology for rapid business system integration with little or no custom programming. Its modular nature, clear and concise set of component types, and rich set of examples mean the learning curve is short and writing your first adaptors is painless. The product has been overhauled from the ground up to adopt new trends and technologies, and to make a number of improvements in areas where the original design fell short. Led by Dresdner Kleinwort, the investment banking arm of Dresdner Bank and a member of the Allianz Group, it is used in critical production systems to process high volumes of financial data. The non-intrusive approach to the payload and the leverage of other popular open source products make Openadaptor faster, lighter, and more intuitive than its predecessor. Openadaptor is being actively developed, with problems fixed and new functionality added as the surrounding technology changes. With a long heritage, it has age and experience on its side. Furthermore, it's open source, which gives you access to the source code and freedom to modify and recompile the code to your liking.



Internal Data Representation
Whether data is sourced from a database, a JMS queue, or from a multitude of other resources, once inside Openadaptor it needs to be represented in a format that may be understood by processors and write connectors (although the framework is in principle payload-neutral, individual components that manipulate the data need to assume certain specific data structures).

Ordered maps, which are Openadaptor implementations of java.util.Map, allow Openadaptor to easily handle list and tabular data (particularly convenient for processing files and JDBC result sets), at the same time being an easy-to-understand, standard API. They can also model hierarchical data, although - admittedly - not particularly elegantly. Ordered maps may contain anything that can be represented in Java, for example, Strings, POJOs, and byte arrays. Many supplied data processors favor input in the form of ordered maps that, together with XML, are seen as the nominal internal format for Openadaptor records, but the framework does not mandate any particular format. This gives users a free hand to use their own data representation in their custom written processors if they wish.


Non-Java Based Systems Integration
Openadaptor does not mandate for systems it integrates to run on any specific platform, in particular the integrated systems need not to be written in Java. By using language-neutral read or write connectors such as Web services (the recommended way of connecting with applications running on the .NET platform), HTTP or socket connectors, Openadaptor can read from or write to any system that can support any of these protocols. Similarly, there is no assumption to the geographical distribution of integrated systems as long as there is an existing network connection between them. The only requirement is that a Java Runtime Environment v1.4 or higher is installed on the actual machine Openadaptor runs on.


Exception Handling
An exception is shorthand for “exceptional event,” i.e., an event that disrupts the normal flow of messages through an adaptor. In a perfect world, there would be no need for exception handling, as data would all be perfect.

As it stands, however, processors and connectors may occasionally throw an exception, for example, as a result of unexpected data, data being in a wrong format, or an external resource being unavailable. Openadaptor is well equipped to deal with these situations. Exception handling is configured through setting up an exception processor in the adaptor. This can be a standard IWriteConnector, or an IDataProcessor (or a group of processors) “piped” with an IWriteConnector. The rules that apply to creating an exception handler are identical to those of the rest of the adaptor. This way errors may be trapped in a location or resource of choice in a way that clearly shows which data caused it.

More Stories By Kris Lachor

Kris Lachor is a senior software developer at Dresdner Kleinwort.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
higginse 10/28/08 09:41:45 AM EDT

Thanks for the feedback, it's always very useful to us. You should be able use stored procedures for updates - see the MapCallableStatementWriter (and corresponding map-stored-proc-writer.xml example, and their XML equivalents). In fact, if you can guarantee that the warehouse will always be based on Oracle it might be easiest to implement the 'upsert' funtionality in a stored procedure which the JDBC writer would invoke.

Having said that, with your comments in mind, we are looking at adding direct support for updates (and possibly 'upserts') with a view towards squeezing it into our upcoming 3.4.3 (November '08) release of openadaptor.

Also it's worth noting that the RawSQLWriter can achieve the same effect - it uses actual SQL strings which get directly executed against the db, albeit with a performance penalty (overhead of constructing the SQL manually, and not being able to compile it).

Eddy Higgins, Kris Lachor (& the openadaptor dev team)

P.S. Note that is the primary resource for openadaptor technical support. This affords the best visibility to the dev team, and other oa users.

imatos 10/27/08 11:55:00 AM EDT

Great article. Great tool. It seems a good fit to a new project I'm involved with.

The project will require extracting data from a ERP system to load into a data warehouse. The ERP system uses a DB2 UDB database, while the data warehouse will be based on an Oracle database. On a daily basis, it is necessary to extract all the new or updated records from selected tables on our ERP database to load on the data warehouse.

From the documentation and the samples, I found that it is very easy to INSERT data in a table, but could not find references to table UPDATES, or more specifically to the situation where an input record may be updating the corresponding record in the target table if it already exists, otherwise it will be inserted on the target table.

What would be the best approach to resolve this "UPSERT" type of problem using Openadaptor?

Many thanks for the help