Data Conflict Solution for ADF BC REST With Versioning

I would like to share sample solution for data conflict processing in ADF BC REST using versioning. When multiple users are editing concurrently the same data row, it is important to inform the user before the overriding changes are already committed by another user. There are other approaches to implement data conflict control, and you should evaluate if the solution explained below is suitable for your use case before applying it.

Sample code can be obtained from GitHub repository.

I'm using a custom change indicator property to evaluate if the client data is expired. The change indicator value is sent to the client together with the request data. PATCH request must include current client-side change indicator value if the change indicator will match the value in the backend — PATCH is allowed, otherwise, a new change indicator will be returned to the client and the response will be marked with 409 Conflict status code. Based on this, the client could decide either to resubmit the PATCH request with a new change indicator and overwrite the current data in DB or refresh the client-side data and try to submit changes later.

In this example, PATCH was executed with a valid change indicator, and response status is 200 OK. A new change indicator value is returned to the client (it should be submitted for the next PATCH call for current row):

To test the data change conflict, I would go directly to DB and change the same record. The change indicator will be updated too:

The client doesn't know about the change indicator update (the data was changed by another user). The client will include currently known change indicator values and execute PATCH. This will result in 409 Conflict status. the backend returns the latest change indicator value in the response:

The data wasn't updated, and the PATCH request was stopped on the backend:

The client knows the latest change indicator value and can submit it again — this time successfully (no one else changed data in the meantime):

Status 200 OK is returned, along with a new change indicator value. Data is changed in DB as expected:

Backend implementation is not complex. You need a DB trigger, which will get a value from the DB sequence and assign it for each changed row:

ADF BC REST includes a change indicator attribute, and it is marked with Refresh on Update support. This allows us to get the latest value assigned from the DB trigger and return it to the client:

In the doDML method, we compare the change indicator attribute value currently stored in DB and the one that comes from the client. If the values do not match (client doesn't have the latest value), the update is not allowed:

When the update is not allowed, we also must change the HTTP response code to be 409 Conflict. This will allow us to execute an error callback on the client side and take the required action to process the data conflict on the client. The HTTP response code is set from custom ADF BC REST filter: