#Crm2Crm – part 3: Replication basics 2

Last time I described the concept of a simple one way replication pattern. In this pattern each time an entity record is added, modified or deleted a message is written in a message entity.

The message pump will process the messages within the message entity in the order they arrived in the message entity (First In First Out), combined with the action assigned to the message entity record (as described in the previous article).

The content of the message entity record is applied on the destination entity. So far so good…

Replication2

I promised to spice up things a bit in this article… The big question is, what will happen if we duplicate this pattern in order to make the replication bidirectional? Instead of one message entity, we now have two message entities and instead of one message pump we now have two message pumps.

We end up with a pattern as drawn below:

Replicationfail

What will happen is the following:

  1. In the original entity we add a new record.
  2. A create message is written to the message entity.
  3. The message pump picks up the create message (with all relevant data) and create a new record in the destination entity.
  4. A create message is created by the destination entity and written to its message entity.
  5. The second message pump picks up the message and creates a new record in the original entity.
  6. A create message is written to the message entity.
  7. and so on…
  8. and so on…

In other words we end up in an infinite loop, also called a replication storm!

In our mechanism we should take measures to prevent a replication storm from happening. Therefor we need to define a simple but effective rule:

A change to an entity caused by a replication action should not result in a change message for replication!

Our enhanced replication pattern (with the rule applied) would look like this:

Replication4

What will happen in this scenario is the following:

  1. In the original entity we add a new record.
  2. A create message is written to the message entity.
  3. The message pump picks up the create message (with all relevant data) and create a new record in the destination entity.
  4. The process stops.
  5. We create a new record in the destination entity.
  6. A create message is written to the message entity.
  7. The message pump picks up the create message (of the new message in the destination entity) and creates a new record in the source entity.
  8. The process stops.

We can apply the rule as well for update and delete messages. By using the rule we ensure that a change is reflected only on the target and not on the source.

When we want to apply this pattern on CRM entities we have to do the following:

In the source entity (data entity) we have to add an additional field “SourceEntityId”. When an entity record is modified by the message pump, we have to add the source entity id in the destination entity.
A plugin registered on the create, update and delete event in the destination entity will execute in case the destination entity is modified.

In case the destination entity record contains a filled source entity id. The source entity id is cleared and the process stops.
In case the destination entity record does not contain  a filled source entity id, a new message is created and offered to the message entity.

This describes more or less how our rule can be implemented. I will need to figure out some specific details.

This leaves us with two questions that need to be answered:

  • How do I specify what entity will replicate to what entity?
  • How do I handle differences between source and destination entity schemes?

For now enough stuff to chew on… In the meanwhile I’ll think on how to resolve the unanswered questions.

Leave a Reply

Your email address will not be published. Required fields are marked *