Dctm VFS Provider Configuration

Using the DctmFileSystemConfigBuilder, which manipulates the FileSystemOptions, is the standard VFS way to do the configuration. However, not all clients support these; in these cases you should use the configuration script.

DctmFileSystemConfigBuilder

These are the configuration settings:

  • setDctmClient: this sets the underlying implementation (default is Dql based)

Configuration script

The default configuration script 'dctmvfs-default-init.bsh' initializes the library. To change this default configuration you should create a file called 'dctmvfs-custom-init.bsh' in your classpath. When it is found, it will be executed right after the default configuration script. You can also configure the name of the configuration script that should be used using a system property. This allows to use the same distribution with different setups. The system property is called 'org.dctmvfs.vfs.provider.dctm.client.customscript'. Setting it should be done with a -D commandline option, e.g.:

  java -Dorg.dctmvfs.vfs.provider.dctm.client.customscript=my_custom_script.bsh ...

Configuration

Currently there are two types of implementation for the client:

  • DQL based, this is the preferred implementation
  • Delegating, which piggybacks another VFS for testing without Documentum

DQL based

This is the default client.

  DctmFileSystemConfigBuilder builder = DctmFileSystemConfigBuilder.getInstance();
  builder.setDctmClient(opts, new DqlDctmClientImpl());

Delegating

The Delegating client uses another VFS to provide the content. You have to configure which VFS this is.

The Dctm VFS Provider uses absolute paths internally; to project your Documentum filesystem on another filesystem, the other filesystem must support absolute paths too.

There are basically three kinds of filesystems: virtual, layered and normal. The root path and the type of filesystem are closely related; to illustrate this you will find some examples below.

  DctmClient dctmClient = new DelegatingDctmClientFactoryImpl();
  dctmClient.setVfsRootPath("file://d:/temp/dctmvfs-${docbase}-${user}");
  dctmClient.setVfsType("virtual");
  
  DctmFileSystemConfigBuilder builder = DctmFileSystemConfigBuilder.getInstance();
  builder.setDctmClient(opts, dctmClient);

While configuring this other FileSystem you can use placeholders for the user ($user), password ($password) and docbase ($docbase).

  file://d:/temp/dctmvfs-${docbase}-${user}

with docbase 'testdb' and user 'testuser' will give

  file://d:/temp/dctmvfs-testdb-testuser

Virtual

The example above is a typical example of a Virtual filesystem. The given path, which points to a local filesystem provider, is the starting point of your filesystem.

Layered

If you would like to use a zip file then you could use the following path

  file://d:/temp/dctmvfs-${docbase}-${user}.zip

However, this is a layered file system. The zip provider works on top of the local filesystem provider.

Normal

Retaking the example of the zip file, there is another way to get the same result.

Instead of layering you could also use the zip provider directly.

  zip://d:/temp/dctmvfs-${docbase}-${user}.zip

This VFS is neither Virtual nor Layered, but a true filesystem in itself.

Configuration of Export, Creation and Update of content

The export, creation and update operations are handled by specific objects to easily change or extend the specific behaviour.

Export

For the export operation there are currently three alternatives.

  • The first one is file based (the default).
  • The second one is based on an internal byte-array. It is faster than the file based option, but if you have lots of big files it will consume a lot of memory.
  • The third one is based on Documentum's export operation. It is the most standard way, but is slower.

Update

For updating content the user must have write or version permissions (depending on the chosen strategy). If the file is checked out by another user, the update will also fail. If the file is checked out by the user, it will stay checked out after the update. For the update there are two alternatives.

  • The first option is based on overwriting the file content (the default). It does not allow versioning but is fast.
  • The second option is based on Documentums checkout and checkin operations. It allows versioning but is slower.

Creation

The creation of content is not easily standardized, since it requires selecting the correct type and format of the new content. If you want to use this you will need to do a small customization. Even so there are two different options you can base your customization upon.

  • The first creates the content by creating a new object and then setting the file content (the default).
  • The second uses Documentums import operation.