InetSoft Product Information: Accessing Java Object Data Sources Using InetSoft's Business Intelligence Software

A Java Object Data Source is useful when your data cannot be accessed via common standards JDBC, SOAP, XML or if you have a pre-existing JAVA API to which you wish to connect.

Creating a Java Object Data Source requires, at minimum, the creation of a Data Loader class. A data loader class can be based on the ‘inetsoft.uql. object.DataLoader’ interface, the ‘inetsoft.uql.object.DataLoader2’ interface or ‘Introspection’ based (by complying to the Java Bean conventions). In some cases an additional ‘Data Helper’ class is also needed to describe the structure of the data being returned.

Read how InetSoft was rated #3 for implementation in G2 Crowd's user survey-based index.

Selecting the Type of Data Loader

If your data has a ‘flat’ tabular structure, the Data Loader should be based on the ‘DataLoader2’ interface. It is the simplest and most convenient option; only deals with primitive data types and does not need any Data Helper class.

For data which has a hierarchy (especially a recursive one) the data loader should be based on the ‘DataLoader’ interface or Introspection. e.g. 1 forest had N Trees; 1 tree has N leaves. OR An ‘Employee’ has a ‘Manager’ who is also an ‘Employee’ etc.

Data Loader based on Introspection

A data loader that does not implement the DataLoader interface is completely based on introspection and must satisfy the following requirements:

• the class must have a default constructor that requires no arguments and

• the class must have methods that return a collection of objects. The collection may be an object of the subclass of either:

  • java.util.Collection,
  • java.util.Enumeration, or
  • java.util.Iterator

When a data source is defined based on the data loader, the query engine uses introspection to discover all public methods that return one of the collection types. Each method is then added to the data source as a request.

If a request is created from a method that requires parameters, the parameter values can be specified as part of the data source or they can be declared as variables, which become the data source parameters.

For each request, the user needs to specify the object type (class) returned by the request. This class will be probed by the query engine to find all of the public getter methods and treat them as the fields in the record. During probing, the query engine follows the object references, thus, the meta data may be a hierarchical structure.

Data Loader based on DataLoader Interface

While the default introspection based data loader works well with the classes that match the defined convention, the DataLoader interface provides a more flexible way to define the procedure to load objects. The design and runtime of the data source works in the same way as an introspection based data loader, except that the DataLoader interface is used for meta-data discovering and runtime execution without relying on introspection.

The DataLoader interface defines the following four methods:

  1. public String[] getRequests()
    • This method should return a list of request names. This corresponds to the methods that return a collection of objects in the introspection based data loader.
  2. public Class getRequestOutput(String request)
    • This method returns the object type for each request. It must handle all request names returned from getRequests().
  3. public Class getRequestParameter(String request)
    • This method returns the parameters for each request, similar to the getRequestOutput() method.
  4. public Collection execute(String request, Object params, XNodePath condition)
    • This method executes the requests. It optionally handles the user defined conditions in the XNodePath. If any conditions defined in the XNodePath can be handled by the execute() method, they should be handled internally (for example, as a condition to an object oriented database query). If a condition cannot be handled by the execute() method, it should raise a ConditionNotSupported Exception. The query engine will call the execute() method again without the condition, and will process the conditions as part of the post processing.
demo icon
View a 2-minute demonstration of InetSoft's easy, agile, and robust BI software.