The following tutorials are designed to help you understand the main principles of component development using Talend Component Kit. With this set of tutorials, get your hands on project creation using the Component Kit Starter and implement the logic of different types of components. Creating your first component Generating a project from the starter Creating a Hazelcast input component Creating a Hazelcast output component Creating a Zendesk REST API connector Handling component version migration With this set of tutorials, learn the different approaches to test the components created in the previous tutorials. Testing a Zendesk REST API connector Testing a Hazelcast component Testing in a continuous integration environment

The Component Kit Starter lets you design your components configuration and generates a ready-to-implement project structure. The Starter is available on the web or as an IntelliJ plugin. This tutorial shows you how to use the Component Kit Starter to generate new components for MySQL databases. Before starting, make sure that you have correctly setup your environment. See this section. When defining a project using the Starter, do not refresh the page to avoid losing your configuration. Before being able to create components, you need to define the general settings of the project: Create a folder on your local machine to store the resource files of the component you want to create. For example, C:/my_components. Open the Starter in the web browser of your choice. Select your build tool. This tutorial uses Maven, but you can select Gradle instead. Add any facet you need. For example, add the Talend Component Kit Testing facet to your project to automatically generate unit tests for the components created in the project. Enter the Component Family of the components you want to develop in the project. This name must be a valid java name and is recommended to be capitalized, for example 'MySQL'. Once you have implemented your components in the Studio, this name is displayed in the Palette to group all of the MySQL-related components you develop, and is also part of your component name. Select the Category of the components you want to create in the current project. As MySQL is a kind of database, select Databases in this tutorial. This Databases category is used and displayed as the parent family of the MySQL group in the Palette of the Studio. Complete the project metadata by entering the Group, Artifact and Package. By default, you can only create processors. If you need to create Input or Output components, select Activate IO. By doing this: Two new menu entries let you add datasets and datastores to your project, as they are required for input and output components. Input and Output components without dataset (itself containing a datastore) will not pass the validation step when building the components. Learn more about datasets and datastores in this document. An Input component and an Output component are automatically added to your project and ready to be configured. Components added to the project using Add A Component can now be processors, input or output components. A datastore represents the data needed by an input or output component to connect to a database. When building a component, the validateDataSet validation checks that each input or output (processor without output branch) component uses a dataset and that this dataset has a datastore. You can define one or several datastores if you have selected the Activate IO step. Select Datastore. The list of datastores opens. By default, a datastore is already open but not configured. You can configure it or create a new one using Add new Datastore. Specify the name of the datastore. Modify the default value to a meaningful name for your project. This name must be a valid Java name as it will represent the datastore class in your project. It is a good practice to start it with an uppercase letter. Edit the datastore configuration. Parameter names must be valid Java names. Use lower case as much as possible. A typical configuration includes connection details to a database: url username password. Save the datastore configuration. A dataset represents the data coming from or sent to a database and needed by input and output components to operate. The validateDataSet validation checks that each input or output (processor without output branch) component uses a dataset and that this dataset has a datastore. You can define one or several datasets if you have selected the Activate IO step. Select Dataset. The list of datasets opens. By default, a dataset is already open but not configured. You can configure it or create a new one using the Add new Dataset button. Specify the name of the dataset. Modify the default value to a meaningful name for your project. This name must be a valid Java name as it will represent the dataset class in your project. It is a good practice to start it with an uppercase letter. Edit the dataset configuration. Parameter names must be valid Java names. Use lower case as much as possible. A typical configuration includes details of the data to retrieve: Datastore to use (that contains the connection details to the database) table name data Save the dataset configuration. To create an input component, make sure you have selected Activate IO. When clicking Add A Component in the Starter, a new step allows you to define a new component in your project. The intent in this tutorial is to create an input component that connects to a MySQL database, executes a SQL query and gets the result. Choose the component type. Input in this case. Enter the component name. For example, MySQLInput. Click Configuration model. This button lets you specify the required configuration for the component. By default, a dataset is already specified. For each parameter that you need to add, click the (+) button on the right panel. Enter the parameter name and choose its type then click the tick button to save the changes. In this tutorial, to be able to execute a SQL query on the Input MySQL database, the configuration requires the following parameters:+ a dataset (which contains the datastore with the connection information) a timeout parameter. Closing the configuration panel on the right does not delete your configuration. However, refreshing the page resets the configuration. Specify whether the component issues a stream or not. In this tutorial, the MySQL input component created is an ordinary (non streaming) component. In this case, leave the Stream option disabled. Select the Record Type generated by the component. In this tutorial, select Generic because the component is designed to generate records in the default Record format. You can also select Custom to define a POJO that represents your records. Your input component is now defined. You can add another component or generate and download your project. When clicking Add A Component in the Starter, a new step allows you to define a new component in your project. The intent in this tutorial is to create a simple processor component that receives a record, logs it and returns it at it is. If you did not select Activate IO, all new components you add to the project are processors by default. If you selected Activate IO, you can choose the component type. In this case, to create a Processor component, you have to manually add at least one output. If required, choose the component type: Processor in this case. Enter the component name. For example, RecordLogger, as the processor created in this tutorial logs the records. Specify the Configuration Model of the component. In this tutorial, the component doesn’t need any specific configuration. Skip this step. Define the Input(s) of the component. For each input that you need to define, click Add Input. In this tutorial, only one input is needed to receive the record to log. Click the input name to access its configuration. You can change the name of the input and define its structure using a POJO. If you added several inputs, repeat this step for each one of them. The input in this tutorial is a generic record. Enable the Generic option and click Save. Define the Output(s) of the component. For each output that you need to define, click Add Output. The first output must be named MAIN. In this tutorial, only one generic output is needed to return the received record. Outputs can be configured the same way as inputs (see previous steps). You can define a reject output connection by naming it REJECT. This naming is used by Talend applications to automatically set the connection type to Reject. Your processor component is now defined. You can add another component or generate and download your project. To create an output component, make sure you have selected Activate IO. When clicking Add A Component in the Starter, a new step allows you to define a new component in your project. The intent in this tutorial is to create an output component that receives a record and inserts it into a MySQL database table. Output components are Processors without any output. In other words, the output is a processor that does not produce any records. Choose the component type. Output in this case. Enter the component name. For example, MySQLOutput. Click Configuration Model. This button lets you specify the required configuration for the component. By default, a dataset is already specified. For each parameter that you need to add, click the (+) button on the right panel. Enter the name and choose the type of the parameter, then click the tick button to save the changes. In this tutorial, to be able to insert a record in the output MySQL database, the configuration requires the following parameters:+ a dataset (which contains the datastore with the connection information) a timeout parameter. Closing the configuration panel on the right does not delete your configuration. However, refreshing the page resets the configuration. Define the Input(s) of the component. For each input that you need to define, click Add Input. In this tutorial, only one input is needed. Click the input name to access its configuration. You can change the name of the input and define its structure using a POJO. If you added several inputs, repeat this step for each one of them. The input in this tutorial is a generic record. Enable the Generic option and click Save. Do not create any output because the component does not produce any record. This is the only difference between an output an a processor component. Your output component is now defined. You can add another component or generate and download your project. Once your project is configured and all the components you need are created, you can generate and download the final project. In this tutorial, the project was configured and three components of different types (input, processor and output) have been defined. Click Finish on the left panel. You are redirected to a page that summarizes the project. On the left panel, you can also see all the components that you added to the project. Generate the project using one of the two options available: Download it locally as a ZIP file using the Download as ZIP button. Create a GitHub repository and push the project to it using the Create on Github button. In this tutorial, the project is downloaded to the local machine as a ZIP file. Once the package is available on your machine, you can compile it using the build tool selected when configuring the project. In the tutorial, Maven is the build tool selected for the project. In the project directory, execute the mvn package command. If you don’t have Maven installed on your machine, you can use the Maven wrapper provided in the generated project, by executing the ./mvnw package command. If you have created a Gradle project, you can compile it using the gradle build command or using the Gradle wrapper: ./gradlew build. The generated project code contains documentation that can guide and help you implementing the component logic. Import the project to your favorite IDE to start the implementation. The Component Kit Starter allows you to generate a component development project from an OpenAPI JSON descriptor. Open the Starter in the web browser of your choice. Enable the OpenAPI mode using the toggle in the header. Go to the API menu. Paste the OpenAPI JSON descriptor in the right part of the screen. All the described endpoints are detected. Unselect the endpoints that you do not want to use in the future components. By default, all detected endpoints are selected. Go to the Finish menu. Download the project. When exploring the project generated from an OpenAPI descriptor, you can notice the following elements: sources the API dataset an HTTP client for the API a connection folder containing the component configuration. By default, the configuration is only made of a simple datastore with a baseUrl parameter.

Testing code that consumes REST APIs can sometimes present many constraints: API rate limit, authentication token and password sharing, API availability, sandbox expiration, API costs, and so on. As a developer, it becomes critical to avoid those constraints and to be able to easily mock the API response. The component framework provides an API simulation tool that makes it easy to write unit tests. This tutorial shows how to use this tool in unit tests. As a starting point, the tutorial uses the component that consumes Zendesk Search API and that was created in a previous tutorial. The goal is to add unit tests for it. For this tutorial, four tickets that have the open status have been added to the Zendesk test instance used in the tests. To learn more about the testing methodology used in this tutorial, refer to Component JUnit testing. Create a unit test that performs a real HTTP request to the Zendesk Search API instance. You can learn how to create a simple unit test in this tutorial. the authentication configuration using Zendesk instance URL and credentials. the search query configuration to get all the open ticket, ordered by creation date and sorted in descending order. The test is now complete and working. It performs a real HTTP request to the Zendesk instance. As an alternative, you can use mock results to avoid performing HTTP requests every time on the development environment. The real HTTP requests would, for example, only be performed on an integration environment. To transform the unit test into a mocked test that uses a mocked response of the Zendesk Search API: Add the two following JUnit rules provided by the component framework. JUnit4HttpApi: This rule starts a simulation server that acts as a proxy and catches all the HTTP requests performed in the tests. This simulation server has two modes : capture : This mode forwards the captured HTTP request to the real server and captures the response. simulation : this mode returns a mocked response from the responses already captured. This rule needs to be added as a class rule. JUnit4HttpApi: This rule has a reference to the first rule. Its role is to configure the simulation server for every unit test. It passes the context of the running test to the simulation server. This rule needs to be added as a simple (method) rule. Example to run in a simulation mode: Make the test run in capture mode to catch the real API responses that can be used later in the simulated mode. To do that, set a new talend.junit.http.capture environment variable to true. This tells the simulation server to run in a capture mode. The captured response is saved in the resources/talend.testing.http package in a JSON format, then reused to perform the API simulation.

This tutorial shows how to create components that consume a REST API. The component developed as example in this tutorial is an input component that provides a search functionality for Zendesk using its Search API. Lombok is used to avoid writing getter, setter and constructor methods. You can generate a project using the Talend Components Kit starter, as described in this tutorial. The input component relies on Zendesk Search API and requires an HTTP client to consume it. The Zendesk Search API takes the following parameters on the /api/v2/search.json endpoint. query : The search query. sort_by : The sorting type of the query result. Possible values are updated_at, created_at, priority, status, ticket_type, or relevance. It defaults to relevance. sort_order: The sorting order of the query result. Possible values are asc (for ascending) or desc (for descending). It defaults to desc. Talend Component Kit provides a built-in service to create an easy-to-use HTTP client in a declarative manner, using Java annotations. No additional implementation is needed for the interface, as it is provided by the component framework, according to what is defined above. This HTTP client can be injected into a mapper or a processor to perform HTTP requests. This example uses the basic authentication that supported by the API. The first step is to set up the configuration for the basic authentication. To be able to consume the Search API, the Zendesk instance URL, the username and the password are needed. The data store is now configured. It provides a basic authentication token. Once the data store is configured, you can define the dataset by configuring the search query. It is that query that defines the records processed by the input component. Your component is configured. You can now create the component logic. Mappers defined with this tutorial don’t implement the split part because HTTP calls are not split on many workers in this case. Once the component logic implemented, you can create the source in charge of performing the HTTP request to the search API and converting the result to JsonObject records. You now have created a simple Talend component that consumes a REST API. To learn how to test this component, refer to this tutorial.

This tutorial walks you through the creation, from scratch, of a complete Talend input component for Hazelcast using the Talend Component Kit (TCK) framework. Hazelcast is an in-memory distributed system that can store data, which makes it a good example of input component for distributed systems. This is enough for you to get started with this tutorial, but you can find more information about it here: hazelcast.org/. A TCK project is a simple Java project with specific configurations and dependencies. You can choose your preferred build tool from Maven or Gradle as TCK supports both. In this tutorial, Maven is used. The first step consists in generating the project structure using Talend Starter Toolkit . Go to starter-toolkit.talend.io/ and fill in the project information as shown in the screenshots below, then click Finish and Download as ZIP. image::tutorial_hazelcast_generateproject_1.png[] image::tutorial_hazelcast_generateproject_2.png[] Extract the ZIP file into your workspace and import it to your preferred IDE. This tutorial uses Intellij IDE, but you can use Eclipse or any other IDE that you are comfortable with. You can use the Starter Toolkit to define the full configuration of the component, but in this tutorial some parts are configured manually to explain key concepts of TCK. The generated pom.xml file of the project looks as follows: Change the name tag to a more relevant value, for example: Component Hazelcast. The component-api dependency provides the necessary API to develop the components. talend-component-maven-plugin provides build and validation tools for the component development. The Java compiler also needs a Talend specific configuration for the components to work correctly. The most important is the -parameters option that preserves the parameter names needed for introspection features that TCK relies on. Download the mvn dependencies declared in the pom.xml file: You should get a BUILD SUCCESS at this point: Create the project structure: Create the component Java packages. Packages are mandatory in the component model and you cannot use the default one (no package). It is recommended to create a unique package per component to be able to reuse it as dependency in other components, for example to guarantee isolation while writing unit tests. The project is now correctly set up. The next steps consist in registering the component family and setting up some properties. Registering every component family allows the component server to properly load the components and to ensure they are available in Talend Studio. The family registration happens via a package-info.java file that you have to create. Move to the src/main/java/org/talend/components/hazelcast package and create a package-info.java file: @Components: Declares the family name and the categories to which the component belongs. @Icon: Defines the component family icon. This icon is visible in the Studio metadata tree. Talend Component Kit supports internationalization (i18n) via Java properties files. Using these files, you can customize and translate the display name of properties such as the name of a component family or, as shown later in this tutorial, labels displayed in the component configuration. Go to src/main/resources/org/talend/components/hazelcast and create an i18n Messages.properties file as below: You can define the component family icon in the package-info.java file. The icon image must exist in the resources/icons folder. TCK supports both SVG and PNG formats for the icons. Create the icons folder and add an icon image for the Hazelcast family. This tutorial uses the Hazelcast icon from the official GitHub repository that you can get from: avatars3.githubusercontent.com/u/1453152?s=200&v=4 Download the image and rename it to Hazelcast_icon32.png. The name syntax is important and should match _icon.32.png. The component registration is now complete. The next step consists in defining the component configuration. All Input and Output (I/O) components follow a predefined model of configuration. The configuration requires two parts: Datastore: Defines all properties that let the component connect to the targeted system. Dataset: Defines the data to be read or written from/to the targeted system. Connecting to the Hazelcast cluster requires the IP address, group name and password of the targeted cluster. In the component, the datastore is represented by a simple POJO. Create a HazelcastDatastore.java class file in the src/main/java/org/talend/components/hazelcast folder. Define the i18n properties of the datastore. In the Messages.properties file let add the following lines: The Hazelcast datastore is now defined. Hazelcast includes different types of datastores. You can manipulate maps, lists, sets, caches, locks, queues, topics and so on. This tutorial focuses on maps but still applies to the other data structures. Reading/writing from a map requires the map name. Create the dataset class by creating a HazelcastDataset.java file in src/main/java/org/talend/components/hazelcast. The @Dataset annotation marks the class as a dataset. Note that it also references a datastore, as required by the components model. Just how it was done for the datastore, define the i18n properties of the dataset. To do that, add the following lines to the Messages.properties file. The component configuration is now ready. The next step consists in creating the Source that will read the data from the Hazelcast map. The Source is the class responsible for reading the data from the configured dataset. A source gets the configuration instance injected by TCK at runtime and uses it to connect to the targeted system and read the data. Create a new class as follows. The source also needs i18n properties to provide a readable display name. Add the following line to the Messages.properties file. At this point, it is already possible to see the result in the Talend Component Web Tester to check how the configuration looks like and validate the layout visually. To do that, execute the following command in the project folder. This command starts the Component Web Tester and deploys the component there. Access localhost:8080/. The source is set up. It is now time to start creating some Hazelcast specific code to connect to a cluster and read values for a map. Add the hazelcast-client Maven dependency to the pom.xml of the project, in the dependencies node. Add a Hazelcast instance to the @PostConstruct method. Declare a HazelcastInstance attribute in the source class. Any non-serializable attribute needs to be marked as transient to avoid serialization issues. Implement the post construct method. The component configuration is mapped to the Hazelcast client configuration to create a Hazelcast instance. This instance will be used later to get the map from its name and read the map data. Only the required configuration in the component is exposed to keep the code as simple as possible. Implement the code responsible for reading the data from the Hazelcast map through the Producer method. The Producer implements the following logic: Check if the map iterator is already initialized. If not, get the map from its name and initialize the map iterator. This is done in the @Producer method to ensure the map is initialized only if the next() method is called (lazy initialization). It also avoids the map initialization in the PostConstruct method as the Hazelcast map is not serializable. All the objects initialized in the PostConstruct method need to be serializable as the source can be serialized and sent to another worker in a distributed cluster. From the map, create an iterator on the map keys that will read from the map. Transform every key/value pair into a Talend Record with a "key, value" object on every call to next(). The RecordBuilderFactory class used above is a built-in service in TCK injected via the Source constructor. This service is a factory to create Talend Records. Now, the next() method will produce a Record every time it is called. The method will return "null" if there is no more data in the map. Implement the @PreDestroy annotated method, responsible for releasing all resources used by the Source. The method needs to shut the Hazelcast client instance down to release any connection between the component and the Hazelcast cluster. The Hazelcast Source is completed. The next section shows how to write a simple unit test to check that it works properly. TCK provides a set of APIs and tools that makes the testing straightforward. The test of the Hazelcast Source consists in creating an embedded Hazelcast instance with only one member and initializing it with some data, and then in creating a test Job to read the data from it using the implemented Source. Add the required Maven test dependencies to the project. Initialize a Hazelcast test instance and create a map with some test data. To do that, create the HazelcastSourceTest.java test class in the src/test/java folder. Create the folder if it does not exist. The above example creates a Hazelcast instance for the test and creates the MY-DISTRIBUTED-MAP map. The getMap creates the map if it does not already exist. Some keys and values uses in the test are added. Then, a simple test checks that the data is correctly initialized. Finally, the Hazelcast test instance is shut down. Run the test and check in the logs that a Hazelcast cluster of one member has been created and that the test has passed. To be able to test components, TCK provides the @WithComponents annotation which enables component testing. Add this annotation to the test. The annotation takes the component Java package as a value parameter. Create the test Job that configures the Hazelcast instance and link it to an output that collects the data produced by the Source. Execute the unit test and check that it passes, meaning that the Source is reading the data correctly from Hazelcast. The Source is now completed and tested. The next section shows how to implement the Partition Mapper for the Source. In this case, the Partition Mapper will split the work (data reading) between the available cluster members to distribute the workload. The Partition Mapper calculates the number of Sources that can be created and executed in parallel on the available workers of a distributed system. For Hazelcast, it corresponds to the cluster member count. To fully illustrate this concept, this section also shows how to enhance the test environment to add more Hazelcast cluster members and initialize it with more data. Instantiate more Hazelcast instances, as every Hazelcast instance corresponds to one member in a cluster. In the test, it is reflected as follows: The above code sample creates two Hazelcast instances, leading to the creation of two Hazelcast members. Having a cluster of two members (nodes) will allow to distribute the data. The above code also adds more data to the test map and updates the shutdown method and the test. Run the test on the multi-nodes cluster. The Source is a simple implementation that does not distribute the workload and reads the data in a classic way, without distributing the read action to different cluster members. Start implementing the Partition Mapper class by creating a HazelcastPartitionMapper.java class file. When coupling a Partition Mapper with a Source, the Partition Mapper becomes responsible for injecting parameters and creating source instances. This way, all the attribute initialization part moves from the Source to the Partition Mapper class. The configuration also sets an instance name to make it easy to find the client instance in the logs or while debugging. The Partition Mapper class is composed of the following: constructor: Handles configuration and service injections Assessor: This annotation indicates that the method is responsible for assessing the dataset size. The underlying runner uses the estimated dataset size to compute the optimal bundle size to distribute the workload efficiently. Split: This annotation indicates that the method is responsible for creating Partition Mapper instances based on the bundle size requested by the underlying runner and the size of the dataset. It creates as much partitions as possible to parallelize and distribute the workload efficiently on the available workers (known as members in the Hazelcast case). Emitter: This annotation indicates that the method is responsible for creating the Source instance with an adapted configuration allowing to handle the amount of records it will produce and the required services. I adapts the configuration to let the Source read only the requested bundle of data. The Assessor method computes the memory size of every member of the cluster. Implementing it requires submitting a calculation task to the members through a serializable task that is aware of the Hazelcast instance. Create the serializable task. The purpose of this class is to submit any task to the Hazelcast cluster. Use the created task to estimate the dataset size in the Assessor method. The Assessor method calculates the memory size that the map occupies for all members. In Hazelcast, distributing a task to all members can be achieved using an execution service initialized in the getExecutorService() method. The size of the map is requested on every available member. By summing up the results, the total size of the map in the distributed cluster is computed. The Split method calculates the heap size of the map on every member of the cluster. Then, it calculates how many members a source can handle. If a member contains less data than the requested bundle size, the method tries to combine it with another member. That combination can only happen if the combined data size is still less or equal to the requested bundle size. The following code illustrates the logic described above. The next step consists in adapting the source to take the Split into account. The following sample shows how to adapt the Source to the Split carried out previously. The next method reads the data from the members received from the Partition Mapper. A Big Data runner like Spark will get multiple Source instances. Every source instance will be responsible for reading data from a specific set of members already calculated by the Partition Mapper. The data is fetched only when the next method is called. This logic allows to stream the data from members without loading it all into the memory. Implement the method annotated with @Emitter in the HazelcastPartitionMapper class. The createSource() method creates the source instance and passes the required services and the selected Hazelcast members to the source instance. Run the test and check that it works as intended. The component implementation is now done. It is able to read data and to distribute the workload to available members in a Big Data execution environment. Refactor the component by introducing a service to make some pieces of code reusable and avoid code duplication. Refactor the Hazelcast instance creation into a service. Inject this service to the Partition Mapper to reuse it. Adapt the Source class to reuse the service. Run the test one last time to ensure everything still works as expected. Thank you for following this tutorial. Use the logic and approach presented here to create any input component for any system.

This tutorial is the continuation of Talend Input component for Hazelcast tutorial. We will not walk through the project creation again, So please start from there before taking this one. This tutorial shows how to create a complete working output component for Hazelcast As seen before, in Hazelcast there is multiple data source type. You can find queues, topics, cache, maps… In this tutorials we will stick with the Map dataset and all what we will see here is applicable to the other types. Let’s assume that our Hazelcast output component will be responsible of inserting data into a distributed Map. For that, we will need to know which attribute from the incoming data is to be used as a key in the map. The value will be the hole record encoded into a json format. Bu that in mind, we can design our output configuration as: the same Datastore and Dataset from the input component and an additional configuration that will define the key attribute. Let’s create our Output configuration class. Let’s add the i18n properties of our configuration into the Messages.properties file The skeleton of the output component looks as follows: @Version annotation indicates the version of the component. It is used to migrate the component configuration if needed. @Icon annotation indicates the icon of the component. Here, the icon is a custom icon that needs to be bundled in the component JAR under resources/icons. @Processor annotation indicates that this class is the processor (output) and defines the name of the component. constructor of the processor is responsible for injecting the component configuration and services. Configuration parameters are annotated with @Option. The other parameters are considered as services and are injected by the component framework. Services can be local (class annotated with @Service) or provided by the component framework. The method annotated with @PostConstruct is executed once by instance and can be used for initialization. The method annotated with @PreDestroy is used to clean resources at the end of the execution of the output. Data is passed to the method annotated with @ElementListener. That method is responsible for handling the data output. You can define all the related logic in this method. If you need to bulk write the updates accordingly to groups, see Processors and batch processing. Now, we will need to add the display name of the Output to the i18n resources file Messages.properties Let’s implement all of those methods We will create the outpu contructor to inject the component configuration and some additional local and built in services. Built in services are services provided by TCK. Here we find: configuration is the component configuration class hazelcastService is the service that we have implemented in the input component tutorial. it will be responsible of creating a hazelcast client instance. jsonb is a built in service provided by tck to handle json object serialization and deserialization. We will use it to convert the incoming record to json format before inseting them into the map. Nothing to do in the post construct method. but we could for example initialize a hazle cast instance there. but we will do it in a lazy way on the first call in the @ElementListener method Shut down the Hazelcast client instance and thus free the Hazelcast map reference. We get the key attribute from the incoming record and then convert the hole record to a json string. Then we insert the key/value into the hazelcast map. Let’s create a unit test for our output component. The idea will be to create a job that will insert the data using this output implementation. So, let’s create out test class. Here we start by creating a hazelcast test instance, and we initialize the map. we also shutdown the instance after all the test are executed. Now let’s create our output test. Here we start preparing the emitter test component provided bt TCK that we use in our test job to generate random data for our output. Then, we use the output component to fill the hazelcast map. By the end we test that the map contains the exact amount of data inserted by the job. Run the test and check that it’s working. Congratulation you just finished your output component.

This tutorial focuses on writing unit tests for the input component that was created in this previous tutorial. This tutorial covers: How to load components in a unit test. How to create a job pipeline. How to run the test in standalone mode. The test class is as follows:

This tutorial shows how to correctly mask the sensitive data of a component configuration. It is very common to define credentials when configuring a component. Most common cases can include passwords, secrets, keys (it is also common to show them in plain text in a textarea), and tokens. For example, this REST client configuration specifies that a username, a password and a token are needed to connect to the REST API: This configuration defines that these credentials are three simple String, represented as plain inputs, which causes severe security concerns: The password and token are clearly readable in all Talend user interfaces (Studio or Web), The password and token are potentially stored in clear. To avoid this behavior, you need to mark sensitive data as @Credential. Talend Component Kit provides you with the @Credential marker, that you can use on any @Option. This marker has two effects: It Replaces the default input widget by a password oriented widget It Requests the Studio or the Talend Cloud products to store the data as sensitive data (as encrypted values). In order to ensure that the password and token are never stored in clear or shown in the code, add the @Credential marker to the sensitive data. For example: Your password and token (or any other sensitive data that you need to mask) are not accessible by error anymore.

This tutorial shows how to adapt the test configuration of the Zendesk search component that was done in this previous tutorial to make it work in a Continuous Integration environment. In the test, the Zendesk credentials are used directly in the code to perform a first capture of the API response. Then, fake credentials are used in the simulation mode because the real API is not called anymore. However, in some cases, you can require to continue calling the real API on a CI server or on a specific environment. To do that, you can adapt the test to get the credentials depending on the execution mode (simulation/passthrough). These instructions concern the CI server or on any environment that requires real credentials. This tutorial uses: A Maven server that supports password encryption as a credential provider. Encryption is optional but recommended. The MavenDecrypterRule test rule provided by the framework. This rule lets you get credentials from Maven settings using a server ID. To create encrypted server credentials for the Zendesk instance: Create a master password using the command: mvn --encrypt-master-password . Store this master password in the settings-security.xml file of the ~/.m2 folder. Encrypt the Zendesk instance password using the command: mvn --encrypt-password . Create a server entry under servers in Maven settings.xml file located in the ~/.m2 folder. You can store the settings-security.xml and settings.xml files elsewhere that the default location (~/.m2). To do that, set the path of the directory containing the files in the talend.maven.decrypter.m2.location environment variable. Add the MavenDecrypterRule rule to the test class. This rule allows to inject server information stored in Maven settings.xml file to the test. The rule also decrypts credentials if they are encrypted. Inject the Zendesk server to the test. To do that, add a new field to the class with the @DecryptedServer annotation, that holds the server ID to be injected. The MavenDecrypterRule is able to inject the server instance into this class at runtime. The server instance contains the username and the decrypted password. Use the server instance in the test to get the real credentials in a secured manner. Once modified, the complete test class looks as follows: This test will continue to work in simulation mode, because the API simulation proxy is activated. This tutorial shows how to set up a CI server in passthrough mode using Jenkins. Log in to Jenkins. Click New Item to create a new build job. Enter an Item name (Job name) and choose the freestyle job. Then click OK. In the Source Code Management section, enter your project repository URL. A GitHub repository is used in this tutorial. Specify the master branch as Branches to build. In the Build section, click Add build step and choose Invoke top-level Maven targets. Choose your Maven version and enter the Maven build command. In this case: clean install. Then, click Save. The -Dtalend.junit.http.passthrough=true option is part of the build command. This option tells the API simulation proxy to run in passthrough mode. This way, all the HTTP requests made in the test are forwarded to the real API server. The MavenDecrypterRule rule allows to get the real credentials. You can configure the passthrough mode globally on your CI server by setting the talend.junit.http.passthrough environment variable to true. Test the job by selecting Build now, and check that the job has built correctly. Now your tests run in a simulation mode on your development environment and in a passthrough mode on your CI server.

Talend Component Kit provides a migration mechanism between two versions of a component to let you ensure backward compatibility. For example, a new version of a component may have some new options that need to be remapped, set with a default value in the older versions, or disabled. This tutorial shows how to create a migration handler for a component that needs to be upgraded from a version 1 to a version 2. The upgrade to the newer version includes adding new options to the component. This tutorial assumes that you know the basics about component development and are familiar with component project generation and implementation. To follow this tutorial, you need: Java 8 A Talend component development environment using Talend Component Kit. Refer to this document. Have generated a project containing a simple processor component using the Talend Component Kit Starter. First, create a simple processor component configured as follows: Create a simple configuration class that represents a basic authentication and that can be used in any component requiring this kind of authentication. Create a simple output component that uses the configuration defined earlier. The component configuration is injected into the component constructor. The version of the configuration class corresponds to the component version. By configuring these two classes, the first version of the component is ready to use a simple authentication mechanism. Now, assuming that the component needs to support a new authentication mode following a new requirement, the next steps are: Creating a version 2 of the component that supports the new authentication mode. Handling migration from the first version to the new version. The second version of the component needs to support a new authentication method and let the user choose the authentication mode he wants to use using a dropdown list. Add an Oauth2 authentication mode to the component in addition to the basic mode. For example: The options of the new authentication mode are now defined. Wrap the configuration created above in a global configuration with the basic authentication mode and add an enumeration to let the user choose the mode to use. For example, create an AuthenticationConfiguration class as follows: Using the @ActiveIf annotation allows to activate the authentication type according to the selected authentication mode. Edit the component to use the new configuration that supports an additional authentication mode. Also upgrade the component version from 1 to 2 as its configuration has changed. The component now supports two authentication modes in its version 2. Once the new version is ready, you can implement the migration handler that will take care of adapting the old configuration to the new one. What can happen if an old configuration is passed to the new component version? It simply fails, as the version 2 does not recognize the old version anymore. For that reason, a migration handler that adapts the old configuration to the new one is required. It can be achieved by defining a migration handler class in the @Version annotation of the component class. An old configuration may already be persisted by an application that integrates the version 1 of the component (Studio or web application). Add a migration handler class to the component version. Create the migration handler class MyOutputMigrationHandler. the incoming version, which is the version of the configuration that we are migrating from a map (key, value) of the configuration, where the key is the configuration path and the value is the value of the configuration. You need to be familiar with the component configuration path construction to better understand this part. Refer to Defining component layout and configuration. As a reminder, the following changes were made since the version 1 of the component: The configuration BasicAuth from the version 1 is not the root configuration anymore, as it is under AuthenticationConfiguration. AuthenticationConfiguration is the new root configuration. The component supports a new authentication mode (Oauth2) which is the default mode in the version 2 of the component. To migrate the old component version to the new version and to keep backward compatibility, you need to: Remap the old configuration to the new one. Give the adequate default values to some options. In the case of this scenario, it means making all configurations based on the version 1 of the component have the authenticationMode set to basic by default and remapping the old basic authentication configuration to the new one. if a configuration has been renamed between 2 component versions, you can get the old configuration option from the configuration map by using its old path and set its value using its new path. You can now upgrade your component without losing backward compatibility.

This tutorial walks you through the most common iteration steps to create a component with Talend Component Kit and to deploy it to Talend Open Studio. The component created in this tutorial is a simple processor that reads data coming from the previous component in a job or pipeline and displays it in the console logs of the application, along with an additional information entered by the final user. The component designed in this tutorial is a processor and does not require nor show any datastore and dataset configuration. Datasets and datastores are required only for input and output components. To get your development environment ready and be able to follow this tutorial: Download and install a Java JDK 1.8 or greater. Download and install Talend Open Studio. For example, from Sourceforge. Download and install IntelliJ. Download the Talend Component Kit plugin for IntelliJ. The detailed installation steps for the plugin are available in this document. The first step in this tutorial is to generate a component skeleton using the Starter embedded in the Talend Component Kit plugin for IntelliJ. Start IntelliJ and create a new project. In the available options, you should see Talend Component. Make sure that a Project SDK is selected. Then, select Talend Component and click Next. The Talend Component Kit Starter opens. Enter the component and project metadata. Change the default values, for example as presented in the screenshot below: The Component Family and the Category will be used later in Talend Open Studio to find the new component. Project metadata is mostly used to identify the project structure. A common practice is to replace 'company' in the default value by a value of your own, like your domain name. Once the metadata is filled, select Add a component. A new screen is displayed in the Talend Component Kit Starter that lets you define the generic configuration of the component. By default, new components are processors. Enter a valid Java name for the component. For example, Logger. Select Configuration Model and add a string type field named level. This input field will be used in the component configuration for final users to enter additional information to display in the logs. In the Input(s) / Output(s) section, click the default MAIN input branch to access its detail, and make sure that the record model is set to Generic. Leave the Name of the branch with its default MAIN value. Repeat the same step for the default MAIN output branch. Because the component is a processor, it has an output branch by default. A processor without any output branch is considered an output component. You can create output components when the Activate IO option is selected. Click Next and check the name and location of the project, then click Finish to generate the project in the IDE. At this point, your component is technically already ready to be compiled and deployed to Talend Open Studio. But first, take a look at the generated project: Two classes based on the name and type of component defined in the Talend Component Kit Starter have been generated: LoggerProcessor is where the component logic is defined LoggerProcessorConfiguration is where the component layout and configurable fields are defined, including the level string field that was defined earlier in the configuration model of the component. The package-info.java file contains the component metadata defined in the Talend Component Kit Starter, such as family and category. You can notice as well that the elements in the tree structure are named after the project metadata defined in the Talend Component Kit Starter. These files are the starting point if you later need to edit the configuration, logic, and metadata of the component. There is more that you can do and configure with the Talend Component Kit Starter. This tutorial covers only the basics. You can find more information in this document. Without modifying the component code generated from the Starter, you can compile the project and deploy the component to a local instance of Talend Open Studio. The logic of the component is not yet implemented at that stage. Only the configurable part specified in the Starter will be visible. This step is useful to confirm that the basic configuration of the component renders correctly. Before starting to run any command, make sure that Talend Open Studio is not running. From the component project in IntelliJ, open a Terminal and make sure that the selected directory is the root of the project. All commands shown in this tutorial are performed from this location. Compile the project by running the following command: mvnw clean install. The mvnw command refers to the Maven wrapper that is embedded in Talend Component Kit. It allows to use the right version of Maven for your project without having to install it manually beforehand. An equivalent wrapper is available for Gradle. Once the command is executed and you see BUILD SUCCESS in the terminal, deploy the component to your local instance of Talend Open Studio using the following command: mvnw talend-component:deploy-in-studio -Dtalend.component.studioHome="". Replace the path with your own value. If the path contains spaces (for example, Program Files), enclose it with double quotes. Make sure the build is successful. Open Talend Open Studio and create a new Job: Find the new component by looking for the family and category specified in the Talend Component Kit Starter. You can add it to your job and open its settings. Notice that the level field specified in the configuration model of the component in the Talend Component Kit Starter is present. At this point, the new component is available in Talend Open Studio, and its configurable part is already set. But the component logic is still to be defined. You can now edit the component to implement its logic: reading the data coming through the input branch to display that data in the execution logs of the job. The value of the level field that final users can fill also needs to be changed to uppercase and displayed in the logs. Save the job created earlier and close Talend Open Studio. Go back to the component development project in IntelliJ and open the LoggerProcessor class. This is the class where the component logic can be defined. Look for the @ElementListener method. It is already present and references the default input branch that was defined in the Talend Component Kit Starter, but it is not complete yet. To be able to log the data in input to the console, add the following lines: The @ElementListener method now looks as follows: Open a Terminal again to compile the project and deploy the component again. To do that, run successively the two following commands: mvnw clean install `mvnw talend-component:deploy-in-studio -Dtalend.component.studioHome="" The update of the component logic should now be deployed. After restarting Talend Open Studio, you will be ready to build a job and use the component for the first time. To learn the different possibilities and methods available to develop more complex logics, refer to this document. If you want to avoid having to close and re-open Talend Open Studio every time you need to make an edit, you can enable the developer mode, as explained in this document. As the component is now ready to be used, it is time to create a job and check that it behaves as intended. Open Talend Open Studio again and go to the job created earlier. The new component is still there. Add a tRowGenerator component and connect it to the logger. Double-click the tRowGenerator to specify the data to generate: Add a first column named firstName and select the TalendDataGenerator.getFirstName() function. Add a second column named 'lastName' and select the TalendDataGenerator.getLastName() function. Set the Number of Rows for RowGenerator to 10. Validate the tRowGenerator configuration. Open the tutorialFamilyLogger component and set the level field to info. Go to the Run tab of the job and run the job. The job is executed. You can observe in the console that each of the 10 generated rows is logged, and that the info value entered in the logger is also displayed with each record, in uppercase.

This document explains how Asciidoctor is used in the context of Talend Component Kit as well as the specific processes in place. For general guidelines about Asciidoctor, refer to the Asciidoc Syntax quick reference page. There are two ways to suggest modifications or new content. Both of the options below require you to have a GitHub account created. On every page of the Talend Component Kit Developer Guide, a Suggest and edit button is available. It allows you to access the corresponding source file on GitHub and to create a pull request with the suggested edits. The pull request is then assessed by the team in charge of the project. Fork the Runtime repository of the Talend Component Kit project and edit .adoc files located under documentation\src\main\antora\modules\ROOT\pages. Make sure to follow the guidelines outlined in the current document, especially for large modifications or new content, to make sure it can properly be rendered. When done, create a pull request that will be assessed by the team in charge of the project. The documentation is made of: Documentation files manually written under documentation\src\main\antora\modules\ROOT\pages. Documentation files automatically generated from the source code under documentation\src\main\antora\modules\ROOT\pages\_partials. These files are individually called in manually written files through includes. Assets, especially images, stored in the documentation\src\main\antora\modules\ROOT\assets folder. Some subfolders exist to categorize the assets. Each file has a unique name and is rendered as a unique HTML page. Some of the files are prefixed to help identifying the type of content it contains. Most common examples are: index- for pages referenced from the main index page. These pages also contain specific attributes to be correctly rendered on the main index page (see 'List of metadata attributes' below). tutorial- for tutorials/guided examples. generated_ for pages generated from the source code. These pages are generally stored in the _partials folder. For all pages: :page-partial indicates that the current .adoc file can be included in another document using an include::. This attribute has no value. :page-talend_skipindexation: indicates that the current .adoc file must not be indexed. This attribute has no value. Add it to files that should not be returned in the search, like index files that only contain includes. :description: is the meta description of the file. Each .adoc file is rendered as an HTML file. :keywords: is the list of meta keywords relevant for the current .adoc file. Separate keywords using simple commas. :page-talend_stage: draft indicates that the current document is a draft and is not final even if published. It triggers the display of a small banner indicating the status of the page. Remove this attribute once the page is final. For pages that should appear as a tile on the index page: :page-documentationindex-index: is the weight of the page. A low weight indicates that the page should be one of the first tiles to appear. A high weight will push the tile towards the end of the list in the index page. :page-documentationindex-label: is the title of the tile in the index page. :page-documentationindex-icon: is the icon of the tile in the index page. The value of this attribute should be the name of a free icon on fontawesome. :page-documentationindex-description: is a short description of the page that will be displayed in the tile under its title. For pages containing API descriptions: :page-talend_swaggerui: true indicates that the page contains some API reference that should be displayed using Swagger UI The Talend Component Kit documentation is published as HTML and PDF. Some parts can differ between these two versions, such as lists of links, that are not functional in the PDF version. To avoid this, it is possible to define some conditionality to have some content only displaying in one of the output formats only. For example: Every .adoc file can only contain one 'level 1' title (=). It is the title of the page and is located at the top of the document. It is a best practices that all sublevels added to the document are kept consistent. For example, don’t use a 'level 3' (===) section directly inside a 'level 1'. When possible, avoid going lower than section 2 (===) to keep the page readable. In the HTML output, the document title is renderedh1, section 1 titles as h2, etc. The "in-page" navigation available on the right side of the HTML rendering only considers h2 and h3 elements. Other levels are ignored to keep the navigation readable and simple. It is possible to reuse content through "includes". Includes can be used to reuse entire files in other files, allowing to avoid copy pasting. When using an 'include' (calling an .adoc file from another .adoc file), you can specify a level offset to keep the hierarchy consistent in the current document. Avoid using includes if not absolutely necessary. An include can be done as follows: In this case, both doc1.adoc and doc2.adoc are rendered in the same page and their content is offset by one level, meaning that the document title of doc1 becomes a section 1 title (h2) instead of an h1 in the final rendering, and so on. Note that both doc1.adoc and doc2.adoc will in addition be rendered as standalone pages (doc1.html and doc2.html). All images are stored under documentation > src > main > antora > modules > ROOT > assets > images. Relatively to .adoc files, it can be ../assets/images/ or ../../assets/images for _partials (automatically generated from code) pages. To avoid handling different relative paths, the backend already resolves directly image: to the image folder. Hence, paths to images should start with the following: image:(/).png[(,parameters)] If there is no subfolder, type the image name right away. Adding an image title is mandatory to avoid empty broken spaces in the content. If necessary, you can add more parameters separated by a comma between the same brackets as the image title, such as the desired width, height, etc. Use values in % for image size. For example; image:landscape.png[Landscape,70%,window="_blank",link="https://talend.github.io/component-runtime/main/1.50.4/_images/landscape.png"] In a general manner, avoid using tables if there are other solutions available. This is especially the case for complex tables that include assets or big code samples, as these can lead to display issues. Table example: value API Type Description @o.t.s.c.api.service.completion.DynamicValues dynamic_values Mark a method as being useful to fill potential values of a string option for a property denoted by its value. @o.t.s.c.api.service.healthcheck.HealthCheck healthcheck This class marks an action doing a connection test The following elements can be used to create admonition blocks. However, avoid using them one after another as it can make reading more difficult: NOTE: for a simple information note IMPORTANT: for a warning. Warnings should include information that lead to important errors if not taken into account TIP: for alternative ways or shortcuts to ease a process or procedure Admonition blocks should be kept as simple and short as possible. In some niche cases, it may be required to insert more complex content in an admonition block, such as a bullet list. In these cases, they should be formatted as follows:

Once the plugin installed, you can generate a component project. Select File > New > Project. In the New Project wizard, choose Talend Component and click Next. The plugin loads the component starter and lets you design your components. For more information about the Talend Component Kit starter, check this tutorial. Once your project is configured, select Next, then click Finish. The project is automatically imported into the IDEA using the build tool that you have chosen.