Microflows and Application Logic
Microflows and nanoflows
Microflows run on the runtime (server side); nanoflows run in the client (browser or native app), which makes them the right choice for page logic such as on-change handlers, visibility expressions and offline behaviour. Nanoflows have a deliberately reduced activity set: no Java action calls, no commit-event triggers, no scheduled events.
Inside a microflow the building blocks are: start/end events with parameters and return values, create/change/commit/delete/rollback object, retrieve (from database or by association), list operations (union, intersect, filter, sort, aggregate), decisions, loops with break and continue, calls to microflows/nanoflows/Java actions, and error handling. Variables are typed and scoped to the flow; a change to an object is only visible outside the transaction after commit.
Traps
- Retrieve inside a loop. This is the classic performance question: retrieve the list once, then filter it in memory or retrieve by association instead of issuing a database round-trip per iteration.
- Custom error handling defaults to rollback; a "continue" branch keeps the transaction and whatever was already committed. Choosing the wrong branch in a partial-failure question is a common slip.
- A microflow runs in the context of the calling user, so entity access rules and their XPath constraints still apply to its retrieves.
- Committing inside a loop creates one transaction per object; commit once after the loop.
Rule of thumb
Use a microflow when you need the database, a Java action, a scheduled event or a commit event; use a nanoflow when the logic is purely about the page. If the flow needs neither server data nor Java, a nanoflow is faster and works offline.