Learn Pentaho - Custom Plugins & Extensibility

#Introduction

Even though PDI has hundreds of built-in steps, sometimes you need logic that isn't available. Episode 16 opens the way out: extensibility. You'll learn three levels of extension — from the simplest (JavaScript in a step) to the deepest (Java plugins and custom steps).

The goal isn't to make you a plugin developer right away, but to understand the capability map: when it's enough to use a built-in step, when to write JavaScript, and when you truly need a Java or community plugin.

#Custom Logic with Scripting Steps

The fastest way to add custom logic is the scripting steps available in PDI:

• Modified Java Script Value: executes JavaScript per row to calculate or change field values. Supported by Mozilla Rhino (for legacy JavaScript) or GraalJS.
• User Defined Java Expression: evaluates simple Java expressions per row without writing a full function.
• Execute SQL Script: runs SQL scripts — useful for logic better handled by the database.

Example: calculating a discount category based on amount with JavaScript:

Example per-row JavaScript logic

var jumlah = row.jumlah;
var kategori = jumlah >= 1000000 ? "VIP" : jumlah >= 100000 ? "REGULER" : "BASIC";
row.kategori = kategori;

Note that the code above uses the common PDI per-row scripting style: reading fields from the row variable, then setting new fields. Variables like row are context provided by the step.

#Getting to Know the Variable Context in the JavaScript Step

The JavaScript step provides several helper objects rarely explained in menus: row to read the row's fields, getVariable() to read job/transformation variables, and the putRow() function to send a row out. For those just starting, simply get to know two things: reading fields via row.namafield, and setting new fields with row.fieldBaru = nilai — the rest will follow when the need arises. Official documentation and community examples use the same patterns, so getting used to these conventions makes it easier to read other people's examples.

#When to Choose JavaScript vs Java

A question that often comes up: when is JavaScript enough, and when do you need Java?

The golden rule: use the lightest solution that meets the need. JavaScript for prototypes and small business logic; Java only when performance or third-party libraries are truly required.

#Understanding Custom Steps and Job Entries

Behind the scenes, every PDI step is a Java plugin. A custom step is built with:

• StepMetaInterface: defines the step's metadata — configuration fields and the dialog.
• StepInterface / BaseStep: the execution logic that receives rows from the previous step and emits result rows.
• Plugin descriptor: an XML file or annotations that register the plugin with PDI.

When a plugin is placed in the plugins/ folder and PDI is restarted, the new step appears in the palette like a built-in step. Although building a plugin from scratch needs deep Java and PDI API knowledge, the payoff is big: steps very specific to your business can be reused across many transformations.

For those just starting, it's recommended to use the plugin SDK provided by the community, or to imitate existing open-source plugins as a template.

#Small Components Worth Trying

Before building a full plugin, there's a smaller component that's often enough: the User Defined Java Class (UDJC) step lets you write short Java directly inside a transformation without building a separate plugin — suitable for logic needing native performance but used in only one place. It's a great bridge to feel the PDI API before committing to building a full plugin.

#Community Plugins and the Marketplace

Before writing your own plugin, check what already exists. The Pentaho Marketplace provides plugins installable directly from PDI, for example:

• Connectors for specific cloud services and APIs.
• Specialized transformation steps like cryptography or niche data formats.
• Steps for interacting with other tools in the data ecosystem.

The Marketplace installation flow: open the menu Tools > Marketplace, search for the plugin, click install, then restart Spoon. Make sure the Java runtime supports the plugin with java -version before choosing a version. Many other plugins are also available in community repositories like GitHub — check version compatibility with your PDI.

#Packaging Reusable Transformations

You don't always need to write a plugin for reusability. A well-designed transformation can become a "component" called many times:

• Parameterization: make every changeable value a parameter, not hardcoded.
• Clear field contract: document the transformation's input and output fields.
• Single responsibility: small, focused transformations are easy to reuse; giant ones are hard.
• Brief documentation: explain purpose, input, and output in the Annotation step or a README file.

A transformation like normalisasi_nama.ktr that accepts any field via parameters and returns a clean version is an example of a component reusable anywhere. This pattern is far cheaper than a Java plugin and covers most needs.

#Conclusion

In episode 16 you understood PDI extensibility: writing custom logic with JavaScript and Java expressions, getting to know the structure of Java-based custom steps and job entries, leveraging community plugins and the marketplace, and packaging transformations into reusable components.

The key takeaways:

• JavaScript suits light logic; avoid it for large volumes.
• Custom Java steps are the deepest path, backed by StepMetaInterface and BaseStep.
• Check the marketplace and community before writing your own plugin.
• Parameterized transformations are the cheapest way to achieve reusability.

In episode 17, we open the big data horizon: big data integration — connecting Pentaho with Hadoop, Spark, and cloud data lakes, understanding the Parquet, Avro, and ORC formats, near real-time streaming ingestion patterns, and data lakehouse support.