Both Joblet and tRunJob component encourage code reuse and refactoring, help improve the development efficiency and ease the maintenance. However, you may wonder what is the difference between them, and in which case you should use one or the other. This article explains the differences between a Joblet and the tRunJob component from a technical point of view as well as from a usage angle.
Although the tRunJob is a generic component available in the core product Talend Open Studio for Data Integration, the Joblets are an advanced feature that is only available in Talend Enterprise subscription products. Therefore this article applies mostly to Talend Enterprise subscription product users.
Talend Studio uses a Java code generator, each Job is translated to a Java class. From a technical point of view, there are two differences:
Because of the differences between a Joblet and the tRunJob component in the code refactoring and function, the decision of when to use a Joblet or the tRunJob component is based on business requirements. The following explanation describes the circumstances which could lead you to choose one or the other.
The Joblet code is automatically included in the main Job code at runtime, thus using less resources and improving performance. A Joblet is usually used to achieve the following needs:
Output or print static messages. Sometimes, we want to trace the Job execution, print a static message for each step, for example, create a Joblet and use a tJava to print this message at the beginning of the Job execution:
The tRunJob component helps mastering complex Job systems in real project. The tRunJob is usually used to achieve the following needs:
The tRunJob component is the only solution for the below case you often face in real projects: read data from a data source, then process the data in a component. However, there might exist problematic data that lead to the Job execution failure. The Job throws a Java exception and stops to run. You need to capture the Java exception with a tLogCatcher component, log it to your database or file, and make the Job continue to perform the next data. For example, a table stores the email information as below:
The request is to read the email addresses from the table and send an email to each person with a tSendMail. But, as this table may contain invalid emails, the Job stops once an invalid email is sent to the tSendMail if you put all the components in one Job. To achieve this request, design the Jobs as follows:
tMysqlInput_1: reads emails from the table.
tFlowToIterate_1: iterates each email.
tRunJob_1: calls the child Job.
In the Basic settings tab of the tRunJob_1, clear the Die on child error check box so that the main Job will not stop even though an error occurs in the child Job. In the Context Param table, pass the current email from the main Job to the child Job. For more information, read the article about Passing a value from a parent Job to a child Job.
tSendMail_1: sends an email to each person.
tLogCatcher_1: catches the Java exception and log it into a table.
In the Basic settings tab of the tSendMail_1, in the To field, enter the context variable that stores the current email passed from the main Job.
Select the Die on error check box. This option makes the child Job throw a Java exception that will be captured by the tLogCatcher component when an email address is invalid.