But we found a workaround. You can simply rename the plugin each time before adding it to the container to upload. So if first plugin is MBS1.fmx and you install MBS2.fmx via Install Plugin Script Step, you get the new one loaded and the old file is deleted. That’s great way to solve this. For the next plugins, we simply include the build number in the linux file name, e.g. MBS.3100.fmx to help you install it easily.
Second, whenever a plugin crashes the FileMaker Server scripting process, you see error 812 on the client. That can be irritating, but it simply means the client didn’t get an answer due to the lost connection.
Third, you may want to see debug messages from the plugin. Especially if we want to debug an issue. As none of the log files so far contain our debug messages, we change the plugin for next prerelease to redirect them itself. Within the /FileMakerData/Logs folder we create two new files ServerScriptingPluginsStdOut.log and ServerScriptingPluginsStdErr.log to log messages from stdout and stderr. Trace messages and debug messages end up in stderr. Regular outputs of messages may be in the stdout file.
I now usually connect two Terminal windows via SSH and run the commands to output the files live:
tail -f ServerScriptingPluginsStdOut.log
tail -f ServerScriptingPluginsStdErr.log
So in both windows I can watch live what is going on. To exit tail, you can press Control-C.
Forth, the FileMaker Cloud linux is secure. This includes that you can’t simply list all environment variables. EnvironmentVariables.Names returns an empty list. But you can still query some variables:
MBS( "EnvironmentVariables.Value"; "LANG" ) returns "en_US.UTF-8"
The MBS Plugin performs well on the FileMaker Cloud, although that's currently only 5% of the servers out there as far as we know about. Popular functions used on the FileMaker Cloud include our CURL functions, SQL functions within FileMaker and JSON functions.