How Replicating Events works within in a Hierarchy?

Products

• IT Management Suite

Issue/Introduction

 This article explains how Replicating Events works within in a Hierarchy

Environment

ITMS 8.x

Resolution

Replicating Events

Events are replicated using a hierarchy container item, using the web service. The standard event queues are not used.

 

To check the last time an event class was replicated, query the EventReplicationStatus table on the source server DB.

 

There is a core setting called ‘ReplicationMaxEventRows’ which controls the maximum number of event rows that can be replicated at any one time, per event class. The default value of the core setting is 100,000. However the UI for the event replication rules allows the user to configure exactly how many event rows to replicate, up to a maximum of 100,000.

 

If enabling the option inside the UI ‘Resend events that have been sent previously’ it is possible that duplicate events records may occur at the destination NS, as all events are resent regardless. This is not a bug, and is by design.

Question and Answer on Event replication

 

In the following scenario what is the expected result?

 

1. Create an event replication rule
2. Select to replicate 1 event class
3. Max rows set to 100
    - There are 300 rows in the source event table
4. Run the replication, and it sends 100 rows as expected
5. Next, run the same rule a second time.

Should it send another 100 rows of event data from the table, those of which had not been sent in the previous replication?

No, it should not,once a rule is run against a particular event class for a particular server, it records the timestamp of the time this event class was last replicated to a particular destination. Only events that are inserted into the event table AFTER this timestamp are sent on subsequent replication runs. This was a design decision made to limit the complexity of event replication due to their volatility.