This guide will help you implement your own custom data source API server. To configure your server so that it can exchange data with Flexmonster, follow these steps:
If Flexmonster is not yet embedded, set up an empty component in your webpage:
Complete the Integrating Flexmonster guide. Your code should look similar to the following example:
let pivot = new Flexmonster({
container: "pivotContainer",
componentFolder: "node_modules/flexmonster/",
toolbar: true
});
Complete the Integration with Angular guide. Your code should look similar to the following example:
<fm-pivot [toolbar]="true"> </fm-pivot>
Complete the Integration with React guide. Your code should look similar to the following example:
<FlexmonsterReact.Pivot
toolbar={true}
/>
Complete the Integration with Vue guide. Your code should look similar to the following example:
<Pivot toolbar />
In report.dataSource, define these parameters to connect to your custom data source API:
var pivot = new Flexmonster({
container: "pivotContainer",
componentFolder: "node_modules/flexmonster/",
toolbar: true,
report: {
dataSource: {
type: "api",
url: "http://localhost:3400/api/cube",
index: "data-set-123"
}
}
});
Here, url is the base URL to your API endpoints and index is the identifier of your dataset. index will be sent with every request.
At this step, since the back end isn’t configured yet, you won’t see any data in the pivot table if you open it in a browser.
In the next steps, you will find out how to pass the data from your server to Flexmonster using the custom data source API.
Flexmonster sends POST requests to the API endpoints using the JSON format. After receiving the responses from the server, it visualizes the data in the pivot table or pivot charts. The first step in the API implementation is to create endpoints on your server to handle these POST requests.
Note If Flexmonster Pivot is running on a different server, enable CORS.
All requests have the type property in the request body. There are 4 types of requests that can be distinguished by the URL path and type value:
<url>/handshake - The first (handshake) request to establish a connection between the client and server sides.<url>/fields - Request for all fields with their types (i.e., meta-object or schema). <url>/members - Request for all members of the field.<url>/select - Request for the data.The value of type will always be the same as the endpoint name, e.g., when a request is sent to <url>/fields, the value of type is "fields".
We also recommend that you check our sample Node.js server or sample .NET Core server that implements Flexmonster’s custom data source API for an example implementation.
After the connection is configured, Flexmonster sends the /handshake request to <url>/handshake. It is used to establish a connection between the client and server sides and exchange some basic information. The front end sends the version of the custom data source API that it implements. Then, Flexmonster Pivot expects the version of the custom data source API implemented by the back end in response.
The /handshake request allows verifying version compatibility. If the server sends the version of the custom data source API in response to the /handshake request, the component can check whether the server and the component implement the same version of the custom data source API.
To receive notifications about version compatibility, respond to the /handshake request with the implemented version of the custom data source API:
const API_VERSION = "2.8.5";
cube.post("/handshake", async (req, res) => {
try {
res.json({ version: API_VERSION });
} catch (err) {
handleError(err, res);
}
});
Note The /handshake request is optional. If the server does not implement it, Flexmonster will proceed to the next request. However, we recommend handling the /handshake request.
The next Flexmonster's request is the /fields request that is sent to <url>/fields. Read more details about the /fields request in the documentation and implement a response to it on your server.
The custom data source API supports 3 field types: "string", "number", and "date". Note that at least one aggregation has to be supported by the server side for at least one field. For example, a field in the response can have "aggregations": ["sum"] defined:
{
"uniqueName": "Quantity",
"type": "number",
"aggregations": ["sum"]
}
This means that the back end will provide aggregated data for this field and it can be selected as a measure in Flexmonster Pivot.
When Flexmonster Pivot successfully receives the response to the /fields request, the Field List with all available fields is shown. To see it, open the HTML page in a browser.
From now on, the component configured in step 2 should show you the data.
The next request to handle is the request for the field’s members that is sent to <url>/members.
Read more details about the /members request in the documentation and implement a response on your server.
Now in the Field List, you will be able to select a string field for rows or for columns and retrieve its members.
Note For the custom data source API, date members should be passed to Flexmonster as Unix timestamps in milliseconds to be recognized correctly. For example, "2016-02-07" is 1454803200000 when converted to a Unix timestamp in milliseconds.
When a field is selected for rows or columns and a numeric field is selected for measures in the Field List, the /select request for the pivot table is sent to the endpoint <url>/select.
To handle the /select request, your server must implement at least one aggregation function. It is easiest to start with one aggregation (e.g., "sum") and extend the list of supported aggregations later.
This is the time to handle the query.aggs part of the request:
{
"type": "select"
"index": string,
"query": {
"aggs": {
"values"[]: {
"field": FieldObject,
"func": string
},
"by": {
"rows": FieldObject[],
"cols": FieldObject[]
}
}
}
}
When Flexmonster successfully receives the response to a /select request, the pivot table is shown.
Note The /select request is also sent for the flat table and the drill-through view with a slightly different set of parameters.
As a finishing touch, you can check if your server handles custom data source API requests as expected. For this purpose, we created a test suite that covers basic use cases. To learn more about server testing, see this guide.
You may be interested in the following articles: