Data Lifecycle management: Statuses
The status of the cat
In my previous post, I examined an ancient drawing of a cat on a mountain. No one knows why it was made, but we know the creation of this drawing is a perfect example of a project. Someone came up with the idea of a drawing of a cat, another Inca selected the mountain, another approved the project and then someone started creating it. Creation took some time and finally it was approved and its status became ‘Finished’. And somewhere in the future it may become ‘Deleted’.
So, the drawing apparently has a status, but maybe even the workers on this project have a status like ‘recruited’, ‘working’, ‘finished’ and the initial drafts of the drawing have their own status like ‘concept’, ‘not approved’, ‘approved’.
It’s not hard to see the similarity with administrative systems. In most systems I know some of the entities have a status. And, in many of them, statuses and status changes are coded using fixed values, also known as ‘hard coding’. As coding needs time, many entities which do NOT have a status, but should, are not enriched with their status information because developers prioritise other things as more important.
Status design
From a business perspective a status looks something like this:
The yellow route is the most general one. Some special situations occur. Every status status-change allowed have codes to access them directly: these have no meaning but are used as a reference only. There is some numeric order to allow checking whether a status has already occurred.
Now in this example all statuses are fixed. But there may be statuses that are more dynamic (e.g. if the status is ‘Active’ but there are no active contracts, render the status as ‘Inactive’).
Why would the business care?
Using a statuses flag takes care of the users’ data lifecycle automatically:
· By using status data, changes can be aligned with the role the data has.
· Reporting and selection can depend on the status, forms only need to show relevant data.
· By maintaining the statuses automatically, decisions can be made without being dependent on whether the user sees the correct status.
· Proper history.
It makes sense to align status processing on all relevant entities, by a generic feature.
Using a generic status feature
It makes sense then, before starting an app build, to create this generic feature for statuses, and use it for all (functional) entities that need a status.
Using a generic status feature has many advantages:
· It only needs to be developed and tested once. If it works, it can easily be added to another entity: it therefore increases the flexibility of the application;
· Functionality like status-changes, authorization, rendering and history are developed just once and have guaranteed quality;
· Most importantly: a complete lifecycle of the entity is created, therefore (functional) trouble shooting, error-correction, audibility and more are improved.
The generic feature should:
· Take care of the initial status of an object.
· Checks that have to be made before a status-change is allowed.
· Handle the status-change.
· Handle dynamic statuses.
· Handle the impact the new status has on the status of other objects.
· Submit everything that is to be done, because the status-change happened.
· Keep track of object status history.
Adding a status to an entity should require no more work than setting a flag on the entity and provide the content of the above status flow.
Mendix implementation
The functionality for statuses can easily be created into Mendix applications:
· Using MxReflection, flagging the entity and filling the status definitions.
· An eNum containing the names of the statuses.
· Creation of a status history table containing all status history of all entities.
· Adding association to the status with the entity and also add attributes for moment of change, status-level and status-word that are maintained by the before-commit event.
· Creation of some microflows: 1 to retrieve status directly, 1 to retrieve a new status based on a status-change (code).
In a more advanced environment you can add:
· Conditions that should apply before allowed to change a status.
· Microflows that should be started after a status-change.
In my opinion every application needs statuses on at least one entity (assuming it is necessary to at least administer something that is more-or-less reproducible). My hope is that one day Mendix would consider adding this feature to the platform, it certainly would make creating part of the functional data foundation of every administrative application, easier and more standardized.
If you want to know more about how to handle this functional feature, or copy mine, please get in touch.
Sign up for Mendix World : https://bit.ly/MXW21
From the Publisher -
If you enjoyed this article you can find more like it at our Medium page or at our own Community blog site.
For the makers looking to get started, you can sign up for a free account, and get instant access to learning with our Academy.
Interested in getting more involved with our community? You can join us in our Slack community channel or for those who want to be more involved, look into joining one of our Meet ups.
