Conflict detection

Matching Algorithm

An algorithm responsible for matching organizations. It allows determining which organization entities represents the same real organization.

OrganizationMatch

The organization match entity will represent a connection between two organization entities which represents the same real organization.

OrganizationComparatorService

Compares organization's entities with matching organization's entities.

Conflict

---

entity Conflict {
  UUID id,
  SystemAccount owner,
  List<SystemAccount> acceptedThisChange,
  UUID resourceId,
  String currentValue,
  ZonedDateTime currentValueDate,
  String offeredValue,
  ZonedDateTime offeredValueDate,
  String fieldName,
  String entityPath,
  ConflictStateEnum state,
  ZonedDateTime stateDate,
  ZonedDateTime createdDate
}

Represents differences in a particular field. It is bound to a specific entity (resourceId) for a specific owner.

Owner

Each organization has a system account. When the data is uploaded or cron job has triggered, the organization compare itself (all entities) to other matched organizations. Every conflict detected at this phase is owned by that organization.

A 'acceptedThisChange' list

A list of all organizations that applied an offered value of the conflict.

EntityPath and FieldName

Each entity is described by EntityPath which consist of superior entity names e.g. organization/service/serviceArea. A FieldName is simply a name of the object’s field e.g. /description.

The rest of the Conflict's fields

• id - uuid of a new conflict,
• resourceId - an identifier of an owner’s entity in the database,
• currentValue - the value of the owner’s entity,
• currentValueDate - timestamp of current field change,
• offeredValue- the conflict value,
• offeredValueDate - timestamp of offered field change,
• state - a state of the conflict { PENDING, ACCEPTED, REJECTED },
• stateDate - timestamp of last state change,
• createdDate - timestamp of creation of the conflict

Detecting conflicts - workflow

1. A new data set is uploaded to the ServiceNet.
2. All created organizations are being passed to the Matching Algorithm and OrganizationMatches are created. The OrganizationMatche have to be extend by adding entities’ mappings which will map entities between organizations i.e. pairs of resource ids.
3. All created or updated organizations and their entities are processed by OrganizationComparatorService.
4. OrganizationComparatorService compares each organization with its organization matches.
5. Each organization entity is compared to the matching one and all differences are gathered as conflicts.
6. When conflict for certain field of entity is detected we search for them using resourceId, currentValue, offeredValue for our conflict and MatchedOrg.mapping.mirrorEntity.id, offeredValue, currentValue for mirror conflict. We can narrow searching by adding conditions regarding createdDate or voided.
7. If the result is empty we create two mirror conflicts (one for our current organization and one for the organization which we compare to) and save them in the database.
8. If the result is not empty we update two mirror conflicts by adding system account to the list of acceptedThisChange.

This workflow will occur when the data is uploaded or when the cron job is started.