Skip to content
Weik.ioUniversity
Try Weik.io

Polling and change detection

Patterns 1 · 3:37

Because the ERP has no change timestamps, every poll fetches all customers. The hub's entity store lets only the new and changed ones reach the CRM, and 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 entity type customer, created with weikio entitystore policy set, and one entity per customer
  • Leaving out the fetchedAt field so that a fresh read doesn't count as a change
  • 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
  1. 0:01With no change timestamps, each ERP poll reads all customers.
  2. 0:06The CRM should receive only what changed.
  3. 0:13In devtest, one route reads every customer from erp.example on a timer.
  4. 0:20The hub's entity store keeps the last copy of each customer.
  5. 0:24Only customers with a change reach the CRM on the second route.
  6. 0:32The folder holds two route files.
  7. 0:34integration.yaml declares the camel dependencies,
  8. 0:38and the properties file holds the two addresses.
  9. 0:42The poll reads the whole list every minute here, ten minutes in real use.
  10. 0:46The entity type is customer, and each customer is one entity.
  11. 0:52The send route posts new and changed customers to the CRM.
  12. 0:59Before the first run, the Weik.io CLI creates the customer entity type in devtest.
  13. 1:07weikio run publishes and deploys the folder.
  14. 1:14The hub builds 0.1.0 as latest.
  15. 1:18The deployment card shows it running.
  16. 1:20The first poll reads all twenty customers.
  17. 1:23A fresh fetchedAt time changes on every read, so the route drops it.
  18. 1:29Twenty new customers enter the store and reach the CRM as created records.
  19. 1:38The second poll reads the same 20 customers.
  20. 1:41Nothing follows the read line, because each customer matches the stored copy.
  21. 1:46The entity store at the hub does this comparison.
  22. 1:52In the ERP, the customer C-1007 gets a new phone number.
  23. 2:00The third poll reads the 20 customers from the ERP again.
  24. 2:04This time one customer is different, and one send line follows.
  25. 2:09The destination has received 21 posts.
  26. 2:13Control C ends the follow, and the integration keeps running.
  27. 2:21The Weik.io CLI reads the store back twice.
  28. 2:31The entity type customer holds twenty entities, one per customer.
  29. 2:36The second command reads one customer and its revisions.
  30. 2:40The updated row is revision 21, above its created row.
  31. 2:50The admin UI's Entity store page lists the customer type.
  32. 2:55The Entities section lists the same twenty entities with their updated times.
  33. 3:00The Changes section lists each put and the one update.
  34. 3:04The view shows both revisions and the new phone number.
  35. 3:11The two route files in one folder run as one integration.
  36. 3:16The store keeps the last copy of each customer by id.
  37. 3:19Every poll reads all 20 customers from the ERP.
  38. 3:24The CRM has received 21 customers, 20 created and one updated.

Next in this track

Patterns 2 · 3:04 Sending data to several destinations Watched