Hi @TDCSOURABH,

If you were to use FSM Connect for the connection then the app param INTEGRATION_DEFAULT_EXECUTION_MODE could then control this sort of roll back behaviour. The ODATA connection will not link the two transactions as you have seen.

Are you able to clarify why you believe that this should be atomic?

Kind regards,

Lee Pinchbeck

Hi, 

But as per the REST API documentation, the change sets are supposed to be atomic and committed together. 

Regards, 

Sourabh Jain

Hi @TDCSOURABH,

In the line before it indicates “Batch requests are sent as sequential independent perform batch message. Within the batch, updates are grouped into changesets.”

Whilst they are in a batch I am not sure these are grouped as a changeset. The two changes are not connected in anyway, one refers to the calendar exceptions and the other to a task with no mention of the person in the task update and no mention of the task in the calendar exception and nothing to indicate the connection to each other.

The example in the documentation is for parent child records which would be more like request and associated task but in your example you are using the exception calendar and the task status which do not share any relation. Do you have a parent child relation between the task table and the calendar exceptions set up in your data?

Kind regards,

Lee Pinchbeck

Hi, 

I don’t think they have to be related by data, they are only related using the change set id.  And the parent child relation is just a user story.  

I have tried with request and task , it also behaves the non atomic way,  the request change is committed even though the task change failed. 

PATCH https://tsrvwapp1497.tdk.dk/IFS_T2FSM_Application/odata/request('20190808-000105') HTTP/1.1
Content-Type: application/json
Content-ID: 3

{
    "cust_prob_descr":"test"   
}

PATCH https://tsrvwapp1497.tdk.dk/IFS_T2FSM_Application/odata/task(83581) HTTP/1.1
Content-Type: application/json
Content-ID: 4

{
    "task_status": "ENROUTE123",
    "status_as_of": "2021-10-26T15:37:37.0047496",
    "user_def109": "",
    "modified_by": "M41896"
}

Can you give an example request where you think the atomic behavior works. 

Regards, 

Sourabh Jain

What happens if you remove:

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621

Content-Type: application/http

Content-Transfer-Encoding: binary

from in between the two POST transactions?

I did not think you had to re-declare that information if it was part of the same changeset.

It is somehow needed, it gives the below error when  removed. 

--batchresponse_fffa1f58-a2a4-4c03-9983-faa142862139
Content-Type: application/http
Content-Transfer-Encoding: binary

HTTP/1.1 500 Internal Server Error
Content-Type: application/json; charset=utf-8

{"Message":"Additional text encountered after finished reading JSON content: P. Path '', line 7, position 0."}
--batchresponse_fffa1f58-a2a4-4c03-9983-faa142862139--

Request

--batch_d3bcb804-ee77-4921-9a45-761f98d32029
--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621
Content-Type: application/http
Content-Transfer-Encoding: binary

PATCH https://tsrvwapp1497.tdk.dk/IFS_T2FSM_Application/odata/request('20190808-000105') HTTP/1.1
Content-Type: application/json
Content-ID: 3

{
    "cust_prob_descr":"test"   
}

PATCH https://tsrvwapp1497.tdk.dk/IFS_T2FSM_Application/odata/task(83581) HTTP/1.1
Content-Type: application/json
Content-ID: 4

{
    "task_status": "ENROUTE123",
    "status_as_of": "2021-10-26T15:37:37.0047496",
    "user_def109": "",
    "modified_by": "M41896"
}

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621--
--batch_d3bcb804-ee77-4921-9a45-761f98d32029

Hi @TDCSOURABH,

In that case this would need to be raised to support to determine why this is not rolling back and correct.

Kind regards,

Lee Pinchbeck

We managed to get it to work in the atomic way. The $batch calls are atomic, there was an error on the content-type I was using (I incorrectly used the change set id in the boundary instead it should be the batch id). This is not mentioned in the ODATA documentation. 

For others who are also facing this issue, you need to include the below Content-Type in the Headers section. 

multipart/mixed;boundary=batch_d3bcb804-ee77-4921-9a45-761f98d32029

Sample request

--batch_d3bcb804-ee77-4921-9a45-761f98d32029
Content-Type: multipart/mixed; boundary=changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621
Content-Type: application/http
Content-Transfer-Encoding: binary

POST http://tsrvwapp1497/IFS_T2FSM_Application/OData/request HTTP/1.1
Content-Type: application/json
Content-ID: 1

{
    "modified_by":"USER1",
    "created_by":"USER1",    
    "req_type":"TEST",
    "cust_prob_descr":"Test",
    "place_id":"TEST"    
}

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621
Content-Type: application/http
Content-Transfer-Encoding: binary

POST http://tsrvwapp1497/IFS_T2FSM_Application/OData/task HTTP/1.1
Content-Type: application/json
Content-ID: 2

{
    "plan_start_dttm":"2021-10-16T16:12:42.7997002",
    "task_status":"ASSIGNED",
    "description":"Test",
    "user_def11":"7500",
    "team_id":"TEAM01",
    "created_by":"USER1",
    "plan_end_dttm":"2021-10-16T17:12:42.7997002",
    "plan_task_dur_min":"60",
    "status_as_of":"2021-10-16T16:12:42.7997002",
    "project_id":"181",
    "task_type":"TEST",    
    "person_id":"USER1",
    "status":"OP",
    "request_id":{ "@xpath_node":"//request/request_id" }
}

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621--
--batch_d3bcb804-ee77-4921-9a45-761f98d32029

If the 2nd call to create task fails then the 1st call to create request will automatically be rolled back.