As we look to modernizing our Web Form applications, we should also investigate options for optimizing and eliminating workflow code.
After many years of having conducted a detailed examination of web form applications and thousands of code-behind files, we have found that much of the CRUD logic that drives the user experience and workflow is related to the current state of the record.
Consider the example of an Order that proceeds from some Draft state, to Submitted, Accepted, In Progress, Completed, Feedback, Analysis, etc. We see that the amount of information available and general user experience changes significantly as the record evolves over its lifecycle.
In a traditional Web Form application these state changes and the workflow they trigger are usually custom coded into the specific user experience forms used to display each type of record. Indeed, much of the CRUD logic in the form code-behind is driven by these states and their allowed transitions.
At Great Ideaz, we have investigated architectural designs that can replace much of this hard coded logic using a data driven approach. The basic concept is that if we use Data Agnostic Record Storage to persist our records, we can add an extra meta-data field to the Instances table that tracks the Instance Status. Executing a state transition is then simply a matter of changing the Instance Status of the record to the new value.
We implemented an optimal method for defining a State Transition and then added extra data records to our UX Creator form builder to be able to define all possible state transitions for each record type (concept). This boils down to:
- A list of allowed states
- A list of allowed events (that trigger state transitions)
- A list of allowed state transitions
For each of the allowed state transitions we want to define:
- The initial state, the event that triggers the transition, and when successful, the final state of the record.
- We also found it advantageous to add the following optional functionality:
- A Gate TSQL stored procedure to encode custom business rules that can suppress the event if the current user is not allowed to trigger it.
- Before and After command capability so that we could execute custom logic either before, or after, the transition.
- Cascading state transitions so that we could also update the state of the record’s children as a part of the state transition logic.
Doing all of this in Form Definition (FD) data means that we can integrate this functionality into the User Experience Definition (UXD) and so it just becomes a core part of our dynamic page builder technology.
This means that all the logic that would normally be manually coded in the specific form code-behind files has now been eliminated from our Single Page Application (SPA).
Furthermore, we can extend this approach to replacing any command that was initiated by the user experience with a record in the Form Definition (FD). We can encode a command that would only be available in:
- Defined states of the record
- To users with the appropriate roles
- Or any combination of custom business rules
This command would only be visible if the user were allowed to execute it.
Adopting a standard interface for any Event/Command execution then means that we don’t need to create specific forms for each record, and we can use a Single Page Application (SPA) to render any record type.
Having the state transitions defined in the Form Definition also allows for a security check within the REST API that will process the Event/Command to ensure that the current user is STILL allowed to execute it. This closes loopholes where a user might try to fulfill an Order twice by mistake, or design, using multiple open applications.
You can access all our developer documentation for free at the trellispark Academy.
Whether you chose to implement your solution using trellispark, these free resources provide excellent training materials on how to achieve the most value from Microsoft’s latest .NET Blazor WASM technology and build sustainable applications.