Using "Perform Applescript" and getting result ("tell application") from a REMOTE script/computer

[dsghs]

I have a script that performs applescript on database A. At the end of the applescript, it does a "tell application Filemaker Pro" and sends the result back to filemaker pro to be stored in a result field. It works fine when I run the script from database a.

 

I try to run the script (containing the applescript) from another script in database B from a different machine (script on database b runs the script on database a. The script/applescript run fine, but it doesn't return the result to database B (or A). Any ideas on how I could obtain the result?

[Fitch]

What does your script look like, and why are you using AppleScript instead of FileMaker script steps?

[Rick Whitelaw]

I use AppleScript but only when necessary. If a task can be accomplished using FM scripting that's the way to do it. For me the exception is calculated applescripts that run shell scripts defined in the calculation. You mention "another machine". What sort of network setup are you using?

[dsghs]

I use Applescript to run a shell script that runs a ruby script using the selenium gem. I use Filemaker Server Advanced to host the db file. The first machine is usually a mobile device (FMGo). The second machine is a "robot" that loops indefinitely looking for flagged records ready to be submitted. This robot must loop through submission ready records of more than one database file so it has its own db file that calls their submission scripts remotely. Once the record is flagged by the iPad, the robot on the remote machine picks it up, parameters are passed to the ruby script which opens a website form and fills in fields and navigates through the form. If the confirmation page is reached and there is no timeout, a confirmation result is returned and the robot records the confirmation on a submission log for the iPad user to see. These forms are found on government sites that my program needs to interact with.

 

The robot also emails pdfs using the same flag method with Filemaker script steps, but Filemaker script steps will not satisfy the requirements of filling out an existing legacy web form for which I have no db connection.

 

So,

1. FMServer

    a. FMGo

    b. FM Pro (robot machine)

 

The script returns the confirmation if I run it directly from the file and it actually runs the ruby script fine from the remote robot database file but loses the confirmation. I, however, have multiple files where I have to run this script so I have to run the scripts remotely from the robot database file.

[dsghs]

Also, I've put a result field in the robot's fm file and it doesn't return the result there either. Where is it going??

[bruceR]

The best thing to do with AppleScript results is to avoid layout dependencies by using a global field and a table (table occurrence) reference.

Do shell script "cd ~/documents; ls"

Set data cell "zResult" of table "contacts" to result

[dsghs]

I am trying out a test script now (all it does is the tell application step) and I'm using exact references with a global field. Again, same problem. If I run it locally, it works fine and sets the field. If I run it from the remote db/machine, it doesn't set the field. I tried making the field on the remote database and modified the applescript to set the remote database's result field to something but it doesn't work either. It would be logical for the remote database's result field to be filled since the remote database/machine is the one running the applescript. But it doesn't set the field.

 

Any thoughts?

[dsghs]

Apparently I was missing a quote somewhere in my applescript... It works now. It sets the result field in the remote database.

[Rick Whitelaw]

I wonder why it ran fine locally if a quote was missing.

[dsghs]

I wonder why it ran fine locally if a quote was missing.

 

There was a quote missing in the remote file's script - I had two separate applescripts at one point when I was trying to get ruby to report back to the main database instead of the remote one. They were supposed to be duplicates, but apparently a quote escaped sometime in the process.