When our code eventually runs as a production job, it is expected that it will be robust, reliable, and bug free. For this to happen, it will usually pass through various stages of testing, including the unit test stage performed by the developer.
This section shows some of the methods that can be used to ensure that developers can find and fix problems quickly during this testing phase.
The ability to find and locate issues within code quickly and efficiently is the key to successful delivery of projects. Talend provides methods for debugging, and so does Eclipse.
Talend debugging instructions are as below:
1. Click on Designer|Run|Debug Run
2. Click on the arrow near “Traces Debug” so “Java Debug” shows up.
3. Click on “Java Debug” and say OK to switch to the Debug perspective. The program will stop in the main method if the Job class.
4. Place a break point by double clicking on the left side of the line number. For example, for the error below I searched for “The Json resource data may have some problems…” inside tFileInputJSON_1Process method.
5. Resume using the green arrow
6. You can add new code and next time you run the debugger, it will be executed (Use the bug symbol to run last debug configuration)
Talend provides useful components for logging and capturing errors in tWarn, tDie, and tFlowMeter. It also provides mechanisms for logging information to the console, which can be a quick and valuable debugging tool, and is a vital part of the developers’ armory. It is often quicker to send and view messages and information to the log output during development than it is to do the same to say a database or files.
The component tLogRow allows you to write row data to the Job log file, or console window, if you’re running your Job from within Talend Studio.
If you’re running your Job from within TalenD STUDIO, remember that, writing a large volume of data to the console windows, makes Talend Studio very unresponsive.
It is obvious that the code needs to be tested, and creation of unit testing data is usually part of the developer’s responsibilities. In many cases, Talend can be utilized as part of the test data creation process to enable jobs to be properly tested.
Find the location of COMPILATION ERRORS using the Problems tab
When you begin working with Talend, you will inevitably hit compilation errors when you run a job. This recipe will show you how to easily identify the errors using Talend.
Open the jo_cook_ch10_0010_findCompilationErrors job.
How to accomplish it…
The steps for finding the location of compilation errors using the Problems tab is as follows:
How it works…
When Talend recognizes that there are one or more compilation errors during execution, it will populate the Problems tab with the errors. Crossing over to the Java code enables the exact lines to be located and fixed.
To fix the problems mentioned previously, replace the ] with ) in the first tMap, and change the type of yearOfBirth to Integer in the output schema of the second tMap.
If you follow the best practice regarding keeping changes small and executing often, then you won’t have to use this method often, because you should be aware of what changes you have made since the last successful execution.
That said, it is a very quick and easy way to find lines that have errors and very useful when you have lots of fields within a tMap or other component.
Locating execution errors from the console output
This recipe shows that the often complex errors returned by Java can, in the main, be located fairly easily if you know how.
Open the jo_cook_ch10_0020_findExecutionError job.
How to achieve it…
The steps for locating execution errors from the console output are as follows:
How it works…
It is fairly obvious from the message that the error occurred in tMap_1, but it’s not so obvious unless you know Java error messages. Unlike compilation errors, Talend does not list the error in the problems log, so a bit of combined Talend and Java understanding is required here.
In most cases, the first line of the main body of the error message will show the job and line number for the error. In our case, you will see that the first line ends with:
This is the line number of the error within the job.
When working in the Code tab, CTRL + L will take you to a line number, in our case, 2636. This is the line that failed, and we can see that the field is the customer age field.
From the job, we can also see that three rows had been read from the input, but only two have been processed. This means that we have an error with the third row in the file.
When you look at the chapter10_jo_0020_customerData.csv file, you will see that the age field for the third row is blank.
If you also look at tMap_1, you will see that the age field is non-nullable.
Thus, it is the blank age value that is causing this job to fail with a null pointer exception.
If you change the blank age to an integer value in the file, then the job should run OK.
This method is a general rule of thumb and works for many Talend errors. Sometimes, the error message occurs within a Java method for which there is no source code.
Sometimes for deployed jobs in different environments the line numbers in the errors do not match the line numbers in the Studio version of the code. It is thus a good idea when deploying the code to ensure that the source code is also deployed. The line number in the error will always match the line number in the deployed code.
Get Updates on Tech posts, Interview & Certification questions and training schedules