Polling and change detection

Patterns 1 · 3:46

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:23Your Weik.io installation keeps the integration at version 0.1.0.
1:33The deployment runs as a Java process on agent dev.
1:36The first poll reads all twenty and puts each into the store.
1:41All twenty are new, so all come back out as created, to the CRM.
1:49A minute later the poll reads all twenty again.
1:52The store takes every copy and skips the ones that change nothing,
1:56so no send line prints.
2:01The ERP gives one customer a new phone number.
2:07The next poll reads and puts all twenty again.
2:10This time the store finds one real change,
2:14and the send route posts that one customer as an update.
2:19Control C stops the following, the integration stays deployed and keeps running.
2:28In the Weik.io CLI, weikio entities list sandbox/customer prints what the store holds,
2:36one row later than the rest.
2:41weikio entities get reads that customer back with its revisions.
2:45The update prints above the creation.
2:48The store keeps two revisions of each record.
2:55The admin UI's Entity store page lists the declared types.
3:00The type's page lists all twenty customers in devtest.
3:05The Changes section marks the one update among the puts.
3:09Opening the changed customer shows its newest data and the revisions behind it.
3:18The integration is two routes: one reads everything,
3:21the other answers with the changes.
3:24The entity store between them keeps each customer's newest
3:27copy and lets only real changes through.
3:31The source needs no change detection, since the timer reads all of it.
3:35The destination receives only the customers that changed.

Next in this track

Patterns 2 · 3:05 Sending data to several destinations