Server side js action: how to feed a grid from a JS business component

A special kind of business component is the one based on server-side javascript. This solution is helpful when a complex logic is required to compose or elaborate the data fetched from the database and a simple SQL query is not enough.

This type of component can be used to feed a grid or a form panel.
The first step is to define a data model: this data model must be of “JS server side” type.

Next, all required fields must be defined for that data model:


Pay attention to the field types: these must be compatible with the ones to show as columns in the grid to feed through the linked JS business component.

After that, a JS business component can be defined and when defining it, the JS data model must be linked to.

A constraint to respect is that the result provided by that business component must be of  ListResponse type.

If the components requires input parameters coming form the grid, these can be accessed though the reqParams variable, as for the ones coming from a Filter panel

Pay attention to the input parameters: it is likely that these are all String type parameters so it could happen that these must be converted to the right type if they are binded as binded variables in the query and here they have a different type.
The most important instruction within the JS business component is utils.getPartialResult:
var json = utils.getPartialResult(
  query,                            // query to execute 
  null,                             // datasource id, null for default datasource
  false,                            // use a separated transaction
  true,                             // interruptExecution
  [ firstDayStr, 
  ]                                  // value to apply to the WHERE clause
The returned value is a JSON string. In case a JS object is required (for instance to process every row), the following instruction is needed:
var resultList = JSON.parse(json); //More secure than eval("(" + json + ")");


That JS object is a  ListResponse class, so it contains a few subobjects:
– resultSetLength – the number of total rows
valueObjectList – the list of rows just read (according to the current pagination settings)
It can be helpful scroll through all the properties of every object to debug the content; this can be done using the following snippet:
for (var property in obj) {
output += property + ': ' + obj[property] + '; \n';


Finally, once processed every single rows according to the custom logic to apply, the final result can be produced and expressed as a JSON string:
var newJson = utils.getListResponse(arrObjs, arrObjs.length, false);
utils.log('newJson  ' + newJson, 'DEBUG');

(To see all the native JSON Objects methods please refer to this page)


This example deeply modified the data model returned by the query so there’s no match between the query fields and the ones declared inside the Datastore Object. Due to this, we had to manually reapply the filters.
We created an action in the filter panel to edit filters in the “Before searching” event:
    Overwrite parameters with DB Field Name and remove the unneeded ones
    var filterNamesArr=filterNames.split(",");
    var filterValuesArr=filterValues.split(",");
 /* Removes parameters */
    var index=filterNamesArr.indexOf('nomeCognomeRichiedente');
/* Map the filters again */
/* Replaces values */