Server-Side Scripting ?

[LaRetta]

This excites me terribly (and I know we've wanted it) but I'm having trouble visualizing how performance might be affected. I've ingrained in my mind that an FM Server should NOT run any other tasks because it would slow performance and Users would be affected. Now we are told that FMS can run its own scripts? It concerns me.

Example: Can this truly replace a client robot (which runs a process every 5 minutes)? If I use server to run a script every 5 minutes and if the script is complex won't that hinder performance which the Users will notice? If so, can FMS fire a script on another server which could handle the processing instead?

I am unable to test this with several users to see how it would impact a 200-user network. I have trouble understanding the concept in general. Can others help me grasp how to properly take advantage of this new feature? I'd sure appreciate it!

ALSO: What would be the script perspective? I mean, if we included a path, such as Get ( DesktopPath), would it look to the server desktop? I'm befuddled.

LaRetta

Edited July 26, 2007 by Guest
Added ALSO

[xochi]

LaRetta -- as I understand it only "web compatible" steps can run, which means that most of the really useful ones (such as sending mail, doing exports, etc) won't work. I'm a little confused by this too, so would appreciate any feedback others can give about whether we can finally replace our robot machines.

My main issues are

1. Email: Can FMSA9 on Mac OS X use server-side scripts to use any of the pop or smtp plugins? Last I checked SMTPit didn't work with FMSA8 and Mac OS X.

2. PDFs can FMSA9 on Mac OS X use SSS to print PDFs to a web-server folder?

thx!

[Genx]

1. Email: Can FMSA9 on Mac OS X use server-side scripts to use any of the pop or smtp plugins? Last I checked SMTPit didn't work with FMSA8 and Mac OS X.

-- Highly Doubt It. You may however want to have a look at developing yourself a small php script to retrieve data from your DB using FM PHP API and send emails based on that data using PHP.

Might also want to try fmwebschool.com for this if you're unsure about the API or your knowledge of PHP).

2. PDFs can FMSA9 on Mac OS X use SSS to print PDFs to a web-server folder?

-- Highly Doubt It given the whitepaper on FMI's website that suggests that FM Pro (vs FM Server) be used to generate reports *wow* (not really).

As FMI states, the primary purpose of this is to perform rudimentary tasks like moving data around etc.

You can actually get a fair bit done with it [sSS], but the idea is that the script runs without ever requiring any user interaction. To be honest they haven't really added anything besides what was already there (you could execute scripts through the XML interface for a while).

Edit: My second response was based on the assumption that SSS means Server Side Scripts?

Edited July 26, 2007 by Guest

[xochi]

You can actually get a fair bit done with it, but the idea is that the script runs without ever requiring any user interaction.

The problem with SMTPit (last I asked) running on FM Server was specific to Mac OS X and seemed more like a bug than a design constraint. Maybe the SMTPit people could answer this (assuming they lurk here?)

Edit: My second response was based on the assumption that SSS means Server Scheduled Scripts (i.e. the new Script Schedule utility in FMS9?)

Yeah, i just made that up -- SSS = Server Side Scripts (or Server Scheduled Scripts) Hopefully it doesn't conflict with an existing acronym... :)

[xochi]

Update: CNS plugins discussion list website is down, so I emailed them about this issue. I'll post their reply.

[mr_vodka]

as I understand it only "web compatible" steps can run, which means that most of the really useful ones (such as sending mail, doing exports, etc) won't work. I'm a little confused by this too, so would appreciate any feedback others can give about whether we can finally replace our robot machines.

According to a post that I read from Geoff Coffey...

"It seems as though that when a server side script is run using the new scheduled scripts feature in FileMaker Server, it runs the same pseudo client that runs an IWP session or a CWP instance. In other words, a tiny little faceless FileMaker client running on the server essentially "opens" the file and the script runs. When it does this, it runs any script that is set to run when the file opens. He believes that the same holds true when you run a script via the XML, XSLT, or PHP interfaces. It will run any opening scripts that you have set to that file."

[Genx]

Yeh I'm 100% with what Geoff said... he sounds so smart (probably cause he is lol).

FM really haven't tried much, but like I said, it has it's uses and its based around a reasonable assumption: The non-compatible steps actually require interaction with the user - not much use on a server sitting there by itself.

[xochi]

Would this work? Use a server-side-script to use the "Open URL" script step. The URL would either be a "file:///" URL which executes a shell script, or if that doesn't work, then use Open URL to open a http:// url that opens a PHP script locally, and the PHP script does all sorts of fun stuff.

[Genx]

.. what for?

[Vaughan]

FM Server schedules can already run os-level scripts.

I think the problem is any script that might require interaction with the file system: FM Server doesn't necessarily have those privileges especially when no users are logged-in to the system.

[JesseSFR]

LaRetta:

I agree 100%. If your server is under heavy load (and if you have 200 users, it probably is) I would never schedule scripts on it.

I haven't tried it, but I see no reason why you couldn't do this though:

1: Create a new file.

2: Add scripts to it that use data (and even run scripts) from other files.

3: Put this file on a *different* filemaker server.

4: Schedule scripts in this file.

Again, I haven't tried it. It's possible it won't work. But if it does, you can offload your server scheduled scripts to a separate filemaker server, which could be devoted to the cause. If you have a site license, you are entitled to install as many filemaker servers as you want, so this can be very economical.

The question is: Why? As far as I can tell, server scripts only have one advantage over a robot: they run in a threaded environment. In other words, you can have *several* scripts running on the same machine at the same time. This could be really nice if you have complex scripts that are time sensitive (I'm thinking of EDI integrations, email bases automation and so forth here).

On the down side, server scripts are limited to web-compatible steps, which throws out import/export, among other things. Also, a server script can only be run as often as once per minute. I have robots that run scripts every second for good reason, so that's a pretty big limit.

I'm rambling here, but anyway, the jury's still out in my book. I'm intrigued by threaded scripts. But only if I can run them on a second server, and even then I'm worried about the limitations.

Geoff

PS: I am using it already in one place. I have a script that restores sample data on a public demo web site. The server isn't busy, and the script is simple and needs to run every few minutes. This is probably exactly the sort of situation this feature was meant for. My 2 cents anyway.

[LaRetta]

I'm a bit behind. But I should have this solution to the point of testing by next week. It is good to know I'm not nuts (at least on THIS issue, ha ha). And I'll respond again if/when I have interesting results to report.

I really appreciate you all helping me on it! I didn't want you to think I'm ignoring any input ... if I ever don't respond right away, it's because I'm giving it serious considerations or testing. :smile2: