3 Replies Latest reply on Aug 14, 2015 5:37 AM by clind

    Perform script on server


      Working with perform script on server and I have a few questions relating to context.


      In calling up perform script on server what is the context it is looking at? Does it know which table, record, field I am using on the client side? Is it possible to assign variables once perform the script on the server is running on the server?


      Example $id of the record


      WIll it go to a layout and perform the requested find?


      Thank in advance



        • 1. Re: Perform script on server



            You will not have the benefit of the Context and Global variables present at the client from within the PSoS.  Beezwax has a great primer at:  https://blog.beezwax.net/2014/04/04/an-introduction-to-perform-script-on-server/


            I have tried converting a few things over to PSoS where I thought it might make sense, and all of the following have been "gotchas" for me so far.


            1.  Found Set - Great that you have the exact found set on the client they want - but now you'll have to pass that to the server somehow reliably.  Maybe the new summary type of List will help - but it certainly requires more work than if the script was running in the client who already has context.

            2.  Globals - The beezwax article covers this also, but Global fields and variables you have populated in the client, aren't going to be available on the server (where PSoS is actually running the script).

            3.  Some functions evaluate differently.  I can't recall which got me, but beware anywhere where the Filemaker Help has a little note like *evaluates differently on client and server, or *not server compatible.  I know one specific issue I had a fantastic (working) Import from one Filemaker layout into another -- which is not supported when running at the server.  It's not really a specific limitation of PSoS, but a general difference in Filemaker script running the headless client with some features being unsupported.


            I have implemented several PSoS for little tasks where I can easily pass a parameter, I use SixFried Dictionary functions, but however you choose to pass parameters - pass everything you need (or maybe collect everything into a working table at the client if you have some complex process).


            I'm sure the more experienced guys will respond with better information tomorrow.  There are many more great reads from Scarpetta Group, SeedCode and Soliant I've already seen - so google and read as much as you can from these experts and get a quick leg-up.


            I just operate under the assumption that it is far more like running the procedure from a server schedule, than from within a client.  Just think of all the information you would need to develop the proper context and pass it into the procedure somehow.

          • 2. Re: Perform script on server

            Jason, in addition to the information passed in the previous response:

            With PSoS FileMaker starts a new 'virtual session' on the server. It will use the login credentials that you have when you start the PSoS, but otherwise your session will start from scratch: you'll have to (re)create the context, set variables and globals etc. You can pass information to te PSoS using a scriptparameter, and retrieve results such as status info with get(scriptresult).

            PSoS is particularly suitable for tasks that operate on many records, like updating or deleting lots of records. But beware: your client software may sometimes lag behind, especially when you're on a slow WAN connection.

            If you use different files for interface and data, there are some other issues to be aware of.


            And, last but not least, when PSoS is completed, the session will be gone.

            Hans Erik

            • 3. Re: Perform script on server

              I have been transferring many of my "big" scripts to run on the server especially for clients running on an iPad and have had a lot of success. When converting a script to run on the server, often I will pass in a list of variables to give the server information to navigate to the same location that the client was when they ran the script (e.g. layout, find criteria, message options). In my server script I will then navigate to the appropriate layout, perform a find with all the same requests, and do anything else the client did. Once I have recreated the client's scenario on the server session I can perform the rest of the script just as the client would have, only a lot faster (providing I don't have any steps that aren't compatible with the server).