Hi all.

I was hoping that the new ability to run a script from a URL, specifying parameters, could help me finally to launch a FM script on a different computer (host or client).

If I understand correctly this is not the case: the

"FMP://192.168.10.0/filename.fmp12?script=scriptname"

will only run a script on the same PC on wich you send the URL (from web browser or other), specifying the IP address of the host.

What I want to remark is that FINALLY it is easily possible to create records (or other things) from an external application, as long as it can compose an URL, sending a "do script" with the appropriate parameters.

Before you had only Applescript (VBscript could not pass parameters).

I think this is really handfull. Don't you ?

Trevix

Hi Trevix,

As long as you have FMS you can use a regular URL to create records (and run scripts) on the server through the XML interface. Ever since FMS9 (before 9 you had to have Server Advanced to do this).

Your fm does need to have been configured for XML access and you have to have a web server as part of your FMS deployment.

The URL script step will open a FileMaker file on the Specified SERVER.

So for example you can have a link in an email that will call a script and approve an Order. The FileMaker file can be on a hosted server.

The IP address in the URL doesn't need to only be the current users machine.

Hope this helps

Jerry

Let's clarify my intended topic (no FMS):

From FM on Client_PC, run a script on FM on Host_PC.

I tried and found that sending a URL from FM on Client_PC, like:

<a name="1031970">FMP://192.168.10.0/Prova.fmp12?script=ListClients&param=TopClients&$NumberToList=10

where 192.168.10.0 is the IP of Host_PC, will run the script "ListClients" on Client_PC, not on Host_PC.

And changing the IP will fail the URL.

So...no remote script.

But what I meant is that at least now I can write a "CreateNewRecord" script with parameters on FM and, from an external application, run it with parameters; much faster than importing them on FM from text file o XML.

Ain't that good ?

In my opinion (and for my clients) the best use of FM is for small business realities (no expensive FMS), but with the ability to exchange data with other apps (like accounting, Calendars, ecc) something that I feel has been neglected by the FM people (see the long due Applescript updates and ridiculous VBscript support).

Trevix

The URL script step will open a FileMaker file on any accessible volume.

This is the absolute #1 cause of damaged files. That opens up the file for multiple access attempts through OS-level sharing.

So...no remote script.

But what I meant is that at least now I can write a "CreateNewRecord" script with parameters on FM and, from an external application, run it with parameters; much faster than importing them on FM from text file o XML.

I think you misunderstood the XML angle. Using the FMS XML interface does not mean "importing from an XML file". It means you can create a URL to talk directly to FMS and have it create a record, run a script, etc.

FMS will send you back XML to confirm the action or let you know what the errors are.

I don't have the syntax for creating a new record close by but the URL to do a find for a random record looks like this:

http://<your server>/fmi/xml/fmresultset.xml?-db= <your file>&-lay=<some layout>&-findany

To finish my thought: your external application can use this to talk directly to FileMaker Server and bypass the potentially fragile step of having to talk to FM Pro on the desktop (that first have to have the hosted files open).

An overview of how you can create those URLs:

http://hasustorm.com/books/English/OReilly.Que.Filemaker.8.Functions.And.Scripts.Desk.Reference.Feb.2006.chm/0789735113/ch15lev1sec4.html

Thanks for the info (even tough I still remark my interest in FileMaker Pro and not on FileMaker Server...).

for whoever is following... :

http://trevixbook.local/fmi/xml/fmresultset.xml?-db=Prova&-lay=Provalayout&-script=ScriptProva&-script.param=pluto|pippo&ID=2&-find

will find record ID 2 on FMS and then run the script "ScriptProva", passing the parameters "Pluto|Pippo".

For what I understand, FileMaker Server 12 cannot still print (or produce PDF) and this is a drag.

Can you confirm ?

Is this some way, from the FileMaker people, to protect their business or it is rather complex and will be introduced some day... ? What do you think ?

As I reported in another post, in order to print from FileMaker GO or save PDF on the server HD without having or be willing to use airprint, I realized a small app that, on the server PC, receive URL from FM clients and lauch printing script on the local FM (no FM server).

It works pretty well but would be much better if FMGO could launch script on different machine...

Trevix

Update (still on FMP12, no interest on FileMaker Server) on runnning a FM script using a URL (I know that there are plugin but I rather not...)

I tried and found that sending a URL from FM on Client_PC, like:

FMP://192.168.10.0/Prova.fmp12?script=ListClients&param=TopClients&$NumberToList=10

where 192.168.10.0 is the IP of Host_PC, will run the script "ListClients" on Client_PC, not on Host_PC.

And changing the IP will fail the URL.

I tried to run the script from URL on the same PC and I've got a strange result.

If, on the same PC (windowsXP, ip 192.168.10.0) with the "Prova.fmp12" already open, you fire (from LiveCode (RunRev) for example but you can do it also from the browser if you got the "fmp" application on the options) a:

"FMP://UserName:[email protected]/Prova.fmp12?script=ListClients&param=10"

FileMaker opens inside the same copy of FMP a "new instance" of the DB (without closing the old one), a clean one...with passed username, no previous global, etc (like if you would open it from scratch) and run the script on this (with parameters received).

If you do a "close window", the new instance will close while the old will still be there (during the "prova" script, if you close the windows the script will stop).

I managed anyway to do what I wanted (run a FM script from URL) but I find no way to get back a result of some sort, which is essential to me.

So the question is: FMP://...does not answer anything ? (on the browser you get a failed connection...)

Comments ?

For what I understand, FileMaker Server 12 cannot still print (or produce PDF) and this is a drag.

Can you confirm ?

Confirmed. But it can be done through the PHP API with some PHP PDF libraries... so it's not a show-stopper.

What I want to remark is that FINALLY it is easily possible to create records (or other things) from an external application, as long as it can compose an URL,

Going back to your original question and you mentioned that you didn't want FMS involved. I would say: why the heck not? The API is there on FMS, it's very straightforward to do what you want. But if you want it to work against a local copy of FMP then you are introducing a lot of moving parts: such as:

- FMP has to be running so the calling has to be able to check if FMP is running and handle if not

- FMP can not be busy with any other task like running its own scripts

- FMP has the files open with whatever the user happens to be logged in. The external call may require different credentials and you'd have no control over that

So even it was possible you'd have to be willing to spend a lot of time and resources around error trapping and handling around it that wouldn't make it worth the effort.

So even it was possible you'd have to be willing to spend a lot of time and resources around error trapping and handling around it that wouldn't make it worth the effort.

While I agree with what you said, I don't understand how can I convince my customer that a 4 user network should shell out 1.000,00 euros (1.250 $) for FMS when FMP can work as well.

Beside it was a requirement to fire DDE (I don't think FMS can do it, so I may have needed an extra robot licence), save PDF from iPad on a server HD, print from iPad without a airprinter (they already owned a big one that was not).

What I don't understand, on the FileMaker people, is what I perceive as a stubborn decision not to give easy access to FM from external application (applescript is in limbo, Vbscript is minimal, ODBC require cumbersome setups and driver, URL (only on 12) is crippled as it was not intended for that.)

Small companies may use FM for recording jobs, tasks, personal data. But I don't think it is convenient for accounting or calendar application.

But, after all, it could only be that XML and PHP are tough if you don't know them :laugh:

Confirmed. But it can be done through the PHP API with some PHP PDF libraries... so it's not a show-stopper.

You mean trough a browser ?

No, PHP is server-side activity so you can have FMS produce PDFs in a folder where you your FMS scripts can get to them. We're talking purely about the ability to create PDFs from FM data and have them sit on the FMS hard disk some where. There is no client-side browser activity required for that.