tHTTPTableInput

This Component extracts HTML-Tables from a given URL.

The \'Syntax for Table\' means:
T=3 / Third(fourth) Table inside the page
C=0,0 / The Column at the position 0,0 in the third(fourth) table
T=1 / The first(second) table inside Cell 0,0 from the third(fourth) [optional]

Exemple 1: "T=3;C=0,0;T=1"
Exemple 2: "T=2;C=0,0;" with the change of revision 3
Exemple 3: "T=2;" with the change of revision 3

Securities Validation

Validate Fixed Income and Equity Securiites.
This routines calculates and compares the check digits for the follow securities

Isin
Sedol
Cusip

tmOracleOutput

This component adds "Delete obsolete" functionality to the existing tOracleOutput component.

"Delete Obsolete" option is enabled for all variants of "Insert and Update" data actions. If Delete Obsolete is turned on, all records from the target table that were not inserted or updated from the input row set, will be deleted. In other words, records from the target table that do not exist in the source set (matched on predefined IDs) will be deleted. This is like full synchronization between the source and the target record set.

Parameters (in addition to the existing tOracleOutput parameters):
- Delete obsolete records – enable deleting the obsolete records.
- Where clause condition for delete obsolete - optional where clause for deleted records. Only records that satisfy the where clause and are not in the input set will be deleted.

The component uses HashSet to store the IDs of the processed records. The limitation is that this is not efficient for large data sets. The component can be further enhanced to use disk implementation of HashSet, or to store the IDs of processed records in a database table.

tmMysqlOutput

This component adds "Delete obsolete" functionality to the existing tMysqlOutput component.

"Delete Obsolete" option is enabled for all variants of "Insert and Update" data actions. If Delete Obsolete is turned on, all records from the target table that were not inserted or updated from the input row set, will be deleted. In other words, records from the target table that do not exist in the source set (matched on predefined IDs) will be deleted. This is like full synchronization between the source and the target record set.

Parameters (in addition to the existing tMysqlOutput parameters):
- Delete obsolete records – enable deleting the obsolete records.
- Where clause condition for delete obsolete - optional where clause for deleted records. Only records that satisfy the where clause and are not in the input set will be deleted.

The component uses HashSet to store the IDs of the processed records. The limitation is that this is not efficient for large data sets. The component can be further enhanced to use disk implementation of HashSet, or to store the IDs of processed records in a database table.

tSharepointFile

This component allows you to grab any file from a Sharepoint server through http.
It performs the necessary NTLM authentication. The component takes the sharepoint file and creates a temporary copy of the file. The temporary file name is stored in tSharepointFile.FILE and can be used with the rest of Talend's components. The temporary file is deleted once the job has completed. (knowledgerelay.com)

tFileInputXbase

Read DBase and FoxPro files with the XBase Perl module.

tOneToMany

This component is a Proof Of Concept : a row component (taking a data flow as input) and creating several distinct data flow as output. Each output has a distinct schema, that you can set dynamically, at design time.

This component needs at least trunk r20522 (it will be available in 3.1.0M1).

CofigurableJobUsingSingleton

Problem Definition
The problem definition of the ETL job is as mentioned below.
1. The Configuration values like database credentials, log file location and name needs to be kept in a XML file
a. Name and Location of the Log File can be changed without modifying the ETL job
b. By editing the configuration file, the user can change the database credentials for the source and target database.
2. The ETL job must support both Windows and Unix family operation system
3. Validation of configuration file needs to be done
a. Whether the mentioned database credentials in the configuration file is correct or not needs to be informed to the user in the log file. Even the database credentials is correct and still it is not possible to connect to a database because might be the database is down then also the ETL job needs to log about this in the log file.
b. The log file path mentioned in the configuration file is correct or not needs to be informed to the user in the console
4. The configuration file needs to be passed from command line because there are more than one instance of the job are expected to be executed at the same time. It means multiple instances of target database are having the same structure. So multiple instances of the same job having different configuration file can migrate the data from the source database in case we need to make the target database values same at the same time. The values in the configuration files like target database name, Ip address must be different in all the configuration files.
5. The command line configuration file name and location needs to be checked by the ETL job and should inform the user, in case it is wrong it must exit from the job. The ETL job can use the console to inform about the wrong command line configuration file name
6. The configuration file should not be loaded each and every time from the disk whenever the values in the configuration file needs to be used by any ETL sub job. It means the configuration file should not be loaded for each sub jobs those use the content of the configuration file. The configuration file must be loaded only once and the values must be kept in the memory and to be used by all sub jobs.
7. There should be a log file and that should tell about the execution of the main job and sub jobs.
a. Information about start and end of each sub job and main job with status and time information should be kept in the log file.
b. In case any record is rejected while inserting the data, it should be kept in the log file with date, time and with an error message
c. Number of records fetched from source database and number of records processed and inserted into the target database must be kept in the log file
d. The log files for each instance of the job must be different and the user needs to be advised to do so. The user should not use the same log file for all the instances get executed at the same time. Other wise the log file will contain garbage
e. The ETL should manage to create log file according to date. It means the ETL will append the date value with the log file name mentioned in the configuration file.

tFileOutputPDF

This is the first version of the component that allow you to export your data in a PDF file.
Please have a look to the advanced settings because you would find a lot of parameters to customize your result.
I hope it will be helpfull

tRunJobRow

This component was created to run another job, sending to the subjob data rows, and getting back result rows :

- input and output schemas of the subjob can be different (technically, the tRunJobRow component has only an output schema)
- input and output row line numbers can be different

To work fine, this component NEEDS the tBufferCopyInput component.

User manual and explanations :
1) In the main job, data rows are sent to a tBufferOutput
2) In the subjob, data rows are read with a tBufferCopyInput. This component also cleans the global buffer for the next tBufferOutput
3) In the subjob, output data rows are sent to a tBufferOutput

See the screenshot for a real example.

DStar

D* Industries Demo Model