HubEngine: Backpersist

The function “Backpersist” can be found in the Connections of a plan under the Advanced Options.

With backpersist, when a record is created in the target system, the ID is written back to a defined field in the source system. There are three options for backpersist:

• backpersist creation field
• backpersist delete field
• backpersist delete value

Backpersist Creation Field

A plan is used to synchronize from system A to system B. A record from system A is created in system B because it does not yet exist there. The ID of the created record in system B is written back to the defined field after creation in system A (Backpersist Creation Field).

Backpersist Delete Field

A value is written to the Backpersist Delete Field when the record is deleted in the target system. The default is 1. If you want to write a custom value, then enter this value in backpersist delete value.

For example you synchronize from system A to system B. If a record is deleted in system B and is no longer available, the HubEngine writes to the specified Backpersist Delete Field.

Backpersist Delete Value

Here you specify the value to be written to the Backpersist Delete Field.

We synchronize unidirectionally from system A to system B. This means that we create the backpersist options in the connection from A -> B.

To illustrate this, we use a very reduced example. The records of John and Jane are synchronized. We map the fields Name and Deleted for the synchronization. Note that the field Deleted has different values in both systems! This makes it easier to illustrate the “backpersist delete” function later. The mapping:

• Name : Name, type = string
• Deleted_In_A : Deleted, type = boolean, Value label mapping: 0 = False, 1 = True

In system A, the integer values 0 and 1 are used to flag whether a record is deleted. In system B this is done by booleans.

The configuration of all backpersist options is:

The relevant fields are ID, Name, ID_System_B, Deleted_In_A. ID_System_B is yet empty. By backpersisting we want to fill exactly this field. Through the synchronization we get the following data in system B:

During plan execution, the IDs of the two created records are written back to system A, into the ID_System_B field that we previously stored in the “backpersist creation field” function. Therefore, system A now looks like this:

If you delete a record in system A, the synchronization will also flag the record in system B as deleted. But if now a record is deleted in system B, you can use the Backpersist Delete option to flag it as deleted in system A as well. We delete John from system B:

During the next plan execution, the HubEngine now recognizes that John was deleted in system B. This activates the Backpersist Delete function. We now write the value 1 (Backpersist Delete Value) into the field Deleted_In_A (Backpersist Delete Field). This means that John is also flagged as deleted in system A.