Polling and change detection

Patterns 1 · 3:45

The ERP reports no changes, so every poll fetches all customers, and the video shows how to find out which of them changed. Weik.io's entity store lets only the new and changed ones reach the CRM. The video assumes you know the Camel track.

Download the mp4Recorded on 2026.2

What it covers

Two route files in one folder, a timed poll and a send route
The send route, which waits on the store for records created or updated
The entity type customer, created with weikio entitystore policy set, and one entity per customer
A first poll that creates twenty customers and a second that sends nothing
One changed phone number reaching the CRM as one update
Reading revisions back with the weikio CLI and on the admin UI's Entity store page

Commands in this video

Terminal

$ weikio entitystore policy set sandbox/customer --env devtest
$ weikio run ./customer-sync
$ weikio entities list sandbox/customer
$ weikio entities get sandbox/customer C-1007 --revisions

Transcript

0:01A source system that reports no changes forces every read to take everything.
0:07This video shows an integration that sends only the changes.
0:15An integration in devtest copies customers from an ERP service to a CRM.
0:21It asks the ERP, and gets all twenty back.
0:25The entity store keeps the newest copy of every customer.
0:29Whatever comes back out of the store goes on to the CRM.
0:36The customer-sync folder holds two route files, starting with the poll route.
0:41Each run calls the ERP's customers address on a timer, once a minute.
0:46Each of the twenty goes into the store as the type customer.
0:50The second file holds the send route to the CRM.
0:53It waits on the store instead of the ERP,
0:56for customers whose record was created or updated.
1:02First,
1:03declare the type with weikio entitystore policy set sandbox/customer for devtest.
1:11The declaration creates the type's store inside the environment's budget.
1:15Then weikio run, the customer-sync folder.
1:19The files go up, the version builds, then the deployment starts.
1:23The hub keeps the integration at version 0.1.0.
1:31The deployment runs as a Java process on agent dev.
1:35The first poll reads all twenty and puts each into the store.
1:39All twenty are new, so all come back out as created, to the CRM.
1:48A minute later the poll reads all twenty again.
1:51The store takes every copy and skips the ones that change nothing,
1:55so no send line prints.
2:00The ERP gives one customer a new phone number.
2:06The next poll reads and puts all twenty again.
2:09This time the store finds one real change,
2:12and the send route posts that one customer as an update.
2:18Control C stops the following, the integration stays deployed and keeps running.
2:27In the Weik.io CLI, weikio entities list sandbox/customer prints what the store holds,
2:35one row later than the rest.
2:39weikio entities get reads that customer back with its revisions.
2:44The update prints above the creation.
2:47The store keeps two revisions of each record.
2:54The admin UI's Entity store page lists the declared types.
2:59The type's page lists all twenty customers in devtest.
3:03The Changes section marks the one update among the puts.
3:08Opening the changed customer shows its newest data and the revisions behind it.
3:16The integration is two routes: one reads everything,
3:20the other answers with the changes.
3:22The entity store between them keeps each customer's newest
3:26copy and lets only real changes through.
3:29The source needs no change detection, since the timer reads all of it.
3:34The destination receives only the customers that changed.

Next in this track

Patterns 2 · 3:04 Sending data to several destinations