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.

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.

More Resources About BI Access

• Create A Named Grouping For Reused Conditions

  This article explains how to define a “Named Grouping” object within a worksheet by entering a custom name in the appropriate field. It shows how to make grouping rules reusable across columns or attributes by data type, and optionally limit them to a specific column from a data source. The example walks through adding groups, naming each group (for example “East Coast states”), and choosing whether unmatched values go into an “Others” bucket or remain separate. The benefit is the ability to apply consistent group logic (by initial letter, category, etc.) across multiple worksheets or reports. The piece emphasises that the name of the grouping object serves as the title in worksheets and repository lists.

• Define A Variable Asset By Entering A Name

  This how-to shows how to create a new variable object for dashboards and reports, specifying key metadata including the name, label, and data type. The 'Name' field defines the title of the asset as it appears in the repository, while the 'Label' is what users see when prompted at runtime. It guides users through selecting value sources (none, embedded list, or query), setting default values, and saving the variable for reuse across worksheets. Reusing the variable means fewer duplicates and consistent naming. The article underscores efficient asset reuse through naming conventions.

• Specify The Name Of An Embedded Table

  This article outlines the steps to add an Embedded Table object into a worksheet and emphasizes the importance of entering a meaningful 'Name' in the properties dialog. That name becomes the identifier used in viewsheets or for binding controls and scripting. After naming, the article recommends editing column names and default values, and optionally linking the table to other data blocks. Good naming simplifies later maintenance, scripting, and embedding. The article positions naming as central to managing embedded table objects in larger deployments.

• Define Object Names For Dashboard Components

  This reference article lists the types of dashboard objects (Table, Text, Chart, Painter, etc.) and explains how each is identified by a unique name or alias. For example, a Text object inherits properties from the Tab object and may need a distinct name for scripting or dynamic property changes. The document details how internal properties refer to ‘Name’ or ‘Alias’ fields, which serve as handles for visibility, dynamic styling, or action triggers. Proper naming helps ensure that elements can be referenced unambiguously in scripts or parameter bindings. It positions naming as part of maintainable dashboard design, especially in complex or embedded scenarios.

• Enter A Dashboard Name For A New Tab

  This article explains how, when creating a new dashboard (or portlet/dashboard container), the user enters a value into the “Dashboard Name” field, which then appears as the tab title in the user portal. It walks through design-mode steps for naming the dashboard, selecting types (Portlet or Viewsheet), and optionally providing a description. The dashboard name thus affects the UI and how users navigate the portal. Clear naming conventions help end-users recognize dashboards by purpose or audience. The article underscores the importance of consistent naming for usability and governance.

• Enter The Asset Name When Saving A Worksheet Or Condition

  This article covers how to save assets (Worksheet, Named Condition, etc.) in the repository and explains that when dragging the icon into a folder the system prompts for an “Enter Asset Name” field. That name determines how the asset appears in folders and lists. It shows the importance of entering a descriptive asset name rather than a generic title. The article gives steps for naming and organizing assets for reuse across worksheets and reports. It highlights naming discipline as part of efficient repository management in the BI platform.

• Assign A Form Name And Field Name To Controls

  This article describes how form controls in reports must have two properties: a ‘Form Name’ and a ‘Field Name’. The Form Name groups related controls into one submission unit, and the Field Name is the unique name of the HTML control in the portal and is used by scripts and server-side logic. It gives step-by-step instructions for setting Form Name and Field Name when adding controls like a text field or radio button. Proper naming allows client-side validation, grouping, and submission flows. The article highlights the role of naming in interactive forms within dashboards and reports.

• Specify The Request Name For Parameter Definitions

  This article explains how in parameter specification you define a “request name” that identifies which request the parameters belong to, and then parameter entries such as “Name” (e.g., param.addParameter("Name", …)). The request name helps link the parameters to the correct report creation workflow. It emphasizes using meaningful request names and parameter names (such as “Name”, “Password”, etc.) so that retrieval methods like getString("Name") return the expected value. The article shows how naming conventions affect scripting, parameter passing, and view logic. Naming discipline supports clarity in report definition and reuse.

• Change The Name Of A Table Or Other Asset

  This article deals with how to rename a worksheet asset (table, variable, named group) by right-clicking its title row, selecting ‘Properties’, editing the Name field, and clicking OK. It explains that all assets in a worksheet must have unique names, and shows how to rename a worksheet asset in the repository by selecting the asset and using the context menu. The article emphasises that proper naming and uniqueness prevent conflicts and aid maintenance. It frames asset naming as a foundational aspect of repository hygiene and collaboration.

• Enter A Name For The Embedded Table Or Grouping Object

  This feature summary mentions that in the ‘Name’ field of the embedded table or grouping object you enter the identifier by which you will reference the object elsewhere (e.g., in a viewsheet or filter). It outlines how dashboards allow naming the embedded table, grouping or other components and how that name is then used for identification, scripting, or referencing. It emphasizes the naming phase as a key design step. It recommends logical, descriptive names to improve readability and maintainability of dashboard definitions.

• Enter A Name For A Query When Building A Table

  This article walks through creating a new query in the Query Wizard and specifies that you must enter a name for the query in the General tab. That name serves as an identifier for the query within the system and may affect aliasing, binding, and reuse. It explains how naming queries properly supports documentation, sharing, and referencing by other worksheets. Good query naming also aids governance and auditing of analytics artifacts. The article positions naming as integral to the metadata layer of BI development.

• Enter A Name For A New Column In Ad Hoc Reporting

  This article describes how to create a new expression or formula column in the ad hoc reporting wizard, starting with entering a value in the ‘Name’ field for the new column. It then guides you through selecting the return data type (String, Double, etc.) and entering the formula or script. The column name then appears in tables and reports as the header of the new column. The article stresses that meaningful column names help end-users interpret results and avoid confusion from generic names like “Column1”. Good naming supports clearer analysis and dashboard consumption.