...
These functions are called to derive the operation and resource to supply to the access control decision performed by the CheckAccess action.
...
Error Handling
The system as a whole follows a fairly standard pattern: flows signal the "proceed" event to allow execution to continue, and any other event will propagate into the error handling machinery of the system (this can have different effects depending on the flow, e.g. a SOAP fault, a JSON result, an error page, etc.).
It's possible to create your own events that can be handled in custom fashion by adding an appropriate <end-state> element to your flowBy default, administrative flows will dump errors into the system's default error handling view(s). Web service interfaces that need to ensure non-HTML output can override this behavior by defining a pair of flow-scoped variables at the top of the flow with the flow states to transition to:
| Code Block |
|---|
<on-start>
<evaluate expression="'CustomView'" result="flowScope.ErrorState"/>
<evaluate expression="'CustomView'" result="flowScope.AuditedErrorState"/>
</on-start> |
The literal expressions are the state names to use, which must be defined somewhere in the flow definition, usually a view or end state. Separate states can be defined based on whether the request should be audited, if desired, but the custom state is responsible for invoking the WriteAuditLog action.