Settings Per Job Type

Some settings can be applied to separate job types. For example, an organisation sets up Photogrammetry and Field edit jobs that follow the same process, but have slight customisations. In the Settings Per Job Type section within the 1Workflow Admin pages, the job types as defined in 1Plan are displayed.

To add new job types, first add them to 1Plan as described in the 1Plan Online Help. Then, refresh the 1Workflow administration interface to display the new job type.

For each setting, click at the bottom of the section to apply any changes made.

To cancel changes and revert to the last saved state, click .

The Settings Per Job Type settings are listed below:

Setting Description
Mandatory
Select whether job data is downloaded and uploaded as changes (Manual) or by directly updating the Oracle Workspace using a separate tool or process (Batch). If the Batch job data is selected, the following "Batch edit module URL" will become available for update. For more information see Configuring Batch Workflow Mode.
Batch edit module URL The URL of the Batch edit module, called as part of the job.
The 1Exchange policy to use for the job The 1Exchange configuration to use for this job type (e.g. the data and data formats to exchange). For more information see Exchange Policies.
Embargo
Enable Embargo to put jobs through a pre-download release approval step The Embargoed status in 1Workflow is intended to offer a point of review for data which is to be worked on in a job before it is downloaded. This is designed to help ensure the accuracy and usability of data before any edits are made. For more information see Embargoed Status.
Grow Extents
Automatically grow the extent of a job to ensure that any features partially included will be wholly within the area of interest (Requires Oracle Spatial License) Automatically growing the extents of a job can ensure that all surrounding features are loaded to ensure the sufficient context for editing and validation. For more information see Grow Extents
Read-only
If enabled, jobs of this type cannot have changes uploaded (this will disable edit validation) Prepare data extracts for sending out but disable the upload functionality as no edits are allowed.
Downstream Endpoint
Invoke a custom endpoint after job completion If you wish for a job to invoke a further action outside of the standard job lifecycle upon completion of the job, you can activate a downstream listener SOAP service to do so.
Custom downstream endpoint URL The URL location of the downstream listener you wish to invoke.
Downstream Job
Type of job to create as a downstream job of the in progress job on its completion

If you wish for a new job of a different type to be created with the same metadata when a job in progress completes, then specify the job type to be created here.

Note: Ensure there are no circular references, otherwise the system would be infinitely creating jobs every time they are completed.
Downstream job assignment The option for the worker and group to be inherited or named.
Worker Group The Worker Group to be assigned if Named worker group and worker were selected for the Downstream job assignment.
Worker The Worker to be assigned if Named worker group and worker were selected for the Downstream job assignment.
Automatically allocate the created downstream job Select if you want the downstream job to be automatically allocated to a group and worker.
Automatically activate the created downstream job Select if you want to automatically activate the downstream job.
Validation of Edits
Enable validation of job edits After a job is edited it will pass through validation, to ensure accuracy of work carried out. These are defined by the validation rules within the validation rules folder.
Validation rules folder The location of the validation rules. This needs to be inside a root folder called ‘Production’ and must contain a CRITICAL folder and optionally a WARNING” folder. E.g. for this structure, “Production\MyValidationRules\CRITICAL” specify ‘MyValidationRules’. The folders are case sensitive.

Validation data store name

 The name of the validation data store which specifies how to load the data. Must be configured to load all the required tables and attributes for validation, including the job id column. It needs to be inside a root folder called ‘Production’ E.g. for this structure, “Production\My1SMSDatastore” specify ‘My1SMSDatastore’.
Refresh the job's workspace before attempting to run validation By refreshing the job's workspace, any new changes that have been applied to the live data will be included during validation. This ensures that validation is done in the context of the latest version of the data. If there are version conflicts then the job will become conflicted and these need to be resolved before validation will continue again.
Pre-release Validation
Enable pre-release validation Pre-release validation is used to catch pre-existing validation issues, before the job is released to the worker.
Validation rules folder The location of the validation rules. This needs to be inside a root folder called ‘Production’ and must contain a CRITICAL folder and optionally a WARNING” folder. E.g. for this structure, “Production\MyValidationRules\CRITICAL” specify ‘MyValidationRules’. The folders are case sensitive.

Validation data store name

 The name of the validation data store which specifies how to load the data. Must be configured to load all the required tables and attributes for validation, including the job id column. It needs to be inside a root folder called ‘Production’ E.g. for this structure, “Production\My1SMSDatastore” specify ‘My1SMSDatastore’.
Child Jobs (for further information see: Child Job Settings)
Validation failure assignment If the job fails validation, select who will carry out the fixes required.
Conflict resolution assignment If the job is conflicted, select who will carry out the fixes required.
Quarantine review assignment

Select who will be in charge of the quarantine review.

Worklist Customisation
Include a link to a custom client tool in Worklist for job editing If a custom tool is used for viewing or editing of data, you can provide the URL of the tool here. This link will be visible from the worklist and will make an HTTP GET request to the URL.
Client tool URL The URL of the tool to link to. The job id will be passed in with this request by replacing all instances of {jobid} with the job id. e.g. http://myserver:port/myTool/job/{jobid} or http://myserver:port/myTool?JobID={jobid}
Client tool link text to display in Worklist Select the text to display above the Job metadata.

Child Job Settings

ClosedValidation failure assignment

Controls how the child job is created as a result of a validation failure

Setting Description
Unassigned

The child job is created unassigned to any specific user or group.

Note: The job will be in the proposed state, rather than allocated.
Allocated to the worker from the invalid job The child job is created with the same worker as the parent and is automatically allocated to that user.
Allocated to the worker group from the invalid job the child job is created with the same worker group as the parent (the worker is cleared) and is automatically allocated to that group.
Allocated to a specific worker group The child job is created with the specified group and is automatically allocated to the entered group.

Note: Allocating to a specific group is used where there may be a separate QA team to handle conflicts or validation errors. This setting will work in tandem with the notification mechanism. For example, if you set it to allocate to a group and the allocated notification is set to email the worker group, the whole of the QA group would be emailed on the creation of a validation failure child.

ClosedConflict resolution assignment

Controls how a conflict resolution job is handled.

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.

Setting Description
Unassigned

The child job is created unassigned to any specific user or group.

Note: The job will be in the proposed state, rather than allocated.
Allocated to the worker from the conflicted job The child job is created with the same worker as the parent and is automatically allocated to that user.
Allocated to the worker group from the conflicted job the child job is created with the same worker group as the parent (the worker is cleared) and is automatically allocated to that group.
Allocated to a specific worker group The child job is created with the specified group and is automatically allocated to the entered group.

Note: Allocating to a specific group is used where there may be a separate QA team to handle conflicts or validation errors. This setting will work in tandem with the notification mechanism. For example, if you set it to allocate to a group and the allocated notification is set to email the worker group, the whole of the QA group would be emailed on the creation of a validation failure child.

ClosedQuarantine review assignment

Controls who is assigned to the role of quarantine review.

Setting Description
Allocated to the worker's group from the quarantined job The child job is created with the same worker group as the parent (the worker is cleared) and is automatically allocated to that group.
Assigned to the planner from the quarantined job

Assign the role of quarantine review to the person that planned the job.

Note: The job will be in the proposed state, rather than allocated.
Allocated to the list of reviewers and/or reviewer groups from the quarantined job A list of users or groups can be provided through the API as a comma separated list.
Allocated to a specific worker group Assign the role of quarantine review to a specified named group.