Bold BI dashboard designer supports connecting almost all web services that has a REST API interface. A live connection in Bold BI is more powerful than an extract connection because it won’t store data in the data process. However, it is different from the Direct Query since it will fetch the data from your server rather than connecting directly to it.
A live connection feature is available for WEB API data sources. Live web API connections do not store data in the data process. The fetched data will be cleared from the data process once all widgets have been visualized in the dashboard.
Some of the limitations associated with the Bold BI Web API LIVE Connection are as follows:
To configure the web data source, follow the below steps:
Click the Data Sources button in the configuration panel to add a new data connection.
Click CREATE NEW to launch a new connection from the connection panel.
Select the Web connection in the connection panel.
NOTE: You can also create a data source from the home page by clicking the Data Sources menu from left menu panel and Create Data Source from the data sources page.
After clicking the data source, the NEW DATA SOURCE configuration panel opens. Follow the below steps to create web data source:
Enter a name and description (optional) for the data source.
Enter a valid REST API endpoint in the URL text box.
Choose one of the Method Type from the combo box for the provided REST API. Options are GET and POST.
If required by the REST API, provide key value pairs in Headers. To get details about headers, refer to Query Parameters.
Choose a time interval for Refresh Settings using the combo box to trigger the Rest API request periodically to keep the data in sync with our dashboard.
Choose a Data Format from the combo box based on the response of your provided REST API. Options are JSON, CSV, and XML.
Choose an Authentication Type supported by the data source. Options are Basic http authentication and None. Learn more about Authentication Types.
Choose a Pagination Type supported by the data source from the combo box.
You can also edit the connection information set here using the Edit Connection option.
Click Preview & Connect to connect with the configurations set.
The Choose Table(s) dialog opens. The schema represents the key data fields retrieved from the Web Rest API request. This dialog displays a list of schemas in treeview and their corresponding values in the grid for preview. Select the required schema(s) from the treeview to use in the designer and click Connect.
Now, the data design view page with the selected table schema opens. Drag and drop the table.
Click Save to save the data source with a relevant name.
Options are None, Offset, Next Page, Next Token, and Next URL.
Note: In accordance with the pagination type, the response data must match the provided JSON format.
It can be used when the REST API does not need to be paginated. This will return the first set of records alone.
The number of records to be skipped before starting paginating.
For example, connect the OData
REST API in the web data source with the pagination parameters as follows:
Field Name | Values | Description |
---|---|---|
URL | https://services.odata.org/V4/Northwind/Northwind.svc/Order_Details | Rest endpoint URL |
Method Type | GET | Request Type of the provided endpoint |
Data Format | JSON | Data format of the response for the provided Rest API |
Authentication Type | None | To connect the provided endpoint, provide proper authorization credentials |
Pagination Type | Offset | Number of records to be skipped before start paginating |
Max Rows | 7 | Number of records to be fetched |
Start field name | $skip | Indicates the name of the parameter to skip the records |
Start field value | 2 | Value for the parameter *Start field name* |
Count field name | $top | Indicates the name of the parameter to fetch the number of records from the index provided |
Count field value | 3 | Value for the parameter *Count field name* |
Total Records Path | (leave as blank) | To find the total records count from the obtained response. Use '.' to specify the nested key as like `data.records.totalRecords`. Refer Sample for Total Records. |
Data indicator path | value | Number of records fetched will be identified from the data. Refer to the sample for Data Indicator Path. |
Sample for total records
Sample for data indicator path
The number of pages to be fetched with the specific number of records per page.
For example, connect the Smartsheet
REST API in the web data source with the pagination parameters as follows:
Field Name | Values | Description |
---|---|---|
URL | https://api.smartsheet.com/2.0/workspaces | Rest endpoint URL |
Method Type | GET | Request Type of the provided endpoint |
Header | Authorization : Bearer {:access_token} | Authorization Headers for the endpoint |
Data Format | JSON | Data format of the response for the provided Rest API |
Authentication Type | None | To connect the provided endpoint, provide proper authorization credentials |
Pagination Type | Next Page | Pagination pairs like page/per_page, page/pageSize, etc... will be supported under this category |
Max Iterations | 2 | Number of Iterations to paginate. |
Next page field name | page | Name of the parameter to fetch the specific page |
Next page field value | 1 | Value for the parameter *Next page field name* |
Page size field name | pageSize | Name of the parameter to denote the number of records per page. |
Page size field value | 2 | Value for the parameter *Page size field name* |
Total Pages | data.records.totalPages | Specify the path where the response has the information for `total number of pages`. Refer to the sample for Total Pages. |
Data indicator path | records | Number of records fetched will be identified from this path. |
Sample for total pages
Sample for data indicator path
Iterate the next set of records using a token.
For example, let’s connect the Google AdSense
REST API in the web data source with the pagination parameters as follows:
Field Name | Values | Description |
---|---|---|
URL | https://www.googleapis.com/adsense/v1.4/accounts/{:accountId}/adclients?maxResults=2 | Rest endpoint URL |
Method Type | GET | Request Type of the provided endpoint |
Header | Authorization : Bearer {:access_token} | Authorization Headers for the endpoint |
Data Format | JSON | Data format of the response for the provided Rest API |
Authentication Type | None | To connect the provided endpoint, provide proper authorization credentials |
Pagination Type | Next Token | To get the next set of records, make use of token from the response |
Max Iterations | 2 | Number of Iterations to paginate |
Next token field name | pageToken | Name of the parameter used to carry the token in the request like http://sample.com/samples?pageToken=1234. To fetch nested key, refer to the sample response |
Data indicator path | nextPageToken | Specify the path of the token to fetch the next set of records |
Sample response
Iterate the next set of records using url obtained from the response.
For example, let’s connect the GitHub
REST API in the web data source with the pagination parameters as follows:
Field Name | Values | Description |
---|---|---|
URL | https://api.github.com/events?page=1&per_page=2 | Rest endpoint URL |
Method Type | GET | Request Type of the provided endpoint |
Header | User-Agent : Syncfusion Dashboards | Authorization Headers for the endpoint |
Data Format | JSON | Data format of the response for the provided Rest API |
Authentication Type | None | To connect the provided endpoint, provide proper authorization credentials |
Pagination Type | Next URL | To get the next set of records, make use of URL from the response |
Max Iterations | 2 | Number of Iterations to paginate |
Next URL path | link | Specify the path to get the next url. |
Look in Header | Enable checkbox | Whether to find the provided URL path in response header or not. |
NOTE: To do pagination, you must provide any one of the field values, either the
Total Records Path
orData Indicator Path
. If both values are provided, theTotal Records Path
will be considered.
API Key is one of the most commonly used authentication types for REST API. API Key will be assigned to a user by the provider at the time of user creation or when enabling the API Key authentication to access the data via REST API.
API Key can be used in following places which have listed below.
To connect REST API for adding API Key in the header, you can follow below steps to connect the API in Bold BI.
Add header in Web API data source as below.
You need to select the Authentication Type as None.
Header value can be either basic or bearer based on the application that you are connecting.
Most of the API Key authentication connect using Authorization header. You can also change the name of the header key as per your need.
Query String parameter will be added within the URL, so you can access the REST API without adding any header or body.
No additional steps may require for connecting API using Query String type of API Key authentication.
You need to select the Authentication Type as None since its API Key added in the Query String parameter.
Body Data usually be added for Post method API calls. If the application designed to send the API Key over the Body Data of REST API, you can follow the below steps.
Choose POST method in Web API data source to add Body Data and add the API Key as below with relevant property names.
You need to select the Authentication Type as None since its API Key added as Body Data.
Use Dashboard parameters with Live Web API connection. The Web API live connection in combination with the dashboard parameter will help to achieve many of the use cases. The following are some examples of dashboard parameters with Live web connections.
Dashboard parameters can be used in the Web API connection’s URL, Headers, and Parameters.
Example 1: Filtering the dashboards based on Literal Mode.
Follow these steps to use the feature.
https://services.odata.org/V4/OData/OData.svc/Products
2. Once you have connected the data source, create the StartDate and EndDate under the Literal Mode dashboard parameters.
3. Save the data source. Then, click the edit data source to reconnect the dashboard parameter URL as given and save the changes.
Example:
http://services.odata.org/V4/OData/OData.svc/Products?%24filter=ReleaseDate%20gt%20@{{:LiteralDS.StartDate}}T00:00:00Z%20and%20ReleaseDate%20lt%20@{{:LiteralDS.EndDate}}T00:00:00Z
4. Create the dashboard with the data source and publish it.
> **NOTE:** A dashboard is rendered according to the date range configured in the dashboard parameter when the data source is created.
5. Click the dashboard parameter icon and adjust the date range to render the dashboard with the specified values.
6. Real-time data will be displayed on the dashboard based on the selected date range.
Example 2: Filtering the dashboards based on Iterative Mode.
Note: The Live Web data sources do not support multiple iterative Modes for optimum performance and time delay.
Follow these steps to use the feature.
https://gorest.co.in/public/v2/users
Once you’ve connected the data source, create the User ID under the Iterative Mode of the dashboard parameters. Refer to the document to add the Iterative Mode dashboard parameter.
Save the data source. Then, click the edit data source to reconnect the dashboard parameter URL as given and save the changes.
Example:https://gorest.co.in/public/v2/users/@{{:IterativeDS.User ID}}
Create the dashboard with the data source and publish it.
NOTE: A dashboard is rendered according to the User ID’s range configured in the dashboard parameter when the data source is created.
Click the dashboard parameter icon and select the User IDs to render the dashboard with the specified values.
Real-time data will be displayed on the dashboard based on the selected User ID’s range.
Live mode max rows limitation | For optimum performance in live mode Web API, records are restricted to 5000 by default. Change the limit from the Max Rows option to fetch more records in live mode or extract mode for more than 5000 records. |
Refresh Settings limitation | For the live mode Web API, refreshing tables is impossible because the data is not stored while connecting the data source in live mode. |
You can configure the URL of the API request with templates containing date queries. The queries will be updated with respective date values.
Syntax{{:today()}}:
It is used for single calendar related method.
Or
Syntax{{:today().adddays(1)}}:
It is used when more than one method is added.
For example,a dummy API is used to explain here
Now, this URL will be parsed, and templates will be matched, hence the templates will be replaced with dates accordingly. This helps you to fetch data between the start date and end date.
You can configure parameters as numeric values for the following functions: AddMinutes, Addhours, AddDays, AddWeeks, AddMonths, AddYears, AddQuarters, SetDayStart, and SetMonthStart.
All the Add methods should not have parameter as 0, the SetDayStart should have a numerical value between 0 and 6, and the SetMonthStart should have a numerical value between 1 and 12.
String parameters are used in the next set of functions which are start, end, format, and SetTimeZone. Both start and end functions support four string parameters which are week, month, quarter, and year. The format function is used to change the format of date and time, and the parameter is matched with the date and time format supported in C#. A support for epoch time is also made available in the format function. The SetTimeZone is used to change the time zone of the date and the parameter is matched with TimeZoneInfo IDs present in C#.
Today
function does not hold any parameters.
Here for example concern we are using today()
as 11/16/2018 12:17
Function Name | Type(s) Used | Description | Example(s) | Result |
---|---|---|---|---|
Today | No Parameter | Sets date and time to current date and time. | {{:today()}} | 11/16/2018 12:17 |
AddMinutes | Numerical | Updates the date and time by changing the number of minutes. | {{:today().addminutes(10)}} | 11/16/2018 12:27 |
AddHours | Numerical | Updates the date and time by changing the number of hours. | {{:today().addminutes.addhours(2)}} | 11/16/2018 14:29 |
AddDays | Numerical | Updates the date and time by changing the number of days. | {{:today().adddays(2)}} | 11/18/2018 12:17 |
AddWeeks | Numerical | Updates the date time by adding a date with the numerical parameter considered as 7 days. | {{:today().addweeks(1)}} | 11/23/2018 12:17 |
AddMonths | Numerical | Updates date and time by adding months with numerical parameter. | {{:today().addmonths(2)}} | 1/16/2018 12:17 |
AddYears | Numerical | Updates date and time by adding years with the numerical parameter. | {{:today().addyears(3)}} | 11/16/2020 12:17 |
AddQuarters | Numerical | Updates date and time by adding months with a numerical parameter, where parameter value 1 means 3 months. | {{:today().adddays(10).addquarters(2)}} | 5/26/2019 12:17 |
Start | String | Sets the date and time values to the start of the given string parameter. | {{:today.addweeks(2).start(week)}} | 11/25/2018 00:00 |
End | String | Sets the date and time value to the end of the given string parameter. | {{:today().addmonths(4).end(year{{}})}} | 12/31/2019 00:00 |
Format | String | Formats the date and time to the correct date format entered as string parameter. | {{:today().start(week).format(MM/dd/yyyy)}} | 11/11/2018 |
SetTimeZone | String | Changes the time zone to the time zone entered as string parameter. | {{:today().settimezone(New Zealand Time Zone)}} | 11/16/2018 19:47 |
SetDayStart | Numerical | Updates the date to the day of the week based on the entered numerical parameter. | {{:today().Setdaystart(1)}} | 11/12/2018 12:17 |
SetMonthStart | Numerical | Updates the date to change the month based on the entered numerical parameter | {{:today().SetMonthStart(10)}} | 10/16/2018 12:17 |
NOTE: Each template should mandatorily start with today function. For a template, if the format function is used, it should be the last function call.