Blogs
Finished the step of Part 3: Liferay Components for Talend Open Studio
We have reached the last blog in this series and the culmination of all our efforts: where we get to run our “Job” which will perform the product loading in to Liferay Commerce in a matter of seconds.
In order to achieve our grand finale we only have to learn how to create routines, which is nothing more than a Java class with methods that will help us in the data processing and mapping between the input fields and the output fields.
1. Continuing where we left off in the previous Blog, we start by creating a routine which will be able to transform the data that we send to the Liferay component according to the OpenAPI specification.
- In Repository, go to “Code” > “Routines” and right click and choose the option “Create Routine” (for more information about how to create a “User Routine”, check this documentation)
- Give a name to the routine. In my case, I chose “TransformToLiferay”. It will create a .java file. You can download my routine from my GitHub repository.
- In the Java file, we will have already 5 methods created for us. We can call these methods from the “tMap” component to transform the data and pass then to the “tLiferayOutput” component.

Secondly (where we do need to use it) every time when the API that you call’s input parameter is a “reference type” variable, you will need to go through a transformation. Talend already includes many serial routines. For more information about the available "system" routines, check the Talend documentation. Important: In the Liferay API, many fields that appears to be plain text, are in fact not. Actually, they are multi-language fields, like many other fields in Liferay Portal. To treat those, you have the method “ setLocalizedField” available in the routine.
2. Before going back to product mapping, it is important to highlight again that all Liferay Headless Commerce APIs are documented in Swagger Hub, where you can check which fields are included and which are mandatory for every API and method:
- All Lifery Commerce APIs begin with the “headless-” prefix. So, in Swaggerhub, the URL will be like the following: “https://app.swaggerhub.com/apis/liferayinc/commerce-admin-catalog/v1.0”
- To build the endpoint, remove from the URL “https://app.swaggerhub.com/apis/liferayinc/” and change the URL until “v1.0”. It will end up like: commerce-admin-catalog/v1.0. Then, include in the beginning “headless-” and we include the Commerce API: “/headless-commerce-admin-catalog/v1.0”.
3. Now that you know where to find all the information and documentation, we will begin mapping the fields, using the routine contexts and methods. Double-click on “tMap”.
- In the “tLiferayRow” column, fill-in the 3 mandatory fields (those we don’t have in the database), with the “contexts” created before:
We will start with the “description” field. In the “tLiferayRow” column, go to the “description” field and click on the “Expression” column on the left, as indicated in the image below:
- Now in “Categories” click on “User defined” > double-click on “setLocalizedField” and pass to the method the required parameters, the “context.LANGUAGE_PT_BR” context and the variable “row1.description”, retrieved from the database. It should look like the image below:
- Repeat the same process for “name” and “shortDescription” fields.
- The process is the same for the “image” field, only we will use a different method. In this case, we choose the “setImage” method. Check the image below:
The last field we will map will be the “skus” and we will use the “setSKU” method. It should look like the image below:
By the way, what’s a SKU (Stock Keeping Unit)?
They are alphanumeric codes used to identify a product and its variations..
The SKU is extremely important for digital commerce and is nothing more than the necessary identifier for a given product and thus have better control of your stock, leaving the products separated according to their characteristics.
SKUs should not be confused with UPCs (Universal Product Code). SKUs are created by individual suppliers and can form any alphanumeric convention. Often suppliers try and follow a pattern that may be somewhat related to the product. But the same product could be referred to by different suppliers or wholesalers by their own individual SKU codes. A UPC is the numeric representation of a product barcode (EAN). These codes are registered for particular products and will be the same regardless of the supplier or wholesaler.
For example, a white shirt that has four different sizes (S, M, L, XL). We can make distinctions between them using SKUs. For example: White Shirt S will have SKU: CB1, White Shirt XL will have SKU: CB4.
Lastly, we will map a very important field: “externalReferenceCode”. This field must always be mapped with a unique code that is the reference between the product within Liferay Commerce and the product in the External System. Although it is not a mandatory field, it is important to utilise it to prevent the generation of duplicates when syncing with external systems as this the primary identifier used by the external system.
4. Now that mappings are finished, the “tMap” will look like:
Click on “Apply” and “Ok”.
5. Before running the Job, we will change the connection settings in “Advanced Settings” in “tLiferayOutput” component:
6. Finally, we go to the “Run” tab and we run the Job.
The outcome should look like the image below, with 1 row per product:
Now you can access Liferay Commerce and check that the products are correctly loaded. In the image below you can see the 10 products we’ve successfully loaded:
Clicking on the first product we can see the information in detail that we’ve just imported:
Checking the SKUs, we can check that everything went well:
…. Commercial information ...
… price and promotional price ….
You can see product on the Website you assigned to the “Channel”, like in the image below:
If you want to try to do the whole product load (without the limit), change the query to “"SELECT * FROM products” (without the limit), click on “Guess schema”, save and run again the job. You will see 64 products registered:
Final closing conclusion
We have seen how to register a Product Catalog in Liferay Commerce with only 3 components and 5 methods.
As we saw in the first blog post of this series, we used a database as the data source, but you might use any data source and external system. Having an integration like the one we have seen for the product catalog makes a task that could be arduous (keeping the update between two systems) easy, fast and practical.
That ETL we created can be exported and be attached to a cron job in your server or if you use Liferay DXP, you can include it in “Data Integration Admin”, so you can manage Jobs inside the Control Panel:
PS: Thanks to Bernard Mc Closkey (Commerce Solution Architect for EMEA) for helping me on the translation of this Blog post.