排程¶

```¶

curl -X PATCH -d @payload.json -H "Content-Type: application/json-patch+json" "https://play.dhis2.org/dev/api/metadata/sharing"

要获取所有可用作业类型的列表，可以使用以下端点：

两个补丁应用项目端点的参数相同:

响应包含有关每个作业类型的信息，包括名称、作业类型、键、调度类型和可用参数。调度类型可以是 `CRON`，这意味着可以使用带有 `cronExpression` 字段的 cron 表达式来调度作业，或者是`FIXED_DELAY`，意味着可以使用 `delay` 字段将作业调度为以固定延迟运行.场延迟以秒为单位。

响应将类似于以下内容：

```json
{
  "jobTypes": [
    {
      "name": "Data integrity",
      "jobType": "DATA_INTEGRITY",
      "key": "dataIntegrityJob",
      "schedulingType": "CRON"
    }, {
      "name": "Resource table",
      "jobType": "RESOURCE_TABLE",
      "key": "resourceTableJob",
      "schedulingType": "CRON"
    }, {
      "name": "Continuous analytics table",
      "jobType": "CONTINUOUS_ANALYTICS_TABLE",
      "key": "continuousAnalyticsTableJob",
      "schedulingType": "FIXED_DELAY"
    }
  ]
}

工作配置{ #job-configurations }¶

DHIS2允许安排各种类型的作业。每种类型的作业都有不同的配置属性，可让您更好地控制作业的运行方式。此外，如果需要，您可以将同一作业配置为以不同的配置和不同的时间间隔运行。

If this is set to true, then the batch function will stop and not updating any objects if there is an error
Otherwise, if this is false then the function will try to proceed with best effort mode.

Table: Main properties¶

Property

Job parameters, if applicable for job type.

类型

[]

empty

10000

int

[]

类型

创建工作配置{ #create-a-job-configuration }¶

要配置作业，您可以对以下资源发出POST请求：

/api/jobConfigurations

不含JSON格式参数的作业如下所示：

{
  "name": "",
  "jobType": "JOBTYPE",
  "cronExpression": "0 * * ? * *",
}

参数为JSON格式的分析表作业的示例：

{
  "name": "Analytics tables last two years",
  "jobType": "ANALYTICS_TABLE",
  "cronExpression": "0 * * ? * *",
  "jobParameters": {
    "lastYears": "2",
    "skipTableTypes": [],
    "skipResourceTables": false
  }
}

作为带有JSON格式参数的推送分析作业的示例：

{
   "name": "Push anlysis charts",
   "jobType": "PUSH_ANALYSIS",
   "cronExpression": "0 * * ? * *",
   "jobParameters": {
     "pushAnalysis": [
       "jtcMAKhWwnc"
     ]
    }
 }

An example of a job with scheduling type FIXED_DELAY and 120 seconds delay:

{
  "name": "Continuous analytics table",
  "jobType": "CONTINUOUS_ANALYTICS_TABLE",
  "delay": "120",
  "jobParameters": {
    "fullUpdateHourOfDay": 4
  }
}

获取工作配置{ #get-job-configurations }¶

列出所有作业配置：

GET /api/jobConfigurations

检索作业：

sqlViews

响应有效负载如下所示：

{
  "lastUpdated": "2018-02-22T15:15:34.067",
  "id": "KBcP6Qw37gT",
  "href": "http://localhost:8080/api/jobConfigurations/KBcP6Qw37gT",
  "created": "2018-02-22T15:15:34.067",
  "name": "analytics last two years",
  "jobStatus": "SCHEDULED",
  "displayName": "analytics last two years",
  "enabled": true,
  "externalAccess": false,
  "jobType": "ANALYTICS_TABLE",
  "nextExecutionTime": "2018-02-26T03:00:00.000",
  "cronExpression": "0 0 3 ? * MON",
  "jobParameters": {
    "lastYears": 2,
    "skipTableTypes": [],
    "skipResourceTables": false
  },
  "favorite": false,
  "configurable": true,
  "access": {
    "read": true,
    "update": true,
    "externalize": true,
    "delete": true,
    "write": true,
    "manage": true
  },
  "lastUpdatedBy": {
    "id": "GOLswS44mh8"
  },
  "favorites": [],
  "translations": [],
  "userGroupAccesses": [],
  "attributeValues": [],
  "userAccesses": []
}

更新任务配置{ #update-a-job-configuration }¶

使用以下端点和JSON有效负载格式，通过参数更新作业：

PUT /api/jobConfiguration/{id}

{
  "name": "analytics last two years",
  "enabled": true,
  "cronExpression": "0 0 3 ? * MON",
  "jobType": "ANALYTICS_TABLE",
  "jobParameters": {
    "lastYears": "3",
    "skipTableTypes": [],
    "skipResourceTables": false
  }
}

删除作业配置{ #delete-a-job-configuration }¶

使用以下方法删除作业：

删除/ api / jobConfiguration / {id}

请注意，某些具有自定义配置参数的作业可能不会被添加，如果 未配置所需的系统设置。一个例子是数据 同步，这需要远程服务器配置。

作为带有JSON格式参数的推送分析作业的示例:¶

{
   "name": "Push anlysis charts",
   "jobType": "PUSH_ANALYSIS",
   "cronExpression": "0 * * ? * *",
   "jobParameters": {
     "pushAnalysis": [
       "jtcMAKhWwnc"
     ]
    }
 }

POST /api/jobConfiguration/{id}/execute

调度项目 API{ #scheduler-api }¶

而 /api/jobConfigurations 则以作业配置对象为中心 API 反映调度项目的状态，而 /api/scheduler API 则提供作业进度跟踪信息。 和 /api/scheduling API 提供作业进度跟踪信息。

To view the errors associated with a specific job use:¶

GET /api/jobConfigurations/{id}/errors

To search for jobs that match user specified search criteria use:

GET /api/jobConfigurations/errors

with one or more of the following search parameters

user: include jobs ran by this user

from: include jobs that started after this point in time

to: include jobs that did not start later than this point in time

code: include jobs that have errors with one of the given error codes

object: include jobs that have errors linked to one of the given object IDs

type: include job with errors of the specified type(s)

When multiple criteria are used all have to be met (AND logic). If multiple code, object or type parameters are given just one has to match (OR logic). * For example, to find tracker import errors for the 1. of January 2024 with error code E1002 (tracked entity already exists) the following search is made: * GET /api/jobConfigurations/errors?type=TRACKER_IMPORT_JOB&code=E1002&from=2024-01-01&to=2024-01-02 * The results show the job run error details. By default, the input (the payload of the impport) is excluded from the results. To include it add includeInput=true: * GET /api/jobConfigurations/errors?includeInput=true

> Note¶

Not all job types do store their errors. Currently, this feature is mostly supported by import jobs. 调度项目接口

而 /api/jobConfigurations 则以作业配置对象为中心 API 反映调度项目的状态,而 /api/scheduler API 则提供作业进度跟踪信息。 和 /api/scheduling API 提供作业进度跟踪信息。

Observe Running Jobs { #running}

The execution steps and state can be observed while the job is running. A list of all types of jobs that are currently running is provided by:

GET /api/scheduling/running/types

To get an overview of all running jobs by job type use:

GET /api/scheduling/running¶

As there only can be one job running for each type at a time the status of a running job can be viewed in details using:

GET /api/scheduling/running/{type}

For example, to see status of a running ANALYTICS_TABLE job use

GET /api/scheduling/running/ANALYTICS_TABLE

A job is a sequence of processes. Each process has a sequence of stages. Within each stage there might be zero, one or many items. Items could be processed strictly sequential or parallel, n items at a time. Often the number of totalItems is known up-front.

In general the stages in a process and the items in a stage are "discovered" as a "side effect" of processing the data. While most processes have a fixed sequence of stages some processed might have varying stages depending on the data processed. Items are usually data dependent. Most jobs just include a single process.

code: include jobs that have errors with one of the given error codes

RUNNING: is currently processed (not yet finished)

Once a job has completed successful or with a failure as a consequence of an¶

exception or cancellation the status moves from the set of running states to the completed job states. This set keeps only the most recent execution state for each job type. The overview is available at: GET /api/scheduling/completed

Details on a particular job type are accordingly provided at:¶

GET /api/scheduling/completed/{type}

In case of the ANALYTICS_TABLE job this would be:

GET /api/scheduling/completed/ANALYTICS_TABLE

Request Cancelling a Running Jobs { #cancel }

Once a job is started it works through a sequence of steps. Each step might¶

in turn have collections of items that are processed. While jobs usually cannot be stopped at any point in time we can request cancellation and the process gives up cooperatively once it has completed an item or step and recognises that a cancellation was requested. This means jobs do not stop immediately and leave at an unknown point right in the middle of some processing. Instead, they give up when there is an opportunity to skip to the end. This still means that the overall process is unfinished and is not rolled back. It might just have done a number of steps and skipped others at the end. To cancel a running job use:

POST /api/scheduling/cancel/{type}

For example, to cancel the ANALYTICS_TABLE job run:

POST /api/scheduling/cancel/ANALYTICS_TABLE

Depending on the current step and item performed this can take from¶

milliseconds to minutes before the cancellation becomes effective. However, the status of the overall process will be shown as CANCELLED immediately when check using GET /api/scheduling/running/ANALYTICS_TABLE

Only jobs that have been split into processes, stages and items can be cancelled effectively. Not all jobs have been split yet. These will run till completion even if cancellation has been requested.

Reset a Job stuck in RUNNING state

When a server shuts down while a job is in RUNNING state the job needs to be reverted back to its initial state manually. To revert a job that has RUNNING state but is not running use:

POST /api/jobConfigurations/{uid}/revert

Job Queues¶

Sequences of jobs (configurations) can be created using job queues. The queue always uses a unique name and a CRON expression trigger. Once a queue is started it runs all jobs in the queue in the given sequence. The second in sequence starts when the first is finished and so forth.

List Names of Job Queues { #queues-list }

To list the unique names of existing queues use:

The response is a array of the names:¶

["queue_a", "queue_b"]

Get A Job Queue { #queues-info }

To get all details of a specific queue use:

GET /api/scheduler/queues/{name}¶

调度项目中的计划是一个基于作业配置和作业队列的列表。 和作业队列的列表。计划表中的条目要么是一个简单的作业配置，要么是一个作业队列、 或作业队列。两者使用相同的条目格式表示。

要获取调度项目列表，请使用

Create a new Job Queue { #queues-add }

To create a new queue send a POST request with a payload object having name, CRON expression and the job sequence:

POST /api/scheduler/queues/{name}

To create a queue with name myQ use a POST to /api/scheduler/queues/myQ:

{
  "cronExpression": "0 0 1 ? * *",
  "sequence": ["FgAxa6eRSzQ", "BeclVERfWbg" ]
}

A name can be present in the payload as well but name specified in the URL path takes precedence.

NOTE

The cron expression of all job configurations but the first in a queue is cleared as they do not have a trigger on their own any longer. It needs to be restored manually once a job is removed from a queue.

Update a Job Queue¶

To update an existing queue CRON expression or sequence use a PUT request

PUT /api/scheduler/queues/{name}

The payload has to state both new CRON expression and job sequence like in the example above to create a new queue.

To rename a queue the new name can be stated in the payload, while the old name is used in the URL path.

Delete a Job Queue { #queues-delete }