You are viewing the documentation for Blueriq 16. Documentation for other versions is available in our documentation directory.
Definitions
Host Runtime | The runtime which contains a project that has an AQ_ExternalFlow_ container implementation running. |
Target Runtime | The runtime which contains a project with a flow that can be started by an AQ_ExternalFlow_ container implementation. |
Source Profile | The domain model of the source. |
Target Profile | The domain model of the target. |
Interface Profile | The domain model of the interface |
Datastore | The location where the serialized profile is stored. |
Requirements
In order to use this functionality you need to enable Blueriq External Flow Component.
Configuration
To configure the External Flow Container to work on the runtime you have to do the following:
- Enable
external-flow
profile inbootstrap.properties
. - When using mutliple runtimes enable the correct redis sessions
- When using a single runtime choose either to use redis or the in memory variant.
External flow functionality saves the profile in a Redis Datastore. Please consult Blueriq External Flow Component in order to see more details on how to configure the runtime to support the external flow.
Using other datastore implementation then Redis
Blueriq provides the IExternalFlowStore
interface which can be used to interact with a generic datastore. A default implementation is already provided in the Blueriq External Flow Component. If other datastore implementation is desired you can follow these instructions.
Modeling an External Flow
Decoupling Pattern 8: External Flow Container
Container type: AQ_ExternalFlow
External Flow Endpoints
External Sessions Lifecycle
See External Flow Session Lifecycle.
Authentication & Authorisation
When an external flow is executed on a different runtime than the one that the current project is open, there needs to be a way in order for the roles of the currently logged in user to be validated on the target runtime where the external flow resides to. In order to support this, the authentication details of the main project are saved in the External flow Data Store and when the external flow is executed, the authentication is retrieved on the runtime where the external flow resides on, and is set up as if the same user has logged in on that runtime.
When an external flow resides on a different Runtime, that Runtime gains access to the authorisation details of the user that is executing the external flow, and it may make requests to other systems with that user credentials (especially when using OpenID Connect).
When executing an external flow on a different runtime, it is mandatory for both runtimes (the current runtime and the one containing the external flow) to have the same authentication type.
Custom Authentication Provider
Since Blueriq 16.10 when a CustomBean authentication provider is used to create a custom BlueriqAuthentication implementation, you are required to implement a Custom Authentication Mapper. Blueriq provides implementations for all of its known Authentication objects, but is unable to provide an implementation for custom BlueriqAuthentications as it may loose implementation details.
Security
Content-Security-Policy (needed when hostname and/or port are different)
Set Content-Security-Policy on the source to allow access to the remote server:
# Content Security Policy blueriq.security.click-jacking-protection.content-security-policy.default-src='self' http://target:port
Cross-Origin Resource Sharing (needed when using multiple domains)
When running an external flow from an AQ_ExternalFlow container, requests could be made between different domains. Therefore, for the external flows to work, you need to configure the Cross-Origin Resource Sharing mechanism. For more information, see Security: Cross-Origin Resource Sharing
Known limitations
The following list contains all currently known limitations for external flows. In general the external flow should not be used to start new sessions within the session of the external flow.
- In Blueriq 16 (prior to 16.10), the host and the target runtimes must be the exact same Blueriq version (major, minor, patch and Java version). From Blueriq 17 onwards, we aim for external flows to always be compatible with the previous major release of Blueriq.
- AQ_StartProject cannot be used and is not supported. It will certainly not work with different tabs when executed on different servers.
- The development tools functionality is limited, reloading projects at different url's does not work
- External flows only work correctly when using V2 of the frontend API (UI REST API V2)
- DCM 2.0 in combination with external flows is not supported
- Using external flows leads to more sessions on the Runtime backend and thus more memory usage. This should be taken into account when assigning resources to the server