In the ribbon menu Administration/Data context a 'Session information' button is added in the context of selected views. This button is used to trigger the custom action event XF_SESSION_DETAILS 'on order'.

However, it can also be triggered automatically by other events (e.g. 'Client logged in', see Login (Events)) or within a workflow via the Dispatch action event.

An example of formatted output of specific data from the 'Session information' object is shown below on the right. Displayed here are:

• CLIENT: Client type

• BROWSER: Type and version of the browser used

• SITE: URL used to log in the session

• SESSION: Internal identifiers for the session

• STARTED: Registration date

• USER: User name and ID of the applicable user account

• ROLE: Role name and ID of the applicable role

• COMPANY: 'Name 1' from the address of the applicable company

►NOTE◄ USER, ROLE and COMPANY may differ from the actual session within a workflow if a temporarily different login context is defined via the Run as event action.

A Custom action event XF_SESSION_DETAILS is created and assigned as a Triggering event to the event handler shown on the right.

The Validating rule is intended to ensure that the 'Session Details' display is only executed when a 'full' user (and not, for example, a guest user) is logged in.

The message should also not appear if, within a guest user session, the XF_SESSION_DETAILS event is triggered by a workflow in which the User of session has been temporarily modified by Run as. Therefore, the rule must not refer to the User of session or to the user field in the return value of Session information.

Here, within an Entity property rule rule, an Object property value resolver reads the value to the authHandler key in the map that provides the Session information in the additionalData field. This refers exactly to the full name of the UserAuthenticationHandler class (see static text on the right of the image) if the session goes back to a 'user login'. So the Validating rule will not be passed if there is a 'Guest user login' (via GuestUserAuthenticationHandler) or a 'Portal login' (via PortalAuthenticationHandler).

A Show alert (Popup) event action is configured here as the Action on passed rule:

• The Type 'Alert' has been selected here so that the message is displayed for an indefinite period of time and the user can also acknowledge it by clicking 'OK'. Furthermore, the text displayed in the 'Alert' can be selected if necessary and copied to the clipboard of the operating system. This should be explicitly possible here – e.g. for sending the displayed data in an e-mail to the support team.

• The Title for the 'alert' is provided here by the Triggering event value resolver.

• In the Message, the Session information value resolver returns the 'Session information' object that contains all the data to be output. The structure of the message can therefore be defined quite easily via the Template value resolver. This interprets the core:SessionInformation object provided as input as a 'print object', whose data is prepared here using XPath expressions in conjunction with literal values.

►NOTE◄ In the example, the XPath expression for the value of the 'SITE' illustrates how accessing a value of the additionalData map via XPath (here via the serverURL key) works.

In place of the Template value resolver, a Concat strings could also be used here, which composes field values from the 'Session information' object in steps with static texts via Object property value resolvers. It should be noted that the field names (see also table above) in most cases, but not always completely, match the corresponding element or attribute names in the XML structure of the object. In the example, the XPath expression{@token} would be equivalent to accessing the sessionToken field of the object.