Implementing a Function Component (FC) follows very much the pattern of developing a Connector. A Function Component is actually easier to implement because of fewer dependencies on the AssemblyLine workflow.
Similar to the Connector foundation classes, we have "com.ibm.di.fc.FunctionInterface"
and the "com.ibm.di.fc.Function" abstract class that implements
the interface (the Java™ sources of both classes are
included in the "fc" folder of this package).
We will usually implement your FCs by subclassing the "com.ibm.di.fc.Function"
class. These are the most important methods we will usually need
to implement:
When the FC is created and used programmatically
the "initialize(...)" method must be called right after
constructing the FC object and setting its parameters, and before
calling its "perform(...)" method.
The general contract for the "perform(...)"
method is that it receives some data on input and based on that input
it produces some output data. There are no other assumptions. As you
will see below it is not even necessary that your FC works with Entry
objects.
When the FC is placed into an AssemblyLine, the AssemblyLine
calls its "perform(...)" method on each iteration. In
the AssemblyLine context the "perform(...)" method will
be given an Entry object as input parameter (this is the Entry object
constructed by the Output Attribute Mapping process - also
called the conn Entry). And it is supposed
to return an Entry object as well; the AssemblyLine will feed the
returned Entry object to the Input Attribute Mapping process, the
result of which is applied to the AssemblyLine's work Entry -
in other words, the returned Entry is the conn Entry
in the Input Map. If we want to enable your FC to be placed into
an AssemblyLine, we need to support this "Entry on input -
Entry on output" behavior.
You might also code the "perform(...)"
method so that it receives non-Entry objects on input and returns
non-Entry objects on output. This could facilitate the process of
programmatically creating and calling an FC. No Attribute Mapping
will be done if we use this method.
When using an FC programmatically, you
must call the "terminate(...)" method after we have
finished using that FC instance.
When building the source code of the Function Component, include
in your CLASSPATH the jar files from the "jars" folder of the IBM TDI installation.
As a minimum, you would need to include "miserver.jar"
and "miconfig.jar".
When integrating your Java code with IBM TDI, pay attention
to the collection of pre-existing components that comprise IBM TDI, notably in the jars directory. If your code relies upon one
of our own library components that overlap or clash with one or more
that are part of the TDI installation there will most
likely be loader problems during execution.
The FC GUI is implemented in the same way as for a Connector.
Use a "tdi.xml" file to describe the FC configuration form by using
the same syntax as used for Connectors.
Packaging and deploying an FC is just like packaging and deploying
a Connector:
We need a jar file that contains:
After creating the jar file of the new Function Component, you only need to drop that jar file in the "jars/functions"
folder in the IBM TDI installation. The next time the IBM TDI is started
it will automatically load the new Function Component and it will
be ready for use.
Building the Function Component source code
Implementing the Function Component GUI configuration form
Packaging and deploying the Function Component