Featured Post

This example uses the same controller as in a previous post but adds a use case to support email validation. A Commons Validator object is ...

Thursday, March 20, 2014

Collaborating on Talend Open Studio Routines: Part 1 - Team Development

To collaborate effectively on a Java program, you need a development environment that provides configuration management, continuous testing, and automated packaging. A Talend Open Studio Routine is a Java program that can benefit from the supporting systems found in most Java workplaces. This is the first part in a series demonstrating the development of BRules, an open source library of useful methods for Talend Open Studio.

Routines

If you want to create a Routine in Talend Open Studio, select Create Routine, code your Routine, and export the Routine for import into other developers' workstations. This simple sequence of steps is a great way to factor out commonly-used functions from your Talend Open Studio components like tMap into something that can be applied to other components and jobs.

However, maintenance of the Routine by a team of developers is difficult because of the lack of version control and automated support. For such a collaborative scenario, this blog series recommends enlisting standard Java development technologies like Git, Maven, Jenkins, and JUnit. This is not an unconditional recommendation; if you're the only one using and distributing a Routine, follow the procedure outlined in the opening paragraph. Rather, this recommendation is given for a team structure.

Team-Based Development

BRules is an open source Talend Open Studio Routine containing functions for parsing, validation, and formatting. An example function is "pad" which adds padding to a number (1 -> 0000001).

BRules in the Repository Manager and Applied in a tMap

BRules development started with the simple Create / Test / Export process outlined at the beginning of the post. I used the Talend Open Studio commands to export BRules which I put on the Talend Exchange. However, I wanted to involve more people in its maintenance and product definition, so I formalized the development, making the source generally available. This meant creating a source code structure that wouldn't be tied to my computer (references to paths like C:/Users/Carl) so that others could modify the code without my involvement. The source code structure fits easily into configuration management but requires a solid build foundation.

Anticipating more development, I also added automated testing of BRules to fend off regressions.

The next post will give an overview of the process that I'm following. It's standard Java development taking elements that are found on every job I work on as a developer. If you're coming to Talend Open Studio from a database background, a lot of this will be unfamiliar. But remember, that this is far from a requirement for Talend Open Studio development and I myself don't create all this overhead each time I put two lines of code together.