- 21 Feb 2022
- 2 Minutes to read
- Print
- DarkLight
External UI Integration
- Updated on 21 Feb 2022
- 2 Minutes to read
- Print
- DarkLight
Overview
Decisions provides many powerful tools for creating UIs for workflows and Forms, but its most powerful features are server-side features. As such, there is a good use case for using Decisions as a backend for a custom external UI.
Example
A UI written in React relies heavily on a Decisions backend. Flows and Reports can easily be exposed using the Flow Integrations Panel. The real choice for an external UI is how to authenticate to these end-points. This could be handled on the server, where requests could be forwarded and rewritten to include stored credentials or a stored session. For a UI that interacts heavily with Decisions directly, or uses Decisions as its primary back-end, those methods could be cumbersome or can cause security issues.
This exercise will focus on authenticating REST requests via a Decisions Login, including:
- Configuring the Decisions REST Root for all of your application’s requests.
- Decisions Authentication over REST.
- Authenticating subsequent API calls.
Decisions web-service integrations can be viewed in the Portal by navigating to System > Administration > Features. Core services are at System > Administration > Features > Decisions.Core.
To view Integration Details in a Flow, navigate to the top right and select VIEW.
Below is an example of an Integrations page
Decisions REST Root V7 IIS hosted
Decisions typically serves API calls from a {base-url}/decisions/Primary/, e.g.
https: //example.com/decisions/Primary |
---|
Decisions REST Root V7 Self hosted
https://example.com/restapi/ |
---|
All API calls will need to have that URL configured at their root, referred to hereafter as the “restRoot.”
For this exercise, POST to the AccountService > LoginUser end-point.
Logging in to Decisions
- To login, POST credentials:
URL: ${restRoot} /REST/AccountService/LoginUser Method: 'POST' Body: { outputType: 'JSON' , username: 'example@decisions.com' , password: '********' } |
---|
- Given a successful login, the response body will contain the session ID:
{ "LoginUserResult" : { "SessionValue" : " " ... } } |
---|
For the scenario discussed in this document, it is advisable to manage sessions in the external application.
Be aware: DecisionsSessionID cookie will be set, whether login succeeded or not (at least as of 5.0.3).
Making API calls to Decisions
As mentioned, URLs to Decisions resources can be created using the Flow Integrations panel, but for friendlier URLs, read adding a Flow alias.
For the reasons outlined above, this exercise assumes the "Login" credential option
The Show Service API button might give users a POST URL like this:
http://example.com/decisions/Primary/?FlowAlias=GreatestFlow&Action=api |
---|
In order to authenticate using the session created above, add the session ID as a sessionId query parameter:
http://example.com/decisions/Primary/?FlowAlias=GreatestFlow&Action=api&sessionId=12345-3xampl3-id-6789 |
---|
Provided that session ID is still valid on the Decisions server instance, the Flow will run and its output will be returned as the HTTP request’s response.
Schema Definitions
XML or JSON schema definitions can at the bottom of the Flow Integrations Pane.