Skip to main content

Veritran Docs

Logic Reuse

Certain logic patterns repeat across different parts of an app. To avoid duplication, ease maintenance, and ensure consistency, it is recommended to extract these structures into reusable inline lambda processes.

Inline lambda processes encapsulate specific logic and can be invoked from other processes. This allows centralizing tasks like data formatting, validations, or transformations, simplifying maintenance. They should be used in the following cases:

  • When a similar logic is repeated in more than one process.

  • When business logic should be centralized for easier maintenance.

  • When consistent behavior is needed across different parts of the app.

Best Practices

Best practices when using inline lambda processes include:

  • Keep each inline lambda process limited to one purpose. They should not become large general-purpose flows, but small, reusable logic blocks with a clearly defined goal.

  • Avoid using logic that depends on the specific context in which it is invoked, so the process can truly be reusable. For this reason, configuring Next blocks is not allowed in this type of processes, except when calling another inline lambda process.

  • Limit the invocation depth to three levels. If more levels are needed, consider regrouping the logic more clearly. Excessive chaining makes the logic harder to read, maintain, and debug, and introduces unnecessary coupling between processes.

  • Avoid circular calls between processes, as they can complicate debugging and cause infinite loops.

Coupling Considerations

To ensure that an inline lambda process is truly reusable, it is essential to minimize its tight coupling with the processes that invoke it. This includes:

  • Using comments to clearly document the expected input and output tokens, as passing parameters directly is currently not supported.

  • Not assuming the existence of specific tokens unless they are explicitly defined as input.

  • Not modifying external states (tokens), except those explicitly defined as output.

  • Limiting its responsibility to a single, well-defined, self-contained task (e.g., validating a field, transforming a value, formatting a response).

Make sure that the inline process operates only on explicitly defined input and output tokens, and that its effects are predictable, controlled, and isolated. This improves reusability, simplifies testing, and reduces unintended side effects.