Developing new components using the Component Kit framework includes: Creating a project using the starter or the Talend IntelliJ plugin. This step allows to build the skeleton of the project. It consists in: Defining the general configuration model for each component in your project. Generating and downloading the project archive from the starter. Compiling the project. Importing the compiled project in your IDE. This step is not required if you have generated the project using the IntelliJ plugin. Implementing the components, including: Registering the components by specifying their metadata: family, categories, version, icon, type and name. Defining the layout and configurable part of the components. Defining the execution logic of the components, also called runtime. Testing the components. Deploying the components to Talend Studio or Cloud applications. Optionally, you can use services. Services are predefined or user-defined configurations that can be reused in several components.

From the version 7.0 of Talend Studio, Talend Component Kit becomes the recommended framework to use to develop components. This framework is being introduced to ensure that newly developed components can be deployed and executed both in on-premise/local and cloud/big data environments. From that new approach comes the need to provide a complete yet unique and compatible way of developing components. With the Component Kit, custom components are entirely implemented in Java. To help you get started with a new custom component development project, a Starter is available. Using it, you will be able to generate the skeleton of your project. By importing this skeleton in a development tool, you can then implement the components layout and execution logic in Java. With the previous Javajet framework, metadata, widgets and configurable parts of a custom component were specified in XML. With the Component Kit, they are now defined in the Configuration (for example, LoggerProcessorConfiguration) Java class of your development project. Note that most of this configuration is transparent if you specified the Configuration Model of your components right before generating the project from the Starter. Any undocumented feature or option is considered not supported by the Component Kit framework. You can find examples of output in Studio or Cloud environments in the Gallery. Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit or Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Javajet Component Kit Return variables availability (1.51+) deprecates After Variables. Javajet AVAILABILITY can be : AFTER : set after component finished. FLOW : changed on row level. Component Kit Return variables can be nested as below: Javajet Component Kit or Previously, the execution of a custom component was described through several Javajet files: _begin.javajet, containing the code required to initialize the component. _main.javajet, containing the code required to process each line of the incoming data. _end.javajet, containing the code required to end the processing and go to the following step of the execution. With the Component Kit, the entire execution flow of a component is described through its main Java class (for example, LoggerProcessor) and through services for reusable parts. Each type of component has its own execution logic. The same basic logic is applied to all components of the same type, and is then extended to implement each component specificities. The project generated from the starter already contains the basic logic for each component. Talend Component Kit framework relies on several primitive components. All components can use @PostConstruct and @PreDestroy annotations to initialize or release some underlying resource at the beginning and the end of a processing. In distributed environments, class constructor are called on cluster manager nodes. Methods annotated with @PostConstruct and @PreDestroy are called on worker nodes. Thus, partition plan computation and pipeline tasks are performed on different nodes. All the methods managed by the framework must be public. Private methods are ignored. The framework is designed to be as declarative as possible but also to stay extensible by not using fixed interfaces or method signatures. This allows to incrementally add new features of the underlying implementations. To ensure that the Cloud-compatible approach of the Component Kit framework is respected, some changes were introduced on the implementation side, including: The File mode is no longer supported. You can still work with URIs and remote storage systems to use files. The file collection must be handled at the component implementation level. The input and output connections between two components can only be of the Flow or Reject types. Other types of connections are not supported. Every Output component must have a corresponding Input component and use a dataset. All datasets must use a datastore. To get started with the Component Kit framework, you can go through the following documents: Learn the basics about Talend Component Kit Create and deploy your first Component Kit component Learn about the Starter Start implementing components Integrate a component to Talend Studio Check some examples of components built with Talend Component Kit

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.