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

System integrators can look to Openadaptor integration toolkit to provide ease-of-use and reliability; Openadaptor aspires to be a viable alternative to commercial solutions that may require considerable upfront licensing fees as well as to other, possibly overwhelming, open source products.

Let's now look at what an adaptor is in more detail.

Architectural Overview
An adaptor is a convenient assembly of Openadaptor components that function together as a unit. Components may be broadly divided into:

  • Connectors that provide mechanisms by which an adaptor communicates with the external environment. Read connectors and write connectors, respectively, accept data from, and output data to, the environment in which the adaptor is operating.
  • Processors that provide mechanisms to filter, route, transform, and enrich data as it traverses an adaptor.

Openadaptor's connectors are components built to normalize communications between external systems and the adaptor. Read connectors and write connectors facilitate incoming and outgoing communications, respectively. The framework comes with several connectors available as standard, including connectors to SQL databases, JMS, flat files, Web services, RMI, HTTP, and JNDI. These can be configured via their JavaBeans properties. Also, either through implementing simple interfaces or extending existing connectors, users can easily add connectors of their own, enabling bespoke systems with non-standard interfaces to feed data into or collect data from Openadaptor. There is no assumption as to what platform the integrated systems run on (see Non-Java Based Systems Integration sidebar for details). Where appropriate, under the hood Openadaptor leverages other well-established open source projects to handle particular technologies, for example, Web services connectors will use the XFire embeddable SOAP framework and HTTP connectors will use the popular open source Jetty web server (see Resources).

Processors are components for the manipulation of records. A given processor takes a record as input and generates zero or more records as output. Openadaptor comes with a number of ready-to-use processors, many of which act upon objects called ordered maps or XML (explained in the Internal Data Representation sidebar). The primary types of processors implement the IDataProcessor interface; these processors are the workhorse of Openadaptor. Other types of processors can manipulate records by enriching them with more data from an external resource, such as a database or an XML document. These are known as enrichment processors and implement the IEnrichmentProcessor interface.

A subgroup of data processors is convertors, whose only purpose is to change the format of the data rather than the data itself. Convertors could, for example change an ordered map into an XML document or a fixed-width delimited String to an ordered map.

Bespoke business logic can be implemented either with standard processors that support scripting languages such as JavaScript, or by implementing new Java processors. This may be very useful, especially for implementing more complex algorithms or for when the desired business logic has already been implemented and packaged up as a Java archive. Script processors have the option of invoking Java methods (say from Java archives) to access such algorithms.

Figure 1 shows four key interfaces. Most Openadaptor users shouldn't need to resort to writing custom Java code as the set of connectors and processors shipped with Openadaptor distribution is rich and comprehensive. Developers who elect to write custom Java code may do that either by direct implementation of one of these interfaces, or through the extension of Openadaptor components that most closely match their criteria.

These interfaces represent primary component types that may be arranged in a processing pipeline to form an adaptor. Adaptors are typically assembled using the Spring dependency injection mechanism by creating an XML configuration that defines connectors, processors, and linkages between them.

The framework also permits configuration values to be specified as placeholders, allowing the substitution of the actual runtime values separately. This is extremely useful for deploying from test to production environments.

A processing pipeline that reads from JMS and outputs to a delimited string file might be configured as a JMS read connector linked to a processor that modifies the data in some way and which itself is linked to a file write connector. A JMS message would be turned into an Openadaptor message and make its way through Openadaptor until it reaches the last component.

In its simplest form, an adaptor would consist of two components (see Figure 2): a read connector directly linked to a write connector:

More often, however, the adaptor would also contain a data processor. In a more complex form, as depicted in Figure 3, an adaptor could implement a fan-out to process the same message through two different branches (messages 3a and 3b onwards in Figure 3) that write to distinct external resources. It would typically have data format convertors and an exception handler (for more information on exception handling see the Exception Handling sidebar). Finally, it may even use an enrichment processor to enrich messages with relevant data from an external resource.

Step by step, each component in the pipeline will take the output of the preceding component, perform an operation on it, and pass the result to its successor.

When a standard Openadaptor JMX bean is added to an adaptor's configuration, individual components will be exposed as MBeans for remote access via a JMX console. This provides an easy way of inspecting a running adaptor's configuration. Information such as an adaptor's build details and runtime environment are readily available. The console also allows for the graceful stopping of running adaptors and dynamic adjustments of logging levels.

Openadaptor implements a transaction management abstraction that uses JTA (Java Transaction API, a high-level API by Sun Microsystems that defines interfaces between a transaction manager and the parties involved in a distributed transaction system). Out-of-the-box Openadaptor uses the open source transaction manager JOTM (see Resources); this can be overridden by any other JTA-compliant transaction manager. It's also possible to delegate transaction management, via Spring transaction abstractions, to any enclosing container other than that which Openadaptor happens to be deployed to (including JEE containers).

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