Data Management
Like any application, much of a Skylight application’s logic is focused on capturing user inputs or responding to system events and either modifying a set of underlying business data or changing the state of the application to reflect certain business rules.
When building a Skylight application, you as a developer have access to three different storage mechanisms that you can use read and write data in different situations and at different points of the development lifecycle.
Application data is created at design time and is transferred to the various clients as part of the application definition. It is edited through Application Builder and is perfect for storing configuration information as well as data that may be intrinsic to the application that isn’t coming from outside sources.
At runtime, application data can be accessed via
skylight.application.data.*.Application data is treated as read-only at runtime.
As described before, work sessions (sessions) are a mechanism that allows you to group the events related to a particular body of work. This could be an inspection of a particular piece of machinery, the assembly of a single widget, or a pick of goods for fulfillment of an order. You as the integrator determine what events trigger the start and end of a session so the length of time and scope of data for a session can be completely tailored to your use case.
Like applications, sessions can also store data. Session data, however, is handled much differently than application data:
- Session data is synced and persisted to Skylight’s service layer
- Changes to session data are tracked over time as a series of atomic events that define exactly what data changed, who changed it, and when
- Session data is accessible via the Skylight API (and thus, connected systems of record)
Session data forms the primary channel through which Skylight applications “talk” with external systems. As you design your application, you define bindings and logic that reads and writes to session data. If your use case calls for an integration with an external system, that system populates various sessions with data and then listens for changes to those sessions' data so that it can update its own records.
Example: Automotive Wiring
Let’s examine how sessions might be used in an automotive wiring use case to get data from an integrated system of record and record results. At run time, your application may perform these tasks:
- The user scans a barcode on a work order that contains its ID
- Reacting to this event, your application creates a new session and sets the work order ID in that session
- Seeing the creation of that session, an extension you’ve created goes to an integrated wiring database and retrieves all the wire information for that job and adds it to the session
- Your application responds to the updated session data by updating databound controls and executing event logic
- As the user performs tasks that change the session data, your extension sees those events and can write necessary data back to the wiring database.
Session data is accessible in the client-side script using the
skylight.session.data object after a session has been set using skylight.session.set().Objects and arrays that are retrieved from
skylight.session.data are immutable.Changing the data type of a value in session data or setting a value to
undefined or null is unsupported.Local data is an ephemeral data store that you can use to track data across a single use of your application. It’s helpful for storing temporary information and application state that doesn’t need to make it to the back end and doesn’t need to survive for longer than a single use of the application.
Local data:
- Is stored in memory and is not persisted
- Is wiped out upon re-loading the application
- Is not synced to Skylight’s back end
Local data can be access in client-side scripts using
skylight.local.data and updated using skylight.local.saveData(), similarly to session data.Objects and arrays that are retrieved from
skylight.local.data are immutable.Changing the data type of a value in local data or setting a value to
undefined or null is unsupported.Local data differs from session data in that setting a value for a key on the root data object will overwrite the previous value for that key.
Last modified 2yr ago