Debugging is a key step when you are developing or coding. This is not different for the Silverfin Templating Language. Since debugging can sometimes be tricky to do, we have developed a debug panel to facilitate this process. The purpose of this panel is to give you more detailed information on what a template is doing, without having to deep-dive into the code.

This guide will provide you with an overview of all the functionalities that are present within the debug panel.

How to activate?

After pressing enter, a new section will appear at the bottom of the template:

javascript:void((*function*(){var locHasAnchor = location.href.split('#').length > 1 ? true : false; var loc = locHasAnchor ? location.href.split('#')[0] : location.href; var anchor = locHasAnchor ? '#' + location.href.split('#')[1] : '';if (loc.indexOf('debug') >= 0) return; loc.indexOf("?") < 0 ? (location.href = loc+"?debug=1"+anchor) : (location.href = loc+"&debug=1"+anchor);})());

We will now go through all the different items, and explain what information then contain and how it can be useful.

Flame graphs

Flame graphs are a great tool to investigate the loading time of a certain template. Each block in the flame graph represents a certain coding function/part (e.g. a fori-loop or an if-statement). If you hover over a certain block, it shows you how much time it takes to run that piece of code in mili-seconds.

For further analysis, you can then click on the block you need to investigate (each block shows the line number of where the code starts), and all the blocks beneath it are parts of your selected block (so the sum of the loading time in mili-seconds of the sub-blocks will be equal to the loading time of your selected block).

Having insights into the loading times will eventually allow you to optimize the code where needed, and make your templates load/render even faster.

Template info

Results

The ‘Results’ section displays the outcomes of the different unreconciled checks that are being executed in the code. Unreconciled indicators expect a couple of parameters (see Reconciliation of a template). The first parameter is the reconciliation itself. Often, this is set to 1 when we want to display the indicator (e.g. unreconciled 1), but it can also be the result of a calculation (e.g. unreconciled trial balance value - template total).

An outcome different from 0 will lead to the indicator showing unreconciled, and as a result, the template itself will become unreconciled as well. Only when all reconciliations are equal to 0, the template will show a green dot.

In the above example, two unreconciled checks are being executed in the code (resulting in a difference of 50 for the first, and 10 for the second one). Since both of them are different from 0, our template will become unreconciled as well (which can be seen by looking at ‘Total’).

So if you are ever in a situation where you don’t know why your template is unreconciled, this section will help you find which check results in a difference, and exactly what that difference is.

Named results

The ‘Named results’ section will list all the result tags created within the code. This can be a great help, since you don’t have to dive into the code anymore, looking for variables that you need to refer to in other templates.

Cache Issue

When a cache issue exists, you will see a warning text in the Debug panel with the following text:

Cache issues are most likely related to a four level dependency issue. It will be flagged in the debug panel with the previous warning text, and you can actually see the difference between the current result and the one stored in the cache in a new section named "Diffs with cached results".

What does this difference mean?
It means that templates that access results from this reconciliation will have access to the value stored in the cache, which will no longer be inline with the currently generated result.

How to interpret this message ?
When you see this warning text in the debug panel of one the reconciliations, it means that the current reconciliation is already (at least) at the third level in the chain of the dependencies. And other templates using results from this reconciliation will face cache differences.

Looking at the previous example, you have a result named result_4 and its value is 53.0. But, the value stored in the cache for this result is 4.0, and that's the value that any other reconciliation will fetch from this one when calling upon the result. This means that outdated data flows through to the next template in the chain.

Required inputs missing

This section will provide a list of the inputs that are indicated as ‘required’, but that do not contain any data yet. These missing inputs will result in the template being unreconciled (See our community case on how required exactly works).
Similar to the ‘Results’ section, this can provide you valuable information if you do not know why your template is being unreconciled.

Autoreconciliation fields

The ‘Autoreconciliation fields’ section gives an overview of all the inputs that can be completed through the Import reconciliation data function. In Silverfin, it is possible to upload your data into a certain template instead of having to complete it manually. However, the data that is being uploaded should exactly match the naming of the variables and its type. This information can be found here.

Here’s an example:

TextProperties

The TextProperties section contains some technical information about the content of input fields (more specifically custom drops). Only those fields that have actual content will be displayed in this list.

TextProperties can be very helpful to immediately see which custom drops are being used in a certain template, and what content they have.

Translations

Translations will provide you an overview of all the translation tags being used in the code, with the actual translations in the different languages.

Rollforward parameters

This section shows a list of all the input fields that have specific rollforward logic defined. Each input field will have the following information:

This is a great place to check when copying details is not working in the way you expect it to.

Dependencies

Dependencies tree

The final section of the debug panel is a visual representation of the dependencies of the template. It’s a double-sided tree graph, representing both the forward and backward dependencies of the template you are debugging.

The template you are debugging, is the root of it all, sitting in the middle of the tree.

left -------| 
            |
            |
           root
            |
            |
            |------- right

On the left, you’ll see the templates in which our current template depends on (using their results for example).
On the right side, you’ll see the templates that depend on the current template.

The tree can thus be seen as a flow of results from left to right.

Here’s an example:

👍

All these sections and tools have their own function and benefits. If you start using them, you will quickly see that they can make your life a lot easier when developing templates in Silverfin.