Usage Statistics Logging
This section describes how to activate the logging of usage statistics.
Note that the process of logging email is completely separate from usage statistics logging. Email logging is covered in Email Logging.
Key Concepts
This section offers an overview of usage statistics logging.
Benefits of Logging
After you start logging data, you can do any of the following, as appropriate:
Use the portal’s built-in Usage Statistics feature, which lets you view data about usage within any particular context. For details about the data you can view with this feature, see the Usage Statistics section.
Set up a custom reporting strategy using the logging database. Custom strategies are not covered by this guide.
Data That Is Collected
When usage statistics logging is enabled, the system logs data about each of the following types of events:
Each time a user adds, edits, or deletes one of the following:
a page
a feature instance
a resource
a post (or a reply) within a Forums feature instance
a category or topic within a Forums feature instance
Each time a user downloads a specific resource file.
Each time a user visits a specific resource URL link.
Each time a user views a specific category, topic, or post within a Forums feature instance.
Each time a user sends email within an instance of the Group Directory feature.
When you activate usage statistics logging, the system stores usage data in the JICS logging database (which by default is called ICS_NET_STAT). Storage of usage statistics is the sole purpose of this database.
The logging database includes fact tables, aggregate tables (summary tables) and dimension tables (tables that centralize attributes pertaining to the fact tables, such as features and pages). This section highlights a few key tables.
SST_ActionType Table and SST_TargetType
The system organizes data in part by recording “actions” that can be performed (for example, when a user creates or deletes something) and “targets” (such as a feature instance or a page). The various types of actions and targets are defined, respectively, in the SST_ActionType table and SST_TargetType table.
SST_Stat*
The logging database includes three tables that detail instances of specific actions taken against specific targets. These tables have names beginning with “SST_Stat.” Records are allocated among these tables based on date, as follows:
SST_StatCurrYear – stores data that was logged in the current year (anything recorded from one year ago through the current date).
SST_StatLastYear – stores data that was logged in the previous year (anything recorded between one and two years before the current date).
SST_SiteStatArchive – stores historic data (anything recorded two years or more before the current date).
The system also includes a SST_SiteStatistic view, which contains data from all three tables. If you are familiar with previous versions of JICS, note that the SST_SiteStatistic view functions like the old SST_SiteStatistics table.
As part of the logging process, JICS leverages Service Broker, a feature of SQL Server. With this approach, the system relies on a system of queues, to which JICS sends “messages” about usage. JICS uses a polling stored procedure that runs constantly and checks for new messages every 30 seconds (by default). This stored procedure is described in more detail in the ICS_NET_STAT - Process Usage Stats section.
JICS uses three jobs to process and maintain usage statistics.
ICS_NET_STAT - Process Usage Stats
The ICS_NET_STAT - Process Usage Stats job runs a stored procedure that processes messages (by taking each logged event for a given session from the Service Broker queue and placing it in the appropriate table in the logging database). This stored procedure also updates the dimension tables with any new or changed data.
This procedure operates continuously as long as there are messages to be processed. If there are no messages, the procedure will check for new ones every 30 seconds (by default—this interval can be customized by changing the WaitForDelay setting in the SST_SessionInfo table in the logging database). The ICS_NET_STAT - Process Usage Stats job should always be in the executing state.
Every 24 hours, the system checks to see whether the ICS_NET_STAT - Process Usage Stats job is still running and, if necessary, restarts the job. Note that the job will never be started while it is already running. It will be started only if it has stopped unexpectedly. This check is done each day at midnight.
ICS_NET_STAT - Process Usage Stats Aggregates
The ICS_NET_STAT - Process Usage Stats Aggregates job runs a stored procedure that looks at all of the logged events processed by the ICS_NET_STAT - Process Usage Stats job and updates the various aggregate tables appropriately (by adding data and/or updating changed data). The job uses the SQL Server Agent Job schedule to run every 10 minutes by default. This interval can be adjusted using SQL Server Agent. Note that it’s not recommended that you set the frequency to less than every 5 minutes.
ICS_NET_STAT - Process Usage Stats Clean Up
The ICS_NET_STAT - Process Usage Stats Clean Up job runs a stored procedure that does “maintenance” work. This work includes closing Service Broker conversations that have been completed and moving logged events from the SST_StatCurrYear or SST_StatLastYear tables to the SST_StatLastYear or SST_SiteStatArchive tables, respectively. This job is set to run at 3 a.m. daily.
When upgrading from older versions of JICS to JICS 2024.1 and above, Bookmarks and Handouts portlets will be migrated to be Resources portlets. When this occurs, previous Usage Stats entries will NOT change at all. They will still display "Added Handout" or "Deleted Bookmark Set", etc.
However, any new Usage Stats entries after the migration to the new portlet will display "Resources" instead of "Bookmarks" or "Handouts". So, for portlets with activity before and after the upgrade occurs, there will be two different sets of actions, one for Bookmarks/Handouts, and another for Resources.
The name of the portlet will continue to appear in the logs and will not change as a result of the upgrade. If a Handouts portlet happened to be named "Handouts", it will be migrated to be a Resources portlet still named "Handouts". That name will still appear in the portlet name-based rows (i.e., "Viewed Handouts Portlet").