Web Application
The Datalogic Connect web application is the browser console that operators use to watch and manage the device fleet of their organization. Every screen is a view over the Datalogic Connect cloud services: the web application reads through the REST API, writes through the REST API, and the cloud services carry the result to the stores through the IoT Edge Gateway. This page describes what the operator sees and what happens behind each screen. The click-by-click procedures live in the Web Application tutorials.
Request Path
The browser never calls the REST API directly. It talks to the web application, which calls the REST API on the operator's behalf with the credentials of the signed-in session. Each request is scoped to the operator's current organization, and the cloud services further limit the answer to the location assigned to the operator's role. The operator therefore only sees the devices, groups, configurations, users and actions that belong to the organization and location they were given access to.
List screens (devices, groups, configurations, actions, users, licenses, RMAs) work the same way: the filters, sort order and page number chosen in the browser become query parameters of one REST API call, and the response is one page of results with the total count. Changing a filter repeats the call. For the components behind the REST API, see Architecture.
Sign-In and Session
The operator opens the welcome screen and clicks Login. The web application hands the browser over to the identity provider, where the operator enters the credentials, and receives the signed-in identity back. The web application then asks the REST API for the operator's profile: the organizations the operator belongs to, and for each one the role and the location it applies to. The first organization becomes the current one, unless the operator saved a different choice earlier, and the browser lands on the Home Page.
The diagram shows the exchange between the browser, the web application, the identity provider and the REST API during sign-in.
The session lives in an encrypted cookie in the browser. While the operator keeps using the console, the web application renews the credentials automatically; when they can no longer be renewed, the operator must sign in again. Logout ends the session and returns to the welcome screen. See Authentication / Login.
The User button in the top right corner opens a menu that shows the operator's email, role, location, current organization and time zone. From the same menu the operator can:
- Switch organization: the choice is saved in the operator's preferences on the cloud services and every following request is scoped to the new organization.
- Change time zone: also saved in the preferences; the console then renders every date and time, including action schedules, in that zone.
Navigation Map
The navigation bar is the same on every screen. The table lists its entries and the tutorial that describes each one.
| Entry | Contents |
|---|---|
| Device visibility | Drop-down menu with Device List, Device Groups and Device RMAs |
| Configurations | The configuration files and firmware stored for the organization, see Configurations Page |
| Actions | Performed, scheduled and saved actions on device groups, see Actions |
| Settings | Organization, licenses, locations, users and roles, see Settings |
| Help | Opens this documentation site in a new tab |
| User | Session menu: switch organization, change time zone, logout |
The Home Page repeats the main areas as cards. Screens that depend on a license feature or on the operator's role appear only when the cloud services confirm the entitlement: the web application asks before rendering the entry, so a Viewer does not see the buttons that create or change data.
Device List and Device Details
Opening Device List triggers a set of REST API reads in parallel: the page of devices that match the current filters, the number of devices waiting for approval, the device family tree with the total and online count per family, and the location tree of the organization. The family list on the left and the Location filter are built from the last two, and clicking either one narrows the device query. Column visibility, page size and the location widget are saved as operator preferences, so the list reopens the way it was left.
Clicking a device opens the Device page. The web application reads the device record and, from it, decides which tabs to show: Overview, Commands and Connected Devices are always present; Battery appears when the device reports a battery; Services is hidden for host and IoT Edge devices; Remote Control and Location Tracking appear when the operator is an Admin or Operator and the license attached to the device includes the feature. Each tab is its own read: the device properties and telemetry, the commands already sent, the child devices, the RMAs for that serial number. See Device Page.
Adding a device is one write that returns the created record, including its status. Devices that enroll on their own appear as To be approved until an Admin or Operator approves them, one by one or all at once with a location, family and license; the Device List shows how many are waiting. For the statuses, see Device List.
Device Groups
A device group is stored on the cloud services as a name, an optional description, a location, a device family and a filter query. When the operator clicks Run query in the group form, the web application sends the query to the REST API and shows the devices that match; nothing is saved until Save. Membership is evaluated by the cloud services whenever the group is read, so a device that later matches the filter joins the group without any edit.
Selecting a group in the list on the left performs two reads: the group itself and the page of devices that currently belong to it. The Actions button on a group opens the action wizard with that group already selected. For the concept, see Device Groups; for the screen, see Device Groups.
Commands
The Commands tab first asks the REST API which commands the selected device can execute, and the license credit each one costs; that list is what the operator sees as buttons. Confirming a command is a single write. The REST API answers at once with the command record in status CREATED, and the web application adds it to the COMMANDS PERFORMED box.
From there the command travels without the browser: the cloud services deliver it to the store through the IoT Edge Gateway, which passes it to the device, or to the POS running AladdinSDS for USB devices. As the command moves through PENDING, IN_PROGRESS and finally COMPLETED or FAILED, the cloud services publish each status change and the web application updates the box (see Live Updates). A command that returns a file, such as Get Logs, stores the response on the cloud services; View response asks the REST API for a short-lived download link.
The diagram shows one command from confirmation to the status change that closes it.
Actions and Scheduled Actions
An action is a command sent to a device group. The wizard has three steps, Configure, Schedule and Review, and nothing reaches the cloud services until the last one. Run and Save both create one scheduled action record; Save marks it as a draft, which is what the Saved list shows. The schedule type decides the rest: IMMEDIATELY runs once now, ONE_TIME runs once at the start date, DAILY, WEEKLY and MONTHLY repeat until the end date.
Every run produces an action: one command per device in the group, plus progress counters (total, completed, failed, pending, in progress) that the cloud services keep as the commands finish. The Performed list is the list of these runs; opening one shows the counters and the per-device command table, which is the report the operator reviews after a run. The Scheduled list shows the recurring records, each with its own run history and an enable/disable switch that is a single update on the cloud services.
The diagram shows how the wizard result becomes a performed, scheduled or saved action.
For the concept, see Actions; for the screen, see Actions.
Configurations
The Configurations page reads three things: the page of stored files, the list of configuration types for the filter on the left, and the file extensions the cloud services accept, which the upload form uses to reject other files before sending anything.
An upload is a three-step exchange, so the file itself never passes through the web application:
- The browser asks the REST API for a temporary upload address for the file name and size.
- The browser sends the file straight to the cloud storage at that address.
- The browser notifies the REST API that the upload is complete, with the name, device family and description; the REST API creates the configuration record and returns it.
Download works in the opposite direction: the web application asks for a short-lived link and the browser fetches the file from the storage. Editing changes only the record (name, family, description); deleting removes both. See Configurations Page and Upload a new configuration.
Settings
Settings opens on the first entry the operator is allowed to see. Organizations is shown to Admins and Operators only; the other entries are visible to every role, and the buttons that change data are hidden from Viewers.
| Entry | What the web application reads and writes |
|---|---|
| Organizations | The organization record: name, owner, organization ID and the enrollment keys that devices and the IoT Edge Gateway use, see Organizations |
| Licenses | The licenses of the organization with seats, credits and the commands each license type allows, see Licenses and Licenses |
| Locations | The location tree; creating, renaming, moving or deleting a location, see Locations |
| Users & Roles | The users of the organization with role and location; creating, editing and deleting them, see Users & Roles |
| Rules | The device approval rules of the organization, shown as a tree that follows the locations |
Every entry is filtered by the operator's location: a user assigned to a store sees the data of that store and its sub-locations, not the whole organization. See Overview.
Live Updates
Once signed in, the web application opens one persistent notification stream to the cloud services for the current organization and the operator's location. The cloud services push an event on the stream every time a command or an action changes status. The screens that show such data subscribe to the events they care about: the COMMANDS PERFORMED box on the Device page, the counters and command table of a performed action, and the scheduled action details. This is why a command sent from the console updates without a page refresh, and why an action launched by a colleague at the same location appears as it progresses.
The stream carries status changes only; the record that was changed is then re-read through the REST API in the usual way. If the stream drops, the browser reconnects on its own.
Every call described on this page is documented in the Datalogic Connect REST API reference, which is the same interface available for integrations.