I just want to know that what are the advantages and disadvantages of performing script on the server?
Please describe and also what those routines should be performing on the server to get the more efficient response?
1) you need more performance, e.g. Server = PC, Client could be iOS device AND the server is much "closer" to the data than a device on a network, possibly a WAN.
2) you don't want the client UI to change during script execution.
3) you need to schedule a script
Hard to be complete for a such question. My 20 pence :
About what routine should be performing on the server to get the more efficient response, say all that are not very optimized for a network use; some examples : Replace field content, Import Records, tasks that need sorting upon a related table...
One major disadvantage from my perspective is that the PSOS is nearly debug-proof. I ended up working around the PSOS script I was trying to do as it never worked. After spending nearly a week trying to get a simple PSOS script to work, posting messages, and even working with FMI support, the script failed to work as expected in all cases. I ended up writing a simple JDBC program that did the same thing (and still called from FMP), but unlike PSOS, the JDBC logic is totally debug-able and works every time.
Another PSOS disadvantage is that you're limited to the file paths on FMS that FMS "allows". If you work around PSOS, say with a micro-service, you can do whatever you want with no FMS-imposed file path limitations as one example.
I'm sure some folks have great results with PSOS so it may be a good solution for them.
Fred already mentioned it but I want to emphasize it: people tend to automatically expect a performance boost, and very often we as developers testing on our own systems do see that. But in the real deployment that is not always a given. The server needs to have the spare capacity in processing power, disk i/o and memory to take on the extra tasks and spin up those small client-like sessions in its environment.
So start with a good baseline of the server's current performance and decide based on that whether that spare capacity is there. This is where those 2-core Mac Minis suddenly don't start to look like such a good idea...
The other point that is oft overlooked: you have to code defensively. In your code you cannot assume that the PSoS call actually worked, not if the result of it is critical to the rest of your client-side workflow.
The server may be out of available PSoS session, or the server' script engine may be down... your client-side code needs to trap for any PSoS failures and decide what to do:
- retry? If so how many times?
- what to do if it still fails after the retries? Halt the process and back out gracefully? Do the processing on the client?
Retrieving data ...