PERFORM SCRIPT ON SERVER

[Jeffrey Bloch]

I have a script which includes a step: PERFORM SCRIPT ON SERVER.

 

The script (being performed on the server) has a line PERFORM SCRIPT.

 

The questions are:

Does this 'second' script also run on the server (because it was called from the server) or back on the user's system?

Do variables set in the initial SERVER script remain populated for the second?

 

Thanks

[comment]

3 hours ago, Jeffrey Bloch said:

Does this 'second' script also run on the server (because it was called from the server) or back on the user's system?

From FM help (emphasis added):

• Server-side scripts can use the Perform Script script step to perform sub-scripts, which also run on the server, only if those sub-scripts are in files on the same server. Additionally, when a client uses the Perform Script on Server script step to run a script that performs sub-scripts in another file, the file containing the sub-scripts must already be opened by the client.

 

3 hours ago, Jeffrey Bloch said:

Do variables set in the initial SERVER script remain populated for the second?

Calling the PSOS script step opens a new session.  Global variables (prefixed by $$) should persist until the end of the session (untested).

---
P.S. Please stop posting questions in this section - see the notice here:
https://fmforums.com/forum/18-community-videos-tips-techniques-articles/

 

Edited October 29, 2022 by comment

[Jeffrey Bloch]

1 hour ago, comment said:

From FM help (emphasis added):

• Server-side scripts can use the Perform Script script step to perform sub-scripts, which also run on the server, only if those sub-scripts are in files on the same server. Additionally, when a client uses the Perform Script on Server script step to run a script that performs sub-scripts in another file, the file containing the sub-scripts must already be opened by the client.

 

Calling the PSOS script step opens a new session.  Global variables (prefixed by $$) should persist until the end of the session (untested).

---
P.S. Please stop posting questions in this section - see the notice here:
https://fmforums.com/forum/18-community-videos-tips-techniques-articles/

 

Thanks! It's difficult sometimes to identify the area on FMForums that a question belongs. That said, I'll try better next time.

[Ocean West]

Just remember that each PSOS will run the onFirstWindow trigger and run your startup script if the session requires globals be set the would be done there. If there are routines that is needed just for a desktop or wd or iOS users that don't need to be performed for a server scheduled or PSOS script you should add logic to exit early the startup script.

Can't remember if it was released but there was discussion of a flag that could be set on server to allow server side scripts to initiate addition sessions on server. 

[Jeffrey Bloch]

On 10/29/2022 at 1:36 PM, Ocean West said:

Just remember that each PSOS will run the onFirstWindow trigger and run your startup script if the session requires globals be set the would be done there. If there are routines that is needed just for a desktop or wd or iOS users that don't need to be performed for a server scheduled or PSOS script you should add logic to exit early the startup script.

Can't remember if it was released but there was discussion of a flag that could be set on server to allow server side scripts to initiate addition sessions on server. 

It would be nice if FM added '$$$' functionality to carry values system-wide (including server-side).

[comment]

1 hour ago, Jeffrey Bloch said:

It would be nice if FM added '$$$' functionality to carry values system-wide (including server-side).

And when would such variables expire?

[Jeffrey Bloch]

18 minutes ago, comment said:

And when would such variables expire?

When replaced. They'd be contextual to the user, just as '$$', but would include server-side.

[comment]

12 minutes ago, Jeffrey Bloch said:

When replaced.

So - fields?

[Jeffrey Bloch]

1 hour ago, comment said:

So - fields?

I don't understand.

[comment]

Variables in computing are normally stored in memory and expire when the program has terminated. Values that would persist "until replaced" are not "variables" in this sense. They would need to be permanently stored somewhere. Filemaker does have a mechanism for storing values that you need to persist until replaced - you put them inside fields.

It is quite common to have a Users table where each user can store their preferences in their own record. It is also common to load these values into global fields/variables at the beginning of a session  (this is what @Ocean Westreferred to earlier).

I am not sure what is the problem that your suggested $$$ values would solve. Keep in mind that you can pass values to the server-side script using a script parameter, and the script can either declare them as global variables or pass them along to subscripts via their own script parameters.

 

 

[Jeffrey Bloch]

1 hour ago, comment said:

Variables in computing are normally stored in memory and expire when the program has terminated. Values that would persist "until replaced" are not "variables" in this sense. They would need to be permanently stored somewhere. Filemaker does have a mechanism for storing values that you need to persist until replaced - you put them inside fields.

It is quite common to have a Users table where each user can store their preferences in their own record. It is also common to load these values into global fields/variables at the beginning of a session  (this is what @Ocean Westreferred to earlier).

I am not sure what is the problem that your suggested $$$ values would solve. Keep in mind that you can pass values to the server-side script using a script parameter, and the script can either declare them as global variables or pass them along to subscripts via their own script parameters.

 

 

The ease of which we use variables when on a local machine is what I’d like to mimic during server hosted work. I set a number of variables when logging on and set these into fields upon record creation, audit functions, etc.. Having to pass these through script parameters are just another step and complicated when variables contain carriage returns therefore fooling receiving scripts into believing there are more parameters than there really are and truncating data due to the returns. 

[comment]

I am afraid I still don't see what is the problem this would solve.

22 minutes ago, Jeffrey Bloch said:

I set a number of variables when logging on and set these into fields upon record creation, audit functions, etc..

You can do the same thing with a server-side script. In fact, you would usually NOT want to do this with a server-side script - hence the caveat posted by @Ocean West. But if you have a start-up script that does that, and you do not take steps to prevent it from doing that when the session is on the server, then that's what will happen.

 

22 minutes ago, Jeffrey Bloch said:

when variables contain carriage returns therefore fooling receiving scripts into believing there are more parameters than there really are

The receiving scripts are not the ones being fooled. If you have multiple values to pass in a script parameter, and these values can contain carriage returns, then you must either substitute the returns for another delimiter before stacking them into a return-delimited list, or use JSON to combine the values.

 

Edited November 2, 2022 by comment

[Jeffrey Bloch]

16 hours ago, comment said:

I am afraid I still don't see what is the problem this would solve.

You can do the same thing with a server-side script. In fact, you would usually NOT want to do this with a server-side script - hence the caveat posted by @Ocean West. But if you have a start-up script that does that, and you do not take steps to prevent it from doing that when the session is on the server, then that's what will happen.

 

The receiving scripts are not the ones being fooled. If you have multiple values to pass in a script parameter, and these values can contain carriage returns, then you must either substitute the returns for another delimiter before stacking them into a return-delimited list, or use JSON to combine the values.

 

For the most part, when you pass script parameters all works fine. However, if one of the parameters is a field that contains line breaks ( ie street address formatted for multiple lines), each line of the address will be interpreted by the receiving script as another parameter rather than a continuation of one. Basically, if you send one parameter (3-line address), the receiving script will interpret there to be 3 parameters (Name, address, city/state/zip). I fixed the problem (for this time) by substituting carriage returns with "@@@@@", then swapped them back out again on the receiving side (see text below).

 

Substitute ( INCIDENTS::PHRASE_CHECK__Phrase to Check for Language_Translations_global ; "¶" ; "@@@@@" )

 

This works fine this time, but having to use script parameters as a workaround to variables losing their persistence in a server environment adds to the workload and risks times where I won't be as lucky and able to predict breaking points. All it would take is for a client to accidentally, or otherwise, add a linebreak where I hadn't anticipated one, and the results will be unpredictable.

 

If upon login, variables could be assigned that would carry over to a server-side function, all would be good. There'd be no need for repeatedly assigning variables into script parameters and reinterpreting them on the other end. We could just assign $$$persistentVariable once and be done with it til reassigned.

[comment]

11 minutes ago, Jeffrey Bloch said:

If upon login, variables could be assigned that would carry over to a server-side function, all would be good.

I don't know if that's technically possible, because the server-side script runs in a different session on a different machine. The only thing that is common to the two sessions is the user account.

14 minutes ago, Jeffrey Bloch said:

All it would take is for a client to accidentally, or otherwise, add a linebreak where I hadn't anticipated one, and the results will be unpredictable.

There is an easy solution for this: always anticipate a line break where one is possible. Note that this is only required if you are passing multiple values in a single parameter as a return-separated list. Your statement that "each line of the address will be interpreted by the receiving script as another parameter" is inaccurate. There is only one script parameter and it contains all the values passed to it. But it's true that each line of the parameter will be parsed out as a separate value.

BTW, there are control characters (e.g. vertical tab) that you can use as alternate delimiters. This is both easier and more reliable than "@@@@@".

 

[Jeffrey Bloch]

4 hours ago, comment said:

I don't know if that's technically possible, because the server-side script runs in a different session on a different machine. The only thing that is common to the two sessions is the user account.

There is an easy solution for this: always anticipate a line break where one is possible. Note that this is only required if you are passing multiple values in a single parameter as a return-separated list. Your statement that "each line of the address will be interpreted by the receiving script as another parameter" is inaccurate. There is only one script parameter and it contains all the values passed to it. But it's true that each line of the parameter will be parsed out as a separate value.

BTW, there are control characters (e.g. vertical tab) that you can use as alternate delimiters. This is both easier and more reliable than "@@@@@".

 

I’m sure you’re right at the moment, but it’d be a nice addition to FM. 

[Jeffrey Bloch]

On 11/3/2022 at 1:27 AM, comment said:

I don't know if that's technically possible, because the server-side script runs in a different session on a different machine. The only thing that is common to the two sessions is the user account.

There is an easy solution for this: always anticipate a line break where one is possible. Note that this is only required if you are passing multiple values in a single parameter as a return-separated list. Your statement that "each line of the address will be interpreted by the receiving script as another parameter" is inaccurate. There is only one script parameter and it contains all the values passed to it. But it's true that each line of the parameter will be parsed out as a separate value.

BTW, there are control characters (e.g. vertical tab) that you can use as alternate delimiters. This is both easier and more reliable than "@@@@@".

 

I have an idea which can solve all these potential issues and the need for Substituting. I'll create a Table which has but one purpose; transfer info from User to Host. Just prior to performing a script ON SERVER, I'll write any data to fields in a new record in this table and the only data passed to the server will be the primaryKey of the new record. The script running on the server-side will access the specified record and thus obtain any data needed, whether list-based, etc .. In fact, there are also more advantages. Records in the new 'Transfer' table can have auto-enter fields which automatically take the values within global variables (ie $$userID) and are thereby passed along without any scripting.

Edited November 4, 2022 by Jeffrey Bloch

[Ocean West]

Suggestion you could write a file with whatever data to the server document folder and another PSOS session could see if that file exist then read it and process what ever data contains. 

[comment]

44 minutes ago, Jeffrey Bloch said:

The script running on the server-side will access the specified record and thus obtain any data needed

Basically the same idea as:

On 11/2/2022 at 12:23 PM, comment said:

It is quite common to have a Users table where each user can store their preferences in their own record.

just using disposable records instead of permanent ones.

17 minutes ago, Ocean West said:

you could write a file with whatever data to the server document folder

You would need some sort of file-naming scheme to avoid user conflict.

 

[Jeffrey Bloch]

55 minutes ago, Ocean West said:

Suggestion you could write a file with whatever data to the server document folder and another PSOS session could see if that file exist then read it and process what ever data contains. 

I’d prefer to have the relationship-based read/write functionality from within FM and there are other benefits as well such as an audit record of events. 

[Ocean West]

I would agree - I am sorry as I've only partially paying any attention to this thread. I've been blind sided by may cat missing for 4 nights. It's been an awful week.

 

[Jeffrey Bloch]

10 hours ago, Ocean West said:

I would agree - I am sorry as I've only partially paying any attention to this thread. I've been blind sided by may cat missing for 4 nights. It's been an awful week.

 

Understood. Best of luck with your cat. 

[Jeffrey Bloch]

On 11/4/2022 at 6:36 PM, comment said:

Basically the same idea as:

just using disposable records instead of permanent ones.

You would need some sort of file-naming scheme to avoid user conflict.

 

I do have a User table. The purpose of the Transfer table would be to momentarily store data normally held in global variables. I suppose a User table could be used for the same purpose, except that one user could simultaneously use more than one device and thus overwrite data midstream. Additionally, although maybe just aesthetics, a User table would end up holding fields having nothing to do with a customary User record (ie $$nextInvoiceNum). Writing data to a Document folder/file risks the same issues as stated earlier. Data within a field that has one or more carriage returns (expected or otherwise) would change the mapping to the data on the server side. For example, if someone was entering a Last Name and accidentally hit the Enter key, acquiring the data on the server side would be throw off by at least one line.

[comment]

1 hour ago, Jeffrey Bloch said:

The purpose of the Transfer table would be to momentarily store data normally held in global variables.

I am afraid my usefulness in this discussion has been exhausted, because I don't really understand what is the exact problem here.. At some point you said that you need these variables to persist "until replaced". Now you say that you only need them "momentarily". If you only need to gather them momentarily for the purpose of transferring them to the server-side script, then I don't see why you would go to the lengths of building a dedicated table for this, instead of using the script parameter. But I don't really know what kind of data you are talking about.

P.S. You keep talking about carriage returns in data. I already give you two solutions for that. No matter which transfer channel you choose, you do need to implement a reliable method for packaging the data you send through it.

 

[Jeffrey Bloch]

1 minute ago, comment said:

I am afraid my usefulness in this discussion has been exhausted, because I don't really understand what is the exact problem here.. At some point you said that you need these variables to persist "until replaced". Now you say that you only need them "momentarily". If you only need to gather them momentarily for the purpose of transferring them to the server-side script, then I don't see why you would go to the lengths of building a dedicated table for this, instead of using the script parameter. But I don't really know what kind of data you are talking about.

P.S. You keep talking about carriage returns in data. I already give you two solutions for that. No matter which transfer channel you choose, you do need to implement a reliable method for packaging the data you send through it.

 

I prefer that variables persist even when performing scripts on a server. Seeing as that isn't currently the case, I need an alternative (momentary use). If I 'transfer' data to the server by way of Script Parameter, at least in my current need, my parameter would look like the following:

 

userKey

organizationKey

incidentKey

languageCode

comment

phraseToBeTranslated

 

The parameter 'incidentKey' may consist of and quantity of keys separated by carriage returns. The parameter 'comment' (example only for this purpose) is expected to be a one-line text field, but if a user hits a carriage return intentionally, or accidentally, no longer would I be able to GetValue (6) for the 'phraseToBeTranslated.' One option would be to Substitute carriage returns in all fields where a user might add a carriage return, then substitute them back on the server. I find it much simpler to create a Transfer record, set the values to the above list, then set variables to these values on the server. That said, it'd be much simpler to just be able to use variables that persist from user to server.

[bcooney]

Haven’t seen any mention of using JSON to package script parameters. https://www.seedcode.com/filemaker-16-json-script-parameters/

[comment]

23 minutes ago, bcooney said:

Haven’t seen any mention of using JSON to package script parameters.

 

On 11/2/2022 at 2:05 PM, comment said:

If you have multiple values to pass in a script parameter, and these values can contain carriage returns, then you must either substitute the returns for another delimiter before stacking them into a return-delimited list, or use JSON to combine the values.

 

[bcooney]

I stand corrected, comment 😊