Programmatically copy a file from server A to server B

Hi everyone :wave:

Context

For a dozen of reasons that are irrelevant now, I want to provide the ability to automatically copy a production file to another server, so an external team can query the database using ODBC.

Plan

I checked the Otto API and I saw it is possible, but I don’t want to share credentials, encryption password to the external key. I think it would be better if I set up a service for them instead.

Furthermore, I think it would be even better if my service ran a FileMaker script in the OttoDeploy file instead of directly requesting a deployment using the Otto API. This will allow me to easily manage the deployment configuration that is meant to be used by this external team. The inconvenience there is that I would need to create a script that runs the deployment API, since OttoFMS has this logic in the web viewer.

Questions

  1. Would you agree with strategy; setting up a service that hits the OttoDeploy file which runs the deployment via a FileMaker script?
  2. While copying the file from production to odbc enabled server, will users in production experience any downtime/issues?

Thanks!

We don’t recommend modifying the OttoDeploy file in any way, because those modifications may be lost with new major versions of OttoDeploy (where we replace the entire file). However, if you’re talking about using it as an external data source (since it’s where your file credentials are stored) then that would not cause any issues. You would have to write a custom deployment script yourself using the OttoFMS developer API, but it’s not too hard to do and we have some guides on how to do this.

Have you considered setting up a recurring deployment for your use case? These effectively leverage the script scheduler on your FileMaker server to run deployments, and you could even leverage that as your “service” to trigger the deployments manually if you don’t actually want it to happen on a schedule. Just schedule the deployment for far in the future and use the FMS Admin API to run the schedule early, on-demand. Similarly, you might be able to use the “Rerun a deployment” OttoFMS API to trigger a deployment manually if you never want to set a schedule.

In either case, no your Production users would not have any downtime. What happens behind the scenes on the source server is the file is paused for an ad-hoc backup, and then that backup is sent to the destination server.

1 Like

Hello,

  1. I would check out this video and blog post. I think it will give you some good ideas on how to pull this off. The key bit is that OttoDeploy gives you an easy way to get the deployment JSON out, so you can use it anywhere that can make a post request, like a FileMaker script.
  1. The users of the production file will not get kicked out. The impact should be roughly the same as running a backup, since that is what OttoFMS does to make a copy of the file.

Hope that helps

Thanks

Hey @toddgeist,

That was exactly what I was looking for. I never noticed that the deployment json can be copied from OttoDeploy! Nice one

Good, I can then create a separate file (use the CustomDeploy) that grabs the deployment json or just copy the deployment json manually every time I do a change, which will be very rarely.

Thank you for your help!