I have a customer that wants to update a GIS website real time with the changes made on FileMaker server. Syncing data will include images and while normal sync will be small at times it could be GB of data.
In the past I have done an auto export and import and scheduling it as often as they want the update to happen. This option has the advantage of making the whole process easy to explain and understand. It also has the advantage of allowing both sides to make changes to there systems without necessarily requiring a change on the other end.
But I know FileMaker has other options with the Data API, SQL, mirror sync, etc. But I have never used any of them before and to be honest a little scared about them. It dose not help that I know almost nothing about webdesign.
I would love any insight or advice on what others do or recommend.
What you are talking about isn't really connecting a web site, but integration between two systems. The fact that the GIS system has a web site component to it is sorta irrelevant. That's the same as FMS having WebDirect so to speak.
As with any integration you have a couple of options, and it depends on where you want to write the code and maintain it, and what technology you need to use or want to use:
1- push and pull from inside FM. That's largely going to be done using the "insert from URL" script step with its cURL options. You'd be using the API as documented by the GIS.
2- push and pull from the GIS system. Using the GIS tools and talking to FMS on the FMS Data API or xDBC
3- write something that sits it the middle that can push and pull from both FMS and GIS
#2 is probably not relevant because I doubt that you have control over the GIS or that it has its own 'script maker' kinda of functionality, a place where you can write code.
That leaves #1 and #2. If the GIS has all right APIs to do what you are after then that is the way to go most likely. #3 would probably mean a learning curve that is longer than you are willing to go through, but only you can decide that.
4 Likes
Thanks you for the response. I will ask if they have an API that will work for what we need. I do not know why I did not think about this before.
Option #2 is what I was originally thinking would be the way to go. I would essentially be able to setup a document explaining how they could use an API to push and pull data correct?
For option #3 would that be similar to using Mirror Sync fileMaker to SQL syncing? of course importantly I would not be writing it just setting it up?
No, it would totally different. No 'other system' typically gives you direct read and write access to their underlying tables. That's why people have APIs. With an API there is an abstraction layer between the database and the external world so that the data tables and fields can be changed at will without breaking other people's integrations.
To some extent; the FMS Data API is documented so if you give them the documentation and a set of credentials that would work with the Data API then they can write the code to do the pulling and pushing.
However:
- that assumes that they would be even willing to do that. If you're the one wanting the integration they may not want to bear that integration cost
- by letting them use the Data API directly you will be limited in the changes you can make to your system because now they will have a dependency on that. By using #3 you could be that layer of abstraction and be free to make the changes to your system you want, provided you also update the private part of the middleware (not the public facing part that they would use). You can even build in some local storage so that your FM system can even be down while they can continue to push data.
1 Like
I think I see your point the Mirror Sync setup would require a level of access on both systems that is unlikely to be given unless you control both of them.
Again thank you for helping me understand this better.
In this case it is the GIS that is asking for access to my solution and they are not the only ones requesting access. I see your point though that by setting this up it could cause future changes to be harder to make as it could effect them as well.
I am kinda getting the impression the current way I do things might be the best option, at least for now.
Only if you set it up in a way that gives them direct access to your underlying structure, like through the Data API directly or through xDBC.
Since you have multiple systems that want to integrate with your system I would definitely build your own API layer through some middleware of your choosing (I'd probably use something like Node.js).
It will be a very rewarding learning curve and depending on your business model you can offer it as a subscription to help you fund it.
1 Like
just to put in some more thoughts ...
in the past I have built some setups following scenario #3, usually working with a MSSQL server in the middle, synchronizing from both sides
Data APIs weren't common than or - the main reason for avoiding them - were dead slow. Synching between systems which are under some usage has to keep up some performance
Today with FM data API and newer license modells we can afford to set up that "middle-server" on another FMS instance. Change the structure for data to be read by systems from the outside. Set up user and privileges restrictively and only for chosen subsets of data. Cut down datasets in tables to only the needed subsets. Preflight data that have to be imported or synched....
For a FM developer like me with only moderate skills on other platforms that flattens the learning curve 
Holger
1 Like