2 Replies Latest reply on Oct 8, 2012 11:00 AM by Vincent_L

    FMS : Server Side Processing


      Finally deliver the "no more bot" marketing promise that FM Inc made in FMS 9 days. Yes we should be able to ditch those Filemaker Bots (a client just running scripts)


      So that means that the server side script steps should be much more expanded. Every scripted scipt steps not involving user attention shoud be Server Side aware


      - Perform applescript should work server side. Very important. Yes that works FMS would just wait the Applecript completion (or kill the process if time exceeded)

      - Execute SQL (in 11 that doesn't work, I'm not talking about internal ExecuteSQL like in 12)

      - Scripted imports whichever the source folder

      - Scripted imports from .fmp12 hosted files

      - Pause script step shoud work (yes soleties you need a scriot to wait, pause with a predetrelined time isn't supported in server side processing

      - Unarmful unsupported script steps (those who don't change the result of the script)  like freeze window, beep, speak, scroll window, allow toolbar etc. should be ignored rather than halting server side processing

      - Scripted exports whichever the destination folder

      - Export field content (very usefful for creating easilly text that suit your need)

      - OpenURL (very usefull to launch web services, like for Applescript server as to wait completion). Also, espceillay important with fmp:/// url

      - Insert Picture / File / Quicktime / Audio&Video / Pdf : or a way to ingest containers via filepath. Especially usefull nowadays with 12's conatiner field renewal

      - Open file

      - Send event


      There's no real reason, that those, if their parameters are set, shouldn't work on Server Side processing. Each of those, force us to stick with Filmekar robot.


      All future new script steps should be server side supported if all their parameters can be set by scripting. Server side processing is really important, of course nowadays it's not used as much as it could be because of the aforementionned limitations, but FMI should forces itself to always think about it, it has to be at the forefront of their thoughts. Now it's an afterthough, and it shows, but by making those scrip steps supported and think about new code to be Server Side Compliant we'll get  much cleaner code, rid of old GUI depencies. That way, Filemaker engine will get GUI independant, so faster (no more freeze window to get decent performances), could run in it's own thread while display would run on it's own thread. I guess, and I hope, that's filemaker plan for the 64bitification of Filemaker Client.

        • 1. Re: FMS : Server Side Processing

          A very comprehensive list which extends the just run it server side discussion

          • 2. Re: FMS : Server Side Processing

            We also need a function that gets the running server side scriptS


            That way, a server side script could check if other scripts are running, and then could be told to wait until some of all the other script to be finished, before going one, in order to save performance.


            it would also be great that we'd be able to scepcify for each script if it can run concurently with some orther server script, or if it has to be queued.


            Let's says we'd have 3 script, each set as to be queued.


            at 4 pm script 1 starts, since there's no ongoing scripts running it's processing.

            at 4:01 pm script 2 is lauched (either y a schedule, a fmscommand line instruction) : since that script is set to be queued, then the FMS will add it to it's queue

            at 4.03pm script 3 is launched : FMS queues it after script 2


            at 4.05 script 1 ends, then FMS continues script 2, and script 3 ios still in queued.


            But at 4.07 PM script 4, with is set not to be queued is launch. So script 4 is made run.


            so at 4.08 pm we've script 2 and script 4 running.


            That would offer much more control upon performance, and avoid many record locking sitruations.