dw.system.Session
- A session is created in Digital on the first user click. This is guaranteed even if B2C Commerce caches the HTML pages. It is not guaranteed when the pages are cached by a CDN.
- A session is identified with a unique ID, called the session ID.
- When a session is created, the application server calls the pipeline OnSession-Start. It can be used to pre-initialize the session, before the actual request hits the server.
- Digital uses session stickiness and always routes requests within a single session to the same application server.
- Session data is also stored in a persistent location.
- In case of a fail-over situation, requests are re-routed to another application server, which then loads the session data from the persistent storage.
- There are two session timeouts. A soft timeout occurs 30 minutes after the last request has been made. The soft timeout logs out and clears all privacy data, but it is still possible to use the session ID to reopen the session. A hard timeout renders a session ID invalid after six hours, even if the session is still in use. The hard timeout prevents a session from being reopened. For example, if the session ID is pasted into a URL after the hard timeout, the session doesn't reopen.
- All primitive types (boolean, number, string, Number, String, Boolean, Date) are supported.
- All B2C Commerce value types (Money, Quantity, Decimal, Calendar) are supported.
- Strings are limited to 2000 characters.
- No other types can be stored in a session. In particular, persistent objects, collections, and scripted objects cannot be stored in a session. B2C Commerce will report unsupported values with a deprecation message in the log files. An unsupported value will be stored in the session, but the results are undefined. Since version compatibility mode 19.10 unsupported types will no longer be accepted, and an exception will be thrown.
- There is a 10 KB size limit for the overall serialized session.
null if called for a non-storefront session
(e.g., within a job or within Business Manager). For a storefront
session, the method always returns a customer. The returned customer
may be anonymous if the customer could not be identified via the
customer cookie.When a shopper starts an agent conversation, the shopper's storefront session must be linked to the corresponding session in the paired Salesforce Core org so the agent can act on the shopper's behalf. This method performs that link in-process: given a session init key issued by the Core org, it posts this session to the org's identity bridge, resolving the shopper's credentials, the target endpoint, and the storefront custom domain in-process from the active storefront request and the trust pairing configuration. The storefront cartridge therefore does not need to read those credentials itself or make its own outbound call to the Shopper Agents API, and only supplies the session init key.
This method is only meaningful when a trust pairing (ANC) with a Salesforce Core org has been established and the
shopper is authenticated via Shopper Login and API Access Service (SLAS) hybrid authentication. It does not throw
for expected failure conditions: it returns an error Status when the session cannot be bridged - for
example when the trust pairing is not established, the shopper's session credentials cannot be resolved, or the
bridge endpoint rejects the request - so callers can degrade gracefully. On success it returns an OK status. The
error status carries a code identifying the failure category (for example ANC_NOT_ESTABLISHED,
MISSING_SHOPPER_TOKENS, or BRIDGE_REJECTED); when the bridge endpoint itself rejected
the request the observed HTTP status code is available under the httpStatus detail.
For more details on Hybrid Authentication for hybrid storefronts please refer to: Hybrid Authentication
This is intended for guest authentication with the Shopper Login and API Access Service (SLAS).
This is intended for use with registered session-bridge call of Shopper Login and API Access Service (SLAS).
null if called for a non-storefront session
(e.g., within a job or within Business Manager). For a storefront
session, the method always returns a customer. The returned customer
may be anonymous if the customer could not be identified via the
customer cookie.