Canvas comes with a suite of powerful logging tools built-in, giving you full, customizable access to all relevant historical data, validation errors, error messages, etc.
There are two main ways to do logging in Canvas:
...
Block output logging, which can be customized with a search model
...
When a block runs, its full output response (as shown in the Response tab) is automatically logged and stored by Canvas for 30 days.
In this article we will explain how you can configure the logging to suit your needs, by using a search model for easy searching, or with in-code logging using the helper function logger.log()Info
This could for example be used to log
See also the related article for how to search the stored logs: Searching logs
| Info |
|---|
|
|
See also the related article for how to search the stored logs: Searching logs
Setting up a block Search Model
To set up a search model, select the block you want to log information for, and head to the Response tab.
...
When you click the icon you will be presented with a hierarchy of fields, from which you can select the relevant fields to log:
...
In this case we have only selected the “badgeNo” field, as we just need to log which employees were transferred.
...
based on the response that was last outputted by the block. (You may need to run the block first, to generate an output response.)
In the screenshot we selected the “badgeNo”, “givenName”, and “familyName” fields. This will ensure that these three fields are searchable in the logs going forward (logs created after the search model was defined).
Press the Save icon after making your selections. 💾
When you search the logs (using search option “By response”) you will see the fields you selected as options in the search settings:
...
Using logger.log()
The logger.log() function can be used in the code for any block. The function accepts both strings and objects, but objects will be stringified. Null and undefined values will be logged as empty strings.
...
It is a good idea to make sure that the strings you log have a unique format that allow for easy searching.
In the example above, one can easily search through the logs to find all ”Validation error”, or “Validation error, badgeNo 12345”, because those parts of the string are fixed.
If the errors were instead stored without a prefix, just using logger.log(err), it would not be possible to search for all validation errors for just one employee, and it would be difficult to tell the log type apart from other uses of logger.log().
See also the related this article for info on how to search the stored logs: Searching logs