Month: February 2020

What is it?

The Session Table is a utility table created for each individual instance of a user’s access to a file. It is created upon entry of the file (OnFirstsWindowOpen script trigger) and closed out upon shut down (OnLastWindowClose script trigger) of the file.

This is a sample of what a Session Table would look like in the Database Manager:

Why Should Every File Have it?

• Helps to track Users Entry and Exit from File – It is critical that administrators know who is entering and how often and how long they are staying in the file. This can be useful for analytical purposes as well as for security. If you know that something malicious happened in a file during a specific period of time, you can go to the Session table to find the users who were in at that exact time.
• Collects User metadata – Using FileMaker’s built-in calculation functions, you can acquire metadata about the user such as the type of device they are using, how they are accessing FileMaker (FileMaker Pro Advanced, FileMaker Go, WebDirect, etc.), the user’s IP address and many more pieces of information. Being aware of all of this can help the file administrators analyze what kind of user is spending time in their file in order to help make decisions.
• Can be utilized to track user actions – If it is imperative that all user actions are tracked (an example being for HIPAA compliance) then the session table is where this can take place. You can create a login in the Session Table by using script triggers on fields and layouts.
• Can be utilized for Creating Session-Based Tables – There may come a situation where you have to build a report or list that combines multiple data into one table multiple users can access this at the same time. As a result, there needs to be a way to distinguish which records are for which user session to make sure that one user does not see other users’ data. The Session table comes in use here. By utilizing the user’s specific session ID, you can determine which records are for that user’s list/report simply by including their session ID. This can be quite complicated, so we will have a blog in the future based solely on this topic.

How can you add it to your file?

After creating the Session table, you must make sure it is connected to your files GLOBAL, SYSTEM, or UTILITY table (this table should be the table in the file that contains all global fields).

At Kyo Logic, we like to name our global table the SYSTEM Table. (We also like to use three-letter codes as part of the names of our tables to make the table occurrences in the relationship graph easier to understand). And we connect SYSTEM (SYS__Sys) to SESSION (SYS_SES__AC) through this simple relationship:

Now that we have the infrastructure in place, we need to build the script to create the Session record.

The script that we have built, “Startup,” we have running OnFirstWindowOpen.

This script first creates the user’s unique SYSTEM record and then creates their unique Session record. It then sets all of the metadata fields that you would want to acquire. Finally, it sets the user’s Session ID to a SYSTEM global field so that the file can obtain the user’s session ID at any time.

We also include the “shutDown” script OnLastWindowClose to set the logout metadata field.

And, there you go. You now have a session table that you can use to track your user access into the file and so much more!

The FileMaker command  Perform Script on Server  offers a powerful tool for speeding up performance by keeping the process local to the server. This option can greatly improve situations where significant data must be handled or where the server connection is slow.

The script command has a simple syntax and offers the option of whether or not to wait for completing the script before the user regains control of their session.

Perform Script on Server [ Specified: By name ; {script name} ; Parameter: {parameters} ; Wait for completion: off ]

Deciding on whether to select the  Wait for completion  option depends on whether the script must complete before the user can continue with their current process. For example, the script might need to prepare a list of addresses before the user can check off which addresses to select. However, in a surprising number of cases, waiting for completion is not necessary and the user experience can be improved significantly by turning  Wait for completion  off.

Server Talkback

Running a server script without  Waiting for completion  sets up an independent user session on the server to complete the script. The downside is that the user can lose control over the script process and cannot see progress during completion. Server talkback can provide a channel to communicate with the user and even provide user control over the script in process.

Server talkback sets up a channel for the server to communicate information back and forth with the user. In this approach, server talkback is achieved by sharing a session record between the user and the server that includes the information required. A method that we use works as follows:

A session record is issued to a user when they log onto the application with a UUID that can be shared with the server. This UUID is passed as a parameter to the server when the Perform Script on Server command is called. The record includes all the control and reporting fields required for the server to communicate with the user.

Javascript object notation (JSON) provides a handy mechanism to pass script parameters in this manner. The server script captures the session ID and sets up a corresponding connection to the session record. An easy way to control access to the session record is for both the user and the server to use a global field “selector” to identify the session that will be used to communicate. This global connection can be set in one or more places as required in the relationship graph. In this example, a global in the system (SYS) table has an equi-join relationship to the Session table.

Since the server and the user now both have access to the session record, data can be easily passed back and forth as needed. An absolutely fundamental requirement of this approach is to always commit session record changes as soon as they happen. This procedure will ensure that the session record is not locked and that the user’s data is refreshed right after the server commits.

Some useful functions that we have been using include: debugging server scripts by building a script trace log and transmitting it back to the user; providing progress reporting on a long batch runs and allowing the user cancel; sending commands to a star controller on the server to perform various outcomes; and reporting back API batch processes. We will dive into some of these use cases in more detail in the future.