RIO Grande · Real-time store data trickle and ETL

Capture any store data. Trickle it in real time. Deliver it anywhere.

RIO Grande is the next generation of RIO, REDList's real-time trickle feed for store data. Store-side collectors capture the transaction log (TLOG), EPS log entries, tax tables and other POS files as they are written and trickle them to the host. There, a pluggable transformation and output engine turns that data into whatever each enterprise system needs: POSLog on a message queue, rows in a database or data warehouse, or the raw file delivered as-is.

RIO has carried store data for retailers since about 2010. Since 2019 it has run in production at a Tier 1 grocer with thousands of stores on Toshiba ACE. RIO Grande, a Rust rewrite of the trickle server, takes that same design forward to ELERA and to whatever POS comes next.

Start the conversation See the timeline
TLOG + EPSLOG + tax tables + POS files Pluggable transforms Kafka · ActiveMQ · WebSphere MQ Databases + warehouses In production since 2019 Rust trickle server ELERA POSLog: prototype, target Q1 2027
  1. CaptureTLOG, EPS log and other store files at the POS controller
  2. TrickleQueued at the store and sent to the host in real time
  3. TransformPluggable: POSLog, database rows, JSON, or untouched
  4. DeliverMessage queues, databases and warehouses, raw file delivery
~2010RIO released, piloted on an AS/400 (now iSeries) host
Any store dataTLOG, EPS log, tax tables and on-demand POS file captures in one trickle
Since 2019In production at a Tier 1 grocer with thousands of stores
Up to 15×Faster POSLog transform in Rust vs. Java, with identical output (measured)

One pipeline, many destinations

Store data in, the format each system needs out.

RIO Grande separates what is captured at the store from what is delivered at the host. Add a collector to capture new store data; add a transform or output to feed a new system. Nothing else has to change.

Capture any store data

More than the TLOG. On Toshiba ACE controllers, RIO's store-side collectors trickle:

  • TLOG: every transaction as it is written
  • EPS log: RIOETQCL trickles daily ACE EPS log entries through the non-TLOG queue
  • Other POS files: RIONTQCL captures keyed and direct files on the POS system on demand and adds them to the trickle
  • Tax tables: RIOTAXCL captures the store’s tax tables (a special format) and includes them in the trickle

Transform with pluggable engines

On the host, transforms plug in per destination. Examples of what has been built:

  • TLOG to ARTS POSLog 2.2.1 XML or JSON
  • TLOG transformed and loaded into an ARTS database or a data warehouse
  • No transform at all: the raw TLOG, exactly as written

Deliver anywhere

Outputs plug in the same way, so one feed can serve several systems at once.

  • Messaging: Kafka, ActiveMQ / JMS, WebSphere MQ; for example, tax table data processed on the host and published to Kafka for listeners
  • Databases and data warehouses
  • Raw file delivery to a host system, for example so a retailer's loss prevention system can process the TLOG directly

History

Built for multi-vendor store data from the start.

RIO was designed so that the part that talks to a POS is small and replaceable, and everything downstream stays the same.

Store collection

RIO first collected TLOG data from IBM 4690 Supermarket Application (SA) stores, with an AS/400 (now iSeries) host for the pilot. A store-side Windows service added non-IBM POS: NCR ACS stores from 2010 and Retalix StoreLine from 2012.

  • Pluggable collector and transmit-queue design
  • One RIO host protocol carries IBM, NCR and StoreLine data

Template-driven parsing

Parsers are selected through a registry of parser templates, so each POS format is its own module. Parsers exist for IBM SA, IBM/Toshiba ACE and Retalix TLOGs.

  • Normalized to the ARTS 6.1 data model
  • ARTS POSLog 2.2.1 output

Enterprise outputs

The normalized transaction feeds whatever the enterprise uses downstream.

  • Kafka
  • JMS / ActiveMQ
  • ARTS POSLog XML and JSON
  • ARTS relational database

Any POS

Only the adapter changes. The engine decides where the data goes.

A new kind of store data or a new POS needs only a new collector or adapter at the edge. A new destination needs only a new transform or output on the host. The systems that consume store data do not have to change when the stores do.

Status varies: TLOG, EPS log, tax table and on-demand captures run on Toshiba ACE / IBM 4690 controllers; ELERA is a working prototype; NCR ACS and Retalix StoreLine support is store-side collection and transport to the RIO host. Other POS platforms need a new adapter. Outputs and transforms shown are examples of implementations built for different deployments.

The Rust progression

RIO Grande: the trickle server, rewritten in Rust.

RIO Grande rewrites the RIO trickle server in Rust. On 30 days of production TLOGs from a representative store, its POSLog output matched the current Java output 100%, and the transform ran up to 15× faster.

  • Faster: 1.157 ms → 0.077 ms mean POSLog transform per transaction; p99 19× lower.
  • Leaner: no JVM, garbage collector or JIT warm-up; a 14 MiB binary vs. a 132 MiB JAR.
  • Lower cloud cost: more work per instance means fewer instances at peak and less autoscaling. Actual savings depend on each deployment; an equal-resource pilot sets the real number.
  • Pluggable: the same design carries forward: outputs (Kafka, ActiveMQ) and the POSLog transformer plug in. The parser reads IBM 4690 / Toshiba ACE TLOGs today; other formats are future extensions.
Measured: Java vs. Rust POSLog transform
MetricJavaRust
Mean per transaction1.157 ms0.077 ms
p99 latency6.04 ms0.31 ms
Serial transform rate864/s13,038/s
Output match vs. Java—100%
App artifact132 MiB14 MiB

Transform benchmark on 30 days of production TLOGs (281,316 records in, 108,731 POSLogs out). End-to-end gains (intake, database lookups, publishing) have not yet been benchmarked.

Direction · The path to ELERA

As stores move from ACE to ELERA, RIO Grande moves with them.

This is where RIO Grande is heading. It describes work in progress, not delivered features.

Working prototype · target end of Q1 2027

POSLog generator for ELERA

The POSLog ETL produces the same POSLog store data feed from ELERA transactions. ELERA does not keep a department number, so it uses the store's ACE department numbers to keep reporting consistent.

Direction

ACE and ELERA side by side

During the migration, ACE stores and ELERA stores feed the same pipeline. Stores convert one by one with no big bang, and reporting continues throughout.

Direction

A POS-neutral pipeline afterwards

After the migration, RIO Grande can stay as the POS-neutral store data pipeline for ELERA, NCR or any next-generation POS, even as its ACE TLOG collection role fades.

Related: ACE-to-ELERA Bridge · ELERA Portfolio · TLOGic

Timeline

From the first trickle feed to any POS, any destination.

  1. ~2010RIO releasedPiloted on an AS/400 (now iSeries) host, collecting IBM 4690 SA TLOGs; NCR ACS store collection from 2010.
  2. 2012Retalix StoreLineStoreLine XML TLOG feed added to the store-side service.
  3. 2019Tier 1 productionIn production at a Tier 1 grocer with thousands of stores on Toshiba ACE.
  4. RustRIO GrandeTrickle server rewritten in Rust: up to 15× faster transform, identical output.
  5. Q1 2027 targetELERA POSLogPOSLog ETL for ELERA, working prototype today.
  6. NextAny POSThe same store data pipeline for ELERA, NCR or any next-gen POS, delivering anywhere.

Planning a move from ACE to ELERA?

Talk with REDList about capturing more of your store data, delivering it to the systems that need it, and keeping the feed running through the migration.

Start the conversation Email sales