Skip to content

Pricer Server

Type: On-premises / customer-hosted gateway (not a Cloud Run service) CQS queue name: pricer-server

Pricer Server (PS) is the hardware gateway that manages the in-store RF/IR network and drives the physical ESL devices. It is not a Cloud Run service — it runs on-premises or is hosted by the customer. Despite being outside the cloud platform, PS is a first-class DTOflow participant: it owns several DTOs, consumes others directly from CQS, and is the terminal delivery step in the display-update pipeline.

PS replaces the former dtoflow-transmission intermediary. PS now subscribes to eslimage.v1 (and related DTOs) directly from CQS, fetches images from LFS, applies rotation, and pushes them to the physical hardware. No bridge service sits between DTOflow and PS.

DTO Ownership

DTO Description
storeeslstatus.v1 ESL lifecycle state. PS is the sole writer: it maintains an internal per-ESL state DB derived from RF/IR communications and PUTs storeeslstatus whenever a relevant transition occurs (see "Status write triggers" below). Per ADR-006.
itemproperties.v1 Item property schema per store — describes which item fields are available and their types
itemprocessingparameters.v1 Item processing configuration per store — controls how item data is transformed before rendering
eccmodel.v1 ECC hardware model definitions
eccfont.v1 ECC font resources
eccparameters.v1 ECC rendering parameters per store
ecceslimage.v1 ECC-rendered ESL images
eccimage.v1 ECC image assets

CQS Subscriptions

DTO Version What PS does on change
eslimage v1 Receive the rendered image: fetch the paired storeesl and esldriver, read the image bytes from LFS, apply esldriver.rendering.displayRotation combined with eslimage.rotation, and transmit to the target ESL device over RF/IR.
storeesl v1 On create/update: register the ESL device in the internal DB; apply any pending image for that barcode. On delete: unregister the device and delete the corresponding storeeslstatus DTO (final step of the deletion cascade — see link-registry.md).

The authoritative queue/DTO mapping is in poc-changequeue-service/src/main/resources/application.yml under the pricer-server queue block.

Status write triggers

PS owns the real-life side-effect — communicating with the physical ESL hardware over RF/IR — and maintains its own internal database of per-ESL operational state (current state, battery, last ACK, roaming sweeps, firmware, etc.). The storeeslstatus DTO is the public projection of that internal state into DTOflow.

PS PUTs storeeslstatus when a relevant transition occurs in its internal state, including:

  • Onboarding events: entering ONBOARDING, transitioning to ONBOARDING_PENDING on timeout, or to OK on successful handshake.
  • Image delivery events: entering UPDATING when an image/flash is queued; back to OK on ACK; to ROAMING on timeout.
  • Roaming recovery / loss: ROAMING → OK on device response; ROAMING/*_PENDING → LOST after the 30-day auto-reset threshold (firmware factory-reset).
  • Offboarding: OFFBOARDING, OFFBOARDING_PENDING, terminal OFFBOARDED.
  • Operational telemetry changes: battery level transitions, firmware/hardware property updates, IR roaming diagnostics — written alongside the state field even when the state itself does not change.

Delete rule. PS deletes a storeeslstatus DTO only when the parent storeesl is deleted. The deletion cascade is:

  1. PS writes storeeslstatus.state = LOST or OFFBOARDED.
  2. link-registry observes the terminal state and deletes the storeesl.
  3. PS observes the storeesl deletion (via its storeesl CQS subscription) and deletes the storeeslstatus it wrote.

PS never deletes storeeslstatus on its own initiative; the parent storeesl deletion is the sole trigger. This keeps the status visible to consumers throughout the terminal-cleanup window.

Role in the platform

PS is the final step in the end-to-end display-update pipeline. A rendered image flows: producing renderer → LFS + eslimage.v1 (via eslimage-merger) → CQS notification → PS reads eslimage, fetches storeesl + esldriver, reads bytes from LFS, applies rotation, transmits to hardware.

PS also feeds data back into the platform via storeeslstatus.v1 and the ECC-side DTOs (eccmodel, eccfont, eccparameters, ecceslimage, eccimage) for legacy ECC rendering deployments.

Migration history

During the link.v1 → link.v2 migration (ADR-003), PS also read link.v1 and storeitemvalues.v1 directly to obtain rendering instructions and item data. Those reads are transitional and will retire once the migration completes. The former dtoflow-transmission bridge service has been removed; PS now consumes eslimage and storeesl from CQS natively.