FME Server Notification Service allows monitoring of external systems and triggering actions in response to events. Notifications can be used to briefly communicate an event but not transmit large amounts of data continuously. Workflows can poll data on a schedule, use database triggers or webhooks to push data in real-time, or update data using FME writers, SQL executer, or HTTP caller. Choosing between polling, pushing, or updating depends on factors like simplicity, ability of the external system to push data, and job processing times.

1. Ultimate Real-Time
Monitor Anything,
Update Anything

2. FME Server Notification Service lets you
act on events as they happen, and send
information as it becomes available.
Publications and Subscriptions let you
publish to and monitor different systems
and data.

3. Notifications
What they are for What they are not for

4. Notifications
What they are for
• A brief message, usually to
trigger an action.
What they are not for
• Transmitting large amounts of
spatial data.

5. Notifications
What they are for
• A brief message, usually to
trigger an action.
• Triggering an FME Server
response to an event that
happened outside of FME.
What they are not for
• Transmitting large amounts of
spatial data.
• Triggering an FME Server
response to a continuous
series of messages (many
per second).

6. Notifications
What they are for
• A brief message, usually to
trigger an action.
• Triggering an FME Server
response to an event that
happened outside of FME.
• Sending a message about
something that happened in
FME.
What they are not for
• Transmitting large amounts of
spatial data.
• Triggering an FME Server
response to a continuous
series of messages (many
per second).
• Sending more than one
message per second about
what’s happening in FME.

7. FME Server Notification Service
See the list of what built-in publications and subscribers can be: http://fme.ly/protocols

8. Workflows for
“Ultimate Real-Time”
Poll it Push it Update it

9. Poll it
“Are we there yet?”

10. Polling Workflow
1. Change detection
○ GeoRSS reader
○ Caching
○ Timestamps
1. Run the workspace on a schedule
Timestamp

11. Scheduling (FME Server)

12. GeoRSS Reader

13. GeoRSS
Reader
●Contains change
detection logic
●Option to only read
new features

14. Caching
●Whole datasets or
timestamps
●ChangeDetector
●SQL - match on ID

15. ChangeDetector Example

16. SQL to find different features:
@Value(uuid) = "uuid" AND @Value(aqi) != "aqi"
SQL Example

17. Timestamps
● Cache the timestamp
● Last updated attribute
● Filter features newer
than timestamp
● Add a timestamp
attributes to your dataset

18. Reads last cached time and replaces
with current time

19. Checks against timestamp and
filters out old features

20. Pros and Cons
Caching whole datasets
• Easy to set up and
detect changes.
• Need to store entire
dataset - processing
time?
Caching timestamps
• No storage needed.
• Harder to set up -
variables, datetimes.
Consider: Does my dataset have a timestamp? Can I rely on the timestamp to indicate change?

22. Workflows for
“Ultimate Real-Time”
Poll it Push it Update it

23. Push It

24. Pushing Methods
●Database triggers
●Webhooks
In FME Server:
●Direct URL
●REST API

25. Database
Triggers
● Databases can trigger
events.
● Functions with HTTP
requests can push data
to FME Server.

26. Database Triggers

27. Webhooks
● i.e. Give systems/services
a URL that will respond.
● Send the notification to
FME Server.
● Queue the received
notifications and process
the requests on a
separate thread.

28. Pros and Cons
Database Triggers
• Pushes right to FME
Server topic.
• Can push lots of
changes to a holding
table.
• Perfect for real-time
database changes.
• Database permissions.
Webhooks
• No need to waste effort
polling.
• Truly real time.
• Complex to set up.
• Not all systems provide
or accept webhooks.

29. Direct URL
Systems can use HTTP to
push data to topics or
trigger workspaces to run.

31. Topic POST URL

32. REST API
In-depth interaction
with FME Server
● Send/receive notifications
● Run jobs
● Manage connections
● Manage users
● Licensing
● Backups
● Scheduling
● Etc!

33. Workflows for
“Ultimate Real-Time”
Poll it Push it Update it

34. To Poll or Push?

35. Poll vs. Push Considerations
● Simplicity vs. “real-time”ness
● Can the system push to FME Server?
● Are jobs too long for polling?
● API restrictions for polling?

36. Tip: Use FME Server for
internal systems and FME Cloud
for external systems.

37. Update It

38. Updating Methods
• FME Writers
• Bulk drop/load/overwrite
• Update option
• SQLExecuter
• HTTPCaller

39. FME Writers: UPDATE operation

40. INSERT, UPDATE or
DELETE in the middle
of a workflow.

41. POST data or changes
to systems.

42. XML Data
Feeds
REST API
Data Access

44. Summary
• Polling workflow:
• Change detection + scheduling
• Pushing options:
• Database triggers, webhooks
• FME Server: URL or REST API
• Updating:
• Operations in writer parameters
• SQLExecutor
• HTTPCaller

45. Questions?
Database triggers tutorial:
fme.ly/dbtriggers
Webhooks etc:
fme.ly/web
REST API documentation:
fme.ly/restv3