Quality and job APIs

Use QUALITY_BASE_URL=https://<host>/quality for quality and the relevant /base or /job service for cross-module execution state. Retrieve rules, run instances, issue lists, and verification separately. Successful execution does not mean issue-free data.

Quality queries

Method and complete path	Key inputs	Result
POST /quality/quality/rules/tech/page	Body currentPage, pageSize; optional keyword, modelCategoryId, buRuleId, hasProblem	ruleList, total
GET /quality/quality/rule/tech/{ruleId}	Long rule ID	Targets, type, publication state
POST /quality/quality/jobs	Body currentPage, pageSize; optional name, modelCategoryId, jobId	Definitions: content, totalElements
GET /quality/quality/jobs/{jobInstanceId}/events	Long instance ID	timestamp, message, status, percent
GET /quality/quality/rule/tasks	No required inputs	Issue lists with rule, result, and verification; array unsuitable for frequent full polling
POST /quality/quality/rules/tasks/{taskId}/data	Path ID; required query currentPage, pageSize, starting at 1; filter body	rowNames, rowData, totalRow

Both quality path segments are required by the definition.

Build a quality dashboard

1. Retrieve rules and tasks by system and retain ruleId, jobId, and scope.
2. Read events for actual run instances and confirm completion or failure.
3. Associate issues by ruleId, jobResultId, modelCategoryId, and batchNum.
4. Display execution, issue, and verification state separately. Do not mix counts from different batches.
5. Compare one batch's rules, instances, issues, and verification with the UI.

Issue status includes INIT, NOT_START, CONFIRM, ACCEPT, FIXED, VERIFIED, CLOSED, END. verifyStatus includes NOT_VERIFIED_YET, VERIFIED_ALL_PASSED, VERIFIED_PARTIALLY_PASSED, VERIFIED_NO_PASSED, NOT_AVAILABLE. Retain both; closed issues are not necessarily fully verified.

Synchronize tickets

Example detail body for a confirmed taskId:

{
  "assignStatus": "ALL",
  "solveStatus": "NOT_SOLVED"
}

Example path: /quality/quality/rules/tasks/2001/data?currentPage=1&pageSize=20. The ID is fictional. Interpret rowData using rowNames order rather than fixed row object fields.

Retain issue list, rule, batch, and available record key to prevent duplicate tickets. Prefer summary, owner, and a DAM link. Synchronize raw issue data only with explicit data authorization and business need.

Ticket closure does not close or verify a DAM issue. Design bidirectional mappings, ownership, and audit separately. See remediation and verification.

Job systems and asynchronous results

Method and complete path	Job system	Inputs and result
POST /base/instantJob/getJobStatus	Base instant jobs	String query jobId; stage, percent, msg
POST /base/instantJob/getJobResult	Base instant jobs	String query jobId; jobStatus, errorMessage, resultType
GET /metadata/simplejobs/status	Metadata simple jobs	Long query jobId; jobStatus, result, errorMessage
POST /sqlink/job/getJobResult	SQLink instance	Long query jobInstanceId, minimum 1; state, times, result
POST /job/main/query/jobs/byCriteria	Generic definitions	JSON criteria; content, totalElements
POST /job/main/query/jobResults/byCriteria	Generic results	Criteria linked to task and instance
POST /job/main/query/jobEvents/byCriteria	Generic events	Criteria linked to instance

Generic criteria require @type and nested page with currentPage and pageSize. Obtain a confirmed DTO example; the schema does not enumerate every concrete type. Prefer module-specific queries until the contract is known.

Base stages are IN_QUEUE, RUNNING, FAILED, FINISHED; metadata and SQLink enums differ. Use the system returned by the initiating endpoint rather than sending every jobId to /job.

Scheduling controls

Call an administrator-approved business entry point, retain the instance ID, poll to a terminal state, then verify business output. Store definition and instance IDs separately.

The /job/main/startJob definition uses a Chinese query name represented in Unicode escape notation as \u4efb\u52a1ID, with a String body. Decode that name if required by the verified contract. This guide provides no untested one-click harvesting command and does not recommend restart, forced stop, or state reset as routine governance APIs.

Use bounded backoff, total timeout, and alerts. Verify actual instance state after failure before repeating execution. Validate read responses in the target deployment; integration checks should not inadvertently run tasks, modify issues, or download business data.