Application Server Transient Data

Temporary data. A Neptune DXP application could store information for subsequent processing. For example, when there is insufficient stock on an eCommerce web-store, you may still wish to capture customer orders to fulfil them once availability improves. Similarly, you can temporarily hold large transactions loads or logs, for example, POS retail transactions, for batch processing rather than overwhelm your backend with synchronous updates.

Session data is typically stored in the user’s device or browser cache as HTTP cookies. However, cookie data can be tampered with on the client’s side and should be validated before deemed as trusted. Furthermore, cookie data are transmitted with each API request increases the payload size introducing latency. Instead, you can propagate session data to a Neptune DXP table and use the record ID created as the session ID stored in the cookie with no other data held in the client:

Error logs. You can use a Neptune DXP table as a sink for runtime errors to allow you to evaluate them and act on them. For example, your script code may capture and record internal script or API response errors. A periodic Neptune DXP job can then execute a script to evaluate the errors and if necessary, generate alerts to a support function.

Configuration options/preferences that control a Neptune DXP’s application appearance and behaviour need to be persisted for access before a new user session. Holding such data in the device will reset the user’s experience when they clear their cache or switch devices. Instead, you can propagate the data in a Neptune DXP table in the application server allowing you to recall it across sessions and devices.

Workflows. Neptune DXP workflows record their own state but when you need to persist additional data specific to your use case you can use Neptune DXP tables.