Skip to main content

Pentaho+ documentation has moved!

The new product documentation portal is here. Check it out now at docs.hitachivantara.com

 

Hitachi Vantara Lumada and Pentaho Documentation

Extend Pentaho Data Integration

Parent article

To extend the standard PDI functionality, you may want to develop custom plugins. The instructions in this section address common extending scenarios, with each scenario having its own sample project. These folders of the sample code package contain sample projects. See the Get started with the sample PDI project section of this guide to learn how to access the sample code.

  • kettle-sdk-step-plugin
  • kettle-sdk-jobentry-plugin
  • kettle-sdk-database-plugin
  • kettle-sdk-partitioner-plugin

Create different types of plugins

Depending on what you want your plugin to do you may want to create one of any of the following types of plugins:

Create icons for step or entry plugins

Depending on your plugin, you may need to create an icon to represent it's purpose. Learn more about how to create an icon that aligns with the design guidelines within PDI.

Debug plugins

A good way to debug PDI plugins is to deploy the plugin, launch the PDI client, and connect the debugger to the PDI client JVM. This section explains how to debug a plugin in Eclipse.

Procedure

  1. Prepare the PDI client for debugging by starting the PDI client JVM, which allows debug sessions and these types of arguments to be passed into the PDI client JVM.

    -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044

    The address argument can be any free port on your machine. This example uses port 1044.

    If you are using Spoon.bat or spoon.sh to launch the PDI client, create a copy of the file and edit it to include the debugging parameters to the Java options near the bottom of the file. If you are using a Mac app, add the JVM parameters to VMOptions key of “Data Integration 64-bit.app/Contents/Info.plist” or “Data Integration 32-bit.app/Contents/Info.plist” respectively.

    When you start PDI client, debuggers connect on port 1044.
  2. Launch a debug session.

    1. Ensure that the PDI client is set up for debugging and running with the plugin deployed.

    2. Connect the Eclipse debugger by creating a debug configuration for your plugin project. From the Run/Debug Configurations menu, create a new configuration for Remote Java Application.

    3. Select your project, making sure the port matches the port configured in Step 1.

    4. Decide whether you want to be able to kill the PDI client JVM from the debugger, then click Apply and Debug.

Results

The debugger opens, stops at the breakpoints you set, and in-line editing of the plugin source is enabled.Eclipse debug dialog box

Localize plugins

Message bundles

PDI uses property files for internationalization. Property files reside in the messages sub-package in the plugin JAR file. Each property file is specific to a locale. Property files contain translations for message keys that are used in the source code. A messages sub-package containing locale-specific translations is called a message bundle.

Consider the package layout of the sample job entry plugin project. It contains its main Java class in the org.pentaho.di.sdk.samples.jobentries.demo package, and there is a message bundle containing the localized strings for the en_US locale.

Message bundle

Additional property files can be added using the naming pattern messages_<locale>.properties. PDI core steps and job entries usually come with several localizations. See the shell job entry messages package for an example of more complete i18n: https://github.com/pentaho/pentaho-k...shell/messages.

Resolving localized strings

The key to resolving localized strings is to use the getString() methods of org.pentaho.di.i18n.BaseMessages. PDI follows conventions when using this class, which enables easy integration with the PDI translator tool.

All PDI plugin classes that use localization declare a private static Class<?> PKG field, and assign a class that lives one package-level above the message bundle package. This is often the main class of the plugin.

With the PKG field defined, the plugin then resolves its localized strings with a call to BaseMessages.getString(PKG, “localization key”, ... optional_parameters). The first argument helps PDI find the correct message bundle, the second argument is the key to localize, and the optional parameters are injected into the localized string following the Java Message Format conventions.

Common localization strings

Some strings are commonly used, and have been pulled together into a common message bundle in org.pentaho.di.i18n.messages. Whenever BaseMessages cannot find the key in the specified message bundle, PDI looks for the key in the common message bundle.

Example

For an example, check the sample Job Entry plugin project, which uses this technique for localized string resolution in its dialog class.