Using logs for application troubleshooting
During the development process, situations often arise when the actual result of the application does not match the expected one. Even for simple business processes with a small number of blocks, identifying errors can be difficult, and for large projects, the use of additional troubleshooting tools becomes mandatory.
In this module, we will deal with application debugging, that is, the development stage at which errors are detected, localized, and eliminated.
The most basic tool for finding errors is the use of a log, that is, the formation of certain entries for further analysis. Let's look at this using the example of the "Basic functions" business process that was created in the fourth module.
The purpose of the business process was to get two numbers to perform certain mathematical operations with them. Suppose we would like to check something along the way and not focus only on the final result (or lack thereof).
We use the log to make sure that:
- The business process really started
- The Round block receives the correct value as input
- The number of elements of the array before the end of the business process is in line with our expectations (5)
Write to Log block
To do this, we will slightly change the business process itself and add Write to Log blocks to it, which, as the name implies, will write information to the log.
We use the first Write to Log block at the start of the business process. It can take two parameters as input: Label (for the title of the entry) and Input (the entry itself). In this case, we record the very fact of starting a business process, so there is no need to transfer parameters from some separate source. It is enough to specify the confirmation text. Therefore, we will write the text "Basic functions BP start" as Input.
The next log entry will be performed before the Round block. And in this case, the record will no longer be fixed. Input will receive a value with the result of division, over which a rounding operation must be performed in the future. The good news is that Write to Log can take any type of values as Input (in this case, it will be Float), and there is no need to convert to String to write.
In the end, you need to write down the number of elements in the array. But to do this, you need to find this amount because we have the array itself, not its size. Therefore, in addition to Write to Log, we will use the Array Size block.
After that, you can publish the application, run the business process, and see the result. Go to the CI/CD tab in the Application Logs section to do this.
The entry bp_log in the Source column means that this entry was made as a result of the Write to Log block. We can ensure that the business process is working correctly and that the logs are actually being written. Moreover, here you can see various system logs, for example, that the endpoint result was received successfully (Status: 200), from which IP address the launch was made and what parameters were used.
A block with the same name (Write to Log) can also be seen when creating frontend business processes. Let's use it for the Y value input field. Let's write down information about what value was entered (Input: Value = ) and in which component (Label: Y log :).
In this case, the block will work exclusively on the front-end. No requests will be sent to the server; accordingly, no results of this block will appear in the server logs. A logical question arises - where, then, to look for them?
To do this, you need to open the Developer Tools in the browser. The launch method and the name itself may differ slightly depending on which browser is used, but the main thing is that any modern browser supports this feature and the general principle of operation is the same.
We entered the number “4” in the Y input field and made sure that Write to Log worked as planned. An entry appeared in the console “Y log: Value = 4”.