michaelsasa.blogg.se

1. #Pentaho data integration server community edition manual
2. #Pentaho data integration server community edition full

Get(Fields.Out, passwordField).setValue(outputRow, value) String value = p.decryptPassword(encPassword, key, salt) Throw new AssertionError("Error while accessing the file(s): " + e.getMessage(), e) Salt = new String(FileUtils.readFileToString(salt_file)) Key = new String(FileUtils.readFileToString(key_file)) String encPassword = get(Fields.In, encpasswordField).getString(r) String saltfile = get(Fields.In, saltfileField).getString(r) String keyfile = get(Fields.In, keyfileField).getString(r) Object outputRow = createOutputRow(r, ()) PasswordField = getParameter("PASSWORD_FIELD") SaltfileField = getParameter("SALT_FILE_FIELD") ĮncpasswordField = getParameter("ENC_PASSWORD_FIELD") KeyfileField = getParameter("KEY_FILE_FIELD") Public boolean processRow(StepMetaInterface smi, StepDataInterface sdi) throws KettleException So for example, if someone perhaps just happened to have a Java class that could decrypt a string encrypted with AES 128 bit encryption then you could use this step to said string inside of the transform before passing it to another step like so:Īnd the contents of that step: import .* Essentially, what this step allows for one to do is use external classes within a step.

#Pentaho data integration server community edition full

The feature uses Janino (link here) which does not implement the full Java 1.8 spec, but fortunately enough of it to accomplish most goals. You can use the User Defined Java Class step to enter your own Java class to drive the functionality of a complete step

#Pentaho data integration server community edition manual

User Defined Java ClassesĪs the Pentaho Data Integration manual states: So, since I absolutely love PDI but I need strong encryption, I figured out a way to leverage one of its most interesting features to effectively undo the handicap. And given the fact that you can pretty much connect to any data source in PDI, the way you handle those credentials inside of the transform where they get stored, how they are eventually passed to the step, etc is a big deal.

For PDI, at least one of these enterprise features is AES encryption, which presents a challenge for the ETL designer when you are forced to handled sensitive data like usernames and passwords.

The thing about “Community” edition tools and products is that their manufacturers generally need to divest them of the “enterprise” features usually found in their non-free variants, otherwise there won’t be any reason for Enterprises to invest in them.

Strong encryption? Well… that may be a problem… Do I need to read JSON from an endpoint? No problem, PDI has Rest Client and a JSON step.

And on projects where time, budget, complexity and resources are concerns, it often saves the day. custom), I find that my customers are more at ease about taking ownership of a work product that is say a custom ETL job in PDI rather custom application or script. Furthermore, since much of what I do is outside of our branded solutions (e.g. And honestly, whether good or bad, I’ve come to rely on PDI because in that regard, it can do just about anything. I’m often involved in projects where at a high level, the goal is produce “something” that takes data from a source, manipulates it, then stores it in a RDBMS for consumption by an unrelated process. Pentaho Data Integration (lovingly known as PDI) is arguably one of the best ETL tools available in a Community Edition variant.