Designing the Server Flow Logic
Log
Log construct used to log messages, warnings, errors, and other runtime information during the execution of an application.
Purpose: Log statements help developers track the flow of execution, detect issues, and provide detailed insights during application runtime.
Types of Log Construct:
- Information: Used for general informational messages.
- Warning: Used to log warnings or potential issues.
- Error: Used to log critical errors or issues that require attention.
- Debug: Used for detailed logs during the debugging process.
- Fatal: Used for critical failures that cause the application to stop.
- Verbose: Used during debugging and troubleshooting to capture a more in-depth trace of events, errors, and program states.
Example for Log Types
Informational Logs
Log("Info", "User has successfully logged in with email: yyy@xxx.com")
Warning Logs
Log("Warn", "API response took longer than expected: 500ms")
Error Logs
Log("Error", "Database connection failed: timeout error")
Debug Logs
Log("Debug", "Rendering UI component: Button1")
Fatal Logs
Log("Fatal", "Critical system failure: unable to load configuration file")
Setting appropriate logging levels is essential to balance performance and observability. Use Debug logs only during development, Info for general tracking, and Error/Critical logs for failures.
Follow the below steps to add the Log construct in a logic flow:
- In the designer canvas of a logic flow, drag and drop the Log construct into the flow.
- Double-click the construct to configure the properties as required and then click Save.
| Property | Description | Comments |
|---|---|---|
| Label | Labels help developers quickly understand each step in the logic flow without examining the details of the construct | It is recommended to provide a simple precise label that improves the logic flow readability. |
| Type* | Type of the log. User can select one of the following: Information Verbose Debug Warning Fatal Error | It specifies the severity level of the log message. It helps to categorize and prioritize the log messages based on the importance. If it is error, then exception field is shown, and data need to be provided. |
| Module ID* | Provide an ID. | Specifies the module or component where the Log construct is located. It provides additional context to the log message and helps in organizing and filtering logs. |
| Message | Message to be logged using the expression builder. | If the type is selected, the message field becomes visible. It can include variable values, error messages, status updates, or any other relevant details. |
| Exception | Exception to be logged using the expression builder. | If the log type is set to error, the exception field becomes visible. It includes exception data. |
| Comment | To comment this construct or not. Either Yes or No. | If marked as Yes, the construct is treated as a commented expression and ignored in code generation. |
| Description | Specify information about the purpose of Log construct. | Helps in understanding Log construct significance. |
An asterisk (*) denotes that the property is mandatory for adding the Log construct.
The success message displays upon successfully adding the construct.
To control logging behavior dynamically, the logging level can be configured in the API settings tab in the run window. This allows developers to adjust logging levels without modifying workflow logic.
Steps to Configure Logging Level in App Settings:
- Navigate to Run tab
- Select the profile
- Locate the Logging section under API Settings tab.
- Set the Default logging level (INFO, DEBUG, WARNING, ERROR, CRITICAL).
- Save the profile settings
Environment-specific settings can be managed using Profiles. Profiles help configure different logging levels for development, staging, and production environments, ensuring optimal logging based on the deployment stage
By defining profiles, logging settings can be automatically adjusted based on the environment without manual changes.