About File Checkins

The FCS supports two types of checkin: one-part checkin is employed when the business object the file is checked into does not exist yet, and two-part checkin is used when the business object already exists. FCS allows override triggers, but only when FCS is disabled during the override trigger operation.

Checking in a set of files to the FCS involves four steps:

  1. Creating a ticket corresponding to the number of files.
  2. Using the ticket, uploading the files into the FCS, and receiving a receipt.
  3. Creating the object proxies that materialize the association between a Business Object and a file previously uploaded.
  4. Validating the check in operation using the receipt and the list of proxies.

Any Java client application that will perform FCS checkin or checkout operations, must now explicitly reference the FcsClient.jar instead of the eMatrixServletRMI.jar. The following error will occur if the Java client is not referencing the FcsClient.jar: 

<java.lang.NoClassDefFoundError: com/matrixone/client/fcs/InputStreamSource_2>

Before a checkin/checkout operation to/from a store or location, verify that the FCS server defined in the FCS_URL on that store or location is running. If not, the operation will fail. Additionally, you should verify factors that may also affect the operation, like a LAN line being down.

If several users try to check in files simultaneously, some of the checkins may fail with an FCS error. This can be avoided by increasing the thread pool size of the application server. Refer to the TomEE+ documentation for more information on adjusting thread pool size.

FCS file operations have been mostly compliant with the system-wide case sensitivity setting.

System-wide case sensitivity is set to ON by default using the following MQL command:

set system casesensitive on;

This section clarifies the expected behavior of filenames in FCS file operations when the system has been configured to be case insensitive.

Case insensitivity is applicable to the administration object name (for example, store name, location name, format name) and the file name of a file. It is irrelevant for the file content.

Filenames in FCS file operations should comply with the system-wide case sensitivity setting. That is, if the system has been configured to be case insensitive, the filenames F.TXT and f.txt are considered to be the same.

Therefore, for a given business object and a given format, either F.TXT or f.txt could be checked-in at the same time. Checking-in either of them replaces the other, and using F.TXT or f.txt as the file name in a query should produce the same result.

Since data are stored as is (the case is preserved) in case-insensitive mode, the cases are preserved in file name display and checkout.

Note: This clarification only applies to captured stores, and does not apply to designsync store, adaplets or non-hashed stores.