Status Management
Primary Entities all have a Status field, used for tracking progression through the entity life cycle.
There’s a numeric value associated with each status values. The numeric value is a simple, linear “progress indicator”, i.e. a status with numeric value 17 is considered to be “greater” or “further in progress” than a status with numeric value 15.
Common Status Values
Status can have the following values:
| Status | Numerical | Description |
|---|---|---|
| None | -10 | Record does not exist, yet (i.e. this should never be seen in the database). Used as “before” status value for events that represent entity creation. |
| Failed | -2 | Processing or preparation failed. Relevant for e.g. experiments, steps, results, samples, or plates. |
| Canceled | -1 | The record was created but the real-world or virtual entity it represents either never was created or was somehow “lost” |
| Creating | 0 | Data creation is in progress – used for multi-transaction creation, e.g. an experiment with multiple steps. Once the entire dataset has been created, the status is updated to 10+ (see the “Eventual Consistency” section below) |
| Initial | 10 | The record has been created but the entity it represents does not yet exist. |
| InProgress | 30 | For process entities (e.g. steps or experiments): Started but neither completed nor abandoned. For stuff: Preparation is in progress (typically the same as the origin step status) |
| Completed | 50 | Process completed, sample or other physical entity is fully prepared. |
##Entity Class Specific Status Values
Some entities have special status values, f.eks. a handover has two additional status values:
| Status | Numerical | Description |
|---|---|---|
| Sent | 15 | |
| Received | 20 |
| Status | Numerical | Description |
|---|---|---|
| Published | 90 |
Status Changes, Events and Workflow Management
Rules that raise events when entities change their status above a certain value
Status Cascades
Eventual Consistency
Scifeon does not support distributed transactions between multiple API calls from the browser to the server. Thus, if you have custom JavaScript code that makes creates e.g. an experiment consisting of multiple steps, using one API call for each step, there's risk that a failure may occur somewhere within this sequence of calls. That would leave a partially created experiment.
This situation is handled in Scifeon according to the Eventual Consistency concept, using Status values to track the successful completion of all API calls.
Creating the following dataset:
- One experiment
- Two steps
- Output plates and samples for each step
Sequence
- Create experiment with status Creating
- Create step 1 with status Creating
- Create output plates and samples for step 1
- Update step 1 status to Initial
- Create step 2 with status Creating
- Create output plates and samples for step 2
- Update step 2 status to Initial
- Update experiment status to Initial
If the process fails and the experiment is left with status Creating for more than e.g. two hours, the status will be changed to Canceled cascading down to steps and step-products (in a bottom-up fashion). This is done by a “garbage-collector” process running asynchronously.
Specific Status Relationships
Sample analysis status
Experiment / step => entities that originate from that step