A life-cycle is defined as the series of changes in the life of a "thing", from its creation to its retirement and the development of the same form again. It helps answer the following questions about a "thing":
- when and why does a “thing” get created?
- what stages does a “thing” go through during its life?
- when does a “thing” get retired?
This page describes the life-cycles of a typical Verne business entity, service instance and service transaction. Be sure to familiarise yourself with the definitions of those three concepts as it will help understand how they relate to each other.
The key aspect to understand is that life of an entity encapsulates ‘lives’ of one or many service instances, life of a service instance in turn encapsulates ‘lives’ of one or many service transactions. So in other words, service instance journey through its life-cycle is based on multiple small journeys of service transactions that represent it.
This article is broken down into the four sections:
- Life-cycle of a service instance – describes service instance life-cycle independent of service transaction or entity
- Life-cycle of an entity – describes how entity travels through its life-cycle by means of ” births and deaths” of its service instances
- Life-cycle of a service transaction – describes service transaction life-cycle independent of a service instance
- Combined life-cycle – describes how service instance travels through its life-cycle by means of ” births and deaths” of its service transactions
This topic is tightly bound with Verne versioning and merging changes.
Life-cycle of a service instance
When and why does a service instance get created?
A service instance gets created when a user initiates a new action on an entity with the purpose to create, maintain, correct or view its details.
At this stage, a unique key for the service instance is generated and is stored in the Service identifier attribute of each service transaction document that represents this service instance.
During its life, a service instance is represented by one or more service transactions. Each service transaction will carry a different version of the service instance data, and only the last committed one will be treated as the current (most recent) service instance version.
What stages does a service instance go through during its life?
Service instances that intend to correct or view a ‘thing’ have a very short life span, their status never changes from the initial, so in fact they reach their end state the moment they are created:
- service instances that intend to correct a ‘thing’ are created with the initial status of Activated and this status won’t change again;
- service instances that intend to view a ‘thing’ are created with the initial status of View and this status won’t change again.
Service instances that intend to create and maintain a ‘thing’ start with a Draft status and go through the following statuses during their life:
Note, this is a "typical" life-cycle. In fact, life-cycle can be configured to suit the specific requirements of the jurisdiction. For example, the Draft state can be split into Draft and Ready for submission, the former would mean that data entry for the service is still in progress, the latter would mean that data entry is complete and the service requires final review before submission.
Various business service can have shared or separate workflow defined for them. Workflow is configured using workflow configuration functionality.
| Logical value | Physical value | Description | Initial state? | Live state? | Final state? |
|---|---|---|---|---|---|
| Draft | Status = Pending | Service instance has been initiated and is being worked on or saved for later amendments. Presenter has neither submitted nor deleted the service, it has not reached the expiry date yet. | Yes, this is the initial state for every new service transaction that is created for the purpose of creating or maintaining an entity. | Yes, this is a live state and the service has a potential to be activated at some stage. | No, every draft service must eventually be expired. |
| Review | Status = Review | Service instance has been successfully submitted and requires an internal review process. A corresponding task is in the work queue waiting for internal review. | No | Yes, this is a live state and the service has a potential to be activated should it be approved. | No, service must be eventually actioned by the internal reviewer, resulting in the change of status. |
| Revise | Status = Revise | Service instance has been through an internal review process and has been returned to the presenter for revision. Presenter has neither re-submitted nor deleted the service, it has not reached the expiry date yet. It is alive and has the potential to be activated at some stage. | No | Yes, this is a live state and the service has a potential to be activated at some stage. | No, every revise service must eventually be expired. |
| Approved | Status = Activated | Service instance has been approved by the internal user or auto-approved by the system after submission (where review is not required), changes applied to the register. This service instance and this service transaction now represent the current version of the entity, with all previous approved service instances of this entity being its previous versions. | Yes, this is the initial state for every new service transaction that is created for the purpose of correcting an entity. | No, this service will never change its status again. Note, data of this service can be further changed by subsequent corrections, however, the correction would be a new service instance that would incorporate itself into the same visioning branch as a sibling. | Yes |
| Rejected | Status = Reject | Service instance has been rejected by the internal user. | No | No, this service will never change its status again. | Yes |
| Canceled | Status = Canceled | Service instance has been deleted. It will never be activated. For the purpose of the service instance life-cycle this is the end state. | No | No, this service will never change its status again. | Yes |
| Expired | Status = Expired | Service instance has not been submitted within the outlined time frame (i.e. until service expiry date) and has been expired by the system. This is the case for services in statuses Draft and Revise. | No | No, this service will never change its status again. | Yes |
| View | Status = View | Service instance is created in response to the user request to view entity data. | Yes, this is the initial state for every new service transaction that is created for the purpose of viewing an entity. | No, this service will never change its status again. | Yes |
When does a service instance get retired?
Service instance reaches the end of its life when:
- it is approved, that is Activated status – this is a happy end;
- or when it is Rejected, Deleted or Expired – this is an unsuccessful service instance.
Life-cycle of an entity
When and why does an entity get created?
An entity gets created when a user initiates a new instance of a business service that creates a new entity (a.k.a. "create" or "registration" business service)
At this stage, a unique key for the entity is generated and is stored in the Identifier attribute of each service transaction document that represents this entity.
During its life, an entity is represented by one or more service instances. Each service instance will carry a different version of the entity data, and only the last activated one will be treated as the current (most recent) entity version.
What stages does an entity go through during its life?
Life cycle of each entity type is configurable to suite the requirements. The basic life cycle of almost every entity includes at least two statuses: Registered and Removed. Entity is assigned a status value only if the "create" business service for this entity gets activated. Otherwise entity status is not populated. Subsequent maintain services, if activated, can change entity status from Registered to Removed and vise versa, but the status can never be reverted to be empty.
When does an entity get retired?
Entity reaches the end of its life when it is assigned Removed status for the last time (note, this can be any other final status configured for the entity). Usually entity can be restored into active status from any of the final statuses, however, eventually every entity will reach its final status and will not be restored again.
Life-cycle of a service transaction
When and why does a service transaction get created?
A service transaction gets created in the following three cases:
- when a user initiates a new action on an entity (i.e. initiates a new business service instance);
- when a user requests to edit or correct data in an existing service instance;
- when Verne successfully merges changes into an existing service transaction.
At this stage, a unique key for the service transaction is generated and is stored as an ID attribute of each service transaction document.
What stages does a service transaction go through during its life?
Service transaction does not have one field that would represent its status, it is a combination of the following fields:
- Committed date – reflects transaction committed status. If the date is empty, then the transaction is considered to be not committed and it represents an unfinished data entry session, otherwise if date is populated then the transaction is committed.
- Ghost flag and Ghost reason – determines if not committed transaction is still alive (has potential to be committed – not a ghost) or is it already dead (a ghost). Ghost reason indicates why not committed transaction became dead.
- Next merge – points to the service transaction that has replaced this one due to successful merge. If pointer is populated then this service transaction is superseded.
Service transaction that intends to view an entity is created with the initial status of Not committed / Ghost (reason is View) / No next merge that is also the end state as no more changes are possible.
Service transactions that intend to create, maintain or correct the entity start with a Not committed / Not ghost / No next merge state. When one of the three fields changes, the service transaction reaches its final state:
| Logical value | Physical value | Description |
|---|---|---|
| Not committed | Committed Date is NULL Ghost = No Next merge ID is NULL | A new business service or an editing / correcting of an existing business service has been started (and maybe auto-saved by the system) but has not been saved by the user yet. |
| Committed | Committed Date is populated Ghost = No Next merge ID is NULL | User saved changes made in the exiting service or saved a brand new service they just initiated. This service transaction now represents the current content of the service instance, with all previous service transactions of this service instance being its previous siblings. |
| Discarded | Committed Date is NULL Ghost = Yes Ghost Reason = Discarded Next merge ID is NULL | User discarded changes made in an exiting service or discarded a brand new service they just initiated. |
| Stale | Committed Date is NULL Created Date + Time out period < Current DateGhost = Yes Ghost Reason = Stale Next merge ID is NULL | User has not saved the data entry session and it has timed out. I.e. they have intentionally or unintentionally abandoned it (e.g. browser crashed, power cut, browser window closed, logon session timed out). |
| Obsolete | Committed Date is NULL Ghost = Yes Ghost Reason = Obsolete Next merge ID is NULL | User started editing an existing business, while work was underway, some other changes have been made to this service instance that resulted in the change of service instance status. |
| Merged | Committed Date is NULL Ghost = No Next merge ID is populated | User started editing an existing business, while work was underway, another service has been activated on the same entity and changes have been successfully merged into this service instance. As a result, a new service transaction has been created with refreshed content, this service transaction reached the final stage. |
| View | Committed Date is NULL Ghost = Yes Ghost Reason = View | Service transaction is created in response to the user request to view entity data. |
When does a service transaction get retired?
As described above, service transaction changes its state only once in its lifetime and then reaches the final stage.
Combined life-cycle
The diagram below combines service instance and service transaction lives into a single life-cycle flow that shows how user and system actions create new service transactions and move service instances from one state to another.
This diagram also covers the umbrella terms that are quite often used to reference a group of statuses:
| Group of statuses | Description |
|---|---|
| In-progress services | Service instances that have been committed (user-saved) and have neither reached approval nor an unsuccessful status, i.e. have a potential to be activated. (i.e. draft, review, revise) |
| Pending services | Services that have been committed (user-saved) and have been already submitted to the Register but not yet approved or rejected. Such services are visible on the register and their content can be protected by business rules in one way or another. |
| Activated services | Service instance reached its final successful status (i.e. approved). |
| Unsuccessful services | Service instance reached its final unsuccessful status (i.e. rejected, canceled, expired). |
| Not committed transactions | Amendments to an existing service initiated and not yet user-saved or a new business service instance initiated and not yet user-saved. |
| Ghost transactions | Not committed session became unnecessary as it was either discarded by the initiator, or timed out by the system or became obsolete due to status changes on the same service instance. Or this is a view service instance. |
