Skip to main content
Blog

From Black Box to Clear Logs

From Black Box to Clear Logs
Remco Kort
Administrator
Forum|alt.badge.img+2

It’s Friday afternoon when you get the following message from a user: “The application is slow” 😅. No other information—maybe a screenshot, if you’re lucky.

But where do you start? There are many things that can make an application “slow.” And what does “slow” even mean? To begin identifying performance issues, it’s essential to have statistics—to know which procedures are slowing things down.

The Thinkstore offers a new solution to help: the Application Log.

 

What Is the Application Log?

The Application Log is a way to track all tasks, subroutines (stored procedures), handlers, and triggers executed in your Thinkwise application.

It logs the essentials, such as which procedure was executed, its parameter values, and execution time. It also captures other procedures that were called during the execution, giving you a clear view of what downstream code was triggered

Another use case for the Application Log is business auditing. When combined with the ‘Trace Fields’ solution from the Thinkstore, as well as the standard logging functionalities in IAM and system-versioned tables, you get a comprehensive overview of who accessed sensitive data, who updated it, and exactly which procedures were run.

For more detailed technical information, see our documentation.

 

Debugging / logging your Thinkwise Application

The Thinkwise Platform includes several debugging and logging tools, each serving a different purpose. Here's a quick overview of when to use each tool:

  • (Live) Error Log – Use the (Live) Error Log to view all information, warning and error messages generated by Indicium. For example when a task caused an error the Live Error Log will display more detailed information about what went wrong such as database error messages etc.
  • Process Flow monitor – Use the Process Flow Monitor to debug Process Flows when they produce errors or unexpected behavior.
  • Database Event Log – Use the Database Event Log to get an overview of all queries executed by Indicium on your application database.
  • Application Log -  Use the Application Log to track when a procedure was executed, by whom, what parameters were used, and what code was triggered downstream. Especially useful when debugging applications with lots of triggers.
  • Trace fields – Use the Trace Fields Thinkstore solution to track who inserted or updated a record—and when.
  • System Versioning – Use System versioning to maintain a full history of data changes. Combine it with Trace Fields to see what was changed, who changed it, and when. Use the "Logging data available in the GUI" Thinkstore solution to display these historical changes in your application.
  • IAM - Logging is available in IAM for multiple purposes, such as:
    • Authorization - All changes related to authorization are logged automatically. This helps maintain SOx compliance and meet important control guidelines.
    • User monitoring - Logs are available for session analysis (for individual users or all users), two-factor authentication analysis (for individual users or all users), and OpenID analysis.
    • Environment interaction monitoring - Environment interaction logs are available in 3-tier production environments. These logs help detect malfunctioning external services, disks and printers, application connectivity issues, and provider misconfigurations.

Setup

To use the Application Log, your application must run on Thinkwise Platform version 2025.1 or higher.

For more information about the Thinkstore and how to install solutions, see our documentation.

Using the Application Log

After generation, additional program objects will be dynamically assigned to all your tasks, subroutines, triggers, and handlers. These program objects contain the code necessary for the solution to work. We recommend performing a full upgrade to ensure all logging code is correctly written to your application database.

To exclude a procedure from logging, use the tag ‘exclude_from_application_log’

 

Keep in mind: Logging procedure execution adds overhead, as it increases write operations in your database. In real-world deployments, we've found this has minimal performance impact—but please be mindful. If you're concerned about performance, consider tactical deployment only when you need it for debugging purposes.

Application Log Overview

This solution includes a new "Thinkstore" menu, which acts as a central hub for Thinkstore solutions by default. If you prefer not to use this menu, you can remove it from the Application Log base model and add the ‘application_log_header’ view to your own menu instead.

 

When you open the Application Log in your application, you’ll see this overview:

  • On the left: a tree view of all executed procedures, ordered by date.
  • On the right: detailed information about the selected procedure.

Display Nesting

One of the most powerful features of the Application Log is its ability to capture everything that happens during the execution of a task, subroutine, or handler—including all downstream actions such as triggers or additional procedures.

This is especially helpful in applications with many triggers, which are often hard to debug. For instance, updating a row may fire a trigger that invokes another trigger—and before you know it, you’re drowning in deeply nested triggers.

The Application Log captures all of this, giving you a clear overview of every piece of code that was executed:

 

The example below demonstrates that the update handler of the employee initiated the sequence. It executed the task ‘task_one’, which initiated ‘task_two’. ‘Task_two’ then inserted a record in ‘date_conversion’, which has an instead_of_trigger. After completion of ‘task_one’, the handler updated the ‘employee’ record, which has a trigger ‘employee_tu’.

Procedure Parameters

When a procedure is logged, all its parameters are included. This makes it easy to see which specific data points were involved and helps determine if an error only occurs under certain conditions.

For example, a procedure might only throw an error when the ‘status_id’ of a row is set to 5. Having the input parameters at hand lets you pinpoint issues much faster—instead of searching for a needle in a haystack.

Parameters with an VARCHAR_MAX, JSON, XML, VARBINARY_MAX, etc. datatype will not be logged to minimize storage / perfomance cost. If you do want to include one of these columns, use the ‘include_in_action_log’ tag. To exclude columns use the ‘exclude_in_action_log’ tag.

 

Retention

To prevent the Application Log from growing indefinitely, logs are automatically deleted after 90 days. You can change this by editing the process variable ‘retention_in_days’ in the ‘application_log_retention’ process flow.

Custom Values

To log custom values, you can either add the log line manually by creating an insert statement in the application_log table or use the provided subroutine application_log_add.

exec dbo.application_log_add @tsf_log_number, @tsf_object_name, 'Log info'

 

 

As with all Thinkstore solutions, this is just the beginning. Our philosophy is that Thinkstore solutions are a foundation—something you can build upon and tailor to your specific needs.

If you create something awesome with it, we’d love to hear about it! Just reply to this topic and share your ideas.

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings