Exception Management, Debugging and Logging Events

Exception Management, Debugging and Logging Events

The Workflow engine ensures that all exceptions thrown out of Rules are recorded within the Orchestration Audit Events. This is important for providing detailed information about what went wrong.

In order to ensure that the Orchestration Audit Events contain as much useful information as possible, it is important to consider the Exception Strategy used by your Rules.

Fluent's Platform Exception Handling

There are 2 different ways exceptions are handled by Rubix:

• Special handling for exceptions of type RuleExecutionException
• Default handling for all other Exceptions

The RuleExecutionException Class

Rubix provides a special exception type called RuleExecutionException which provides special handling of exceptions ,  any RuleExecutionException, or subclass thereof, thrown from or bubbled up through a rule back into the Rubix Executor, will be handled as follows:

• Rubix engine will stop the execution of the current Ruleset, but continue processing previously queued inline events
• Rubix will not process any queued actions
• Rubix will log the exception in an orchestration audit Event, without a stack trace
• Rubix will mark the Event as a success
• Rubix will return a successful response to the UI if the execution was triggered by a User Action
• Rubix will create and attempt to execute a Ruleset Exception Event
  • The name of this new Ruleset Exception Event is the same as the Ruleset that threw the exception and the eventType is set to EXCEPTION
  • The RuleExecutionEvent message and the cause throwable (if it exists), will be available as part of the Exception Event for use within your rules

Default handling for other Exceptions

Fluent Platform supports the default Exception handling and  all  exceptions thrown or bubbled through from Rules, the Workflow Engine will handle these as follows:

• Rubix will stop the current execution
• Rubix will not process any queued actions
• Rubix will log the exception in an orchestration audit Event, including a stack trace
• Rubix will mark the Event as failed
• Rubix will return an error response to the UI if the execution was triggered by a User Action
• Rubix will not create and attempt to execute a Ruleset Exception Event

Types of Debugging

You can debug either locally using IDE debugging options or on the sandbox.

IDE Debugging

You can use your IDE Debugging menu and can debug as per standard Java Practice while running rules in Unit Tests or with the TestExecutor.

Fluent does not provide a Remote Debugging capability whereby you can step through the code running in the deployed environment but we do provide Debugging in Sandbox for how to troubleshoot issues in the deployed environment.

IntelliJ Debugging menu and debug tool window are shown in the image below.

Sandbox Debugging

The primary mechanism for debugging on a deployed environment is activity tracking or Orchestration Audit Events. You can easily query these for any context via the Event API, or via the Admin Console.

Recommended practices

• Avoid Trial & Error debugging and testing
• Always try to reproduce the issue locally, either with Unit Tests or with the TestExecutor
• Use the Events (Activities) to see what happened during the execution
• Ensure your Rules are as atomic (small single-purpose) as possible - the more granular your rules, the more useful information will be provided by the Audit Events, making problem identification much simpler.

Logging & Audit Events

The Workflow Engine is designed to provide Audit Log Events during the execution of any workflow.

This includes the following categories of Audit Events:

• Snapshot - A snapshot of the Entity at the time the Orchestration Event is received into the workflow.
• Ruleset - An audit of the ruleset executed as a result of an Orchestration Event
• Rule - An audit of a Rule executed within a ruleset as a result of an Orchestration Event
• Action - An audit of an Action executed as a result of an output of a Rule
• Exception - An audit of an Exception that has occurred during the execution of an Orchestration Event
• Custom Logs (LogAction) - The context.action().log() can be used to log custom Orchestration Audit Events.

Custom Log Examples

• Custom Log - Create a class for logger. A maximum of 1 log is allowed per rule for performance reasons. This provides accessible information for debugging purposes.
• LogLevels constants - Create an enum representing different Log Levels.
• Create a list for collecting logs - You can collect logs throughout the execution of your class, and write them as attributes to the log.

• Logs are internal only - System logs ( log.debug) are internal to our SRE teams. Heavy logs in rule code can impact our support and maintenance procedures, as well as performance.