...

The External Flow Session Lifecycle is different than usual sessions, de deviation occurs in the parent child relation of session when created by a AQ_StartProject, or the AQ_Dashboard_Widgets. These services and containers start a session as a child session of the main session.

In the image above we have two different styles of Session management: 

• Application X uses a AQ_Dashboard_Widget
• Application Y uses a External Flow

In Application X can see the same Runtime with two applications. "Application X" uses on of the AQ_Dashboard_Widgets to start the child session "Session A-1" in the session is a nested child session of "Session A". "Application Y" on the other hand uses the External Flow to start a new root session "Session B" from the session "Session A" due to the nature of how AQ_Dashboard_Widgets work.

In Application Y we have two Runtimes A and B, "Session A" starts and External flow on Runtime B creating "Session B". The image depicts that"Session B" is a child of "Session A" however there are only linked together by a reference. This difference is crusial in how the sessions are managed.

...

The session cleanup for Application X and Y differ from eachother as they both use different techniques to create and management sessions.

AQ_

...

Dashboard_Widgets

The AQ_StartProject, and AQThe AQ_Dashboard_Widgets all create a nested session in the current session, when looking at "Application X" this noticeable as "Session A-1" is a child session of "Session A". Direct nested sessions are cleaned up when the its parent session is closed or removed. For External Flow session this is not directly the case. 

...

In "Application Y" the External Flow is used to start "Session B" from "Session A", there is a reference from "Session A" to "Session B" but it is not tightly coupled as for the sessions in "Application X". The sessions in "Application Y" should be managed as seperate sessions and therefore must be disposed of individually. Runtime A is not able to dispose of sessions on a different Runtime, even if the External Flow is configured on the same Runtime. 

Session Lifecycle

In order to understand how External Flow Session Lifecycle work we need to know how the usual Session Lifecycle work.

Image Added

In a typical flow a user start the application and it gains a HTTP session and a Blueriq session, the applications is displayed and the user will perform its task. Once the user is done the application is closed and the Blueriq session including its child sessions are closed, afterwards the HTTP session is closed and everything is disposed of. This is the flow where users close their application and Blueriq is notified of the closure, so it can dispose of the user's resources. 

Session expiration

Session can expired once the user becomes inactive, or closes the application without notifying the Runtime.

Image Added

The Application and the Runtime have a Session Timer inplace which checks if a session has become expired due to inactivity, once a session has become inactive the usual session lifecycle kicks in and will dispose of the user's resources. 

External Flow Session Lifecycle

External Flow can be run on different Runtime servers and therefor the session lifecycle can be distributed over one or more Runtime. 

Image Added

Just like the traditional Session Lifecycle an application is started and a HTTP session and Blueriq session is created, afterwards the External Flow is initialised on the main Runtime so it keeps a weak link to the External Flow. A new External Flow Session is started on the other Runtime that includes an HTTP session and a Blueriq session. Once the External Flow is closed or ended a notification is send to main Runtime that the External is completed,