Jan 13, 2014

ETL Application Comparison, Part 3


The next application we are evaluating in this series is Linx 5. This article represents my experiences with the current beta-version of Linx 5 (hereafter referred to as just “Linx”) while using it for the first time to implement the data loading problem as defined in the first post of this series. Linx distinguishes itself from the application of the previous post, PDI, in the sense that Linx programs are procedural in their structure as opposed to workflow-based. This aspect can make the application immediately very intuitive to use for anyone having some prior programming experience.


Instead of featuring a large array of different components to use like PDI, Linx offers a fairly minimal set of components. The number of components is smaller, but the components that are available tend to be more versatile. The ExecuteSQL component, for instance, can be used to read data from a database, or for lookups, or for updating or inserting into a database. This means that there is a smaller number of components one needs to know of in order to get the task done.

Many properties of the components support expressions, and all expressions are written in the same language, namely C#. This consistency makes things easier for Linx users, as there is no need for using different languages in a Linx program. In PDI, on the other hand, a complex transformation with many steps often uses different types of expressions. Furthermore, most fields do not support expressions, forcing one to introduce additional steps for fetching variables or making calculations. The simplicity and consistency in Linx contributes to a more positive user experience when building a Linx program.

Opposed to PDI, Linx currently lacks a component for writing a block of C# code. This did not cause any trouble with the implementation of our simple data loading scenario, but such a component would come in handy when there is a need to do some involved task that is not directly supported by any of the existing components.

Implementing the data loading problem seemed fairly natural and I was satisfied with the result. Here is a screenshot of the program that I’ve built. As I went along, I have given the components concise, but descriptive names in order to keep the program readable.

 

As you can see, the program turned out nice and simple.

Linx offers a very simple and clean way to schedule and monitor processes. A Windows Service that runs in the background periodically checks the schedules and automatically runs the processes when they are due. With the help of services, a process can be scheduled to run on a periodical basis, or whenever changes in a folder are detected.

In this exercise, building the data loading process using Linx has produced a program with a very concise representation. The task of scheduling the process to run on a periodical basis is a quick and easy process. Even though it did not hamper us in this example, one shortcoming of Linx that presented itself was the lack of a component to enable the user to do more advanced things that cannot be done using the existing components. Maybe Linx 5 will soon add a component to address that issue.

No comments:

Post a Comment