|
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.
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.
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.
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.
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
{
"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
{
"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