Contents
1 Document Change Management 3
4.1.1 Stateful Operation Service Proxy
4.1.3 Stateless Operation Service Proxy
5.2 Update data object name/description
6 Auxiliary Services to get data
1 Document Change Management
| Release | Date | Author | Comments |
| 1.0 | 03/2018 | RF | First release |
| 1.1 | 04/2025 | RF | Update DataObject name/description |
| 1.2 | 03/2026 | RF | Update document to Bruno software |
2 Introduction
Several REST web services are provided allowing tenants and customers to interact with Triskell virtually from any environment/platform. This document describes how to update the basic data of a data object and load data on a given rate using the operational services. Creation of data objects is not allowed by the Rest API.
|
Usually, Web services are designed to manage small set of data.
If you are not sure they will cover your requirements, please contact us at: support@triskellsoftware.com.
|
In this document there are some examples about how to send information to Triskell using Bruno plug-in, from Bruno Software. You can get Bruno for free here. Then you just need to import the attached file "TriskellAPI.yml" and the file “NextRelease-environment.json”. The last file is used to set environment variables, so it can be easily tested on different environments.
It's very important to test your code on the Nextrelease environment before delivering it on the production environment (https://nextrelease.triskellsoftware.com/triskell/). In this document examples given are using Localhost as testing environment.
|
Some internal id's can be different between testing and production environments. Please review the hardcoded id's before delivering it on production environment.
|
3 Authentication
From the authentication point of view, there are two kinds of web services on Triskell: stateful and stateless.
Most of the REST services provided are Stateful, which means that interacting with them requires a login first.
On the other hand, Stateless services will do user authentication on every call.
Stateless services are intended to be used by clients not capable of managing a session cookie to maintain a dialog with the server.
| In this document, only Stateless services will be denoted, most of the services being Stateful by default. |
Two services are provided to log in and log out of Triskell.
Stateless services must provide their authentication parameters like HTTP Headers on every service call.
3.1 Login Service
The login service must be invoked before any other stateful Triskell web service call. It receives a user identifier and a password as URL parameters.
| URL | https:// SERVER /triskell/service/rest/login/user/{userId}/passwd/{pass} |
| HTTP Method | GET |
| URL Parameters |
{ userId }: String containing user identifier as ‘user@tenant.com’ URI encoded { pass }: String containing a Base64 encoded MD5 hash of the password |
| When login is successful it returns a HTTP response code ‘200 – OK’An authentication failure will return HTTP response code ‘401 – UNAUTHORIZED’ |
Example:
3.2 Logout Service
Logout service provided for closing the session at the server.
| URL | URL: https:// SERVER /triskell/service/rest/logout |
| HTTP Method | GET |
Example:
| Don't forget to close your session when finishing your REST conversation |
4 Service Proxies
Service Proxies are a simple way of executing remote procedure calls Operation services.
Requests and responses are exchanged as JSON objects with the clients, to enhance easiness and interoperability.
The proxy input object DataRequest, is compound of the following properties:
- Id: numerical identifier
- Params: A simple JSON object containing only primitive type properties.
- Objects: Array of JSON objects of any type.
These properties must be present into the object being used or not.
Example of DataRequest :
|
{ 'id': 1, 'params': { "param_1":"A", "param_2":2 } , 'objects': [ {"NAME":"OBJECT_1"}, {"NAME":"OBJECT_2"} ] } |
The proxy output object Result, is compound of the following properties:
- success: Boolean indicating successfulness of the request.
- message: Error description.
- resultType: Numerical identifier, error severity (1-OK, 2–Warning, 3-Error)
- data: a String or a JSON object
- id: a numerical identifier
- authash: session identifier
- executime: service execution time in nanoseconds
- i18NParams and i18NMessageId: used on internationalized error message
Example of DataResult :
|
{ "authash":"dd06d7c94cd9a73f62b45c5b54247bce", "executime":10997027, "success":true, "message":null, "resultType":1, "data":"Hello world !!!", "id":0, "i18NParams":[], "i18NMessageId":"" } |
4.1 Operation Service Proxy
This is a Web Service to execute operations on a Triskell OperationService.
An OperationService groups related functionalities allowing to access then by his Operation Name.
OperationServiceProxy has two implementations, stateful and stateless.
4.1.1 Stateful Operation Service Proxy
Any stateful service requires a Login to be done before submitting any request to it.
4.1.2 WS Operation execute
Execute a service operation call. DataRequest is sent attached to the body of the HTTP request.
| URL | URL: https:// SERVER /triskell/service/rest/proxy/operation/execute/{serviceName}/{operationName} |
| HTTP Method | POST |
| Content-Type Header | application/json |
| URL Parameters |
{serviceName}: String containing the name of the service to be called {operationName}: String containing the operation name |
4.1.3 Stateless Operation Service Proxy
This web service does not require doing a previous Login on Triskell, a user authentication is done on every request.
4.1.4 WS Operation execute
Execute a service operation call. DataRequest is sent as a URL parameter.
| URL | https:// SERVER /triskell/service/rest/proxy/operation/execute/{serviceName}/{operationName}/{payload} |
| HTTP Method | GET |
| Content-Type Header |
X-Account-Name Header: Optional, username@tenantdomain X-API-Key Header: Optional |
| URL Parameters |
{serviceName} : String containing the name of the service to be called {operationName} : String containing the operation name {payload} : JSON DataRequest Object encoded in Base64 |
5 Data Object Update Services
In this section, we describe the main operations available to handle a Data Object in Triskell using the existing Stateful services for the most basic use of case. In this document, we are using examples from a standard configuration at test.com.
5.1 Update a data object
To use this call, we need to get some information from your instance to make it work properly.
What information do we need to update a data object?
- Data object to update: "Application for Rest"
- Name: " Application for Rest "
- Description: “This is the first description”
- Calendar: “Parent Calendar”
- Currency: “Euro”
- Lifecycle: “1.Conceive”
We need to extract all this information from Triskell. Some information can be taken directly from your Triskell instance using the UI and, in some cases, we need to make a request using an operational service to get data from a stored selector report.
This is a request example:
This is the example content request:
|
{ "id": 0, "params": { "dataObjectId": "1712", "ppname": "KRONOS for Rest (new name)", "ppdesc": "The second description", "calendarCombo": "2", "defaultCurrencyCombo": "10", "pplf": "128" }, "objects": null } |
| Customer can make more than one request on the same REST conversation depending on your functional needs. This feature should not be used to load big data volumes because. During the REST conversation Triskell users can get blocked processing the request, so we suggest using it with common sense in terms of data volume and scheduling. Triskell will limit the number of requests by day in the future to avoid collapsing the server, so please take this in account when developing your interfaces. |
To see if the Data Object was updated you can check on Triskell.
5.1.1 Fields description
5.1.1.1 Mandatory fields
- dataObjectId: unique data object identifier (Integer). In previous example is "2082". It requires making a request to Triskell to get it.
- ppname: unique data object name (String). In previous example is "Application for Rest (new name)".
- ppdesc: data object description (String). In previous example is "The second description". This field can be or not require, that depends on the configuration of the object of the data object.
- calendarCombo: unique calendar identifier (Integer). In the previous example is “Rest Calendar”. Can be extracted from the UI on the configurator environment:
- defaultCurrencyCombo: unique currency identifier (Integer). In the previous example is “Escudo”. Can be extracted from the UI on the configurator environment:
- pplf: unique lifecycle identifier (Integer). In the previous example is “2. Design”. It only works if the object is not set to “Advanced lifecycle changes”. It requires making a request to Triskell to get it.
5.2 Update data object name/description
To use this call, we need to get some information from your instance to make it work properly.
What information do we need to update one dataObject name and description?
- Data object to update: "Work Package 01 (for Rest)"
- Name: "Work Package 01 (for Rest)"
- Description: “”
We need to extract all this information from Triskell. Some information can be taken directly from your Triskell instance using the UI and, in some cases, we need to make a request using an operational service to get data from a stored selector report.
This is a request example:
This is the URL of the Rest:
| {{serverURL}}/triskell/service/rest/proxy/operation/execute/DataobjectRestService/setDataObjectNameAndDescription |
This is the example content request:
|
{ "id": 0, "params": { "dataobjectId": "1166", "name": "Work Package 01 (for Rest v2)", "description": "The new description" }, "objects": null } |
| Customer can make more than one request on the same REST conversation depending on your functional needs. This feature should not be used to load big data volumes because. During the REST conversation Triskell users can get blocked processing the request, so we suggest using it with common sense in terms of data volume and scheduling. Triskell will limit the number of requests by day in the future to avoid collapsing the server, so please take this in account when developing your interfaces. |
To see if the Data Object was updated you can check on Triskell.
5.2.1 Fields description
5.2.1.1 Mandatory fields
- dataobjectId: unique data object identifier (Integer). In the previous example is "1166". It requires making a request to Triskell to get it.
5.2.1.2 Optional fields
- name: unique data object name (String). In previous example is "Application for Rest (new name)".
- description: data object description (String). In previous example is "The second description". This field can be, or not required, depending on the configuration of the object of the data object. If one empty value send, the current description will be deleted, but take into account if it is required or not.
6 Auxiliary Services to get data
In this section it will be explained how to extract data required to call main services.
6.1 Get data object id
In this section we describe how to get the data object identifier from Triskell. Triskell allows extract data from your instance using reports. You need a stored selector to build your report.
This report requires two parameters to get the data object id.
DATAOBJECT_NAME (Text):
OBJECT_TYPE (List): This is a list of values existing in Triskell. Can be extracted from the parameter list of the reporting on the configurator environment:
Create the stored selector using the parameters:
Then you can test the query to check that you get the id properly:
This is the result of this example:
This is the query for the example above:
|
select dataobject_id from tenant_vw_dataobjects where object_id = ##OBJECT_TYPE## and dataobject_name = ##DATAOBJECT_NAME## |
This view contains all data objects.
Once you create and test your stored selector, you need to create the associated report:
Now we have all id's needed and report to get data object id dynamically from our API rest.
6.2 Get lifecycle (pplf)
In this section we describe how to get the lifecycle (stage) identifier from Triskell. Triskell allows extract data from your instance using reports. You need a stored selector to build your report.
This report requires two parameters to get the stage id.
STAGE_NAME (Text):
OBJECT_TYPE (List): This is a list of values existing in Triskell. Can be extracted from the parameter list of the reporting on the configurator environment:
Create the stored selector using the parameters:
Then you can test the query to check that you get the id properly:
This is the result of this example:
This is the query for the example above:
|
select to_stage_id from tenant_vw_workflows where object_id = ##OBJECT_TYPE## and to_stage_name = ##STAGE_NAME## |
This view contains all data objects.
Once you create and test your stored selector, you need to create the associated report:
Now we have all id's needed and report to stage id dynamically from our API rest.
Comments
0 comments
Please sign in to leave a comment.