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.
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.
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.
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.
It is possible to integrate tables from Cloud apps and On-Prem apps. This requires active authentication. The user must be logged into both the Cloud app and the On-Prem app.
On Premise FMS cannot authenticate with Claris Cloud without an active client. Please correct me if there is a way to do this.
This means that script schedules running On-Prem only have one form of authentication when the script may need two forms. This is why the tests from the On-Prem side failed to access data from the Cloud app. They didn't have sufficient privileges.
Claris Cloud does not allow the admin to schedule scripts.
Claris Cloud does allow scripts to be run via Perform Script on Server. However, there still seem to be issues accessing data from external data sources that are identical to authentication issues.
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.
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.