I'm looking at different ways to pass data back and forth between an on-premise instance of FMS 19 and a cloud instance of FMS19.
I'm able add a TO from the on-premise DB into the cloud DB.
When I work with the cloud database I can access data from the on-premise app.
When I run scripts locally I can access data from the on-premise app.
When I use PSOS to run scripts on the cloud instance, I cannot access data from the on-premise app.
Is that expected? Or should I be trying to find an error?
Hi Malcolm
I can’t comment on the procedure you’ve outlined, as I’ve never tried it. However, 2 comments:
You’re not specific in what way you can access the on-prem when working with the cloud database. If you’re working within FMP then you’d expect to access both if both hosts are specified or perhaps as an external data source. I don’t see from your description any interaction from cloud to on-prem servers.
Sounds like an ideal use for the data API!
All the best
Andy
Using the on-premise DB as an external data source in the Cloud DB, I then create layouts in the Cloud DB so that I can interact with the on-premise DB table data. When I open the cloud app and navigate to the correct layout the data is accessible and I can interact with it.
The problem I have is that the data does not seem to be accessible when the scripts run on the server.
You’re using FileMaker Pro in both cases? Although you have an external data source, it is still being interacted through FM Pro?
Yes. It's all FMP at this point.
I don’t see any evidence of each server talking to each other, FileMaker Pro is what has added the TO and consolidating the data, whereas your PSOS script requires one server to directly connect to the other, which is where the data API could come in.
@AndyHibbs are we talking at cross purposes?
The app running on FMCloud has a table occurrence which is based on an external data source. The external data source is a FileMaker database running on Filemaker Server v19. The connectivity between the servers is provided by under-the-hood-claris-magic.
The app includes a script which copies a container from the TO based on the external data source into a container in a table which is local to the app.
When I perform this process manually: open the app, go to the layout, drag-n-drop or copy/paste, the contents of the TO (external data source) container field to a container field in the local table, everything works.
When I perform this process by script with the file open in front of me everything works.
When I perform this process by PSOS or by Server side script Schedules the script runs, no errors are recorded, and no data is transferred.
I have been saying all along that this fails with script schedules. That is a mistake on my part.
Hi Malcolm
Quite probably 
- as mentioned this is not something I’ve ever tried, but was conscious you’d posted and had zero responses, hence attempting to stimulate something that might be helpful
I think you’re very much into ‘undocumented features’ here. What I was trying to communicate was the difference in the way an FMP client communicates to a server when compared to server to server. I guess in some ways, I was trying to indicate that at times FMP may have been acting as a form of middleware to make certain elements work.
If you think about how FMP client performs a script on server, it authenticates as per your user account. If one FM Server tries to script on another server, there has to be authentication issues. We’ve had all sorts of fun on different servers when using server side scripts to call the Amazon CLI when backing up to S3 storage (which works brilliantly). Depending on how the server is configured will change the authentication needed to complete the script. If there is a chance that this could work, that is where I’d personally be trying alternative options.
Kindest regards
Andy
It seems that I'm going to have to pass this off to the data API. Back to the AWS Cognito kerfuffle.
Has anyone managed to get Cognito auth set up as a Lambda function? I've seen a few mentions of it being possible but that is outside my skill set.
Can’t help you on Lambda but it is worth reposting this for anyone looking at this post: https://youtube.com/watch?v=99BuLS3mCSY&feature=share
This is on my list to do! But if anyone else wants to take a stab, my thought was:
Take this ExpressJS service by Soliant
And wrap it with one of these (not sure which is better):
Either way it should ideally be deployable using SAM or Serverless framework, rather than manually in the AWS console.
A painless deployment of Soliant's code would be a great contribution to our community.
...and FileMaker’s target market is internal developers for small workgroups 
Please don’t reply to this and take Malcolm’s post off subject. Just made me laugh that I needed to share.
Me: I want to pass data between databases on two different servers
Geek World: use SSH
Web World: use API
Me: They run different products but they are from the same company
Web World: use Vue.js, use Node.js, use React.js
Geek World: setup an Ethereum server to validate transactions between actors.
Me: They are Claris products
Geek World: 
Web World: 
We fired up three open-source alternatives to Claris while you were talking.
Web World: 
IPO for the best one is next week.