Predictive Replication Rules

In a multi-site environment, when a user requests a file that is not present in the local FCS, the MCS triggers an operation called "on demand replication".

This operation involves copying the file from another FCS to the FCS of the current user, and can take quite some time since the FCSs can be spread worldwide, with high network latency between them and with a high network packet loss rate. The user has to wait until the file is copied to the local FCS. An FCS synchronization server rule allows you to predict where the file will be required and synchronize both FCSs preemptively.

This page discusses:

Overview

The rule synchronizes recently checked-in files to the locations where their previous revisions have been replicated. The idea is that if a previous version of the file has been replicated to a given site, there is a strong probability that the new version of the file will also need to be replicated on that site. Performing this replication preemptively before a user requests it enhances performance. The replication of the files occurs only once the rule has been executed.

Note: The lxFile table definition in the database needs to be up-to-date (run the MQL upgrade command if this is not the case).

How the Rule Works

Predictive replication is enabled by adding a predictivesyncrule in an FCS synchronization server XML rule file and adding an event monitor on the check-in operation. The event monitor logs every check-in date, and the business object and the fileID.

When the rule is executed, the FCS synchronization server will scan all the entries in the event monitor. If the entry is older than the validity duration or does not match any valid data, it is removed. If the business object of the entry does not have revisions or if its revisions files are not replicated, the entry is removed. Otherwise, the FCS synchronization server follows the business object revision chain backwards (starting from the BO on which the file has been checked-in) until a stop condition is reached.

Stop conditions are:

  • the end of the revision chain has been reached
  • the limit of the depth in the revision chain (to which the server follows the rule back) has been reached
  • a business object having at least one up-to-date file with the same format as the checked-in file has already been synchronized on a different site than the one of the checked-in file.

In the last case, the FCS synchronization server searches all the sites where files with the same format are replicated, and replicates the newly checked-in file to those sites.

To detect newly checked-in files, a new type of event for the business object must be created in the event monitor: the event type checkin.

Example

The new DTD of the XML rule file is:

<!DOCTYPE syncrules [

<!ELEMENT syncrules (predictivesyncrule, syncrule+ ) > 
<!ATTLIST syncrules locale CDATA ""> 
<!ELEMENT syncrule ( store , source , dest , ( 
(daily, concurrency? , zip? , (query?|buslist?|formats?)) | 
(weekly, concurrency? , zip? , (query?|buslist?|formats?))| 
(monthly, concurrency? , zip? ,(query?|buslist?|formats?))| 
(delay, concurrency? , zip? ,(query?|buslist?|formats?))| 
(size, concurrency?, zip?,formats?))) > 
<!ATTLIST syncrule name CDATA #REQUIRED > 
<!ELEMENT predictivesyncrule ((daily|weekly|monthly|delay), predictivefetcher, concurrency? )>
<!ATTLIST predictivesyncrule name CDATA #REQUIRED > 
<!ELEMENT predictivefetcher (eventmonitorname, depth?, validityduration? )>
<!ATTLIST predictivefetcher name CDATA #REQUIRED > 
<!ELEMENT eventmonitorname (#PCDATA)> 
<!ELEMENT depth (#PCDATA)> 
<!ELEMENT validityduration (#PCDATA)> 
<!ELEMENT daily (synctime) > 
<!ELEMENT weekly (synctime) > 
<!ELEMENT monthly (synctime) > 
<!ELEMENT size (syncsize) > 
<!ELEMENT delay (syncdelay) > 
<!ELEMENT synctime (#PCDATA)> 
<!ELEMENT syncsize (#PCDATA)> 
<!ELEMENT syncdelay (#PCDATA)> 
<!ELEMENT zip EMPTY> 
<!ELEMENT concurrency (#PCDATA)> 
<!ELEMENT buslist (class , param+ )> 
<!ELEMENT class (#PCDATA)> 
<!ELEMENT param (#PCDATA)> 
<!ATTLIST param name CDATA #REQUIRED value CDATA #REQUIRED>
<!ELEMENT query ( predicate ) > 
<!ELEMENT predicate ( and | or | attribute* ) > 
<!ELEMENT and ( or | attribute* ) > 
<!ELEMENT or ( and | attribute* ) > 
<!ELEMENT attribute EMPTY> 
<!ATTLIST query lang (ipml) #REQUIRED> 
<!ATTLIST predicate type CDATA #REQUIRED> 
<!ATTLIST attribute name CDATA #REQUIRED> 
<!ATTLIST attribute value CDATA #REQUIRED> 
<!ATTLIST attribute operator CDATA #REQUIRED> 
<!ELEMENT dest (#PCDATA)> 
<!ELEMENT source (#PCDATA)> 
<!ELEMENT store (#PCDATA)> 
<!ELEMENT formats (#PCDATA)>

]>

Here an example of an XML file using the predictivesyncrule rule and no syncrule rule:

<?xml version="1.0"?>
<syncrules>
	<predictivesyncrule name="ExampleRule">
		<delay>
			<syncdelay>00:30</syncdelay>
		</delay>
		<predictivefetcher name="revisionbased">
			<eventmonitorname>checkinmonitor</eventmonitorname>
			<depth>6</depth>
			<validityduration>10</validityduration>
		</predictivefetcher>
		<concurrency>2</concurrency>
	</predictivesyncrule>
</syncrules>

where:

predictivesyncrule
The attribute name in the element predictivesyncrule is the name of the rule that will be printed in the logs. In our example the name is ExampleRule. As for syncrule, predictivesyncrule requires a trigger when the rule must be started.
syncdelay
Predictivesyncrule accepts the same trigger sync rule, exempt the size trigger (month, week, day, and delay). In our example, as a delay trigger is defined with the value 00:30, the rule will be executed every 30 min.
predictivefetcher
The element predictivefetcher is used to find which files must be synchronized. The attribute name says which strategy will be used. Currently, only revisionbased is authorized. This element requires the mandatory sub-element eventmonitorname containing a string.
eventmonitorname

This string must be a valid event monitor on the event businessobject checkin previously created by the administrator. In our example, the name of the used event monitor is checkinmonitor, which the administrator should have already created using the MQL command:

add eventmonitor checkinmonitor event businessobject checkin;

depth
The first option of predictivefetcher is depth which is used to limit the depths of the search of the previous file revisions. The default value is 0. A value of 0 or a negative value means no limit. In our example the value is 6, so if the six previous revisions of the business object (on which a check-in event has been logged) do not have any replicated files, no action is taken for this event.
validityduration
The second option of predictivefetcher is validityduration. The option is used to avoid processing an event which is too old. The default value is 3 days. The value in the XML file is in days, so in our example, events older than ten days are discarded. If the value in the XML is 0 or less, the validityduration is reset to the default value.
concurrency
As for syncrule, predictivesyncrule accepts the option concurrency which indicates the number of threads the rule will use to perform file synchronizations. The default value is 1. In our example, the value is 2, so two threads will be used.