REVIEW: Jitterbit 3.0 Effectively Links Disparate Apps, Data Sources

Jitterbit is a data integration suite that organizations can use to link up disparate applications and data sources that may not be capable of communicating with each other on their own. In eWEEK Labs' tests, Jitterbit 3.0 was easy to set up and use, and allows for a certain amount of self-service among data-savvy users.

Jitterbit 3.0 is a data integration suite that organizations can use to link up disparate applications and data sources that may not be capable of communicating with each other on their own. What's more, Jitterbit is easy enough to use to allow for a certain amount of self-service among data-savvy users looking to forge these links.

Jitterbit 3.0, which began shipping last fall, comes in three editions: Community, Enterprise and Enterprise MX. The Community edition is freely downloadable, but lacks the project, user and server management features of the two subscription-priced editions. Pricing for Jitterbit's Enterprise Edition starts at $6,400 per year and varies based on number of records managed, deployed servers and support options.

For a look at Jitterbit in action, click here.

In each of its three incarnations, Jitterbit consists of separate client and server elements. The client works in the creation of data integration operations, which are then deployed to one or more servers for execution. Multiple team members can have the Jitterbit client installed on their machines, and can collaborate around projects stored on one or more servers.

The Enterprise MX edition of the product, which is the flavor I tested, adds facilities for managing multiple servers and wrangling teams of users with role-based access controls.

I tested Jitterbit 3.0 on a virtual machine running CentOS 5.4 and playing host to both the client and server components of the product.

The Jitterbit software was easy enough to install. During the server portion of the installation, I was dumped out of the installer script a few times for lack of specific dependencies, but all the components I needed were close at hand in the default CentOS software repositories.

I set out to test Jitterbit 3.0 by creating an integration operation in which the product would fetch a plain-text, fixed-width delimited file containing basketball statistics from a public Web server and insert those stats into a table in a PostgreSQL database.

I created a new project in the Jitterbit client, and then created a new operation within that project. The client led me to define a source, a transformation and a target for the operation by rendering a simple diagram with placeholders for each of these elements in the application's workspace.

Double-clicking on the source element in the diagram spawned a new tab in the workspace with a wizardlike form for defining my source. I named my new source, chose "HTTP" from a source-type drop-down list and provided the URL where Jitterbit would be able to find my source file. I could also tap FTP, SFTP and FTPS locations; file shares; ODBC- or JDBC-connected databases; LDAP directories; and Web services as sources for integration operations.

Next came the transformation step, which involved specifying my text file to database intentions, selecting the text file source I'd just configured and then creating a new text structure definition to describe how the data in the source file had to be divvied up into rows and columns.

This step got a bit tedious because although the Jitterbit client offered to suggest a text structure based on a sample source document, the client was unable to come up with one on its own. Instead, I had to specify the start and end character positions for each column by hand, consulting a separate text editor to get those positions from my source sample.

Fortunately, once I'd defined the text structure for my source, I could use it in other operations simply by choosing it from a drop-down menu of sources saved along with my project. For each element I used or created, I could consult a "dependent objects" dialog that would keep me aware of what other elements in my project relied upon the component in question.

If I wanted to export any set of project elements for use in another project, I could wrap up those elements in the form of a Jitterpak, which I could then import into another project or even share with other Jitterbit users through the Trading Post section of the company's Website.

With my data source in place, I turned to the target side of the equation by configuring my new integration operation with a Postgres database and table to receive my stats.

When I reviewed Talend Open Studio a few months back, I was able to instruct the product to create a new table to receive my data. With Jitterbit, I had to create the table in Postgres on my own first.

After creating and configuring a target table, I used the Jitterbit client to set up my source to target data mapping and jump into an initial test of my new integration operation. Once I confirmed that my operation worked as expected, I deployed it to the Jitterbit server. There, the operation ran according to whatever schedule I chose for it from the client's scheduling dialog.

In addition to its integration project creation tools, the Jitterbit client provides a slate of administrative functions, including access to relevant server, operation and debug logs; views into the status of Jitterbit servers, process queues and scheduled events; as well as a user console with which I could divvy up access to very specific portions of projects on a per-user or per-group level.

Executive Editor Jason Brooks can be reached at