Logging PSoS Activity: Episode III – Return of the JSON

In looking back at our initial approach to logging FileMaker PSoS (Perform Script on Server) activity, I reflect back on a number of times where this has been extremely helpful. If you have come to rely on the benefits of PSoS then you also know some of its challenges — one of the biggest is debugging and monitoring how long sessions take.

Since FileMaker 16 introduced JSON, in new systems we’ve switched over to using JSON as the main way of exchanging data for parameters. Because we also use PSoS in new systems, we updated our method for PSoS Logging and this blog entry talks about the changes we made there and also restates the usefulness of this log.

So as mentioned, we update it to no longer require our custom functions for parameter passing. Those date back all the way to the six fried rice methods. After more than a decade of fine use, we finally retired them. Now in any new systems we build, we pass parameters using JSON.

It never ceases to amaze me how we can always improve our code with new ways of thinking.

There is one custom function that is at the heart of the way this works, I think it is very forward-thinking in its architecture.

Credit Steve Senft-Herrera (aka “Steve”) of Beezwax for redefining things using this approach. And Arnold Kegebein for technical review and corrections.

LogPsosParameter ( StartOrEnd )

NOTE: We store our token in a local variable scoped to the current script. This means we can set it at the start of the script, and still retrieve it at the end of the same script. The custom function builds the JSON object at the time it is called.

The first time called with Start, it builds the ID for the script. When it is called at the end it can then use that variable to locate and update the PSoS log record. The nice enhancement that Steve made in the custom function is that it doesn’t have to return the PSoS ID it is working with — the ID is in a variable that both the script and custom function have access to that save variable. One would think that defines the laws of variable scope, but no, it works and it is great. And Steve is a genius!

Here is what the PSoS script looks like in action:

Paired scripts

There is another design choice that we make when relying on PSoS and that is to have scripts work in pairs. So, we have a local script that might make sure that everything is OK to run the script on server. For example, often times we’ll do validation on the date before it gets set to the server. If everything is good then we’ll call the script via PSoS. Sometimes we’ll want to wait for the result sometimes we don’t. In either case, I find it helpful to separate them out into 2 parts.

Some developers like to have the patter of a single script being self-calling. I find that too confusing when you are trying to debug it. Just my preference!

NOTE: There are limits to how many concurrent PSoS sessions you can have. That setting can be found on the Sever Admin –> Database Server –> FileMaker Clients.

Maximum Simultaneous Script Sessions:  ###

It allows you to set this number to a very high number, but good rule of thumb is to not set it more than double the number of cores that you have.

Exploring the log

Once wired up and you want to explore the log, here is an example of what it looks like. There are 2 important columns of information: RS and RE. RS means the total number of scripts running at the start of this script, and RE means the total number of scripts running PSoS at the time this current script terminated. So, in the example below you’ll see a section primary in green. What this tells you is that you maybe have a runaway script.

What it can be helpful at telling us is how long these scripts have been running concurrently.

For this log to work it needs to have 3 custom functions, 1 table, 2 layouts ( one for the PSoS Log and one for the PSoS report ), and 1 script. Let’s look at how this works. The other thing that we recommend for PSoS logging to work reliably, would be to follow a pattern called Single Pass Loop. What this pattern allows you to do is guarantee that your script has one entry point and one exit point. This is important for PSoS logging: if you can guarantee that you only have one exit, then you can always call the terminating part for doing PSoS reliably. Including the calls for PSoS Logging, here is what the basic structure of the script would look like.

Implementing this into your solution is done with a few easy steps:

  1. Copy the 3 custom functions
  2. Copy the PSOoS table ( the default layout will be referenced by the script )
  3. Create a new layout named “Report PSoS”
  4. Copy the PSoS script folder ( it should copy over the folder and the scripts )
  5. You are ready to start integrating PSoS Logging into your solution!

Enjoy! And please let us know if you have any questions or need any help.

Demo File


Account: Admin
Password: PSoS

JavaScript for FileMaker with bBox

In 2017, we released several new versions of bBox plugin. In the spirit of yearly retrospective, let’s highlight perhaps the most exciting new bBox feature: JavaScript for FileMaker. The new JavaScript for FileMaker functions in bBox are great for heavy duty JSON processing tasks, repurposing JavaScript code for use in FileMaker, or other computation intensive processing. Here’s a recap…

Continue reading “JavaScript for FileMaker with bBox”

FileMaker Server 16 Gotcha: Get ( SystemDrive ) and Friends

FileMaker 16 has been out for several months, however we wanted to call attention to a change that can effect your application’s use of server side scripting. Recently, we upgraded a client project to FileMaker Server 16, and found that critical functionality had mysteriously broken. After a bit of sleuthing and gnashing of teeth, we found that changes to the output of Get(SystemDrive), when executed server-side (PSOS or via a scheduled script), was the culprit.

Continue reading “FileMaker Server 16 Gotcha: Get ( SystemDrive ) and Friends”

Creating Your Own SSL Certificates For FileMaker

Typically, you buy an SSL certificate for a server from a SSL vendor. However, some companies may decide that they want to issue their own SSL certificates. Often this is because the domain is only used internally, and most vendors don’t easily allow (if at all) the signing of server certificates for non-public domains. Additionally, issuing your own certificates can remove complications caused by the certificate verification process used by most vendors, and there are no fees needed for each certificate.

Continue reading “Creating Your Own SSL Certificates For FileMaker”

LOgiCATOR Part 3: Ready, Set, Integrate…Into Your FileMaker Apps

We’re thrilled to announce the official, “integration-ready” version of LOgiCATOR. LOgiCATOR is a modular search interface for FileMaker that can be easily integrated into new or existing solutions. It’s designed to help users locate data with logical precision, via a powerful yet intuitive interface for searching across FileMaker tables. This article includes a download link for the module and demo file, describes what’s changed since the preview version (a lot), and explains how to integrate LOgiCATOR into your FileMaker solutions.

Visit the LOgiCATOR page at Beezwax. Continue reading “LOgiCATOR Part 3: Ready, Set, Integrate…Into Your FileMaker Apps”

FileMaker Konferenz, Salzburg 2017

The 8th FileMaker Konferenz is happening October 12 – 14, 2017 at the Crowne Plaza Pitter Event Center in Salzburg, Austria.

At the konferenz Vincenzo Menanno, director of FileMaker Development for Beezwax presents two sessions on advanced FileMaker development:

Continue reading “FileMaker Konferenz, Salzburg 2017”

FileMaker and PHP 7

At the Custom Web Publishing (CWP) user group at FileMaker DevCon 2017 in July, a number of speakers (and a big thank you to everyone for a great session!) discussed solutions they’ve taken or investigated for making CWP apps compatible with PHP 7.

At Beezwax, we have a client project with a requirement for PHP 7 compatibility, but many of the available approaches were closed to us due to various constraints, so we came up with this solution.

Continue reading “FileMaker and PHP 7”

bBox 0.88 for FileMaker Now Available

We are pleased to release bBox version 0.88. bBox is a free utility plug-in to extend FileMaker solutions to easily use code libraries and macOS-based functions from Python, JavaScript, PHP, Ruby, AppleScript, Bash/sh, XPath, and SQLite. Included is a demo file that has over 180 examples of how you can put bBox functions to work for you.

Continue reading “bBox 0.88 for FileMaker Now Available”

bBox for FileMaker v0.86 Now Available

We are pleased to release bBox version 0.86. bBox is a free utility plug-in to extend FileMaker solutions to easily use code libraries and macOS-based functions from Python, JavaScript, PHP, Ruby, AppleScript, Bash/sh, XPath, and SQLite. Included is a demo file that has over 180 examples of how you can put bBox functions to work for you.

Continue reading “bBox for FileMaker v0.86 Now Available”

1 2 3 15