Lifecycle of a Job
Jobs in 1SMS follow a fixed lifecycle that is defined by 1Workflow, which uses each component to achieve this workflow. Some steps in the lifecycle are configurable options (such as Quarantine). For more information on the details of each state, please refer to the List of Job States.
Job State Diagrams
The following diagrams show the lifecycles of various jobs within the 1SMS suite.
Note: Clicking the diagrams will open them in a full screen display for clearer viewing.
The Parent job lifecycle is the default lifecycle, there are a number of child jobs that can branch off this and they have been highlighted in the key.
The Read Only job lifecycle can be used if the extraction of the data package is all that is required. This job type does not allow a job to be uploaded, so the data can never be updated.
The Embargoed status in 1Workflow is intended to offer a point of review for data which is to be worked on in a job. This is designed to help ensure the accuracy and usability of data before any edits are made. For more information about Embargoed Jobs, please see Embargoed Status.
The Quarantined Child job is used if the parent has been selected to be manually inspected. This status is reached after the data has been uploaded and validated but before it has been committed. For more information about Quarantined jobs, please see Quarantined Status.
The Conflicted and Invalid Child job lifecycles are carried out if a Parent job conflicts or is discovered to be invalid at the point of upload.
Note: If your deployment is using an FME Workspace to convert data formats from Oracle, and you want to perform manual conflict resolution, please contact 1Spatial support.
The Batch workflow mode allows data to be updated by a (typically automated) batch edit module (a custom web service), that updates the data directly in the Oracle Workspace without having to extract and submit the changes via 1Exchange. For more information about Batch Workflow Lifecycles, please see Configuring Batch Workflow Mode.
There are a number of job states available throughout 1Workflow. The following outlines each state and what they represent in the lifecycle of a job within 1SMS.
The Type column describes:
- Interaction - The job requires user action.
- Terminal - The job requires no further action.
- Transient - The job is actively processing.
- Waiting - The job is waiting for an external process or job.
|ABANDONED||When a job is ABANDONED there will be no further work on the job and it is removed from the job lifecycle.||Terminal|
|ACTIVATED||An ACTIVATED Job has been activated by the Worker.||Transient|
|ALLOCATED||An ALLOCATED Job has been assigned to a group.||Interaction|
|APPROVED||The APPROVED status means that the review of the QUARANTINED or EMBARGOED job has been approved by the reviewer.||Terminal|
|BLOCKED||A BLOCKED job is awaiting a named user to upload a file attachment, to be used as part of the package preparation. Jobs can name the users to be requested for attachments by populating the "jobAttachments" parameter via the REST API.||Waiting|
|COMMITTED||A COMMITTED job is in a state where no further work or corrections are required to the Job. Feature edits have been applied to the database.||Transient|
|COMPLETED||COMPLETED jobs are no longer worked on in 1Workflow and progress further in the job lifecycle.||Terminal|
|CONFLICTED||Once a job has been UPLOADED, it will enter the CONFLICTED state if another job has edited the same data upstream.||Waiting|
|CORRECTIONS REQUIRED||When a job has been identified as needing extra work before moving through the job lifecycle.||Terminal|
|DISCARDED||Review feedback saying that the data is not suitable for further processing.||Terminal|
|DOWNLOADED||A DOWNLOADED job has been downloaded ready to be edited by the worker.||Interaction|
|EMBARGOED||If enabled, an EMBARGOED job is held in this state whilst a reviewer checks that the data is accurate and can be progressed through the remainder of the job lifecycle. For more information please see Embargoed Status||Waiting|
|FAILED||The FAILED state is only applicable to "batch" jobs and applicable jobs will enter this state if an error is detected.||Terminal|
|INVALID||The INVALID state is applicable after the data has been Uploaded if validation failures are detected.||Waiting|
|PREPARED||Once a job has been ACTIVATED and the job package has been assembled it enters this state and is now ready for DOWNLOAD. For more information about DOWNLOAD packages, please see: Package Download.||Interaction|
|PROPOSED||A PROPOSED job is the first stage in the job lifecycle and is ready to be Allocated.||Interaction|
Once a job has been uploaded it can enter QUARANTINED if it has been enabled in the admin pages. For more information please see Quarantined Status.
|UPLOADED||The UPLOADED state is activated once a worker has edited their job and uploaded it for review and to await a commit.||Transient|
Reasons for Failure
Below are the reason for failure values that are only set for child jobs. These can be found in the metadata field titled Failure Type, visible in the metadata side panel that appears when you click on a job tile.
|VALIDATION||If the parent job fails validation then this validation fix up job is created.|
|CONFLICT||If the parent job is conflicted then this validation fix up job is created.|
|QUARANTINE_REVIEW||The Job type that applies to a Child job that is created when the Parent is within QUARANTINE.|
|EMBARGO_REVIEW||The Job type that applies to a Child job that is created when the Parent is within EMBARGO.|
|QUARANTINE_CORRECTIONS||This job type is created when a QUARANTINE_REVIEW is marked as needing corrections.|
Note: Jobs will be no longer visible in the Worklist after they have been completed for more than 24 hours.