Custom logger

In the case when the tools listed above for finding errors are not enough, you can always make your own logger and implement all your needs in it. For example, let's create a logger that will add information about the user who triggered this event and its access level in addition to the general description of the event.

Logger data model

To do this, let's start by creating a model in the database. We need a very simple model, with three required fields.

• info (text) - general information about the event
• user (integer) - User ID
• access (array string) - user groups (there may be several)
  

Logger business process

After that, we will create a business process for writing a log to the database. Its task will be to receive information about any event, supplement it with information about the user, and save the final result in the database.

To get information about the user, use the Auth: Get current user block. Note that it will only be able to represent the result as a user model if Middleware Token Auth was enabled on the endpoint that initiated its execution.

We use Expand User to expand the result and get the required fields. In our case, these are ID, Login, and Groups. Using the first two is quite banal, you just need to convert Login from the mail format to a standard String (To String block).

In the case of user groups, the situation is somewhat more complicated. They are stored in Enum format. This is an enumerated type that stores only a list of identifiers in the database, not their text value. In our case, the value 1 corresponds to the group of administrators (Admins), and the value 2 to the group of users (Users).

Our task is to decrypt this identifier and write the result in the form of convenient textual data. For this, you need:

• Declare a variable into which text information about user groups will be written. Let's use the String Array and Set Variable blocks.
• Start the loop with the For each loop block. It will receive an array of the user's groups and, then, in each iteration, convert the next group to its text value and add it to the array.
• Using the Switch block, check the user group and, depending on the result, direct the process further.
• Using the String and Set Variable blocks, store the required value of the user's group in a variable.
• Use the Append Array and Set Variable blocks to add the result to an array and store it in a variable declared before the start of the loop.
  

Upon completion of the loop, you should use the Concat Strings (Multiple) block to form a final string from scattered data, which will be converted to Text and written to the log.

The last thing to do is to generate the log model and write it to the database.

The resulting BP should looks like this:

Logger endpoint

The business process is ready. Now we need to create an endpoint for it. To do this, we will replace the system business process of the POST /log/ endpoint with the business process that was just created.

Now our own log is completely ready to go. You can return to the very beginning of the module, to the Basic functions business process, and replace the standard log with the one you made yourself.

Now, each time calculations are started, a special log will record not only information about the very fact of this event but also about which user did it. We can check the result in Swagger.

Great, our log really works. Now it contains information about the event, the user's login, and his access rights.

Possible errors and recommended actions

As a result, we structure possible variants of errors and actions to correct them.

• Errors in the business process itself. It is recommended to use logs for step-by-step verification. Thus, you can check the very fact of launching a certain block of business process and all the parameters that the block uses, both at the input and output.
• Errors in sending the request to the server. To do this, use the Developer Tools in the browser. You can check the fact that the request was sent, parse its structure, and see the received response.
• Requests are malformed. It is recommended to use Swagger for thorough testing, checking various query options, and parameter combinations.
• The result of the request is not parsed correctly. It happens that we are waiting for the result where it should not be. For example, we add data to the database but do not update them in the table that displays this data. Remember that each component requires a corresponding business process, and ensure that this process is configured correctly.