Microflows and Business Logic
This domain tests server-side logic: microflow versus nanoflow, the standard activity set, parameters and return values, error handling, and the entity-access setting that changes what a microflow may do.
Microflows versus nanoflows
Microflows run in the runtime: they can commit, log, call Java actions and REST services, and raise errors. Nanoflows run in the client, are the backbone of offline apps, and cannot use Java actions, REST calls, or logging. A nanoflow may call a microflow; a microflow cannot call a nanoflow.
Activities you must recognize
Retrieve (from database with an XPath constraint, or by following an association), Create object, Change object, Commit (with or without events), Delete, Rollback, Decision, Loop, Call microflow, Call Java action, Error event, Log message, Show message, Validation feedback, Call REST.
Error handling
Each microflow has an error handler: rollback, custom with an error event, or continue. A custom error path receives $latestError and lets you show a message or re-raise.
Worked example
Requirement: setting a customer to Blocked must fail while they have open orders. Reasoning: retrieve the open orders by following the Customer–Order association with an XPath count; if the count is greater than zero, route to an error event (or raise via a validation feedback plus rollback) instead of committing the change. A bare decision that merely returns a value leaves the caller free to commit anyway - the guard must stop the commit, not just observe the state.
Traps
- Committing with events triggers before- and after-commit event handlers; committing without events silently skips them.
- 'Apply entity access' is off by default, so a microflow can read and write data the calling user could never touch on a page.
- Rollback discards uncommitted changes; it is not the same as delete.
- A non-persistent object cannot be committed to the database.