Developing an ODI Open Tool is quite simple. Some Java skills and understanding are required, but it is totally not needed to be an expert. The guide is pretty good, it explains how to build OpenTools and how to put them for Oracle Data Integrator to use. The tutorial can be found in the ODI documentation.

The one thing I was missing in the documentation is the jars (probably, I was just too lazy to look further…), which I had to add to my classpath in order  to be able to develop my code in my IDE of choice. The Jar is odi-core.jar, in the 11G version is located at <install directory>/oracledi.sdk/lib/, after adding it to your project classpath you will be able to use Open Tool classes.
Update: The jars which should be included in the classpath are all the jars, that are located at <install directory>/oracledi.sdk/lib/ . Otherwise, the following exception is thrown when trying to use the OpenToolExecutionException in the Execute() method as described in the documentation:

No exception of type OpenToolExecutionException can be thrown; an exception type must be a subclass of Throwable


The process of developing such a tool is straightforward (OK. I am not going copy/paste from the official documentation, so I will just give you the links):

1. Develop the class as described here:
Developing Open Tools

2. Put your jar in the classpath as described here:
Add Additional Drivers and Open Tools

3. Add the tool into ODI following these steps:
Installing and Declaring an Open Tool

So far, so good. Although, as you continue to develop, you will encounter a few questions and maybe even some pitfalls, which are better addressed from the beginning. Some are pointed out int the documentation and some are not.

  1. Do I really need an Open Tool for this task? This is the first question to ask before starting coding. Open Tools are usually things to reuse in multiple packages and multiple projects, which serve a very specific task. If it is not your case, you are better off with a KM or procedure.
  2. The best way to start is by extending the OpenToolAbstract class. If you are extending your own class and since, extending more than more class is not allowed in Java, than make sure you have implemented the IOpenTool interface.
  3. Open tool is not supposed to be a complicated Java class. Overwhelming it with a large amount of parameters and methods is a bad thing.  A much smarter thing to do, is break large difficult tasks, into small and specific multiple mini tasks, then create an Open Tool for each one.
  4. Modifications and updates, if you have deployed many scenarios using your Open Tool and you have created a new version of it, than updating the Jar in the classpath, will result in all the scenarios, packages or anything else using your tool advancing instantly to the new version. This means, that any update should be deployed with much care and backwards compatibility. This is the main reason for me, not to make my Open Tools too complicated.
  5. This is Java. you get, what you have written. Performance, cleanup and bugs are your responsibility.
  6. The parameters must be validated within the Open Tool code. The “Mandotory” Boolean parameter passed when initiating the OpenToolParameter class are just for displaying in the UI and ODI will not validate these parameters are set correctly or set at all, even if the parameter is initiated with this variable set to true.
  7. getSyntax() method is very simple, but has a lot of influence. The name of the tool and the parameter’s initial values will be determined by this method.
  8. Create nice icons for your tools.
Those things are better taken into account before starting writing the code. It is a very simple process and I suggest starting by writing something, that does not require much coding. KISS.