Microflows and Application Logic
Microflows and Application Logic
This domain checks that you can express business logic in the right artifact and that the logic survives large lists, failures and concurrency.
Core rules
- Nanoflows execute client-side: no commits, no Java, no direct database retrieve. Use them for screen logic; move anything touching persistence into a microflow.
- Retrieve with an XPath constraint and a range. Unbounded retrieves of large entities are the single most common performance defect.
- Error events offer
Custom with rollback,Custom without rollbackandContinue. Rollback undoes all database changes made in that microflow, not just the part after the error. - Commit is per object. Committing inside a loop produces N round-trips; either commit once at the end of the flow or batch-commit a list through a small Java action.
- Prefer list operations and aggregate activities over looping to count, sum or filter.
Worked example
An order import receives 5,000 lines. The naive flow retrieves the matching product inside the loop - 5,000 queries. The correct flow retrieves all referenced products once into a list, builds a lookup by product code, loops over the input comparing against that in-memory list, changes each order line, and commits the whole list once. Failure handling wraps the loop in an error event with rollback so a malformed line leaves the database untouched, and the error is rethrown with context rather than swallowed.
Traps
- An empty error handler that hides the exception and lets the caller believe it succeeded.
- Retrieve-in-loop (the classic N+1) disguised as clean modular sub-microflows.
- Using a microflow where a rule would do, paying transaction overhead for a pure calculation.
- Forgetting that a microflow called by a page runs in the user's security context, while scheduled events do not.