Configuring FCS

Although you do not need to install anything to use FCS, you will probably need to configure it.

This page discusses:

Configuring FCS for Storing Images

To save image files on a remote FCS, complete the following steps:

  1. Copy only the following required out-of-the-box property files from the MCS server [..]/server/managed/properties to the FCS server […]/STAGING/ematrix/WEB-INF/classes:
    • emxCommonHelp.properties
    • emxLogin.properties
    • emxSystem.properties
  2. Copy emxComponents.properties file from the MCS server [..] /server/STAGING/ematrix/properties to the FCS server […]/STAGING/ematrix/WEB-INF/classes.
  3. Copy only the following required out-of-the-box jar files from the MCS server [..] /server/STAGING/ematrix/WEB-INF/lib to the FCS server […]/STAGING/ematrix/WEB-INF/lib:
    • framework.jar
    • common.jar
  4. Regenerate the ear/war files and deploy the ear webapp file into TomEE+.
  5. Configure the FCS URL for the needed stores or locations. See the File Collaboration Server Guide : Defining FCS URLs.

    For details about defining stores and locations, refer to MQL Concepts for more information.

  6. Restart the TomCat instances on the MCS and FCS systems.

Configuring FCS Based on Usage

User involvement with FCS depends on the type of user:

  • For users, setup is minimal. App JSP pages are enabled for FCS. You simply define which stores/locations will have FCS URLs. All others will default to the URL of the MCS.
  • For Studio Customization Toolkit users, the FCS is normally not used. You can make the Studio Customization Toolkit use the FCS for checkin/checkout by setting the environment variable MX_FCS_ENABLED=true. When set to FALSE, FCS is not used.
  • For installations having their own JSP-based applications, see FCS with Custom JSPs.

Managing Standard FCS Logs

You can manage the FCS logs through a standard logging system and easily control log levels and appenders. With the FCS standard logging system, you can enable traces without restarting the FCS server and use circular logs.

The FCS logging infrastructure relies on SLF4J Logback which is the default logging framework. You can change the log level by editing the logback.xml file generated at installation. By default, the SLF4J Logback checks the logback.xml file every 30 seconds for changes. You do not need to restart the server when you change the log level, just update the logback.xml file and wait 30 seconds to view your changes.

The location of the logback.xml file is:

  • For the web server installation: webapps/$SERVER_URI/WEB-INF/classes/logback.xml
  • For the modelingStudio/Collaboration server installation: $OS/docs/javacommon/logback.xml

To change the levels and appenders of the FCS logger, add the following element to the logback.xml file:

<logger name="FCS" level="LOG-LEVEL">
	<appender-ref ref="APPENDER-NAME" />
<logger>

where:

APPENDER-NAME is defined in the Logback documentation http://logback.qos.ch/manual/.

LOG-LEVEL must be one of the following:

  • ALL
  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • OFF

For FCS log messages, in the context of an FCS ticket created on an MCS, with a log level at least DEBUG or activated through MQL, log message level are raised up to the INFO log level, if needed. In this case, the default Logback configuration dynamically dumps logs.

You can also use JMX to change log levels through the JConsole.

To enable JMX on the Web server, add the following option on the Java launch command line:

 -Dcom.sun.management.jmxremote.port=5522
 -Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

For more information about JMX, see the JMX documentation.

Example of Activating FCS for the DEBUG Level

This is the logback.xml file with the log level set to DEBUG:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="30 seconds">
  <jmxConfigurator />
  <property file="E:/tmp/TestCD216/server/win_b64/code/bin/enovia.ini"/>
  <define name="pid" class="com.matrixone.util.PIDPropertyDefiner"/>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>
%d{yyyy-MM-dd HH:mm:ss.SSS,GMT} GMT ${HOSTNAME} [%thread] %-5level %logger{64} - %msg%n
      </pattern>
    </encoder>
  </appender>
  <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>				${MX_TRACE_FILE_PATH}/${MX_TRACE_FILE_NAME:-platform}_${pid}_%d{yyyy-MM-dd}_%i.log
      </fileNamePattern>
      <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
        <maxFileSize>64MB</maxFileSize>
      </timeBasedFileNamingAndTriggeringPolicy>
    </rollingPolicy>
    <encoder>
      <pattern>
%d{yyyy-MM-dd HH:mm:ss.SSS,GMT} GMT ${HOSTNAME} [%thread] %-5level %logger{64} - %msg%n
      </pattern>
    </encoder>
  </appender>

  <logger name="FCS" level="DEBUG">
    <appender-ref ref="STDOUT" />
  </logger>
  <root level="INFO">
    <appender-ref ref="ROLLING" />
  </root>
</configuration>

Downloading audit logs files

You can enable and disable the audit logs file download through the logback configuration.

On the cloud only: The audit logs file download is enabled by default on all DistributedFileStore services.

Each audit logs file download event captures the following information:

  • platform name
  • user
  • client IP
  • timestamp
  • metadata object ID
  • filenames
  • file sizes

The download events are written in a dedicated FCSAudit_YYYY-MM-DD.log file under /usr/local/FCS/logs directory of the VM Store of DistributedFileStore service.

When to Define FCS URLs

You may need to define FCS URLS for each store and location you want to enable. The FCS URL points to the store or location server containing the actual files.

When to define a URL:

  • You must define the FCS URL for FCS file replication.
  • The FCS URL is NOT required for file checkin and checkout operations.
  • DesignSync stores do not require an FCS URL and one should NOT be defined for them.

When an FCS URL is not defined, the system uses the URL of the local MCS. Since there are two ways to connect to the 3DSpace Service, note that the MCS URL can be inferred only when connecting through the application server, usually at port 8080. The other way to connect is through the server, usually at port 1099, but an MCS URL cannot be inferred when connecting this way. Therefore, if you are connecting through the server and need to perform FCS operations that require an FCS URL, you must manually define the FCS URL.

For details on defining an FCS URL, see Defining FCS URLs for a Store or Location.

FCS Settings in the web.xml File

You can use the web.xml (or framework.properties) files on the MCS or FCS to configure the FCS.

For example, you can set ticket and receipt expiration and cleanup settings such as:

  • The length of time a ticket or receipt is valid.
  • How many tickets or receipts the system retains before deleting them.

You can specify settings in either web.xml or framework.properties; however, we recommend that you add all settings to web.xml. If a property is set in both framework.properties and web.xml, the value in web.xml is used.

See the 3DSpace - Web Application Installation - Deployment Guide : FCS Parameters under Modifying J2EE Settings.

Image Caching

The FCS includes support for image caching from the database that is used by the ENOVIA products. Images are modeled as connected Image type objects that provide file storage in the database. It handles images as URLs, and images are generally provided via an FCS.

Images from the database persist for the duration of a browser session, although if new files are checked in during the session, the new images are fetched and appear as needed.

You can configure settings for FCS image caching in the web.xml file. See Installation and Setup - Install - 3DEXPERIENCE Platform - Installing 3DEXPERIENCE Platform Services for the First Time - Installing Services One-by-One - Web Apps Installation - Deploying Web Apps - Modifying J2EE Settings - web.xml Parameters - FCS Parameters.

Using FCS in a Single Sign On Environment

To use an FCS in a Single Sign On (SSO) environment, you must add each MCS and FCS in your environment to the access list that excludes them from authentication checks. Note that you cannot use a remote thick client with SSO. A local thick client can be used with SSO since it will be on an MCS that should be on the access list.

See Installation and Setup - Install - 3DEXPERIENCE Platform - Installing 3DEXPERIENCE Platform Services for the First Time - Installing Services One-by-One - Web Apps Installation - Deploying Web Apps - Modifying J2EE Settings - web.xml Parameters - FCS Parameters for more information.

Accessing Files on a Local Server

The File Collaboration Server works with the MX_SITE_PREFERENCE environment setting in the server's initialization file. This allows FCS to access files on a server that is local to the user, but not necessarily local to the Web site from which the user accesses the database. See The Preferred Site. .

Multiple FCS Server Configurations

You can set up configurations with multiple FCS servers enabled in different locations servicing the same clients. This configuration requires replication. See Replication.

Running Different Versions of the MCS and FCS

If you receive an error message that begins with "MLC Warning," it means you are running different versions of the MCS and FCS at the same time.

Store and Location definition recommendation

Note the following:

  • Performance optimization: the host parameter of captured file stores/locations must be set to localhost in order to prevent certain performance issues when remote FCS are used.

    For stores:

    mod store store_name host localhost;

    For locations:

    mod location location_name host localhost;
  • Deployment: we recommend that you isolate the files between stores/locations. Do not share the same path between stores/locations.