Introduction

Jobs are tasks that run in the background at set intervals. They are typically used for:

Updating database tables. An example is to aggregate transactional data into summary Data Sheets that can be used for reporting.
Importing and exporting data to/from files
Cleanup and monitoring tasks

Jobs are Entities and are configured on the Entity Configuration pages. They need to be INSTALLED before they can start. Jobs can’t be published and they can only be accessed through the Config API. There is a separate Jobs Admin section in the Config API which can be used to control the Jobs programmatically.

Types of Jobs

There are four different types of Jobs:

Type	Purpose
STANDARD Jobs	These can be added, modified and controlled by users through the Portal. These Jobs form a central part of NEON’s CDP and Automation functionality. Note that some Standard Jobs come pre-installed and are used to support the NEON Portal. Modifying those Jobs may break some of the Portal functionality or reporting.
EXTERNAL Jobs	These are configured as part of integrations with surrounding systems, and they let those systems take advantage of NEON’s Job functionality and monitoring. They are set up during the integration process and should not be changed.
SYSTEM Jobs	These come pre-installed and are used internally by NEON to keep the platform running. The logic behind these jobs is hidden and the jobs should only be managed by SPIKA’s support team.
LOYALTY Jobs	Similar to SYSTEM Jobs, they come pre-installed and are used internally by NEON to control Member and Loyalty aspects such as Journeys. The logic is hidden and the Jobs should only be managed by SPIKA's support team.

In addition to these types, a Job can also be configured as Automatic or Manual, where Automatic starts and runs automatically at set intervals, whereas a manual Job has to be started manually each time.

Job Statuses

Once a Job Entity is installed it appears on the Jobs page in the Portal where its execution and state can be monitored and managed. The Job can have any of the following states:

State	Description
ASLEEP	The Job is enabled, idle and ready to start when the right time comes.
RUNNING	The Job is currently executing. The started and current step gives information about how long it's been running for and what step is currently executing. Once the Job has finished executing it will go back to ASLEEP.
DISABLED	The Job has been disabled from automatic execution, and need to be reset to status ASLEEP before it can run. Newly installed Jobs always start in this state to prevent them from running straight away. A sleeping Job can manually be disabled at any time to stop the automatic execution. This is handy if for example a Job is behaving unexpectable
FAILED	The running failed, either repeatedly or the configuration says that the Jobs should fail if it goes wrong. A Failed Job will cause a system alert and needs attention, usually by checking the Job execution Logs and errors. Jobs can fail for several reasons, for example due to an invalid SQL statement or an attempt to read a missing file, or if the Job has been running for too long or there’s a database deadlock, or in rare cases because of un unexpected SYSTEM restart. Once the failure has been resolved the Job can be reset to ASLEEP or DISABLED