Interpreting Spotfire Logging to Understand User Activity

  • Are you a Spotfire administrator?
  • Would you like to know more about what users are doing in Spotfire?
  • Is logging turned on but you don’t quite understand what it’s telling you?

If your company is using Spotfire server, the logging feature is available to develop an understanding of user activity.  I highly recommend utilizing this feature because your company will run into the scenario I found myself in recently — renewal time — and logging is critical to understand usage.  However, it’s not enough to know how many people are using the application.  It’s also important to understand HOW they are using it.  In other words, are users opening the desktop app simply to view data when they could be using the web player, which is a cheaper license.  Or, are they actually creating and saving content?  These are very important questions that significantly impact licensing costs.

I’ll start with a brief overview of what you can get out of logging.

Spotfire Logging

Overview

Questions you can ask and answer include…

  • What data sources do users access — information links, data connections, files, etc?
  • How often are they accessing it?
  • How many Spotfire files are out there in the library and stored as files elsewhere?
  • When was the last time someone logged in?
  • How many active users are there?

The data provided in the log entries include… (from TIBCO documentation):

  • The time of the action.
  • The time the server logged the action.
  • The addresses for the server and the computer where the action was performed.
  • The user name who performed the logged action.
  • The category of the action, specifying whether the action originated on the Spotfire Server (such as an admin action) or from a service (such as Automation Services).
  • The logged action, including properties specific to the action performed.
  • Whether the action was completed successfully.
  • The session and service instance unique identifiers.

Figuring out exactly what users are doing in the app is a bit tricker, but I’ll come back to that. Next, let’s talk about how to setup logging and view the information.

Setting Up Logging

Now, logging isn’t enabled by default.  The Administrator must configure logging, which you can do with these instructions.   As you’ll see in the instructions, logging can be written to different locations — a file, a database, or a web service.  If logging is written to a database, it’s then very easy to connect information links to the views or tables and review the data in Spotfire.

I counted all of the tables and views in my Spotfire action log database, and there are 75 of them.  However, the DXP TIBCO provided for logging only connects to two — ACTION_LOG and AUTH_LOGIN_LOGOUT.   TIBCO provided both the DXP and the information links, although you could easily set up your own against those two tables in the database.

Logging Categories & Actions

Once connected to these tables, the next step to understand what the data means.  There is a lot process.  ACTION_LOG contains 26 columns and AUTH_LOGIN_LOGOUT has 17 columns.  Some are intuitive, such as the username and login/logout times, but others, such as id1 – id6 are not. I’ve taken a screen shot of the categories from TIBCO documentation below.  Scanning these, you might realize logging details where requests come from and what users are connecting to, but it doesn’t tell you much about what people are doing in the desktop app.  Hmmm….what to do about that…????

Logging categories
Logging categories

The way I look at it, there are two ways to get a handle on this…

  1. Read the documentation.  I recommend starting with the logging categories and actions. This is kinda boring and might not actually help you ask and answer the right questions. OR….
  2. Partner up with another user and have them log in to Spotfire and perform a series of actions or small tests and see what comes back in the logging.

I found the second method to be much more effective, and that is exactly what I did when I need to give managers a quick answer.

My Q&A

After we recorded login times and performed tests, I created a quick cross table with the category and action on the vertical axis so I could see which actions belonged to which categories.  It’s also important to note that logging had been turned on in our environment for several years, so I had a healthy cross-section of comparison data to compare my tests against.

Now, keep in mind, one of the key questions I needed to ask and answer was — Are users taking advantage of the desktop app? 

Thus, I needed a logged action deliniating a user logged into the desktop app to only view data from a user who creates and saves content.  As you can see, there isn’t much to help answer this question.  Even digging deeper into the analysis_pro category didn’t yield much.  Two actions might be helpful — set_page (when a user adds a page) and apply_bookmark.  Obviously, I can’t use apply_bookmark as my criteria, but set_page will do.  If I user logs set_page, they are creating content.  If this is null, they are only viewing data and are not creating content.

Logging actions per category
The screenshot does not show a complete list of all categories.

 

I combined this logged action with the last login time to figure out who was active and who was using the desktop app to create content.  Problem solved.  Questions answered.

Now, if anyone knows why apply_bookmark is worthy of logging, please let me know.  I’d really like to know why this is a logged action.

In conclusion, logging generates a lot of useful data.  This post should help you understand the basics to ask and answer simple questions.  If logging ever moves beyond second to last in my priority list, I’ll post more on the subject.

Spotfire Version

Spotfire version 7.9.1 was used to develop this content.

Guest Spotfire blogger residing in Whitefish, MT.  Working for SM Energy’s Advanced Analytics and Emerging Technology team!

Leave a Comment

Your email address will not be published. Required fields are marked *