Setting Up the FCS Synchronization Server

The File Collaboration Server (FCS) Synchronization Server is an administration tool used to monitor and plan replicated store synchronization, and to facilitate production data management.

For customers deploying the 3DEXPERIENCE server with a multi-site configuration, this tool makes location synchronization easy and efficient. It is a centralized administration server for multi-site deployment.

This page discusses:

Overview of FCS Synchronization Server Functionality
FCS Synchronization Server Deployment
How the FCS Synchronization Server Components Work
Supported Synchronization Rules
Configuring Synchronization Server Daemon Parameters
Time and Date Values in Rule Definitions
Compression Definitions
Concurrency Definitions
Business Object List Definitions
Changing Default Java Options for the FCS Sync Server

Overview of FCS Synchronization Server Functionality

The FCS Synchronization Server performs synchronization between two locations of the same store, or a location and its store, based on customer-defined synchronization rules. The FCS Synchronization Server monitors the progression of these synchronization rules and returns information on the amount of synchronized data and the locations concerned.

FCS Synchronization Server Deployment

The FCS Synchronization Server is deployed as a daemon program, running on the central site, connected to the database.

Note: On UNIX, the maximum number of file descriptors has to be increased to 10000.This is the correct way to get the FCS Synchronization Server up and running correctly.

How the FCS Synchronization Server Components Work

The FCS Synchronization Server daemon is a multi-threaded stand-alone process in charge of selecting and executing the synchronization rules. Its activity is traced in three rotating log files.

The synchronization server periodically sends HTTP FCS "ping" requests to the FCS servers managing locations involved in synchronization rules.

Supported Synchronization Rules

All rules perform synchronization between two locations of the same store or a location and its store.

Rules executed periodically: the specific parameter for this rule is the time interval between two executions. For example, "synchronize two locations every two hours" means that two hours must elapse between two executions of this rule.
Rules executed daily, weekly, monthly: the specific parameter for those rules is a date.
Rules executed when the amount of non up-to-date data files between two locations or a location and store reaches a fixed value: for example, synchronize a store and one of its locations when the size of non up-to-date data files is above 100m.

These synchronization rules can also contain compression, concurrency, and business object list definitions.

Configuring Synchronization Server Daemon Parameters

Configure as follows:

Rules check frequency—The synchronization server daemon periodically checks for rules to be executed. This parameter defines the frequency of those checks.
Max-retry—The synchronization server daemon counts the number of times a business object file synchronization fails. When this count reaches max-retry, the bus is excluded from all synchronization rule execution. In this case, the bus is listed in the log.

? Rule declaration: synchronization rules are declared in the <syncrules> section of Synchronization Server xml rule file.

Here is the DTD of the syncrules section:

<!ELEMENT syncrules ( 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 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 is a sample <syncrules> section:

<?xml version="1.0"?>
<syncrules locale="en_US">
    <syncrule name="rule1">
       <store>plmx</store>
       <source>dali4dsy</source>
       <dest>plmx</dest>
       <daily>
          <synctime>16:00</synctime>
       </daily>
       <zip/>
       <concurrency>4</concurrency>
    </syncrule>
    <syncrule name="rule2">
       <store>plmx</store>
       <source>dali4dsy</source>
       <dest>plmx</dest>
       <weekly>
          <synctime>Monday 11:00</synctime>
       </weekly>
    </syncrule>
    <syncrule name="rule3">
       <store>plmx</store>
       <source>dali4dsy</source>
       <dest>plmx</dest>
       <monthly>
          <synctime>13 16:00</synctime>
       </monthly>
    </syncrule>
    <syncrule name="rule4">
       <store>plmx</store>
       <source>dali4dsy</source>
       <dest>plmx</dest>
       <size>
          <syncsize>150</syncsize>
       </size>
    </syncrule>
    <syncrule name="rule5">
       <store>plmx</store>
       <source>plmx</source>
       <dest>gagny2dsy</dest>
       <delay>
          <syncdelay>05:00</syncdelay>
       </delay>
    </syncrule>
    <syncrule name="rule6">
       <store>plmx</store>
       <source>gagny2dsy</source>
       <dest>plmx</dest>
       <delay>
          <syncdelay>03 12:00</syncdelay>
       </delay>
    </syncrule>
    <syncrule name="rule7">
       <store>plmx</store>
       <source>gagny2dsy</source>
       <dest>plmx</dest>
       <daily>
          <synctime>11:00</synctime>
       </daily>
       <buslist>
          <class>com.dassault_systemes.fcs.syncserver.FileBusListTNRIterator</class>
<param name="path" value="E:\path_to_buslist_file\buslist.txt" />
       </buslist>
    </syncrule>
</syncrules>

In the above sample:

Rule rule1 is launched at 16:00 (tea time) every day and executes on four concurrent threads. The file synchronization streams generated by the rule are compressed.
Rule rule2 is launched at 11:00 AM every Monday.
Rule rule3 is launched at 16:00 (tea time) every 13th of the month.
Rule rule4 is launched when the amount of data to synchronize reaches 150mb.
Rule rule5 is launched 5 hours after the last "rule5" run has finished.
Rule rule6 is launched 3 days and 12 hours after the last "rule6" has run finished.
Rule rule7 is launched at 11:00 AM every day and synchronizes only the files of the business objects listed in buslist.txt.

The locale attribute of the <syncrules> node defines the locale in which time and dates is expressed in the rule definition file. This locale attribute is optional. If not provided, the synchronization server hosting system's locale is used for date and time parsing.

Accepted values for the locale attribute follow the pattern aa_BB:

aa expresses the language encoded by two lowercase letters using the ISO-639 code.
BB expresses the country with two upper case letters using the ISO-3166 code.

Samples: fr_FR French locale and France, en_UK English locale for the United Kingdom.

Time and Date Values in Rule Definitions

All time values are locale dependant, using jvm default local.

For daily rules <daily>—Accepted sync time is HH:mm in 24h. As usual, H stands for an hour digit, m stands for a minute digit, and s for a second digit.
For weekly rules <weekly>—Accepted sync time format is EEEE HH:mm where E stands for day-in-week letter. For example, with the German locale, di 14:30 stands for "Dienstag, 14:30". Writing dienstag 14:30 is recommended.
Using the French locale, to create a weekly rule starting every Friday at 8:30 PM, you can set the synctime value to vendredi 20:30.
For monthly rules <monthly>—Accepted sync time format is dd HH:mm, where d stands for a day-in-month digit.
For delay rules <delay>—Accepted sync delay formats are dd HH:mm and HH:mm.
For size rules <size>—A positive non-zero integer is expected, ranging from 1 to 2 147 483 648. This size is implicitly expressed in megabytes (m). Size rules cannot contain business object list definitions.
Warning: A size below 100m might impair MCS performance.

Compression Definitions

The zip flag <zip/> can be used in any rule to compress the file synchronization streams generated by the rule. Compressed synchronization should only be used in a WAN environment (the underlying network should have more than 1ms of latency) and when the files involved are not already in a compressed format (for example, .zip, .jpg, .gif, .gz, etc.).

Concurrency Definitions

The concurrency flag <concurrency> can be used in any rule to execute the rule on more than one thread. Executing a rule on multiple threads increases synchronization performance in WAN environments by using more bandwidth for file synchronization. The FCS Synchronization Server uses a smart dispatcher to prevent dead-locks and to distribute the file synchronization operations evenly across the available threads. It is recommended that no more than six threads be used to execute a rule. Concurrency should only be used in a WAN environment.

Business Object List Definitions

The business object list flag <buslist> can be used in any rule except size rules to restrict file synchronization to only the files of the business objects listed in a text file. The public sync server interface is com.dassault_systemes.fcs.syncserver.BusTNRIteraton; which is in FCSSyncServer.jar. Based on this interface, the provided implementation for this restrictive list is "com.dassault_systemes.fcs.syncserver.FileBusListTNRIterator".

The text file containing the list of business objects should contain a line for each business object. Each line must contain a type, name, and revision separated by the pipe character (type|name|revision). The type, name, and revision combination should uniquely identify the business object. For example:

VPLMtyp/PLMRepresentationDS|Fermoir Long_CENTRAL1806Representation87|---
VPLMtyp/PLMRepresentationDS|Maintien court_CENTRAL1806Representation88|---
VPLMtyp/PLMRepresentationDS|Maintien long_CENTRAL1806Representation89|---
VPLMtyp/PLMRepresentationDS|Fermoir_CENTRAL1806Representation90|---
VPLMtyp/PLMRepresentationDS|CouronneRonde_CENTRAL1806Representation91|---
VPLMtyp/MaterialDomainDS|CENTRAL1806_Aluminium_MATERIAL_4MATERIAL|---
VPLMtyp/PLMRepresentationDS|CENTRAL1806Representation47|---
VPLMtyp/PLMRepresentationDS|Aiguilles_CENTRAL1806Representation94|---
VPLMtyp/PLMRepresentationDS|Verre Saphir_CENTRAL1806Representation96|---
VPLMtyp/PLMRepresentationDS|Corps_CENTRAL1806Representation97|---

Changing Default Java Options for the FCS Sync Server

On Windows:

Change to the installation folder: SERVER_INSTALL\OS\code\bin\.
Edit the ENOFCSSyncServer.bat file and set the java option for the mxmrun tool by setting following variable in the environment before the call to mxmrun.
In the sample below, the java heapsize is increased up to 1024MB. This is what the .bat file should look like after the modification:
```
set MXMRUN_JAVAOPTS="-Xmx1024m"
%~dp0mxmrun.exe FCSSyncServer com.dassault_systemes.fcs.syncserver.Main %*
```

On UNIX:

Change to the installation folder: SERVER_INSTALL/scripts.
Edit the ENOFCSSyncServer.sh file and set the java option for the mxmrun tool by setting following variable in the environment before the call to mxmrun.
In the sample below, the java heapsize is increased up to 1024MB. This is what the .sh file should look like after the modification:
```
export MXMRUN_JAVAOPTS="-Xmx1024m"
dirname $0`/mxmrun.sh FCSSyncServer com.dassault_systemes.fcs.syncserver.Main $*
exit $?
```

Set up the FCS Sync Server SLF4J logs

Configure a dedicated logger (name: FCS.FCSSyncDaemon) in the logback xml file.

Example with a logpath “/tmp/” and logSize “50MB”, with logback file under:

<install_path>\server\linux_a64 \docs\javacommon\fcssyncserver_logback.xml

<install_path>\server\win_b64\docs\javacommon\fcssyncserver_logback.xml --

<appender name="ROLLING-FCSSyncDaemon" class="ch.qos.logback.core.rolling.RollingFileAppender">

<file>/tmp/fcssyncd0.out</file>

<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">

<fileNamePattern>/tmp/fcssyncd%i.out</fileNamePattern>

<minIndex>1</minIndex>

<maxIndex>2</maxIndex>

</rollingPolicy>

<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">

<maxFileSize>50MB</maxFileSize>

</triggeringPolicy>

<encoder> <pattern> [%d{yyyy-MM-dd HH:mm:ss.SSS,GMT} GMT - %logger{64} -

[%thread] - %-5level]: %msg%n

</pattern>

</encoder>

</appender>

<logger name="FCS.FCSSyncDaemon" level="INFO" additivity="false">

<appender-ref ref="ROLLING-FCSSyncDaemon" />

</logger>

Add the following in the first line:

in the ENOFCSSyncServer.sh:

export MXMRUN_JAVAOPTS=-Dlogback.configurationFile=<install_path>\server\win_b64\docs\javacommon\fcssyncserver_logback.xml

Or in the ENOFCSSyncServer.bat script:

set MXMRUN_JAVAOPTS=-Dlogback.configurationFile=<install_path>\server\win_b64\docs\javacommon\fcssyncserver_logback.xml