💡 [REQUEST] - Add validation rules to context variables

[medchedli]

Summary

This issue proposes adding functionality to validate context variables based on user-defined rules. Currently, there isn't a flexible way to ensure that context variables conform to specific formats or patterns. This feature would empower users to define custom validation logic, enhancing data integrity and preventing unexpected behavior in downstream processes.

Motivation:

In various scenarios, it's crucial to ensure that context variables adhere to specific formats. For example:

• Ensuring an order ID context variable only contains digits.
• Verifying that a tracking number follows a specific alphanumeric pattern.
• Validating that a user input matches a defined regular expression.

Without built-in support for such validation, users often have to implement these checks manually within their workflows, leading to code duplication and potential inconsistencies.

Proposed Solution:

We propose introducing a mechanism that allows users to define validation rules for context variables. This could be implemented in several ways, including:

• Simple Rule Types: Providing predefined rule types such as "digits only," "alphanumeric," "minimum length," "maximum length," etc.
• Pattern Matching: Allowing users to specify a digit pattern (e.g., DDD-DDDD-DDD).
• Regular Expression Support: Enabling users to define validation rules using regular expressions for more complex patterns.
• Custom Validation Functions (Advanced): For highly specific requirements, allowing users to provide a custom function that takes the context variable as input and returns a boolean indicating validity.

Basic Example

Example Usage:

Imagine a workflow where a user provides a "zip_code" as a context variable. The user could define a validation rule like:

• Rule Type: digits_only and length_equals: 5
• Pattern: \d{5} (using a digit pattern)
• Regex: ^[0-9]{5}$ (using a regular expression)

If the "zip_code" variable does not meet this rule, the system could:

• Raise an error and halt the workflow.
• Provide a warning or log message.
• Potentially trigger a fallback mechanism.