Accessing a Filemaker script from an ASP website

[tripswitch]

Hi,

This question is related to the topic below:

http://fmforums.com/forum/showtopic.php?tid/171863/post/185201/hl/scripts+odbc/

Bear with me while I give you a little background on the project:

I'm an ASP developer working with a Filemaker developer on a project to build a public website that draws a lot of data from our client's FM database. Whilst I'm pretty experienced with Access and SQL Server, I'm a complete idiot when it comes to Filemaker so the whole project has been a steep learning curve for me.

The client's FM database has been migrated to a Windows Server 2003 box running FM7 Server Advanced. We're upgrading to FM8 Server Advanced in the next couple of days - it was not available here in the UK when we began the project. The site interfaces with Filemaker using the FM ODBC driver.

We've conquered most of the issues that have arisen during development, but there's one problem that's proved difficult to surmount - part of the brief demands that we insert images uploaded to the server via an ASP ActiveX component into container fields in the FM DB. I'm unable to do this using ODBC - you can only insert text into container fields. So I had the bright idea that if something like SQL Server's stored procedures were available in FM, I could call them from ASP, passing a path to the image and ref for the container field, and the FM script could do the rest of the work.

Well it seems we're part way there. My colleague has written an FM script that will do just that - and enhancements in FMS8A mean that we can pass variables (i.e. file path and container field ref) to the FM script. So the question is, how can I call the script from a VBscript ASP page?

I came across the thread above in researching this , and downloaded Wim Decorte's VBscript for triggering FileMaker scripts from outside FileMaker Pro. Since ASP is VBScript-based, it was logical that I could adapt this to run our FM script. So I made slight mods to his VBScript as follows to test the basic functionality, and uploaded it and the test .fp5 to the server:

<%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>

<%

' turn off standard error handling:

On Error Resume Next

Set objFM = Server.CreateObject ("FMPRO.Application") 'open FileMaker

' check whether there was an error:

if not err.Number=0 Then

' error occured

cause = err.description

if cause="" then

cause = "unknown error, code: " & Err.Number

End If

Response.write "Could not launch FileMaker: " & cause & " (" & Err.Number & ").

"

' clear error condition and quit

err.clear

wscript.quit

Else

%>

Object created successfully.

<%

end If

objFM.Visible = True ' show FileMaker for testing only. Hidden by default.

Set objFMfiles = objFM.Documents.Open("{path to VBS_fm.fp5}","") ' open test FileMaker file, no pw.

' check whether there was an error:

if not err.Number=0 Then

' error occured

cause = err.description

if cause="" Then

cause = "unknown error, code: " & Err.Number

End If

Response.write "Could not find the test file: " & cause & " (" & err.Number & ").

"

' clear error condition, quit FileMaker and quit the script

err.clear

objFM.Quit ' quit FileMaker

wscript.quit

Else

%>

Connected to fm database successfully.

<%

End If

objFMfiles.DoFMScript ("ShowMessage") ' call the ShowMessage script in the test file.

' check whether there was an error:

if not Err.Number=0 Then

' error occured

cause = err.description

if cause="" Then

cause = "unknown error, code: " & err.Number

End If

Response.write "Could not locate the correct script: " & cause & " (" & err.Number & ").

"

' clear error condition, quit FileMaker and quit the script

objFM.Quit ' quit FileMaker

wscript.quit

Else

%>

Script executed successfully.

<%

end If

objFM.Quit ' quit FileMaker

%>

However when testing this out it becomes apparent that, since the ASP is executed under the IUSER_MACHINENAME account, this does not have sufficient privileges to launch FMP. And rightly so. I get an error when trying to create the Application object:

"Could not launch FileMaker: 006~ASP 0178~Server.CreateObject Access Error~The call to Server.CreateObject failed while checking permissions. Access is denied to this object. (-2147024891)."

While I think one way round this would be to change permissions on the FMP executable to allow EVERYONE to launch it, this seems like a security minefield, and I'm sure my FM developer colleague would agree.

So my question is, is there another way to get ASP to call the FM script? Thinking round the problem, I'm wondering if I maybe need to write an ActiveX component in VB to launch FMP and set the privileges on that, but a) I'm not sure if it would work and I haven't coded dll's in VB since college, so it's perhaps a lot of work if there's an easier way.

Any thoughts or suggestions would be greatly appreciated ...

[Wim Decorte]

Hi Tripswitch,

This post really belongs in the "Publishing FileMaker Online" forum since that is what ASP is all about (Active Server Pages).

You hit the nail on the head with your findings: you can't use FM's ActiveX model on the web. At least not easily. There might be a possibility by forcing IIS to run it "out of process" but that would be:

- a security risk

- a potential stability risk on your web server if one or more instances of that would hang and not release their memory

Your best bet is to talk to the FileMaker Server Advanced side and trigger a script when you need it through the Web Publishing Engine of FMS.

I've been working on a .NET class to do just that and make it easy for ASP and ASP.NET developers to work with FMSA but I'm a couple of weeks short of that goal. But if you look into the Server Advanced documentation provided by FMI you'll find info on how to run scripts through the WPE. Forget about ActiveX unless you're willing to go the "IIS out of process" route.

(the trade-off is that not all FM script steps are supported through the WPE. If you can find a stable way to run the IIS out-of-process thing then you can have more functionality than is available through the web interface).

[Wim Decorte]

My colleague has written an FM script that will do just that - and enhancements in FMS8A mean that we can pass variables (i.e. file path and container field ref) to the FM script. So the question is, how can I call the script from a VBscript ASP page?

As a side note: FMI has not updated the ActiveX model to allow for passing parameters to a script when called from *outside* FM. You can call the script, but you can't pass it a parameter. Sucks, but there it is...

[tripswitch]

Hi Wim,

Sorry, got pulled onto another job and had to leave this one alone for a few days ...

Thanks very much for your informative explanation - it's at least reassuring to know that I was thinking along the right lines. Unfortunately it's clear we have a problem with what we were trying to do ...

I would definitely agree that going the 'out of process' route is probably best avoided given the potential ramifications ... however that does leave us with the issue you mention in your last post that we can't pass parameters to our script through the WPE So it looks like our plan might be dead in the water for now ...

Do you know if this is something that FMI will be updating in the ActiveX model any time soon? And do I understand correctly that this is not something that your .NET class will be able to work around? In any case I'd be very interested to hear more about the class, it sounds like it could be extremely useful for developers like myself who are trying to integrate with FM ...

Many thanks

Nick

[Wim Decorte]

Hi Nick,

Sorry for the delay, I was on the road.

I hope FMI fixes the ActiveX model, it would add lots of power to integration projects.

My "fmDotNet" class can set fields directly since it uses the FM web publishing engine. I should have the project on sourceforge in a week or two. I'm doing a presentation for the German speaking FSA community the week after next. Send me a back-channel email and I'll keep you posted.

[Wim Decorte]

I should add that since we're using the WPE, we can als run scripts on the server directly but the script steps are limited to the web compatible ones.