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.
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 jbrooks@eweek.com.
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. Jason's coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
Email
Print
