How to Access FM Server on Web?

[Eric Kelly]

This may be a hopelessly ignorant question, but I'll ask anyway. We have a number of files running on our OS X network, hosted by FM Server 5.5. It now looks like we will need to provide remote access to these files via the Web, but still have them served inhouse by FM Server. I see how one can serve files on the web using FM Unlimited, but what about Server? Do we need to purchase some special additional CGI?

Thanks,

Eric

[Kundinger]

Hello Eric,

Quick answer... You NEED FileMaker Pro Unlimited.

FMP Server will serve up FMP data files to users with FMPro. FMP Unlimited (web) will serve up FMP web pages to users with a web browser. FMP Server and FMP Unlimited (web) can interact (simultaneously) together to serve up FMP data files to FMPro users and FMP web pages to web browser users.

To clarify... users inside and OUTSIDE your network can access FMP Server as long as they have FMPro... also, users INSIDE and outside your network can access FMP Unlimited (web) as long as they have a web browser.

Something to consider... Balance the cost (FMP Unlimited, server, web page development, etc.) to deploy a web solution for remote users... VERSUS... the cost to purchase additional FMPro licenses for your remote users. You may opt to just purchase additional FMPro licenses for a small number of remote users... OR... you may opt to deploy a complete web solution and move ALL your users to web browsers.

Hope this Helps!!!

Bob Kundinger

[email protected]

[Eric Kelly]

Thanks so much for your helpful reply. I didn't realize that you could run FM Server and FM Unlimited on the same set of files simultaneously. There are potentially quite a few remote users who would wish to access files, so I don't think that purchasing extra FMPro licenses for everyone will be very practical.

I am curious about one comment you made -- I thought FM Unlimited essentially could serve files directly to the web with layouts and formatting intact, but your comment sounds like there would be a lot of extra work involved in tailoring the solution to the web. I have never tapped the web features of FMPro, so have no idea what is involved.

Thanks,

Eric

[Unable]

IWP sux.

Oops. Excuse me. What I meant to say was that IWP is very limiting. It creates the HTML "on the fly". That means that there is some builtin programming. You either must find adequate documentation (lots of luck), be a cyber-psychic (lots of luck), or do a lot of trial and error (good luck).

And all of your ScriptMaker scripts that you have worked so long to develop ...

CWP is the way to develop your browser solution.

[Anatoli]

IWP = Instant Web Publishing

CWP = Custom Web Publishing

IWP is next to useless

CWP is quite all right, but it is still not fully developed language for easy programming.

And FM on web is quite insecure.

If you really want to have secure and programmable web part of your solution, You need PHP or Lasso engines.

If you need only solution and security isn't much of concern, then CWP programmed in CDML language plus some JavaScript in web pages will be maybe OK.

YMMV

[Kundinger]

Hello again Eric,

Quick answer... LOTS of WORK!

Here's the deal... you basically have two FileMaker web options and other options from other software developers.

FileMaker Instant Web Publishing (IWP) is built-in to FMP Unlimited... it serves up web pages using built-in (pre-designed) web pages (format files). You have very little options for customizing... meaning you can't modify the 'look & feel' of your system. You need to try this option and determine if the cost (small) are worth the built-in 'look & feel'... does the public need to see these pages, or... are they only view by organizational staff?

FileMaker Custom Web Publishing (CWP) is where you build your on web pages (format files) that interact with FMP files to display the data to web browsers. This is typically done with HTML, XML, and CDML (a FileMaker subset of HTML). You create the system with your organizations 'look & feel'... this is referred to as 'branding' and is very important in the marketing world... particularly if your pages are accessed by the public. Again... you need to understand the 'balancing' of the learning & development costs (large) against the customized 'look & feel'.

There are also some web security issues with both of these solutions... there are some 'work-a-rounds', and FMI is addressing these security risks... see their web site for details. You should discuss with the upper-level management of your organization, the value of the 'DATA' in your organization.

Other options... use systems (or combinations) created by other software developers... Lasso, PHP, MySQL, Java, etc. to develop your own web pages (format files) that interact with FMP files. This is just like FileMaker CWP... utilizing other systems. Again, there are large learning & development costs, but you get the customized 'look & feel'.

My feelings... I use FileMaker IWP for simple, quick & easy data viewing where security is not critical. I have spent the time to learn HTML, CDML, and some XML & Java. I therefore utilize FileMaker CWP for more secure and complex solutions. I've stayed away from other systems... purely due to the cost of learning them. This will inevitably change as I more forward with my clients. I'm investigating the DreamWeaver/Lasso system... and the possibilities of completely converting to 4th Dimension. I used 4D over 15 years ago... prior to FileMaker... it's looking more inviting.

My recommendations... play with FileMaker IWP on FMPro. See how it functions for your organization... it may be all you need. Then learn how to output XML web pages from FMPro. This will give you an idea of the capabilities and learning & development costs to a customized solution. Your upper-level management may then opt to out-source the web development because of these costs. You could then focus on the FMPro version and interact with the sub-contractor to see that web system functions smoothly.

Hope this helps... Good Luck!!!

Bob Kundinger

[email protected]

[Eric Kelly]

I am hugely grateful to all who have posted, particularly Bob Kundinger. This is a terrific forum. Your info has greatly increased my understanding of the issues involved in our project.

As it turns out, security is VERY important, while "branding" or prettiness isn't -- the main function of this system would be to allow psychotherapists to enter their confidential client notes from remote locations, rather than having to come back to the clinic to do it, and also to allow supervisors to review notes, and administrators to review productivity stats.

If I understand the advice above correctly, we should go with some sort of third party application to interface with the FM database, rather than use either of FM's built-in tools, because of security concerns. We are a non-profit, so cost is a big issue; also, the database tends to be a bit sluggish as it is, so speediness would be a consideration in whatever tool we used. Given this extra info, would people care to recommend any particular third party tool (Lasso, PHP, etc.)?

Thanks,

Eric

[Anatoli]

Mariano Peterson would go for PHP, me for Lasso. It depends on what you or your help will prefer.

[John Caballero]

Mariano IS the PHP guy for his company.

Just ask him!

[Anatoli]

RE: You can't have everything. Where would you put it?

That IS great idea

We are saying, "money isn

[Christian Coppe]

Maybe I can add some comments, as I'm working in the medical sector and the web security is an important issue. I think that the time you spend to learn the languages of the tools to use to publish the web pages is important, as it seems that you start from scratch. IWP is definitely not a good idea. It is easy, but you learn nothing with it, without talking about the security issue, mentioned above. CWP is a good opportunity to learn HTML for the pages desing and the forms, and CDML for the databases interactions. It is realy easy and quick to learn, and mandatory if you want to develop web pages.

But not enough and a second step is necessary. You then have to use a midlleware, as PHP or Lasso, for two reasons : security and development possibilities. When developing your web pages with CDML, you will be naturally tempted to use FMP scripts : it is so easy ! Never do that. PHP or Lasso can perform the same tasks, directly from the web pages. By this way, as recommended by Anatoli, FMP is your database system and the midlleware is your software. Both are separated. Is it difficult ? I started to use Lasso 2 weeks ago from scratch, and the job is completed today. It is secure, robust and very fast. To be honest, I have no experience with PHP, but I was surprised whith the time spent to implement Lasso. My development is fully validated, following the FDA guidelines.

A last issue : as you work in the medical sector, develop a solid login system, preferably in two layers : one to control the personal login/pwd of the user and the second one to open the entry database(s).

[Keith M. Davie]

"...you will be naturally tempted to use FMP scripts : it is so easy ! Never do that."

Oh bullroar! A poor workman blames the tool.

That is flat-out erroneous advice. ScriptMaker on the web can be an effective and useful tool. In point of fact its best use is for security. Just because you either could not figure out how to effectively use the tool, or were too lazy to try, does not make it ineffective and unworkable.

[Christian Coppe]

I cannot agree, but I wonder if I really want to discuss about it. FMP being monothread, it cannot manage simultaneous script calls by the web. Maybe your experience is with a web site with low traffic, and you are lucky up to now. In the medical area, it is not the case. You then need a multithread midlleware. And...I tell it by experience !

[Keith M. Davie]

I am more than well aware of the single-thread nature of ScriptMaker. That does not mean it cannot be used safely on the www. There is a way to work around the single-thread capabilities, to allow the solution to capture whether or not an event runs , to notify the client appropriately and to either automatically resubmit the event for processing or to allow the client to do so. Working around the single-thread drawbacks a successful solution is possible.

You may tell it by experience; the fact is that your experience is severly lacking.

My experience is of demonstrated success.

[Anatoli]

Deja vu

[Mariano Peterson]

How have you managed to work around the single threaded issue, Keith? Using a RAIC of FM Pro clients in combination with a smart router or the Web Server Connecter?

How do you notify the client? Via the send mail script step? Via a command line tool called by the send message step? Via send mail in CDML?

Eric:

As far as publishing your data to the web, I would absolutely not waste your time with CDML and instead learn PHP or Lasso. CDML is far too limited, and too often you are left to find a time consuming and fragile work around for what are normally very simple and straight forward web development tasks.

Frankly, I found learning PHP much easier than learning CDML (I learned CDML first, and sincerely wish I had not spent my time running in the wrong direction). CDML can be tempting because it is a small language, and is included with FileMaker. The problem with CDML is also that it is a small language, and while you can learn the syntax almost immediately, you'll waste your time trying to solve problems that are already handled in almost every single other middleware application out there - PHP, Lasso, ASP, Perl, etc.

I like PHP. For starters, its free, commercial strength, and integrates perfectly with the Apache web server, which is also free! PHP is a [relatively] object oriented language, which will allow you to build much more manageable, maintainable, and extensible code. Also, PHP syntax is a "c based" language. This means that the syntax for PHP is very similar to C. This will make it much easier to learn other c based languages like JScript (ASP), JavaScript, and many more.

Also, there is a freely available class (a code object) written in PHP that enables your PHP scripts to communicate with FileMaker extremely easily. It uses XML over HTTP to interact with FileMaker, but abstracts it beautifully so that you don't have to know anything about XML at all to use it.

The fact that PHP uses XML over HTTP is great because that is the most efficient method for FileMaker to serve up data to 3rd party applications (except perhaps for Lasso's engine).

Also, if you need to secure your data at any level, you really shouldn't use CDML. PHP, Lasso, ASP, and Perl will give you far better security than CDML.

Finally, I strongly agree with Christian. If you can avoid it, it is much better not to call FileMaker scripts from your web code. Every time you call a FileMaker script, the FileMaker node running the script becomes unavailable to handle other web requests until the FileMaker script has completed (it is single threaded, or only capable of handling one thread/process at a time). This means that if other web users navigate to your web page, the page will not load until after FileMaker is done running the script. This is bad.

Unlike FileMaker, PHP and Lasso are multi-threaded. They can process multiple web scripts (not FileMaker scripts) simultaneously. If one of the scripts is very lengthy, the other scripts will still continue to serve up web pages to other users even while the long script continues to run.

There is very little you cannot do in a web script that you might otherwise do in a FileMaker script. On the contrary, web scripts are vastly more capable than FileMaker scripts. So, why not write the logic into your web scripts, make use of the more powerful tool that is available, and not worry about single threaded processing slowing things down?

Re: "In point of fact its best use is for security"

This is only true if you're using CDML. If you're using middleware (PHP, Lasso) then you don't need to worry about using FileMaker scripts for security. While you could build a house out of cards, why not build it from wood and nails (or steel for that matter )? Specially if they're both the same price (since PHP and Apache are free)?

[Anatoli]

It is easy to run scripts from web Collision? Not a problem. Just let another script set the field with flag or value indicating if the script was successful or not.

I will never rely on that obviously. Keith yes

[Keith M. Davie]

Mariano, it is done in a script with a flag, as Anatoli suggests. Anatoli hasn't stated it quite properly, but he is close. Somewhat like the superior racehorse which lacked motility as a stallion, Cigar.

And that is more information than I had to work on when I developed my solution. Internet traffic, contrary to Anatoli's claims, is not an issue with my solution. Certain scripts, like a looping script, can be issues. But for security, my method can remove "confidential" data completely from web accessible db files, and similarly can access that data via the www.

I'm not a programmer. But I can develop ok. Thanks for asking.

BTW. When Anatoli saw my solution three years ago, he said it could not work. Freakin COULD NOT WORK, PERIOD. I do believe he as since eaten crow on that one. Now he sells Lasso.

[Mariano Peterson]

I'm still convinced you should try and avoid calling FM scripts from your web code. If your web solution is authored in CDML, then I agree you will need to use FM scripts to create a (sort of) secure login module. However, your solution will still be vulnerable, as there are too many bugs and loop holes in the CDML security model. To provide any reasonable level of security to your web solution, you really need to use standard middleware, like PHP or Lasso. I think that FileMaker even concedes this in one of their white papers.

Further, calling FM scripts from your web code will severely decrease performance on the web. A single FMP node can only run one FM script at a time. Running an FM script, even a short one, ties up FileMaker for a significant amount of time in the web context. On the other hand, manipulating an FMP node from middleware (and not running an FM script) ties up the node for a much shorter period of time. This allows FileMaker to free itself to handle the next request much faster. It is not that the middleware is faster than FileMaker (although it is), but rather that the middleware runs independently of Filemaker and confines its interaction with FileMaker to quick, short, requests.

Remember, FileMaker is not tied up for the duration of a web script -- it is only tied up for the brief moment it takes to respond to the request from the middleware. A single web script will typically have to make numerous calls to the database during its execution. Freeing up FileMaker as quickly as possible is very important so that FileMaker can respond to other parallel instances of the same web script. Basically, once the web script has loaded the data from FileMaker, it can peform as many manipulations and apply as much logic to the data as needed, all the while leaving FileMaker available to respond to other requests.

Just about every action that can be performed in an FM script can be performed in a web script. Usually web scripts even offer more functionality. You can always check the result of your action in a web script as well - you don't need to rely on a FileMaker script to determine if an action failed or succeeded.

Anyway, I still must strongly suggest that web scripts not utilize FM scripts, with the exception of CDML, in which case FM scripts are an unfortunately necessary to overcome CDML's shortcomings.

[Keith M. Davie]

Mariano, I'm convinced that, for most developers, the solution is beyond their grasp, mostly because of laziness.

Yes ScriptMaker processes one event at a time. And if two near simultaneous requests are made, one event will not perform, yet both clients will be informed of a successful transaction, because CDML does not, in and of itself, recognize an event failure. To resolve that issue is the reason to create the solution.

Regarding your time concern, when I was demonstrating the solution on a web site for Pro developers, the script which removed data from web accessible db files operated, on average, in 38 milliseconds. A complex search on a large db file can take longer.

ScriptMaker is not the solution if you need loops, such as for multiple record edits. JavaScript is the answer there.