Skip to main content

Talend Best Practice


Good Job design is at the heart of your Talend development. Here, we look at the different aspects of designing your Jobs. We can then, through the tutorial and reference pages, look at each of these in a little more depth, and how we can achieve our design goals.
Menu Pointer Read about these items in detail by viewing our Talend Best Practice menu items.
  • Purpose of Job
  • Job Architecture
  • Reusability
  • Error Handling
  • Restart & Recovery
  • Robustness
  • Performance (speed of execution)
  • Logging

Purpose of Job

The first and possibly easiest of our design goals is What's the purpose of the Job?. Unfortunately, this is often where it ends. This may be ok for your first simple Job; but this is not a good basis for working on a larger project either on your own or with a team of developers.
As with any software development, you want to write reusable and reliable code that is written once and run many.
It is the goal of this website to lay the foundations and show the building blocks of good Talend design – through tutorials, working examples and reference material.

Job Architecture

Even the simplest of Jobs needs some design thought. A trivial Job that reads data from a source, performs some manipulation and then writes the results to a target, may only require three basic components. But what if the Job fails? You may then need to start thinking about recovery and adding some error handling. Suddenly, the Job becomes much more complex than first thought. Often, it’s these aspects of Jobs that gets left for another day.
As Jobs become more complex, it’s important to think about the modularity of your work. What code is common across many Jobs and is reusable? Can a large task be broken down in to several smaller Jobs that can beorchestrated by a master Job?

Reusability

A key aspect to our overall design strategy is reusability. Each time we write some reusable and robust code, whether it’s just a simple fragment of code or an entire Job, we are closer to our goal of quickly writing fast and robust Job.
Talend provides many features to help you write reusable code. These include Jobs, Joblets, (Enterprise only), Context Groups, Repository Code Routines, Custom Components and other Repository objects.
As well as the features provided by Talend, there are other techniques that we can use. I usually have a Job in each of my projects named Palette. Here I store all of my pre-configured Components so that I can copy-and-paste them in to my Jobs with the minimal of effort. Of course, they are pre-configured using Context Variables so there is the minimum of effort each time they’re used.
For more on reusability within Talend, read our Talend Reusability Reference.

Error Handling

As with any programming, your Job may receive errors and these need to be handled.
These may be Exceptions thrown by the components in your Job or they may be other softer errors that you also need to handle in some way.
You may, for example, refer to a null Object and receive a NullPointerException. Unless you catch this exception and deal with it, your Job will usually terminate immediately. This may or may not be your desired result.
Sometimes, you may receive softer errors. Your Job may call a Web Service which is not available. No exception will be thrown; but the request may return an HTTP Status Code 503. This will not be fatal to Talend but, again, you may want to deal with this in a special way, for example, you may want to retry the request at a later time.
Talend provides a selection of components and techniques for handling errors.

Restart & Recovery

Now that you’re handling errors, you’re in a much better position to deal with your Job should it receive a fatal error.
Can your Job simply be restarted from the beginning? Is that practicable? Or should you restart the Job at a logical point of failure?
There are many techniques for restarting your work at a point of failure and we’ll look at some of these in more detail in a later article.

Robustness

Once the architecture of your Job is in place, errors are being handled, and there is restart and recovery capability, your Job is well on the way to being reliable and robust.

Performance

Performance (usually meaning speed of execution) is often a key metric of a Jobs success or failure. There are many aspects to tuning your Job, including: General Job design, Memory management, I/O, Sharing the load with inputs and outputs (e.g. Databases) and Parallelism. There are also factors that may not be under the direct control of the Talend Developer such as Network performance and the configuration of external sources and targets. These should all be taken in to consideration.

Logging

Finally, it’s good practice to record information about the execution of your Job, over time. This helps with performance tuning and resolving issues.

Comments

Popular posts from this blog

ODI KM Adding Order by Option

You can add Order by statement to queries by editing KM.I have edited IKM SQL Control Append to provide Order by.  1) Add an option to KM named USE_ORDER_BY, its type is Checkbox and default value is False. This option determines you want an order by statement at your query. 2)Add second option to KM named ORDER_BY, type is Text. You will get order by values to your query by this option. 3) Editing Insert New Rows detail of KM. Adding below three line code after having clause. That's it! <% if (odiRef.getOption("USE_ORDER_ BY").equals("1")) { %> ORDER BY <%=odiRef.getOption("ORDER_BY" )%> <%} %>  If USE_ORDER_BY option is not used, empty value of ORDER_BY option get error. And executions of KM appears as such below; At this execution, I checked the KM to not get errors if ORDER_BY option value is null. There is no prove of ORDER BY I'm glad.  Second execution to get  Ord

Creating Yellow Interface in ODI

Hello everyone! In Oracle data integrator (ODI), an  interface  is an object which populates one datastore, called the  target , with data coming from one or more other datastores, known as  sources . The fields of the source datastore are linked to those in the target datastore using the concept of  Mapping . Temporary interfaces used in ODI are popularly known as  Yellow Interfaces . It is because ODI generates a yellow icon at the time of creation of a yellow interface as opposed to the blue icon of a regular interface. The advantage of using a yellow interface is to avoid the creation of  Models each time you need to use it in an interface. Since they are temporary, they are not a part of the data model and hence don’t need to be in the Model. So let’s begin and start creating our yellow interface! Pre-requisites : Oracle 10g Express Edition with *SQL Plus, Oracle Data Integrator 11g. Open *SQL Plus and create a new table  Sales  in Oracle. You can use any existing ta

Running Count in Talend Open Studio

Most Talend components keep a count of the records processed using variables like NB_LINE or NB_LINE_OK.  But these are only available after all processing is completed.  Define your own counter variable to keep a running count for use in a tMap. Variables like tFilterRow.NB_LINE or tAccessOutput.NB_LINE_INSERTED can be used to report the number of affected lines after a subjob's processing.  However, it may be of use to get the current line index for use in a tMap.  The index variables used to form NB_LINE aren't available during processing; they're only written out the globalMap at the end of processing. In this example, staging records are loaded from Excel to Access.  The order in which the Excel records are read is preserved in a database column called DISPLAY_SEQ_NB.  Note that there is an auto-increment column used for record ID in the Access table.  This could be used to infer a loading order, but this job uses a separate column to keep the ID as a meaningless surr