The Township of Langley partnered with Spatial DNA to design and implement FME Server as an enterprise integration platform, enabling the bi-directional exchange of data across all systems. The final solution leverages FME as a message broker to integrate Microsoft Dynamics CRM (call center), billing (Tempest), address validation (Esri), and the work management platform for the third-party contractor who performs delivery and exchange of garbage and compost carts.

1. FME = ESB
@ TOWNSHIP OF
LANGLEY
Jason Isaak – Township of Langley
Todd Lewis – Spatial DNA

2. PRESENTATION AGENDA
1
2
3
FME Integration Concepts
Case Study: Township of Langley
Observations + Lessons Learned
Todd Lewis
Jason Isaak
Jason Isaak

3. FME
Integration Concepts

4. Location-Powered Enterprise
Our approach to integration leverages the
power of geography + a lot of help from
FME
$
Enterprise Ecosytem
60 – 250 systems per
municipality = growing
complexity
FME = ESB
How does FME
support enterprise
messaging?

5. Big Concept
FME is not just a tool for ETL - it is
enterprise middleware that supports
enterprise messaging and API integration.
Integrating location context into an
enterprise service bus (ESB) enables us to
enrich messages in-flight with new content,
leverage spatial operators in business rules,
validate and correct properties, and route
messages based on geographic entities such
as administrative boundaries.

6. The Challenge – Growing Complexity
A typical municipality has between 60 and 250 systems that support the overall business. Many of
these exchange information through file transfers or point-to-point integrations. The majority are
undocumented. The problem is that the combination of system interconnections creates a power
relationship. And each connection is a single point of failure for the whole system.
B
A
C
3 systems = 3 connections
B
A
C
D E
5 systems = 10 connections
B
A
C
D E
F
J
IH
G
10 systems = 45 connections

7. The Answer – Enterprise Service Bus
Leveraging an enterprise service bus breaks the power law by reducing the number of dependent
connections. It also decreases per-system integration costs as you move beyond the first 3 systems.
B
A
C
D E
F
J
IH
G
B
A
C
D E
F
J
IH
G

8. Enterprise Service Bus (ESB) Capabilities
AN ESB CAN… HAS…

9. Enterprise Service Bus (ESB) Capabilities
Route data between systems Testers, Notifiers
AN ESB CAN… HAS…

10. Enterprise Service Bus (ESB) Capabilities
Route data between systems
Transform formats and protocols
Testers, Notifiers
XML | JSON Templator & Extractor
AN ESB CAN… HAS…

11. Enterprise Service Bus (ESB) Capabilities
Route data between systems
Transform formats and protocols
Synchronous | asynchronous responses
Testers, Notifiers
XML | JSON Templator & Extractor
Service types
AN ESB CAN… HAS…

12. Enterprise Service Bus (ESB) Capabilities
Route data between systems
Transform formats and protocols
Synchronous | asynchronous responses
Publish | Subscribe Message Channel
Testers, Notifiers
XML | JSON Templator & Extractor
Service types
Notifications
AN ESB CAN… HAS…

13. Enterprise Service Bus (ESB) Capabilities
Route data between systems
Transform formats and protocols
Synchronous | asynchronous responses
Publish | Subscribe Message Channel
Event message constructor
Testers, Notifiers
XML | JSON Templator & Extractor
Service types
Notifications
Publish | Subscriber protocols
AN ESB CAN… HAS…

14. Route data between systems
Transform formats and protocols
Synchronous | asynchronous responses
Publish | Subscribe Message Channel
Event message constructor
Extensible and pluggable
Testers, Notifiers
XML | JSON Templator & Extractor
Service types
Notifications
Publish | Subscriber protocols
Chaining workspaces & automations
AN ESB CAN… HAS…
Enterprise Service Bus (ESB) Capabilities

15. Enterprise Service Bus (ESB) Capabilities
Route data between systems
Transform formats and protocols
Synchronous | asynchronous responses
Publish | Subscribe Message Channel
Event message constructor
Extensible and pluggable
Publish metadata
Testers, Notifiers
XML | JSON Templator & Extractor
Service types
Notifications
Publish | Subscriber protocols
Chaining workspaces & automations
FME Server API & API Gateway
AN ESB CAN… HAS…

16. Or a light mode screenshot could go here
Convert CRM Service
Request to Canonical form
Send Notification:
CaseFromCRM
Topic:
CaseFromCRM
Convert Canonical Service
Request to Innovadel
format
Update Innovadel Database
For New requests:
Notify of new Innovadel
Work Request Id(s)
Topic:
WorkRequestFromInnovadel
Convert Canonical Service
Request to CRM form at
Update corresponding
Service Request using API
REST API
NOTIFY
SUBSCRIBE
SUBSCRIBE
NOTIFY
REST/JSON
Innovadel
Database
REST
New Service Request
Initiated
Innovadel
Split new requests of type
exchange to two requests
(add, rem ove)
Scheduled Task
Determine last transaction
date processed
Query CRM for new Service
Requests since last
transaction
Resource File:
Last transaction
processed
REST/JSON
Update last transaction
processed
REST API
(future)
Direct update to
the Innovadel
database only if
API access is not
available

17. Or a light mode screenshot could go hereTopic:
ClosedRequestFromInnovadel
Determine last transaction
date processed
Convert work request status
to common form at
Resource File:
Last transaction
processed
Send Notification
Update last transaction
processed
NOTIFY
Query Innovadel API for
work requests closed since
last transaction
Scheduled Task or
Ad-Hoc
Innovadel
Work Requests are
closed
Select and group work
requests initiated in CRM
REST
Convert Canonical Service
Request to CRM form at
Filter Closed items
Write to Tempest form atted
file
SUBSCRIBE
Resource File:
Tempest Im port File
Tempest
Database
JDBC/ODBC
Update Tempest Database
to trigger im port process
REST API
(future)

18. FME + EI Patterns = ESB
A set of relatively simple instructions,
applied through common patterns,
can create a system that elegantly
handles complexity.

19. Township of Langley
Adopts FME ESB

20. Ready to
Begin?
Any sufficiently advanced
technology is
indistinguishable from
magic. – Arthur C. Clarke
● 20+ Separate Applications
● Each has at least some level of
integration to at least one other
● Several current integrations are
completely “black box”
● Desire to take ownership of
integrations and control of
business rules
● Opted for one of the most
complicated processes to start
with: Garbage Container
Request

21. Place screenshot here
Garbage Cart Workflow Process

22. Place screenshot here
Garbage Cart Dataflow Process

23. The Path from
Manual to
Magic
I do not fear computers. I fear
the lack of them. – Isaac Asimov
● Build the CRM and Web
Interface
● Have API’s built by Service
Vendor
● Have Billing Vendor build import
process
● Link these systems together
● Remove manual steps where
ever possible

24. Place screenshot here
Garbage Cart Dataflow Process with FME

25. Issues along
the way
Show me a completely smooth
operation and I’ll show you
someone who’s covering
mistakes. – Frank Herbert
● Potential change in our Service
Vendor part way through the
project

26. Issues along
the way
Show me a completely smooth
operation and I’ll show you
someone who’s covering
mistakes. – Frank Herbert
● Potential change in our Service
Vendor part way through the
project
● Using FME as the Service Bus
allows the easy swap of end
points, like the Service Vendor;
so opted to proceed in spite of
likely change.

27. Timelines &
Goals
I love deadlines. I love the
whooshing noise they make as
they go by. – Douglas Adams
● Started in June of 2018
● Original goal of Phase 1 live in
October 2018

28. Place screenshot here
Phase 1 Garbage Cart Workflow Process

29. Timelines &
Goals
I love deadlines. I love the
whooshing noise they make as
they go by. – Douglas Adams
● Started in June of 2018
● Needed to secure consultants to
build CRM (Catapult) & FME
(Spatial DNA) functions
● Put the project on hold while
looking at Service Vendor
options
● Re-started in January 2019
● Phase 1 Live April 2019

30. Where are we
now?
● Since April 2019
● Future platforms:
• Cityworks
• Perfect Minds

31. Observations +
Lessons Learned

32. OBSERVATIONS
 Focus on design and workflow made
technology choices and automation
easier
 More meetings with end-users and
buy-in from management
 Collaborative approach
 Engaging with experienced
consultants
✾ Learned more about the business
logic / operations / requirements –
speaking a different language
✾ Back-end systems may not have a
fully-formed API
✾ Assumptions used in design-build are
only valid until operations understands
what they actually mean
THINGS WE DID RIGHT… AND SOME CHALLENGES TOO…

33. LESSONS LEARNED…
✔ Decisions that were made in the past on systems implementation may affect
current/future automation
✔ Don’t be afraid to move forward even if change is expected – look at what is the
potential impact and how to minimize it
✔ Continued validation of your process flows is important as our perception at design of
how things should work versus during build will change

34. THANK YOU!
Jason Isaak ⎔ +1.604.532.7587 ⎔ jgisaak@tol.ca
Todd Lewis ⎔ +1.416.645.9093 ⎔ todd.lewis@spatialdna.com