...
The base URL of the APIs is: /onelistserver/api/datasync
e.g. https://iqx.onelistapprovals.com/onelistserver/api/datasync/synctasks. These APIs can be viewed and tested using Swagger which is accessible via /onelistserver/swagger
. The full API signatures can also be found here.
Authentication
The source system adapter must use the OneList API key that is assigned to it by OneList the source system to interact with the data sync APIs. Follow the steps in Manage Source Systems to find the API key for the source system. The API key should be specified in the X-API-Key
header in every HTTP request. Below is an example of a HTTP POST request:
...
The key terms used in the APIs
Term | Description |
---|---|
TaskType | This constant value must match the Task Adapter Task Type in OneList configured to handle the request. |
TaskId | This is the source system unique identifier of the task. The value must be consistent in the whole lifecycle of the task. |
BusinessObjId | This is source system identifier of the business object associated with the task. For example,
|
ActionId | This is the source system workflow action identifier. |
Assignee | The user id of the source system user who is assigned to the task as the approver / agent. |
Delegator | The user id of the source system user who is delegating the task. |
Delegate | The user id of the source system user who is the task delegate. |
HashValue | The string value can be used to compare if the task has been changed. The following can be used as the hash value for a task:
|
The key APIs for integration
Note: only the key parameters of each API are listed here, please view the full API signature via /onelistserver/swagger
Swagger
.
Function | Description |
---|---|
| This API synchronizes OneList tasks with source workflow tasks.
|
| This API returns the list of user id of the source system users who have outstanding task but are not yet mapped to an OneList user. The source system should call the SyncUsers API to |
create or update their accounts in OneList so they can view their tasks in OneList. | |
| This API returns the profile of active OneList users. It can be used to compare with source system user information to detect outdated OneList user profile.
|
| This API adds or updates OneList user account with the source system user information. It also creates the user mapping between the OneList user account and the source system user account.
|
| This API synchronizes OneList task attachment cache with source system files.
|
| This API returns the list of user task actions. The source system should perform the requested task action in the workflow.
|
| Source system calls this API to notifiy OneList of the requested task action.
|
What needs to integrate with OneList
...
The adapter is a daemon service. It needs permission to query all user’s tasks, as well as the business objects and attachment files related to the tasks. You need to decide whether it should use the running serivce service account or an explicit account to access source system data and make sure that account has sufficient permission to query the soource source data.
The adapter may need to impersonate the approver to perform task action in the source system. Impersonation requires permissions such as to run SAP background job as the approver, or to request access token using the approver’s refresh token.
What is the main source for user information in the organization? Is user mapping required?
The adapter needs to implement the user sync process if the source system is the main source for OneList users.
...
Should the adapter implement user sync process?
The adapter is required to implement the user sync process when
the source system user id and the OneList user id are the same;
the adapter can automatically map the source user id to the OneList user id.
The user sync process involves calling the /onelistserver/api/datasync/GetUserSyncRequests
to get the list of user ids to be sync’d and calling the /onelistserver/api/datasync/SyncUsers
to post the user profile and user mapping to OneList. The adapter should query the user information from either the source system or the identity management system, e.g. internal AD or Azure AD. In response to the Sync Users API, OneList will create user accounts and send email notification to the new users inviting them to start using OneList.
If there is no relationship between the source system user id and the OneList user id are different, then the adapter can does not implement the user mapping process when it can automatically map source user id to the OneList user idsync process. OneList will prompt users log in to the source system with the source system user credentials in order to complete the user mapping process. The prerequisites of this manual mapping are:
user has an existing OneList account;
the source system supports one of these protocols: OAuth, OpenID Connect or SAML.
What level of detail in the task is required?
It is better to involve end user early to identify the level of detail required for approvers to make decisions and make sure the adapter has sufficient access to the source data internally and externally as needed. In order to provide sufficient detail for users to make approval decisions directly within OneList, the adapter will need to retrieve comprehensive information for the task, such as
details of the business object associated to the task, e.g. the purchase order detail, the SharePoint list item properties;
the key and value of master data look ups;
prior approvals and comments from the workflow history;
documents attached to the task or the business object;
What is the selection
...
criteria for the initial load?
When integrating with an existing workflow, it is important to identify the selection criteria for the initial load to avoid outdated and invalid tasks being posted to OneList. Fields like task id, creation date and status are commonly used as the selection criteria. The adapter should efficiently perform the initial push of tasks to OneList. Consider HTTP connection and request size limits imposed on the OneList APIs, paging of data may be required to handle large volumn volume of data.
Event-based integration process
Event-based process is preferred as it is timely and efficient. However, the adapter should also consider implementing time-base trigger for the process so that it can catch up any missing missed events due to downtime and or lost of connectivity to the event source.
...