Configuring activity-based timeout

Sometimes requests are made to the Transaction server without passing the WC_USERACTIVITY cookie. Some examples of this are REST requests using WCToken, Management Center for HCL Commerce requests, and web service requests. In these cases, since cookie-based timeout cannot be enforced, session timeout must be enabled. Activity-based session configuration is stored in the HCL Commerce configuration file.

Procedure

  1. Open the configuration file.
  2. Find and configure the <ExpiryManagement> element to suit your bussiness requirements. 
    <ExpiryManagement  
		ExpiryMgmtChannelId=”-4, -6” 
		InactivityTimeout="15" Threshold="15"  
	enable="true"/>
    Where:
    ExpiryMgmtChannelId
    Refers to the channel ID (BUSCHN table) where activity timeout is enforced. Multiple values can be specified as demonstrated in the example.
    Accepted values are:
    • -4, used for the following cases:
      • REST requests using WCTokens when the WC_USERACTIVITY cookie is not present.
      • Management Center requests.
      • Web service requests.
    • -6 refers to mobile device requests.
    • -1 refers to web channel requests and REST-based requests. This is not recommended to be used. Cookie-based timeout is recommended for these requests.
    InactivityTimeout
    Used in combination with Threshold, InactiityTimeout defines the minimum amount of time between database updates when extending sessions.

    The last access time is first set in the database when the user logs on. The session remains active within the value of time set by this parameter, in minutes. In the example configuration, this is set to 15 minutes. In this case, any requests that are made to the server within 15 minutes of the activity’s last access time will be considered in session. No updates are made to the last access time.

    Threshold
    If a request comes after the amount of time set by InactivityTimeout but within the period of time defined by this parameter, then the last access time of the activity will be reset to the current time in the database. At this point, the session is kept active and both timers are effectively reset.

    In the example configuration, the threshold time is 15 minutes. Therefore, the activity remains active for 30 (15 + 15) minutes. If a request comes more than 30 minutes after the last access time, then the session is considered expired, and the activity is set to the expired state.

    The combined use of InactivityTimeout and Threshold are used to reduce the number of updates that are made to the database for active sessions. For example, if the total timeout value is desired to be 60 minutes, one option is to keep the InactivityTimeout value as 15 minutes, and the Threshold value as 45 minutes. In this case, any requests that come after 15 minutes but before 60 minutes result in the last access time to be updated to the current time, keeping the session active for at least another 60 minutes.

Results

Activity-based session timeout now applies across the configured channels for your site.