Skip to main content
Skip table of contents

Supported tool types

Data Management supports four tool types:

All tools extend net.redpoint.dataflow.transform.Tool, and implement the interface appropriate to their tool type.

Input tool

Input tools implement the net.redpoint.dataflow.transform.InputTool interface. Input tools are record producers. Typically, they read records from an external source (files, databases, queues, or APIs) and send them to a single output connector. Input tools can also generate records algorithmically and independent of any external source; for example, they can generate random numbers, primary keys, or mock data for testing.

The InputTool interface is reactive, meaning that its nextRecord() method will be called by RPDM whenever the next record is wanted.

Output tool

Output tools implement the net.redpoint.dataflow.transform.OutputTool interface. Output tools are record consumers. They generally read records from a single connector and write records to a sink such as a file, database, queue, or web service. Output tools can also consume records without emitting them to a sink.

The OutputTool interface is reactive, meaning that its nextRecord() method will be called by RPDM whenever the next record is available for output.

Transform tool

Transform tools implement the net.redpoint.dataflow.transform.TransformTool interface. They accept an input record, transform that record (or more accurately, a copy of that record) in some way, and emit an output record.

The TransformTool interface is reactive, meaning that its nextRecord() method will be called by RPDM with an input and output record, whenever the next input record is available.

General tool

General tools implement the net.redpoint.dataflow.transform.GeneralTool interface. They follow a more procedural model, running in their own thread, reading records from any number of inputs, and writing records to any number of outputs.

Implementing a general tool tends to be more complicated; they should only be used when the desired functionality can't be easily achieved by an input, output, or transform tool.

The GeneralTool interface is proactive or procedural, meaning that its run() method will completely process all input and output records before returning. The run() method is also "in charge" as opposed to responding to RPDM's callbacks.

Because of the GeneralTool's procedural model, there are cases where it is easier to implement GeneralTool than the other tool types. For example, if you are using a SAX-based XML parser or other library that expects your code to be reactive, you may find it difficult to marry the reactive requirements of RPDM and the library.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.