AnsweredAssumed Answered

Perform Script on Server w/OnFirstWindowOpen

Question asked by dewitte on Jan 29, 2019
Latest reply on Jan 30, 2019 by BruceHerbach

Like • Show 0 Likes0
Comment • 10

Hello! I recently started using the Perform Script on Server command. I haven't needed it before or didn't think I did.

I'm curious about a best practice

I develop webdirect apps and I always have a "OnFirstWindowOpen" script. This script usually handles setting up variables based on the current user. The app uses domain groups to log in so the user is authenticated as they come in. However, on most of my apps, I maintain a list of users that can be managed by an admin of that particular app. So, in this OnFirstWindowOpen script, I might set a variable such as "$$IsAdmin, or $$ValidUser", etc - based on this user table.

What I just found out is that if I do a Perform Script on Server, the server actually logs in and hits this script. It took me a little debugging to figure that out since I didn't expect it. I thought it would just run the command I provided.

I therefore added the following statements to the top of the OFWO script -

If LeftWords ( Get (ApplicationVersion) ; 1 ) = "Server" and Get(SystemPlatform)<>4

Exit Script

End If

I also had to tell my app in the security to all fmapp logins. I didn't have that checked before. In the OFWO script, I already tell the user they have to be in WebDirect, so I didn't have an issue, however the server wouldn't log in.

This all works great, however it really makes me wonder if I shouldn't be using an OnFirstWindowOpen script in the first place. Have I been using a wrong approach all along OR is it normal to add a server login check to scripts in apps that might use Perform Script on Server?

What is a best practice for this?

Andy Hibbs Jan 29, 2019 9:38 AM

Correct Answer

I can't remember a single system where we didn't have a OnFirstWindowOpen (we call them startup) script running, so you're in good company.

As you say, any PSOS or server run script will activate this script. We tend to use a couple of options, one being to pass a parameter within the PSOS call and the startup script is set to exit script upon checking for this script parameter if true.

The other is a variation on your suggestion If ( PatternCount ( Get ( ApplicationVersion ) ; "server" ) > 0 ) ) then exit script. I started a thread some time ago about the best method for this and there were about 3 variations all of which worked fine.

Also, do not forget that any 'OnLastWindowClose' scripts will be triggered as well.

We carried out a lot of investigation and testing to fully understand what goes on with PSOS. This was some time ago, but I've lifted the logs from one of these tests that records the whole process (IP address anonymised):

- Startup Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- PSOS Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- Shutdown Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- FM Pro Info:

Calling Script:

Account Name: Andy Hibbs

Application Version: ProAdvanced 16.0.1

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: E6E56E723D46D52059068134E2D01F06

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:30:6a

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Users/andyhibbs/AppData/Local/Temp/3/S10.1/

User Name: Andy Hibbs

Use System Formats State: 1

If anyone is interested, at a time when I'm less busy, I can list the actual tests in order to make sense of the above. Also, during these tests we found the bug in PSOS in v15 where the FMP client could not update quickly enough to display the correct results without a pause for 0 seconds after the PSOS has run, which FileMaker fixed on a subsequent release.

Now, if we could have a script step option 'Suppress Script Triggers', life would be much easier

Kind regards

Andy

See the reply in context

No one else had this question

Outcomes

Andy Hibbs Jan 29, 2019 9:38 AM

I can't remember a single system where we didn't have a OnFirstWindowOpen (we call them startup) script running, so you're in good company.

Also, do not forget that any 'OnLastWindowClose' scripts will be triggered as well.

- Startup Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- PSOS Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- Shutdown Script Info:

Account Name: Andy Hibbs

Application Version: Server 15.0.3

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: C185BC20E5152671A80B94972761DD93

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:88:10

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Windows/Temp/S67057/

User Name: PSOSScript - Andy Hibbs 358

Use System Formats State: 0

- FM Pro Info:

Calling Script:

Account Name: Andy Hibbs

Application Version: ProAdvanced 16.0.1

Device:2

Extended Privileges: fmapp

fmreauthenticate10

fmwebdirect

Host Name: FMS5

Persistent ID: E6E56E723D46D52059068134E2D01F06

System Drive: /C:/

System IP Address: xxx.xxx.xxx.xxx

System NIC Address: 00:50:56:b9:30:6a

System Platform: -2

System Version: 6.3

Temporary Path: /C:/Users/andyhibbs/AppData/Local/Temp/3/S10.1/

User Name: Andy Hibbs

Use System Formats State: 1

Now, if we could have a script step option 'Suppress Script Triggers', life would be much easier

Kind regards

Andy

2 people found this helpful

Actions

Mike Duncan @ Andy Hibbs on Jan 29, 2019 9:53 AM

Part of our internal development standards include having an "if" step in any script that is to be used as a script trigger that tests for a global variable, like so:

If [$$SCRIPT_TRIGGERS_OFF = 1]

exit script [True]

End If

That way if you want to be able to not run script triggers, you set that global variable to 1, or clear it to re-enable them. Handy for debugging.

I also put a test in my open script to test for server or webdirect sessions, if needed. I depends on what the script is doing, but may be needed. I think you are on the right track.

3 people found this helpful

Actions

Andy Hibbs @ Mike Duncan on Jan 29, 2019 10:19 AM

+1 for that Mike, we have a very similar opening to scripts called by triggers.

Actions

dewitte @ Andy Hibbs on Jan 29, 2019 10:26 AM

Thank you - That makes sense. I'm glad I wasn't doing something completely wrong. I think I might start sending an extra parameter instead of checking for server versions, etc which might change someday. What about the having to add fmapp login privilege? I could play around with the app, but maybe you've run across this issue also.

Actions

Andy Hibbs @ dewitte on Jan 29, 2019 11:09 AM

Looks like fmapp not only controls FileMaker Pro/Go access, the following is published at: Editing extended privileges for a privilege set

fmapp

Access via FileMaker Network, server-side scripting, or FileMaker Go

Interesting that WD requires this for PSOS, which after all is server side scripting.

All the best

Andy

3 people found this helpful

Actions

dewitte @ Andy Hibbs on Jan 29, 2019 12:17 PM

Look at that! Well, thank you. I'm glad to know I'm on the right track all around.

Actions

Daniel Farnan @ Andy Hibbs on Jan 29, 2019 5:26 PM

My understanding is that PSOS causes server to launch a virtual copy of the FMP client to handle the script execution, and this is why the script triggers fire.

1 person found this helpful

Actions

Julio Toledo @ Daniel Farnan on Jan 29, 2019 5:46 PM

Correct, when it comes to PSoS it's always wise to evaluate your environment during all layout /window-related script triggers such as 'OnFirstWindowOpen', 'OnLayoutLoad', etc.

A conditional block should exclude whatever code which should not execute on server (or perhaps the entire script if appropriate).

3 people found this helpful

Actions

BruceHerbach Jan 31, 2019 8:09 AM

When PSOS first came out there were a number of articles about how to use it. One of the key points was to not Run the OnOpen script. So very early in my on Open script I have the following lines:

If [ PatternCount( Get( ApplicationVersion ); "Server" )

Exit Script [ Text Result: ]

End If

When I say early it is right after any thing that is required by the PSOS script.

The other really key part is that the PSOS script may need the same environment as the users session. What I mean is the same Global field settings and Global variables. As an example I developed a script has to create a set of records based on values set in global fields. If the file is connected to the server Get( ConnectionState ) > 0 my PSOS setup is really 2 scripts. The first is called from the button script and gets a set of values to enter into the Global fields. In short it duplicates the User environment on the server. This script then calls the same script that would have run if Get( ConnectionState ) = 0 ( not connected to hosted file ).

HTH

4 people found this helpful

Actions

dewitte @ BruceHerbach on Jan 30, 2019 7:51 AM

That's also helpful to know since it didn't take me long to realize my global variables weren't available. I only had two, so I passed them as parameters but I can see if you were doing something really involved, it would be smart to have a global save/restore like you do. The one new script I added was a set defaults script. This used to happen during the startup script and still does - but I've moved it into it's own script and when I check for PSoS, I can run this script and I have my basic variables in place.

Actions

10 Replies

Andy Hibbs Jan 29, 2019 9:38 AM
Unmark Correct
Correct Answer
I can't remember a single system where we didn't have a OnFirstWindowOpen (we call them startup) script running, so you're in good company.

As you say, any PSOS or server run script will activate this script. We tend to use a couple of options, one being to pass a parameter within the PSOS call and the startup script is set to exit script upon checking for this script parameter if true.

The other is a variation on your suggestion If ( PatternCount ( Get ( ApplicationVersion ) ; "server" ) > 0 ) ) then exit script. I started a thread some time ago about the best method for this and there were about 3 variations all of which worked fine.

Also, do not forget that any 'OnLastWindowClose' scripts will be triggered as well.

We carried out a lot of investigation and testing to fully understand what goes on with PSOS. This was some time ago, but I've lifted the logs from one of these tests that records the whole process (IP address anonymised):

- Startup Script Info:
Account Name: Andy Hibbs
Application Version: Server 15.0.3
Device:2
Extended Privileges: fmapp
fmreauthenticate10
fmwebdirect
Host Name: FMS5
Persistent ID: C185BC20E5152671A80B94972761DD93
System Drive: /C:/
System IP Address: xxx.xxx.xxx.xxx
System NIC Address: 00:50:56:b9:88:10
System Platform: -2
System Version: 6.3
Temporary Path: /C:/Windows/Temp/S67057/
User Name: PSOSScript - Andy Hibbs 358
Use System Formats State: 0

- PSOS Script Info:
Account Name: Andy Hibbs
Application Version: Server 15.0.3
Device:2
Extended Privileges: fmapp
fmreauthenticate10
fmwebdirect
Host Name: FMS5
Persistent ID: C185BC20E5152671A80B94972761DD93
System Drive: /C:/
System IP Address: xxx.xxx.xxx.xxx
System NIC Address: 00:50:56:b9:88:10
System Platform: -2
System Version: 6.3
Temporary Path: /C:/Windows/Temp/S67057/
User Name: PSOSScript - Andy Hibbs 358
Use System Formats State: 0

- Shutdown Script Info:
Account Name: Andy Hibbs
Application Version: Server 15.0.3
Device:2
Extended Privileges: fmapp
fmreauthenticate10
fmwebdirect
Host Name: FMS5
Persistent ID: C185BC20E5152671A80B94972761DD93
System Drive: /C:/
System IP Address: xxx.xxx.xxx.xxx
System NIC Address: 00:50:56:b9:88:10
System Platform: -2
System Version: 6.3
Temporary Path: /C:/Windows/Temp/S67057/
User Name: PSOSScript - Andy Hibbs 358
Use System Formats State: 0

- FM Pro Info:
Calling Script:
Account Name: Andy Hibbs
Application Version: ProAdvanced 16.0.1
Device:2
Extended Privileges: fmapp
fmreauthenticate10
fmwebdirect
Host Name: FMS5
Persistent ID: E6E56E723D46D52059068134E2D01F06
System Drive: /C:/
System IP Address: xxx.xxx.xxx.xxx
System NIC Address: 00:50:56:b9:30:6a
System Platform: -2
System Version: 6.3
Temporary Path: /C:/Users/andyhibbs/AppData/Local/Temp/3/S10.1/
User Name: Andy Hibbs
Use System Formats State: 1
0

If anyone is interested, at a time when I'm less busy, I can list the actual tests in order to make sense of the above. Also, during these tests we found the bug in PSOS in v15 where the FMP client could not update quickly enough to display the correct results without a pause for 0 seconds after the PSOS has run, which FileMaker fixed on a subsequent release.

Now, if we could have a script step option 'Suppress Script Triggers', life would be much easier

Kind regards

Andy
2 people found this helpful
Like • Show 1 Like1
Actions
Mike Duncan @ Andy Hibbs on Jan 29, 2019 9:53 AM
Mark Correct
Correct Answer
Part of our internal development standards include having an "if" step in any script that is to be used as a script trigger that tests for a global variable, like so:

If [$$SCRIPT_TRIGGERS_OFF = 1]
exit script [True]
End If

That way if you want to be able to not run script triggers, you set that global variable to 1, or clear it to re-enable them. Handy for debugging.
I also put a test in my open script to test for server or webdirect sessions, if needed. I depends on what the script is doing, but may be needed. I think you are on the right track.
3 people found this helpful
Like • Show 2 Likes2
Actions
Andy Hibbs @ Mike Duncan on Jan 29, 2019 10:19 AM
Mark Correct
Correct Answer
+1 for that Mike, we have a very similar opening to scripts called by triggers.
Like • Show 0 Likes0
Actions
dewitte @ Andy Hibbs on Jan 29, 2019 10:26 AM
Mark Correct
Correct Answer
Thank you - That makes sense. I'm glad I wasn't doing something completely wrong. I think I might start sending an extra parameter instead of checking for server versions, etc which might change someday. What about the having to add fmapp login privilege? I could play around with the app, but maybe you've run across this issue also.
Like • Show 0 Likes0
Actions
Andy Hibbs @ dewitte on Jan 29, 2019 11:09 AM
Mark Correct
Correct Answer
Looks like fmapp not only controls FileMaker Pro/Go access, the following is published at: Editing extended privileges for a privilege set

fmapp
Access via FileMaker Network, server-side scripting, or FileMaker Go
Interesting that WD requires this for PSOS, which after all is server side scripting.

All the best

Andy
3 people found this helpful
Like • Show 1 Like1
Actions
dewitte @ Andy Hibbs on Jan 29, 2019 12:17 PM
Mark Correct
Correct Answer
Look at that! Well, thank you. I'm glad to know I'm on the right track all around.
Like • Show 3 Likes3
Actions
Daniel Farnan @ Andy Hibbs on Jan 29, 2019 5:26 PM
Mark Correct
Correct Answer
My understanding is that PSOS causes server to launch a virtual copy of the FMP client to handle the script execution, and this is why the script triggers fire.
1 person found this helpful
Like • Show 1 Like1
Actions
Julio Toledo @ Daniel Farnan on Jan 29, 2019 5:46 PM
Mark Correct
Correct Answer
Correct, when it comes to PSoS it's always wise to evaluate your environment during all layout /window-related script triggers such as 'OnFirstWindowOpen', 'OnLayoutLoad', etc.

A conditional block should exclude whatever code which should not execute on server (or perhaps the entire script if appropriate).
3 people found this helpful
Like • Show 1 Like1
Actions
BruceHerbach Jan 31, 2019 8:09 AM
Mark Correct
Correct Answer
When PSOS first came out there were a number of articles about how to use it. One of the key points was to not Run the OnOpen script. So very early in my on Open script I have the following lines:

If [ PatternCount( Get( ApplicationVersion ); "Server" )
Exit Script [ Text Result: ]
End If

When I say early it is right after any thing that is required by the PSOS script.

The other really key part is that the PSOS script may need the same environment as the users session. What I mean is the same Global field settings and Global variables. As an example I developed a script has to create a set of records based on values set in global fields. If the file is connected to the server Get( ConnectionState ) > 0 my PSOS setup is really 2 scripts. The first is called from the button script and gets a set of values to enter into the Global fields. In short it duplicates the User environment on the server. This script then calls the same script that would have run if Get( ConnectionState ) = 0 ( not connected to hosted file ).

HTH
4 people found this helpful
Like • Show 1 Like1
Actions
dewitte @ BruceHerbach on Jan 30, 2019 7:51 AM
Mark Correct
Correct Answer
That's also helpful to know since it didn't take me long to realize my global variables weren't available. I only had two, so I passed them as parameters but I can see if you were doing something really involved, it would be smart to have a global save/restore like you do. The one new script I added was a set defaults script. This used to happen during the startup script and still does - but I've moved it into it's own script and when I check for PSoS, I can run this script and I have my basic variables in place.
Like • Show 2 Likes2
Actions

Perform Script on Server w/OnFirstWindowOpen

Outcomes

Related Content

Recommended Content