跳到主要内容

🥷 [S2] Challenge 17

· 阅读需 2 分钟

Just KNIME It, Season 2 / Challenge 17 reference

Challenge question​

Challenge 17: Better Workflows with Error Handling and Logging

Level: Hard

Description: The goal of this challenge is to remind you of the importance of building robust solutions with error handling and logging. These are best practices in workflow development that are often forgotten, but make a big difference in the end -- especially if the application is critical or if you are working with a team. Concretely, you will pick any workflow of your choice and add the following elements to it:

Error handling: Use the Try & Catch construction; Logging - Extract the workflow name, username, start and end of the execution. Next, create a table containing these metadata as well as the name of a failing node (if any) and its message in one row, and write this table to a CSV file. Make sure that once the workflow is executed again, a new row is appended to the log table in the CSV file. Optionally, you can add more columns to your log file, e.g., the column with a custom message depending on the execution status - success or failure. You can also create a logging component that takes workflow name, username, start and end of the execution as input, allows configuring the custom message, and updates the log file.

Author: Lada Rudnitckaia

Any thoughts?​

This challenge is quite difficult. The problem can be seen in several ways:

  1. The error format of each node is inconsistent. For example, when the GET node fails, its output port displays a red cross. However, when the CSV reader node encounters an issue, such as a missing file or incorrect configuration, the error display is different from the previous GET node. Should configuration errors be handled in the same manner as runtime errors? This inconsistency is a problem.

  2. Regarding components, when I attempt to build one, I encounter an error similar to the following. Based on my limited knowledge, I suspect this may be a bug.

  3. It may be necessary to test this functionality across a broader range of components and workflows.

I am eager to see how officials will address this challenge. Additionally, I believe it might be relatively simpler to parse knime.log for this challenge.