WEM Session Folder

The Old "Session" in your Data Model

We all have become accustomed to having fields in the Data Model that are not part of a Persistent List - so they are not saved to a database and their values are only available to one specific user in one specific user-session. Also known as temp(orary) fields, or transient fields. Many WEM-users have created a folder "Session" within their projects to store some (or most) of these fields, to make clear what these fields were used for: to store user-selected filter options, logged-in user information, keep track of certain progress in certain processes.

Once a user would close the browser, all these values would be lost and a new session could be started. Also it was not possible to have multiple tabs open for a specific application and share the same data and the same progress over these multiple tabs. You could duplicate an active tab and then have 2 tabs with momentarily the same situation - but as soon as you would change a thing in one tab - it would go on with its own session unaware of the situation in the other tab.

Summary of characteristics for the "old" Session Transient Fields:

• Values for fields only available in one Single Tab (not shareable).

• Same fields may have different values in multiple tabs.

• All values are lost when closing browser.

One situation to consider: when a user closes the browser, and shortly thereafter opens the browser and uses a link from the application, it MAY very well be that the user continues exactly where user left off, INCLUDING transient fields and even unsaved data changes.

HOW?

1. Browsers stay active in the background even when closing all tabs - for user-benefit, easy and fast startup and continue where you left off.

2. Browsers may auto-complete your most recent address, so when typing in the hostname of the application, the browser may autocomplete it including the ?sv=..... value - which is actually specifically asking for that Session Version on the server - if it still exists and has not expired, you will pick up the situation exactly where you closed your browser. You may not even notice this....

But anyway - as this is all to make it more user-friendly from the browsers, it is not a security issue, as it is still linked to your active device-user-browser-session.

It is only a security issue when you leave your device behind unattended and unlocked - that way someone else can start your browser and create mayhem. So secure your own workplace and device first.

You may always choose to add some checks and re-authentication flows if you think it is necessary in your application, and not put all your trust on only the starting point and login flow of your application.

The new WEM Session Folder

With the new Kubernetes environments, WEM Runtime can now support a more powerful WEM Session using the specialized WEM Session Folder. This special Session Folder can be activated from the Project Features page in Project Configuration:

Activating the Session Folder setting will create a specific Session Folder below your Data Model tree:

The fields you put in this Session Folder will behave different from what you may have become accustomed to in the old way.

Once you have activated the Session folder Feature, the Session folder is created - this action cannot be reverted. The setting will disappear from the Project Legacy Features Page. Not to worry - you can (and have to) choose what fields to put in this special Session folder, and only those fields in this folder can be used in the new way.

You can - and will - use most of the Transient Fields in the same way you are accustomed to. You will only put fields in this special Session Folder that may - or should - be used in the more powerful way we will describe in more detail.

New Session Characteristics

• The new Session works more like how a Web Application Session is expected to work.

• Values for Session Fields are available in multiple browser Tabs (shareable).

• A Session Field value changed in one tab will also be changed in the other tabs:

• A Session Field has only one single value at any one time within a user's session in possibly multiple tabs.

• A Session Field's Value only changes "forward" - by getting assigned a new value (or gets cleared).

• Browser's Back Button has no more effect on these Session Fields (forward changes only).

• Values for Session Fields may stay available when user closes the browser - and if the user restarts the application, these values can be picked up again to continue where user left off. Only after the Session Timeout threshold has been reached, the user session will be removed. Only the same user on the same device using the same browser can re-attach to this session (which is also standard Web-Session technology - not WEM-specific).

• Clear Session Node will clear all values in the Session Folder (as well as the other transient fields in the Data Model). This node should be specifically used when you provide a specific Logout flow.

• Obviously - lists within this Session can only be Transient - you will not be able to create Persistent Lists - those can only be part of the Data Model.

Typical use of Session Folder fields

• Use transient collections (Lists) for selected items - like products for a shopping cart - or any selection of items to be handled in a process going forward.

• Use fields that may be shared (as a single value) over multiple tabs for the same user, eg Reference Field to current logged on user (to be cleared at the start of the portal to trigger authentication).

• Use fields for user-selectable portal/application-level settings that can or should be shared over multiple tabs, like Selected Language or Preferred Colors.

• Use fields that need to be carried over across several parts and processes of your application, between which the user can switch using deeplink navigation items.

---

• Keep search and filter fields in the Data Model tree - as user may want to search for different results in different tabs and then add some of those results to the same list that does reside in the Session Folder.

• Keep fields that are used to change how a specific page may be displayed in the Data Model - like fields used to show or hide elements - - unless you are sure about being able to share the same value across multiple tabs or are part of a broader context within the application.

• For most fields and most situations, you will just keep using the "old" way - use transient fields in the Data Model - but these are now limited to the current process and do not carry over onto other features and processes when a Deeplink GET navigation is performed.

• Only when you are sure you need the specific new Session way-of-work, you put those fields specifically in the Session Folder.

  • when using the browser-back-button should not affect the value;

  • value (or collection) should always be the same when shared over multiple tabs;

  • if value is changed in 1 tab, it should also change in the other tab;

  • if value should be available accross all processes and features in your application - even when deeplink navigation is performed.

Session and Navigation

There is a BIG difference in how Navigation (menu items and navigation nodes in flow) works with Session (fields and values) based on the Navigation Action Type. This type can be set on Project Level, using the Legacy Features (same as where the Session Folder can be activated if not available yet).

The Legacy way uses POST-requests, which kept and transferred the session information via that form-post over to the flow behind the navigation item. But this was before we evolved to new techniques and the new Session Folder.

The NEW and default way (in new projects) for navigation of Deeplink-type items uses GET-requests. This way, the current flow STOPS and a new request is made to the server. This approach requires the use of the new Session Folder.

So, Session Folder and Navigate using GET- Requests go hand-in-hand.

Important to understand:

• Transient fields that are outside of the Session Folder, are no longer considered session fields and are NOT transferred over to flows accessed via Deeplink Navigation (in the GET-navigation approach). Their values are limited within a current process until a Deeplink-Navigation is performed.

• ONLY Fields within the Session Folder can be considered real Session Fields, and they will carry over into other processes of features in your application started with a Deeplink Navigation.