Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

Best way to test a multi-user solution with server

Question asked by jakhay on Jan 12, 2018
Latest reply on Jan 12, 2018 by philmodjunk

Like • Show 0 Likes0
Comment • 9

I am developing a new app for a client who already has a server setup and FM running on it with multiple users.

I am doing all of my dev locally on my machine and am getting to the point where I will need to test to make sure that there are no problems when multiple users are running the app simultaneously.

Short of deploying my app on the server and connecting to it using multiple machines (or reproducing that setup locally) - is there a way to test this? For instance, is there a way to run multiple clients on my dev machine at the same time? Could I run a client and server on the same machine? Or do I actually need three physical machines in order to test 2 clients plus server?

No one else has this question

Outcomes

9 Replies

techt Jan 12, 2018 8:33 AM
Mark Correct
Correct Answer
Are you concerned about a licensing issue, or something else with coding? Record locking should keep you out of most trouble, but it is possible to have shared fields that users might try to update simultaneously, and in those instances, I would recommend using global variables or code to prohibit that from happening or at least happen in an orderly fashion (e.g. invoice sales numbers). Is this a Windows or Mac environment? I haven't found anything for the Mac, but there are some nice automated testing programs for Windows that can simulate all kinds of activity by basically recording activity and then "playing it back" on a number of computers at the same time. Limiting initial found sets and not letting users (easily) Show All Records can help performance for large record sets.
Like • Show 0 Likes0
Actions
philmodjunk Jan 12, 2018 9:21 AM
Mark Correct
Correct Answer
A couple of thoughts:
You can simulate a number of "edit lock" issues by opening two sets of windows on the same machine and simulating typical user workflows on both sets of windows at the same time.

FileMaker Pro, out of the box, can host a solution for 4 other FileMaker clients. Not a good production set up, but adequate for user testing.

No amount of testing in advance is likely to cover every possible user action in a large complex solution. I've painfully learned the hard way, that if you plan on upgrading an existing live system, do some disaster planning in advance. Set things up so that you can quickly revert changes if your new version fails miserably despite your best efforts at planning for all eventualities. I often keep old script steps in place in a script for a limited period of time so that I can quickly disable the new and enable the old to flip a script back to the previous set up. (I use comments to identify what steps will need such handling in case of emergency.)

I'll even have the original VM on hand with the older version and a new VM with the new version so that we can literally "flip over" to the old server if needed. (Will be set up like that on this Monday if all goes as planned for a client that I'm upgrading from 10 to 16...)
Like • Show 1 Like1
Actions
jbrown Jan 12, 2018 10:15 AM
Mark Correct
Correct Answer
I began my post by wondering why you need to test it for 'multi-user issues'. My first thoughts were with record-locking. IF you follow those principles of FileMaker records, you shouldn't have any problems:
1. Explicitly open a record thru a button.
2. Check to see if someone else has locked it.
3. If not, proceed with editing
4. Explicitly commit or revert.
Other multi-user issues that might come up are:
1. Time zones for timestamp fields
2. accounts and priv sets (making sure the system knows who the person is and what they can do in the file)

But then as I was writing it, my original post sounded crass–it sounded like you should build so you don't have to test. That's, of course, ridiculous. Test test test away. However, I think the advice is still sound: following the principles of FileMaker (security, record locking, etc) can give you the best possible chance of developing successfully.

I agree with Phil though in ways to test it. And yes, put it on a server. Why not? That's the best way to test multi-users.
Like • Show 1 Like1
Actions
jakhay @ philmodjunk on Jan 12, 2018 1:39 PM
Mark Correct
Correct Answer
I wanted to test in the environment that the app will be running in just on general principle because I'm not sure what issues might crop up. In addition, I have one specific issue that I am concerned with.

I have a layout which displays records. One of the fields in the record is name field.
To make it easy for a user to see all of the records containing a certain name, I created (in the top nav area) a pop-up menu which shows the list of all the possible names and allows them to pick one. Then I created a button next to that which does the find.
The searchName picker fills a global field in a TO that holds the name to search on.
I am concerned that if two users are using this feature at the same time, that one would affect the other.
I thought I had read that global fields would behave like global variables, in that each user would have their own set of global fields, and I wanted a way to verify this.
When I open two windows in my local filemaker app (running FM pro 15 advanced on Mac os), if I choose a name in one window, the field in the other window is affected. This is not what I want. I'm not sure if this is a valid test, though, for this piece of functionality.
Like • Show 0 Likes0
Actions
jbrown @ jakhay on Jan 12, 2018 1:44 PM
Mark Correct
Correct Answer
Fields with global storage are user-specific. Your set up is a common use case solution, so that will work nicely.
If MyTable::SearchName_g field has global storage, then you and I will have different values in there. I can change the value in my field and it won't effect you.

You're running into an issue because you have the same app in two windows. . .
Like • Show 0 Likes0
Actions
philmodjunk Jan 12, 2018 1:49 PM
Mark Correct
Correct Answer
Note that I said that you can test record locking issues this way, not all hosted solution based issues. You'll be able to see the same global data in both windows so that isn't testable in this way. But if you open a record for editing on one window, you'll find that you can't in another so you can test the record locks and see how your interface handles them when they occur if you've taken steps to avoid the locks as is often the case.
Like • Show 0 Likes0
Actions
philmodjunk Jan 12, 2018 1:50 PM
Mark Correct
Correct Answer
"You'll find that you can't edit the same record in another window" is what I meant.
Like • Show 0 Likes0
Actions
jbrown @ jbrown on Jan 12, 2018 1:51 PM
Mark Correct
Correct Answer
I should say, this is assuming the file is hosted. I'm not sure about a sharing model. I've never used that and wouldn't use it
Like • Show 0 Likes0
Actions
philmodjunk Jan 12, 2018 1:55 PM
Mark Correct
Correct Answer
Agreed. File sharing from a shared volume is dangerous. You can end up with corrupted files that way. File is opened by FileMaker Server (or by FileMaker Pro for testing purposes) then the others use Filemaker Pro or GO on their own machines to access the hosted file. (Then there's web publishing but that's also not going to directly access a file in a shared volume.
Like • Show 0 Likes0
Actions

Best way to test a multi-user solution with server

Outcomes

Related Content

Recommended Content