NextGen APIs

POST /integration/work-orders/r1/work-orders/operation-requirements (WIP)

Http Verb

POST

Url

/integration/work-orders/r1/work-orders/operation-requirements

Permissions required

Core Additional Parameters: Edit (fsm.core.additionalparameter.edit)

WorkOrder: View (fsm.core.workorder.view) or WorkOrder: Edit (fsm.core.workorder.edit)

WO Configuration: View (fsm.core.workorder.configuration.view) or WO Configuration: Edit (fsm.core.workorder.configuration.edit)

Resource Configuration: View (fsm.core.resource.configuration.view)

Last Modified Version

r1

Tech Tags


Available Async

No

BPMN Diagram (TBD)


Business Logic

This API manages resource assignment constraints (mandatory, preferred, or excluded) on Work Order operations.

One of workOrderCode or workOrderExternalCode must be present. If workOrderCode is provided it has the precedence among the other fields.

System verifies Permission Required and starts the elaboration that is organized in steps.

STEP 1 - External System Validation

System takes Input fields and checks their existence in internal configuration.

API Verb: GET

Resource: External Systems

Input: externalSystemCode, active=true

Output: externalSystemId

If System can obtain the Output fields → continue to next step.

If System can’t obtain the Output fields → responds with error. Elaboration is stopped.

Error Type:

STEP 2 - Work Order Validation

System takes Input fields and checks their existence in internal configuration.

API Verb: GET

Resource: Work Orders

Input: workOrderCode OR {externalSystemId, workOrderExternalCode}

Output: workOrderId

If System can obtain the Output fields for all input fields → continue to next step.

If System can’t obtain the Output fields for at least one input field → responds with error. Elaboration is stopped.

Error Type:

STEP 3 - Work Order Operation Validation

System takes Input fields and checks their existence in internal configuration.

API Verb: GET

Resource: Work Order Operations

Input: workOrderId, list of [workOrderOperationCode]

Output: list of [workOrderOperationId]

If System can obtain the Output fields for all input fields → continue to next step.

If System can’t obtain the Output fields for at least one input field → responds with error. Elaboration is stopped.

Error Type:

STEP 4 - Resource Validation

System takes Input fields and checks their existence in internal configuration.

API Verb: GET

Resource: Resources

Input: identificationNumber OR secondaryIdentificationNumber, loan=false

Output: resourceIdentityNumber(=identificationNumber)

If System can obtain the Output fields for all input fields → continue to next step.

If System can’t obtain the Output fields for at least one input field → responds with error. Elaboration is stopped.

Error Type:

STEP 5 - Operation Requirement Retrieve

System takes Input fields and checks their existence in internal configuration.

The system autonomously decodes the typeCode into typeId:

  • MANDATORY → 1

  • PREFERRED → 2

  • EXCLUDED → 3

API Verb: GET

Resource: Operation Requirements (add link to GET /api/work-orders/r1/operation-requirements)

Input: workOrderOperationId

Output: operationRequirementId, workOrderOperationId, resourceIdentityNumber, typeId

If System can obtain the Output fields, compares the list of ‘workOrderOperationId, resourceIdentityNumber’ pairs in output with the list of ‘workOrderOperationId, resourceIdentityNumber’ pairs in input body:

  • If there are pairs in output not present in input body → Delete → go to next step Operation Requirement Deletion.

  • If there are pairs in output present also in input body → Update → go to step Operation Requirement Update.

  • If there are pairs in input body not present in output → Create → go to step Operation Requirement Creation.

If System can’t obtain the Output fields for at least one input field → responds with error. Elaboration is stopped.

Error Type:

  • Others - see link in Resource

STEP 5a - Operation Requirement Deletion

System takes Input fields and deletes the Operation Requirement by setting the fields to empty. It is not a physical deletion.

This step is skipped if Input fields are null or absent.

API Verb: PATCH → to be DELETE

Resource: Operation Requirements (add link to PATCH /api/work-orders/r1/operation-requirements/{operationRequirementId} or DELETE …)

Input: operationRequirementId, workOrderOperationId=null, resourceIdentityNumber=null, typeId=null

Output: Response State

If Response State is SUCCESS → continue to next step.

If Response State is ERROR → elaboration is stopped. See Response payload fields.

Error Type:

  • Others - see link in Resource

STEP 5b - Operation Requirement Update

System takes Input fields and updates the Operation Requirement.

This step is skipped if Input fields are null or absent.

API Verb: PATCH

Resource: Operation Requirements (add link to PATCH /api/work-orders/r1/operation-requirements/{operationRequirementId})

Input: operationRequirementId, typeId

Output: Response State

If Response State is SUCCESS → continue to next step.

If Response State is ERROR → elaboration is stopped. See Response payload fields.

Error Type:

  • Others - see link in Resource

STEP 5c - Operation Requirement Creation

System takes Input fields and creates the Operation Requirement.

This step is skipped if Input fields are null or absent.

API Verb: POST

Resource: Operation Requirements (add link to POST /api/work-orders/r1/operation-requirements)

Input: workOrderOperationId, resourceIdentityNumber, typeId

Output: Response State

If Response State is SUCCESS → elaboration is stopped. See Response payload fields.

If Response State is ERROR → elaboration is stopped. See Response payload fields.

Error Type:

  • Others - see link in Resource

Query String Parameters

Start with a ? and includes parameters listed one after the another separated by &.

Not applicable.

Header Parameters

Parameters included in the request headers. Generally, request headers are used to keep authorization parameters.

Default.

Request Body Parameters

Request body parameters are used when clients send data to the API. They are shipped in a JSON Object only in POST, PUT, or PATCH requests.

Field


Description

Mandatory

Constraint

externalSystemCode


External System Code

Y

Not Blank

workOrderCode


Work Order Code

N

Null or Not Blank

workOrderExternalCode


Work Order Code in External System

N

Null or Not Blank

operationRequirements

(minOccurs=1, maxOccurs=N)

workOrderOperationCode

Work Order Operation Code

Y

Not Blank

identificationNumber

Resource Identification Number

N

Null or Not Blank

secondaryIdentificationNumber

Resource Secondary Identification Number

N

Null or Not Blank

typeCode

Requirements Type Code: ‘MANDATORY', ‘PREFERRED’, 'EXCLUDED’

N

Not Blank

Request example

JSON
{
  "extension": {
    "myFieldName": "myValue"
    },
  "externalSystemCode": "SAP",
  "workOrderExternalCode": "2026-000123-ODL",
  "workOrderCode": "NG123"
 ,
  "operationRequirements": [
    {
      "extension": {
       "myFieldName": "myValue"
       },
      "workOrderOperationCode": "0010",
      "identificationNumber": "MAT001",
      "secondaryIdentificationNumber": "SUB001",
      "typeCode": "1"
    }
  ]
}

Response documentation

Response payload fields

Compliant with RFC Standard https://www.rfc-editor.org/rfc/rfc9457.html

Extension fields:

Field

Description

Note

code

Extension member of a Problem Details Object that contains the error code

Only for ERROR

Response example

JSON
{
  "type": "about:blank",
  "title": "Not Found",
  "status": 404,
  "detail": "External system string does not exist",
  "instance": "/integration/work-orders/r1/work-orders/cancellation",
  "code": "IA001_001"
}


Response error codes