Standard Request¶
A number of endpoints require a request packet in order to work properly.
The request is a JSON string containing two or three values:
- command
- options
- data
The request must always contain a command key-value pair and one or both of the options and data pairs.
Command¶
The request must always contain a command key-value pair. The value identifies the desired operation. For example:
{
"command": "get"
}
Possible values include:
Value | Description |
---|---|
get | Get data from a Repository, Entity or Business Rule |
add | Add data to a Repository, Entity or Business Rule |
edit | Update data in a Repository, Entity or Business Rule |
run | Run an analysis of data in a Repository, Entity or Business Rule |
Options¶
The value will be a JSON string containing options for the operation specified by the Command. The contents of this value are particular to each endpoint and operation, but many include items like a where clause, or key patterns.
Endpoints that return non-trivial amounts of data conform to a standard set of options. These options allow filtering (where clause), sorting, paging, and clearing the cache. They can be used together in any combination to achieve the desired results. These options are described in more detail below.
Paging¶
The paging options allow the data to be returned in smaller chunks. This is essential when processing tables that contain non-trivial datasets. Paging the data increases responsiveness and performance, and allows the data to be processed without restrictions on memory size. These page options are also available in the URL, but we recommend that users keep their URLs as simple as possible and specify page information using this method instead. The paging options are:
Value | Description |
---|---|
pageStart | The row number to start the page from. |
pageSize | The maximum number of rows to return starting from the row specified in the page option. |
For example - get the first 65 rows of data:
{
"command": "get",
"options": {
"pageStart": "1",
"pageSize": "65",
}
}
Filtering¶
Where Clause¶
The ‘where’ option allows a predicate to be specified that will filter the underlying data. The predicate is specified in terms of the TSS Server’s expression builder language, and all expression builder functions are available. Attribute names are to be specified in their humanised form.
Examples:
Display only those rows that have ‘Threshold’ (humanised name) greater than or equal to 10.
{
"command": "get",
"options": {
"where": "Threshold >= 10"
}
}
Using attributes where the humanised name has a space.
{
"command": "get",
"options": {
"where": "'Fail Count' > 0"
}
}
Using literal strings in the expression.
{
"command": "get",
"options": {
"where": "Result = \"failed\""
}
}
Using expression builder functions.
{
"command": "get",
"options": {
"where": "CONTAINS(UPPER('Result'), \"FAIL\")"
}
}
Keypattern Clause¶
The effect of ‘keypattern’ clause is to filter selected records to be those that match the specified keypattern pattern (i.e. to limit the output by specifying a keypattern.). It is desirable to allow the client to have more control over exactly which records are selected. This can be also improve the performance of the query by limiting the scope of the query. The pattern must form part of the primary key of the source.
For example - display only those rows that have keypattern “1 0 2” (i.e EntityID = 1, AttributeID = 0, SeqNo/RuleID = 2).
{
"command": "get",
"options": {
"keypattern": "1 0 2"
}
}
Keypatternlist Clause¶
The ‘keypatternlist’ clause filters selected records in similar way to the above ‘keypattern’, but allows clients to supply multiple key patterns to filter.
For example - display only those rows that match all of the following keypatterns:
{
"command": "get",
"options": {
"keypatternlist": ["1", "2 0 1", "4", "5 0 1"]
}
}
Keypatterns | Matching Rows |
---|---|
1 | Rows where EntityID = 1 |
2 0 1 | Rows where EntityID = 2 AttributeID = 0 and SeqNo/RuleID = 1 |
4 | Rows where EntityID = 4 |
5 0 3 | Rows where EntityID = 5 AttributeID = 0 and SeqNo/RuleID = 3 |
In Clause¶
The ‘in’ clause can also be used to limit the output.
For example - display only those rows where column name ‘actual_priority’ is set to 1 and ‘_actual_threshold’ is set to 10:
{
"command": "get",
"options": {
"in": ["actual_priority 1", "_actual_threshold 10"]
}
}
Columns¶
The ‘columns’ option allows the consumer to restrict or reorder the set of columns they want returned in the dataset. Restricting the number of columns can improve performance, especially for very wide views (e.g. business_rules), and can be used to structure the data more closely to the format required. The columns parameter requires each column’s columnised name to be specified in a JSON list. NOTE: If columns are specified, the HATEOAS URL links will be disabled, because it cannot be guaranteed the returned data will contain the information required to build these URLs.
For example:
{
"command": "get",
"options": {
"columns": ["_ename", "actual_name", "_result","_actual_fraction"],
}
}
Sorting¶
The ‘sort’ option allows the data to be sorted using one or more columns. The sort option contains a list of sort specifications that will be executed in the order they are specified. Each sort specification requires the columnName (columnised name) at a minimum, and will default to sorting ascending by each value. The full set of options is:
Value | Description | Default |
---|---|---|
columnName | The columnised name of the field to sort. This is the only mandatory field. | N/A |
type | Whether to sort the data by its “value” or by its “length” | “value” |
order | Whether to sort in “ascending” or “descending” order | “ascending” |
unique | The resultset will contain only one record per value | false |
For example:
{
"command": "get",
"options": {
"sort": [
{
"columnName": "RULE_ID",
"type": "value",
"order": "ascending",
"unique": true
},
{
"columnName": "ENTITY_ID",
"type": "length",
"order": "descending",
"unique": false
}
]
}
}
Cache¶
The cache option has only one valid argument: flush. When specified, the underlying cached information relating to the endpoint is deleted and recreated. This should be used whenever sorted or filtered data needs to be regenerated in order to pick up changes made to the database. This option should be used with care, as it can greatly increase the time taken to return the response.
For example:
{
"command": "get",
"options": {
"where": "('Threshold'=100)",
"cache": "flush"
}
}
External JSON Format¶
A number of endpoints now support returning the underlying data rows in a JSON key/value pairs format. This allows access by different tools that requires the JSON data in a key/value pair instead of standard array of row data with columns names defined separately.
For example - get list of entities in external JSON format:
GET /api/repositories/test/entities?external=1
{
"command": "get",
"options": {
"external": 1
}
}
Parameter | Type | Purpose |
---|---|---|
external | int | Return rows as key/value pairs if set to 1 to support external clients; returns normal view data if not set. |
When external JSON format is selected, the row data will be returned as JSON key/value pair.
Data¶
The value will be a JSON string containing the data for the operation specified by the Command. The contents of the value are particular to each endpoint and operation.
For example:
{
"data": {
"NAME": "January",
"ENTITY": "1",
"THRESHOLD": "10",
"EXPRESSION": "<expr><text>'Sales Person' = 14</text><eq><var>Sales_person</var><int>14</int></eq></expr>",
"ENABLED": "0"
}
}