|
Http Verb |
DELETE |
|---|---|
|
Url |
/integration/work-orders/multistages/r1/group-operations |
|
Permissions required |
Core Additional Parameters: Edit (fsm.core.additionalparameter.edit) Organizational Structure Entities: View (fsm.core.structure.view) Organizational Structure Entities: Edit (fsm.core.structure.edit) |
|
Last Modified Version |
r1 |
|
Tech Tags |
|
|
Available Async |
No |
BPMN Diagram (TBD)
Business Logic
This Integration API logically deletes a Multistage Group by removing the operations and their dependencies.
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 — Operation Center Validation
System takes Input fields and checks their existence in internal configuration.
API Verb: GET
Resource: Operation Center
Input: operationCenterCode, active=true
Output: operationCenterId
-
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 3 - 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 4 - 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 5 - Multistage Group Validation
System takes Input fields and checks their existence in internal configuration. The system also verifies if the group state is consistent with the cancellation of its operations → if status NOT IN (‘CLOSED’, ‘CANCELLED’).
If System can obtain the Output fields and group status is ‘CLOSED’ or ‘CANCELLED’ → responds with error. Elaboration is stopped.
If System can obtain the Output fields and group status is not ‘CLOSED’ or ‘CANCELLED’ → continue to next step.
If System can’t obtain the Output fields → Create → responds with error. Elaboration is stopped.
STEP 6 - Multistage Group Operation Validation
System takes Input fields and checks their existence in internal configuration.
API Verb: GET
Resource: /{groupId}/operations
Input: groupId
Output: list of [multistageGroupOperationId, workOrderOperationId]
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:
-
Others - see link in Resource
STEP 7 - Multistage Group Operation Deletion
System takes Input fields and deletes Group Operations.
The private API automatically deletes also the Group Dependency linked to the Group Operation AND reverts the group to the 'Created' state, if allowed. If not allowed, the Private API blocks all these actions.
API Verb: DELETE
Resource: /{groupId}/operations/{multistageGroupOperationId}
Input: groupId, multistageGroupOperationId
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
Path Parameters
As their name suggests, they are included in the URL path of the endpoint.
Query String Parameters
Start with a ? and includes parameters listed one after the another separated by &.
Filters
|
Field |
Description |
Mandatory |
Constraint |
|
|---|---|---|---|---|
|
1 |
externalSystemCode |
External System Code |
Y |
Not Blank |
|
2 |
groupExternalCode |
Group External Code |
Y |
Not Blank |
|
3 |
operationCenterCode |
Operations Center Code |
Y |
Not Blank |
|
4 |
workOrderCode |
Work Order Code |
N |
|
|
5 |
workOrderExternalCode |
Work Order External Code |
N |
|
|
6 |
workOrderOperationCode |
WO Operation Code |
N |
|
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.
Not Applicable
Request example
{baseUrl}/integration/work-orders/multistages/r1/groups-operations?externalSystemCode=SAP&externalCode=PRJ-2026-XYZ&workOrderCode=YYYY&workOrderExternalCode=XXXX&operationCenterCode=NorthArea&workOrderOperationCode=1001,1002
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/inventory/r1/materials/string?externalSystemCode=string",
"code": "IA001_001"
}