Blueriq Session management

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

...

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

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

In Application X "Session A-1" is a nested child session of "Session A" due to the nature of how AQ_Dashboard_Widgets Widgets work.

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

Session cleanup

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

AQ_Dashboard_

...

Widget

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

External Flow

In "Application Y" the External Flow is used to start "Session B" from "Session A", there . There is a reference from "Session A" to "Session B," but it is not tightly coupled as for is the sessions case in "Application X". The sessions in "Application Y" should be managed as seperate separate 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 works, we need to know how the usual Session Lifecycle work.

...

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

Session expiration

Session can expired Sessions can expire after a set duration once the user becomes has been inactive, or closes when the user closed the application without notifying the Runtime.

The Application Server and the Runtime have a Session Timer inplace which checks if in place that checks whether a session has become expired due to inactivity, once . 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 Runtimes and therefor the session lifecycle can be distributed over one or more RuntimeRuntimes. 

Just like The initial part of the External Flow Lifecycle is the same as the traditional Session Lifecycle, an application is started and a HTTP session and a Blueriq session is created, afterwards are created for the application on the blue Runtime. The blue Runtime will initialize 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, sending along its session id. The session id of the blue Runtime is used by the green Runtime to create a weak reference to the blue Runtime when creating the External Flow Session. This weak reference is required for when sessions are not cleaned up properly. The External Flow is started in the green Runtime and a new HTTP session and Blueriq session are created with a reference to the blue Runtime session.

Once the External Flow has ended, the blue Runtime will be notified and continues the application. At this point, the External Flow resources can be disposed on the green Runtime, ending the External Flow Lifecycle. 

External Flow Session expiration

External sessions are created when different Runtimes start an external flow on the current runtime. The external sessions are closed when the HTTP session has expired. When the user logs out from the host project or the host session simply expires, the external session has no knowledge of that and will remain open, even if not used.

Image Added

Both Runtimes have a Session Timer which checks whether the session is expired. The External Flow Session has an additional responsibility of notifying that the session has been closed. By doing so, other External Flow Sessions can be notified that the parent session has been closed and no further actions should be performed.

Image Added

To mitigate the problem that sessions exist when no actions can actually be performed on the session, a mechanism was introduced that stores information about the host session, and the target runtime will check for all of its host sessions if any of them are closed or are still opened. Every time it finds one that was closed, then it will also close the external sessions that were created by that host session.

Session Timeout

Sessions will expire once there are no interactions between the user and the session. For external sessions to work smoothly, without running into unexpected 'Session Expired' problems, the session timeout on the External Flow Runtime should at least have the same time-to-live as the Host Runtime. When the session timeout is shorter on the External Flow Runtime, it is likely that you will run into 'Session Expired' errors.

Configuration

Session timeout can be configured by configuring the following properties, when no configuration is provided the default will be set to 30 minutes.

 server.servlet.session.timeout=30m