Book Image

Talend Open Studio Cookbook

By : Rick Barton
Book Image

Talend Open Studio Cookbook

By: Rick Barton

Overview of this book

Data integration is a key component of an organization's technical strategy, yet historically the tools have been very expensive. Talend Open Studio is the world's leading open source data integration product and has played a huge part in making open source data integration a popular choice for businesses worldwide.This book is a welcome addition to the small but growing library of Talend Open Studio resources. From working with schemas to creating and validating test data, to scheduling your Talend code, you will get acquainted with the various Talend database handling techniques. Each recipe is designed to provide the key learning point in a short, simple and effective manner.This comprehensive guide provides practical exercises that cover all areas of the Talend development lifecycle including development, testing, debugging and deployment. The book delivers design patterns, hints, tips, and advice in a series of short and focused exercises that can be approached as a reference for more seasoned developers or as a series of useful learning tutorials for the beginner.The book covers the basics in terms of schema usage and mappings, along with dedicated sections that will allow you to get more from tMap, files, databases and XML. Geared towards the whole lifecycle, the Talend Open Studio Cookbook shows readers great ways to handle everyday tasks, and provides an insight into all areas of a development cycle including coding, testing, and debugging of code to provide start-to-finish coverage of the product.
Table of Contents (21 chapters)
Talend Open Studio Cookbook
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Common Type Conversions
Index

Manipulating contexts in Talend Open Studio


Creating contexts in the studio is described in the recipe Adding contexts to a context group in Chapter 6, Managing Context Variables.

Pros

This is the simplest method of managing contexts. It all takes place in the Studio and is very visible to the developer.

It is also is a reasonably good way of protecting an environment, because when the code has been deployed, the context variables and launchers in production are usually available only to operational personnel. This means that the values available to a job in production, for example, passwords, can only be set in production by operation staff and will never be known by other personnel.

Cons

The number of contexts can easily get out of hand and become unmanageable, especially when multiple developers are working on the same project. Each will usually require a copy of the context, uniquely named, containing their information for their test environment.

Another downside is that it is very easy to create different context groups with different contexts, so that you end up with a variety of flavors or development, for instance, dev, DEV, Dev, and so on.

However, great care must be taken when using this method to ensure that after the first deployment of the context variables and launchers in production, they are not accidentally copied over when deploying a new version, or that the support staff remembers to update them if the new version of the code is copied to different folder.

Conclusion

If the processes surrounding this method are robust, then this can be a reasonable method for deployment in a small environment.