This document provides an overview of a migration process from an arbitrary source system to the FileNet Content Engine. It describes the setup and the solution used for building the FileNet Import Connector. The connector aims only the Content Engine (CE) component of FileNet. The Process Engine (PE) component is outside the scope of this connector. The FileNet Import Connector is capable of migrating data from a generic data model to the FileNet CE, creating different FileNet content types and adding content to them, filling in custom metadata and importing permissions. The transformation of the extracted records to allow the loading into a target system is outside the scope of this document.


In order to successfully run the FileNet connector scripts, the following requirements must be met:

  • The scripts code must be opened in Xill IDE 3.1
  • A MongoDB instance must be running locally on the standard port (
  • Access to a FileNet user environment (FileNet server) is required
  • Access to the FileNet Content Engine (CE) Java API is required; the Java API must be configured to run through the WSI (Web Services Interoperability) protocol, by using the following WSI url: http://<server-name>:9080/wsi/FNCEWS40MTOM
  • The FileNet proxy has to be accessible and running. The proxy can be accessed through the following url:http://<server-name>[:port]/filenetproxy/v1/
  • The authentication to the Content Engine requires: a username, a password and a stanza. The stanza is a JAAS (Java Authentication and Authorization Service) configuration that contains a list of login modules. Since the authentication is done over the CEWS (Content Engine Web Services) transport, FileNetP8WSI needs to be used as stanza.
  • Administrator privileges for the FileNet CE are required in order to have access to the user account information and object permissions

Before running any of the connector's extract robots, the access credentials to the FileNet CE, the proxy details and the object store must be specified in the "" file.

Unified Data Model Setup

Generally the Unified Data Model (UDM) is built based on the dataset that needs to be migrated. For FileNet, however, some configuration may be required to align the Content Engine object types with the content types used in UDM. Since different UDM content types contain not only standard metadata, but also their own custom metadata, a way should be found to create content types with custom metadata in FileNet as well. This functionality can be configured in FileNet by using the class concept. The class in FileNet is a specification for a set of objects that have the same properties. The Content Engine has some pre-defined classes: "Document", "CustomObject", "Folder", but one can also create custom subclasses. These subclasses will then inherit the properties of the parent class, but will also have their own set of custom properties. To give an example, a "Letter" with custom properties such as: originator, recipient, subject of a message can be created in FileNet as a subclass "Letter" of the "Document" class. The "Letter" subclass will inherit the "Document" properties, such as: title, but unlike the rest of the "Documents", it will also have its own properties: originator, recipient, subject of message and others. Such configurations can be done in the Administrative Console for Content Engine (http://<server-name>:9080/acce).

Custom mapping of content types can be added to the connector when the import of particular content types is required. Below there is an example of a mapping for the content type "Letter". In the mapping, the metadata of the content type "Letter" from UDM is being used to populate the metadata of the content type "Letter" from FileNet CE.

function mapLetter(document, data) {
    document += {
        "properties" : {
            "OriginatorName" : {
                "dataType" : "STRING",
                "value"    :
            "OriginatorAddress" : {
                "dataType" : "STRING",
                "value"    : data.originator.address
            "RecipientName" : {
                "dataType" : "STRING",
                "value"    :
            "RecipientAddress" : {
                "dataType" : "STRING",
                "value"    : data.recipient.address
            "MessageDate" : {
                "dataType" : "DATETIME",
                "value"    :
            "MessageSubject" : {
                "dataType" : "STRING",
                "value"    : data.message.subject
    return document;
Most of the decorators created for the FileNet Extract Connector are standard decorators. In addition to the standard decorators, a separate decorator is created for FileNet-specific objects. 
"filenet" : {
	"id" : {
		"type" : "STRING",
		"required": true
	"path" : {
		"type" : "STRING",
		"required": false
 The rest of the custom decorators are dataset-specifc and they differ per migration.


The FileNet Connector has been implemented using the Content Engine Java API. First, the REST API has been considered for building the connector, but there is no REST API provided for the Content Engine. Since the Content Engine Java API offers complete API functionality, it is easy to use and provides good supportability, it was chosen over the Content Engine Web Service (Disadvantages of using CEWS) for implementing the FileNet connector. The API has been configured to communicate with the CE server through the Web Services Interoperability (WSI) protocol.

This document does not go into details in what regards the Content Engine building design and the FileNet Java API. Other articles exist that cover these aspects. For documentation on the Content Engine Architecture, please refer to the following link: For documentation on the FileNet Java API and the FileNet concepts in general, please refer to the following link: However aspects such as: why was the FileNet Proxy built, how it works, how is a FileNet connection established and what features the FileNet import incorporates,are described further in the document.

FileNet Proxy

At the beginning the connector was built by directly employing XILL routines written in Java, based on the CE Java API. That approach failed since the CE resides within a Java Enterprise Edition Application Server and the Java API requires a LDAP context when connecting to the CE, which cannot be provided with XILL IDE. Therefore a FileNet Proxy-middleware has been developed to allow communication with the CE through the FileNet Java API. The proxy has been developed using the RESTful Web Services with Spring. There are several ways to start the proxy. The current solution is running the proxy application packaged as a JAR file from XILL IDE. When the proxy runs, one can use the FileNet Extract Connector to extract data from CE and can also get interactive documentation with the swagger-enabled API (http://localhost[:port]/swagger-ui.html). The swagger UI can be used to get the complete list of all the RESTful URIs employed when building the connector.

FileNet Connection

The connection with the FileNet as well as the rest of the API calls to the FileNet are done through the FileNet proxy. In order to establish a connection, the following FileNet connection information is needed:
  1. FileNet Credentials (username and password)
  2. Stanza (FileNetP8WSI should be used as stanza as explained in the Prerequisites section )
  3. WSI URI (see Prerequisites section)
  4. Proxy URI (see Prerequisites section)

Below there is a code snippet that shows the REST call used in the connector for FileNet authentication.  

function connect(server, proxy){
	var body = {
		"urlString" : server.apiUrl,
		"userName" : server.user,
		"password" : server.password,
		"stanza" : server.stanza

	var result = post(server, proxy.proxyUrl :: "core/session/open", body);
	return result.body.localSessionId;

  FileNet Import

Once a connection with FileNet is established, the import connector starts creating documents in the FileNet CE based on data stored in UDM. Content is also added during the import either from the local disk or from a different system. It is possible to import different content types to FileNet CE, with the mention that content type mappings have to be added to the connector separately since they usually differ per project. Furthermore, the FileNet import connector supports version and permission import. All the above-mentioned features are implemented with REST calls with RESTfull URIs generated by the FileNet proxy. An example of a post request to create a FileNet document is shown in the code snippet below:
function createDocument(server, proxy, className, path, name, parentPath, mimeType, properties, permissions, objectStoreId, localSessionId){
    var body = {
        "objectStoreId"           : objectStoreId,
        "className"               : className,
        "path"                    : path,
        "name"                    : name,
        "parentPath"              : parentPath,
        "mimeType"                : mimeType,
        "properties"              : properties,
        "permissions"             : permissions
    var result = post(server, proxy.proxyUrl :: "command/createDocument", body);

Closing remarks

The FileNet Import connector offers a good head-start for migration projects from a certain ECM system to the FileNet Content Engine. The built-in functionality covers to a large extent the expected features of a FileNet content import. Adding custom content type mappings should suffice for realizing migrations involving FileNet imports.