External UI Integration
  • 21 Feb 2022
  • 2 Minutes to read
  • Dark
    Light

External UI Integration

  • Dark
    Light

Article Summary

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.

For further information on Integrations, visit the Decisions Forum.

Was this article helpful?