Conflict is detected in the middleware when there is a modification to a SyncBO instance in both the client and backend. In MI there are 2 ways of detecting the Conflict. The 2 types of conflict detection are a) Normal Conflict Detection (Default) b) Row based Conflict detection. In Normal Conflict Detection, MI detects a conflict when there is change to the same SyncBO instance on the client and backend. This check is done when the client uploads the data to the middleware. After data is uploaded MI will compare the uploaded data with the data from the backend. If there is any change to the data from the backend then MI detects this as a conflict. When a conflict is detected, MI sends the current data of the backend to the client. The data sent to the client will have header data with ‘R’ action in the ACTION field. This SyncBO instance on the client will be overwritten with the data from backend. The changes made on the client for this SyncBO will be lost. The user has to again do the changes and then upload them to the backend. A change in the SyncBO instance can be header data being modified or the SyncBO instance itself being deleted. There can be changes at the item level such as creation, deletion and modification of the items. When such scenarios occur, MI sends the reason for conflict in the message reply. The information sent will be as follows 'Conflict: R/3 = xxxxxxx, device = xxxxxxx'. Where xxxxxxx can be Modify or Delete. In the worklist monitor, the user can see the status of the inbound request as shown in the image below during a conflict scenario. 
The message reply will have the following response. The following screen shot shows that a conflict was detected as the SyncBO data was deleted in the backend and the same data was modified in the client. 
In Row Based Conflict Detection, MI detects a conflict only if the changes to the SyncBO instance are at the same row both on the client and as well as the backend. This is switched off by default and can be enabled in Profile Dialog by putting a check in the Row Comparison Column. Here a row in a SyncBO instance may the header row (TOP) or item instances (010, 020….). The following figure will give more clarity on row concept of SyncBOs. 
In the above figure, each there is 7 rows of data. This consists of 1 header row and 6 items row. Consider a scenario where the user on the client will modify the header data of the above SyncBO shown in figure. So the change is in the top row. Also in the backend there was a change in the structure 010’s 2nd item. This change is in the 3rd row. The above scenario is NOT CONSIDERED as a conflict since the changes are at different rows. The middleware will merge the changes made both on the client and as well as the backend. The change made from the client gets reflected in the backend and the change made in the backend gets reflected in the client. Consider a scenario where the user on the client will modify the 010’s 2nd item data of the above SyncBO shown in figure. This change is in the 3rd row. In the backend there was a change in the structure 010’s 2 nd item also. This change is also in the 3rd row. The above scenario is CONSIDERED as a conflict since the changes are at same row both in the client as well as the backend. When a conflict is detected, MI sends the current data of the backend to the client. The data sent to the client will have header data with ‘R’ action in the ACTION field. This SyncBO instance on the client will be overwritten with the data from backend. The changes made on the client for this SyncBO will be lost. The user has to again do the changes and then upload them to the backend. The behaviour and response of the MI server after conflict is detected is same as the normal conflict detection which has been explained above. The difference between the types of conflict detection is the process of identifying the conflict. When Row Level Conflict detection is enabled, the probability of data getting updated in the backend will increase. In the 2 types of conflict detection explained are always Server Wins Strategy, where the changes made in the backend is always retained and the client changes are discarded during a conflict scenario. Here backend is always the winner. We can implement the Client Wins Strategy where the change made by the client is always used to overwrite the backend data. MI achieves this strategy by skipping the conflict check altogether. The changes in the backend are always discarded and replaced with client data. This can be configured using Profile dialog (Synchroniser Tab>Config Button) for MI2.5 SP19 onwards. The Client Application will have to implement Error/Conflict Inbox feature in order to inform the user in case of conflict. More details on this can be found in the MDK documentation.
The message reply will have the following response. The following screen shot shows that a conflict was detected as the SyncBO data was deleted in the backend and the same data was modified in the client. In Row Based Conflict Detection, MI detects a conflict only if the changes to the SyncBO instance are at the same row both on the client and as well as the backend. This is switched off by default and can be enabled in Profile Dialog by putting a check in the Row Comparison Column. Here a row in a SyncBO instance may the header row (TOP) or item instances (010, 020….). The following figure will give more clarity on row concept of SyncBOs. In the above figure, each there is 7 rows of data. This consists of 1 header row and 6 items row. Consider a scenario where the user on the client will modify the header data of the above SyncBO shown in figure. So the change is in the top row. Also in the backend there was a change in the structure 010’s 2nd item. This change is in the 3rd row. The above scenario is NOT CONSIDERED as a conflict since the changes are at different rows. The middleware will merge the changes made both on the client and as well as the backend. The change made from the client gets reflected in the backend and the change made in the backend gets reflected in the client. Consider a scenario where the user on the client will modify the 010’s 2nd item data of the above SyncBO shown in figure. This change is in the 3rd row. In the backend there was a change in the structure 010’s 2 nd item also. This change is also in the 3rd row. The above scenario is CONSIDERED as a conflict since the changes are at same row both in the client as well as the backend. When a conflict is detected, MI sends the current data of the backend to the client. The data sent to the client will have header data with ‘R’ action in the ACTION field. This SyncBO instance on the client will be overwritten with the data from backend. The changes made on the client for this SyncBO will be lost. The user has to again do the changes and then upload them to the backend. The behaviour and response of the MI server after conflict is detected is same as the normal conflict detection which has been explained above. The difference between the types of conflict detection is the process of identifying the conflict. When Row Level Conflict detection is enabled, the probability of data getting updated in the backend will increase. In the 2 types of conflict detection explained are always Server Wins Strategy, where the changes made in the backend is always retained and the client changes are discarded during a conflict scenario. Here backend is always the winner. We can implement the Client Wins Strategy where the change made by the client is always used to overwrite the backend data. MI achieves this strategy by skipping the conflict check altogether. The changes in the backend are always discarded and replaced with client data. This can be configured using Profile dialog (Synchroniser Tab>Config Button) for MI2.5 SP19 onwards. The Client Application will have to implement Error/Conflict Inbox feature in order to inform the user in case of conflict. More details on this can be found in the MDK documentation.
2 Comments
