docXtend is a ‘no-code’ solution for simple and automated content integration from an arbitrary enterprise application and an Enterprise Content Manager (ECM) platform. The first release is supporting Alfresco, BOX (and other CMIS-compatible platforms; check our support matrix). The only requirement is that your application stores the to-be-integrated content inside a relational database as Oracle or SQL Server.

The main product value is that you don’t have to modify your application to do that. docXtend automatically creates a data virtualization layer in database based on your application data model, enabling tight integration with the content manager. Without ANY application re-engineering your content will be moved to your ECM platform, saving space in the application database and avoiding the inconsistencies found with data replication tools. But the key benefit is that your application will start reading the content from the content manager, so your legacy application functionality will not be altered in any way. However, the moved content can be flexibly and dynamically enriched with metadata, so that you can control where the content is saved, the name to be used, assigned to an out-of-the-box or custom document type and properties.

Using docXtend your content will be ‘unlocked’ from your (potentially legacy) application, opening up a myriad of additional documental processes and workflows to be created with your ECM platform without changing a single line of code.

Integrating your business applications with your content manager has never been easier. You have to run the installer, identify the database schema of your application, select the tables/attributes with binary (BLOB) content that are suitable of moving to your content manager, optionally defining the metadata mapping rules and it is all set. docXtend will automatically create a new schema (database in the case of SQL Server) for your application (it is just a thin virtualization layer, your data will remain at the original schema/database). You only have to reconfigure your application for using that schema/database (typically this will comprise changing the database connection settings in an application configuration file). Magically, your application is integrated. Any new content, inserted or updated through your application will be tracked and moved to the content manager (the job is running every minute), enriched with the metadata configured during setup and safely stored in your ECM platform. When your application tries to read it with a SQL query, our data virtualization engine will automatically fetch it from the content manager repository and inject it into the query results; your application will work as before, with the same functionality, interface, data, … however, a new range of possible documental processes are enabled through the ECM platform; your content is not captive anymore!

For more information on how to install the solution check our “Installation” post. For more advanced setup scenarios, register and check our Install guide.

Curious? Just download the FREE version!

The value of integrating with a your ECM platform is not just moving content as unnamed files. This option is available of course but the real value of docXtend is the capability of metadata enrichment while the content is moved. We can of course define the rules for folder definition and document name (typically using attributes in your application data model for dynamic generation), but also assign a custom document type (including one or more ‘aspects’ in Alfresco terminology) with its specific properties.

Let’s imagine we are integrating a payroll solution that is storing the payroll pdf documents in its custom database. We can not only move those pdf’s to our content manager listing as a ‘pdf document’, but we can move those documents assigning the ‘payroll’ document type with the specific ‘payroll’ properties (as employee id, year/month, department id, category, ….). This will enable a much richer integration and additional capabilities when triggering new document processing capabilities (as creating a new ’employee portal’ using your ECM platform capabilities).

Our architecture is neat and simple. All the complexity is hidden under the covers. We use a docXtend agent (installed as a service in a Windows or Linux host or directly packaged in a virtual appliance) to act as a bridge between your application’s database and the ECM platform. A ‘docxtend’ user and schema in your database created during setup will store the configuration settings. The installer will automatically create your application’s specific data virtualization layer to hold the links of the content moved to the content manager and keep it ‘SQL client compatible’ (so the existing queries, insert, update and deletes your application was issuing before installation, keep working when being issued trough the data virtualization layer). And that’s all! Reconfiguring your application to connect to the new schema will activate the integration and start moving any inserted/updated content to the content manager. For moving the already existing content you can use de command line interface (CLI) that is installed during setup (“docxtend move” command)

 

Installing docXtend cannot be simpler. We do all the heavy lifting for you behind the scenes, with a wizard based setup. The installer will deploy the software, configure it, connect to your database and content manager, analyze your data model, identify those tables with binary content, present them for your selection and definition of metadata mappings (you can skip them all and use the defaults) and create the data virtualization layer in order to enable the no-code integration with your Enterprise Content Manager platform. Just reconfigure your application through the created schema (will be named as your original application schema with the suffix “_DXTND_“) an is all set.

Let’s go with the details… (additional configuration information is described in the setup tool itself; read carefully while installing).

Requirements

First thing first. What will you need for a successful implementation:

• An existing app storing content in a database: This is the application you would like to integrate with the content manager. It must store the ‘to-be-integrated’ content in a database, either Oracle or SQL Server in binary table attributes (BLOB attributes in Oracle terminology; image or varbinary(max) in SQL Server’s).
• An Alfresco or CMIS based content manager: You must have an Alfresco or CMIS compliant content manager. If still not provisioned and you are familiar with docker/docker-compose, it is very simple to bring up an environment in minutes based on the Alfresco community version.
• A Linux or Windows server with java: You will need a server where the docXtend where run the setup and the agent will be installed. It is required a recent release of one of the supported x64 java versions (java 8 or 11). Check our supported configurations for details.

From the connectivity perspective, it is required:

• Outbound Internet connections through https to two well known addresses: https://app.docxtend.tecknolab.com and https://admin.docxtend.tecknolab.com.
• DB client connections from the agent host with the database server (by default, TCP 1521 in Oracle, TCP 1433 in SQL Server; this may be different depending on your DB setup).
• TCP connectivity from the database host(s) and the agent host (TCP 8099 by default, but this can be configured during setup).
• HTTP(s) connectivity from the agent host and the content manager.

With those pre-requisites fulfilled, you will have a successful implementation in minutes.

Installation modules

docXtend setup installer is comprised of four modules, designed to be potentially executed several times, depending on your requirements and deployment strategy.

• Database server preparation: Once per Database environment. Required as initial setup to have a functional environment.
• Database schema preparation: Typically once per Database schema (one application typically uses one database schema). Required for at least one schema (the schema where our application stores the data)
• docXtend Agent installation: One per host where the agent will be installed (depending on your setup strategy described above). Required in at least one host. It may be the same database host.
• docXtend CLI installation: Command line interface (CLI) installation. Once per host or workstation where we need to execute the CLI.

When executing the installer, we can select or deselect those modules, so the installation comprises those parts required. In an initial test setup, we will typically select and install all the modules in a host.

Depending on the selected modules, the installation wizard will present the different information gathering panels and checks, in order to generate a correct installation.

If you are planning to install the agent in several hosts (either at the database hosts or independent hosts) it is important to activate the check of ‘Clustered agent installation’ (in Agent data panel if Database Server preparation module is selected) . This will ensure that all the agent instances in the cluster share and get notified any configuration change. If you already have a non-clustered installation and need to upgrade to a clustered setup, please go to your My-account section in our website and file a support request for configuration instructions through the CLI.

Information to be provided

As a summary, the information you need to collect in order to successfully deploy the solution is:

• docXtend service license: You have to provide your service id and license. This information is generated once you order the docXtend license and will be sent to you by email. Access here to request a FREE one; if already registered and ordered, here to get the order status and licensing information (it may take a few hours from requested to provisioned).
• Database dba credentials: Some setup processes (e.g. defining security configuration to allow the connection from the database with our docXtend agent installed) requires dba privileges (sysadmin in SQL Server). This is ONLY required during setup. We will not store nor use those credentials during the solution operation; docXtend will use a low-privileged database user to create a configuration schema and store configuration settings; this user is automatically created during setup with the password defined by you.
• Schema credentials: In order to automatically create the data virtualization layer for your application data model during setup, we require the database credentials for the user that is the application tables’ owner. The setup will automatically inspect the data model and identify those tables that has binary fields (BLOB attributes). Based on that list of candidate tables and attributes, you will have the option to define the metadata mappings that will govern your cotent manager integration. You will only be able to archive data from the table/attribute you select at this stage. However, it is supported to re-run the installer again, select the module “Database schema preparation” and select additional tables/atributtes from the same or different schema if you change your opinion and decide to move data from additional tables. The FREE version will only allow integration from a single attribute in a single table.
• Content Manager credentials: Provide the connection and credentials to your content manager. There is a specific choice for Alfresco with a predefined format for the connection URL (where you will typically only change the host and port); for any other CMIS compatible content manager, select the CMIS dropdown menu to set the connection URL and user credentials. For using BOX as content manager, select the specific choice from the dropdown menu and use a JSON connection file for the connection settings (the JSON connection file should be generated using the BOX developer console, authorizing a new application using JWT authentication. Check https://developer.box.com/guides/authentication/jwt/jwt-setup/ for additional details).
• Agent DNS name or IP: This where you define how the database will reach the docXtend agent installed during setup. So, it will be the name or IP of the host where you are installing the solution or preferably, a custom entry in your DNS directory pointing to the server. Make sure this name is resolvable from the database server wherever it is located (so for example a “ping <agent-host-name>” from the database server will correctly resolve the agent IP address). If this setting need to be updated, run the setup again in “update mode”.
• Metadata mappings: This is the key part of the setup where we define how the data will be placed and structured in the content manager (which subfolder, what name, description, custom properties’ values, document type,…). It is not mandatory to set any of this values but defining them for every candidate table attribute that will be integrated will enrich your data management capabilities at the content manager. It may be easy to fail when defining the right names and folder structure for your content. During setup, the tool will simulate a few values for the existing content, so you can check if the generated values are the expected or not and fix the mappings. However, if we want to update the mappings once we have already moved some content to the content manager, it is recommendable to restore the content back to the database (with the CLI “docxtend rollback” command) and update the mappings (running the setup tool in update mode). For this reason, we advise to start using a non-production environment where we can test several times the mappings configuration. Check our metadata mappings post for additional details.

It is important to notice that the setup tool will NOT move any data to your content manager. The setup is only adapting the environment to enable this operation. For effectively moving data to the content manager you need to reconfigure your application and point it to the created virtualization layer (a new schema automatically created during setup with the same name and suffix “_DXTND_”); content will be moved as it is inserted or updated (with jobs executed every minute). For the existing backlog, use the CLI command “docxtend move”.

Windows installation

We provide a graphical user interface for the windows installer. Just double-click on the docxtend-setup.jar and follow the installation instructions. The setup will request Administration rights in order to properly create the installation directory and install the agent service (a “docXtend Agent” service is installed in the server when selecting the “Agent installation” module).

In the case you need to use a command line based installer (e.g. installing through a console interface) follow the following procedure:

• • Open a Command Line console with Administration rights.
  • Execute the installer through the command “java -jar docxtend-setup.jar -console”

Important note for windows users:

When downloading the docxtend-setup.jar file through a desktop or server with Microsoft Antimalware executable installed and active, the server may take a very long time analyzing the file and preventing its execution (the setup is a large java jar file packed as windows executable and Microsoft Antimalware is extremely inefficient analyzing these type of files). We recommend to close the browser used for downloading the file as a way to cancel the analysis. In the case of any issue downloading or installing our software, please, open a support ticket through the My account area and we will promptly provide an alternate download mechanism.

Linux installation

The Linux based installation is very similar to the Windows installation (the graphical interface is exactly the same) with the following caveats:

• You can use a command line or graphical interface for setting up docXend. As expected, the graphical interface is more intuitive but both provides the exact same results. Use the option -console for a console based interface.
• From a security perspective, we recommend to use a non-root user for installing docXtend. The docxtend-agent service will run using the user that executes the setup, so it is convenient to use a non-privileged user. However, during setup this user will require sudoable rights (with no password). Those rights can be temporarily granted during setup only (see the detailed instructions below).
• The setup tool will not have the required privileges to automatically create the install directory (by default /usr/local/docxtend). Create it in advance and assign it to the ‘docxtend’ user.

Recommended instructions:

• Create a linux OS user (e.g.):

sudo useradd docxtend

• Create a install dir (by default /usr/local/docxtend) and assign it to docxtend user

sudo mkdir /usr/local/docxtend
sudo chown docxtend /usr/local/docxtend

• Check that you have installed java 64bit version. Otherwise install it from Oracle website

java -version

• In order to run the installer graphical interface, you may need to enable xhost in your current session. Otherwise, the console based version will be used instead. E.g.:

xhost +

• Run a shell with docxtend user

sudo su – docxtend

• In order to run the graphical interface instead of the command one, you may need to set the DISPLAY variable to your local session (providing you are running a graphical linux interface):

export DISPLAY=:0.0

• Make it (temporarily) sudoable without password (procedure may vary depending on the linux distro and security settings). E.g.:

sudo /usr/sbin/usermod -aG wheel docxtend

• Execute the installer

java –jar docxtend-setup.jar

• Follow the setup instructions.

 

Checking the installation

Providing that the installation is successful (otherwise, please go to my-account and file a support request), we should check that the solution is working correctly.

The typical and most frequent source of problems is the connectivity from the database with the agent, the agent with the content manager. So we have to make sure that those connections are possible and there are no problems (routing / firewalling) preventing them.

The simplest to check that everything is OK is using the CLI command “docxtend info -test” (executing from the install directory). In the default setup, it will request our schema credentials (the DB credentials for our application schema, that we already provided during setup), provide a general set of setup information (agent host, product version, managed tables, …) and perform a basic connectivity check ensuring that everything is OK. If not, check that the agent is started and any potential error message (very frequently the problem is that we configured a wrong address name for the agent host, so when the database is trying to locate the docXtend agent, the request fails). If you cannot find the problem, file a support request.

Uninstalling

We love that our customers use our technology but if they don’t want it, we ensure they have an easy way to restore their original setup, both in the docXtend host and in the database. Upon install we put an uninstaller in the <INSTALL_DIR>/uninstall folder. Just double click or execute “java –jar docxtend-uninstall-setup.jar” and follow the uninstaller instructions for restoring everything . After full uninstall you should only have the <INSTALL_DIR>/uninstall folder with the uninstaller jar. Just delete them manually.

For uninstalling is required to restore back in the database any content moved to the content manager; otherwise, the uninstall will generate and error message and abort. For restoring the content, just use the “docxtend rollback” CLI command.

If you have executed the setup several times (e.g. for installing agent instances in several hosts or for adapting several database schemas) you should run the uninstaller also several times, in the reverse order. (e.g. first uninstall the agent in all the additional hosts where you installed it and finally, uninstall the other modules; the “Database Server Preparation” should be in the last execution).

After successful installation, the next steps that you can take are:

• Activate the integration

The integration will not be active until you effectively conmute your application database connection to the new data virtualization layer created during setup (the setup tool will give you the exact name of the new schema, typically the original one plus a “_DXTND_” suffix). No data will be moved to the content manager until this operation is done and some activity (inserts or updates in the managed table / attribute) is performed. You can check with the CLI command “docxtend info” if there is any enqueued content (pending to be moved to the content manager) and any error message in the case that the operation is failed.

• Check your statistics (activity dashboard)

An operational dashboard is automatically generated in your customer My-account section. Just check the information to validate that everything is OK and the transferred content statistics are the expected.

• Move old data

Old data (content already stored in the application database before docXtend setup) is not automatically moved (this may require, depending on the volume, specific windows or data segmentation to avoid high database/content manager loads). Use the “docxtend move <table> <attribute>” command for executing this operations (-help option will provide detailed information for the available options). The -where option is useful for providing a SQL filter expression in order to segment/select the candidate rows to be moved.

• Rollback (restore data back to the database)

The “docxtend rollback” command is the opposite to “docxtend move”. With rollback, we can move data back to our database, either because we want to update the mappings or because we want to uninstall the solution (we require a full restore of the information before executing a uninstall in order to avoid any data loss).

We have described the main topics regarding docXtend installation and configuration. In the case of doubts or problems, please don’t hesitate to fill a support request through you My-account section.

That’s all folks; go ahead and request your FREE license!

docXtend is designed as a ‘no-code’ solution. It means that your business application is integrated with your Enterprise Content Manager (ECM) platform with no need of a customization, API integration or application re-engineering.

The solution is based on Tecknolab‘s innovative technology of DB data layer virtualization. This technology is able to automatically inspect your application data model and create an ad-hoc virtualization schema in your applications’ database (it is an independent schema; your application data model is not altered in any way). This virtualization schema has the capability of solving syntactically and semantically the same SQL “CRUD” operations (select, insert, update and delete) as the original one (data is not copied from the original data model it is just a thin data virtualization layer). This enable us to reconfigure the application and connect it to the database through the automatically created schema; the application will issue the same queries and SQL operations as before, receiving the same results, so it should work exactly as before.

However, the new virtualization layer adds some capabilities that we did not have before. In this case, the solution can move content stored at the database to an external repository, in this case a content manager, without impact. The virtualization layer is able to intelligently merge the SQL select operations and inject the externalized content when requested by the application. From an application perspective, the interface is the same; it remains issuing SQL queries through the database. The results are the same either, the content is retrieved as if it were at the database. So, from a existing (potentially legacy) application and from an application’s user perspective there is no changes. However, our selected content (typically documents, images, the type of content that bloats a database, increasing its size and maintenance costs) is now at our content manager. This is not only operationally optimal but opens a wide range of additional scenarios and documental processes that can be easily triggered when using a powerful ECM solution.

In summary, we can achieve a complete and tight integration from any arbitrary business application with an ECM platform without writing a single line of code.

Your data is securely stored in your database and we want to ensure that it keeps secure when integrating with your content manager. We have designed our solution to meet stringent security criteria and ensure only authorized entities can access the data. In addition, we have defined a very strict process in the information life cycle in order to ensure data integrity.

From a security standpoint our design criteria is tight integration with the database security model. This ensures a predictable security schema where the security principles of your application are not broken by the fact that a new content repository is added to the equation.

Data access

Going through the details:

• Database schemas: we only create one additional schema and user (docxtend) where only configuration information and a shared secret mechanism is stored. The only external entity that is required to connect to the database with this user is the docXtend agent. The user credentials are explicitly defined at setup (so you can ensure they follow your organization specific security policies) and stored encrypted. In any case, this user has minimal grants and, very important, has no access to any actual application data schema.
• Shared secret and key pair: the docXtend agent requires authentication credentials for any BLOB read operations. Those shared secrets are securely generated and stored at the database so, only the docXtend agent and the database schema owner has access to read it. This connection (database to docXtend agent) can be configured to use https protocol so the content connections are encrypted. In addition, some operations are secured with a public/private key pair created and stored at the database during setup.
• CLI operations: All the CLI operations (move, rollback …) that move actual data to the content manager, requires database schema credentials (the credentials of the database user the data belongs to). This way, we ensure only a user with those credentials can execute those operations. Those credentials can optionally be stored for convenience in a user profile specific file in the server where we run the CLI (this way you do not have to specify the credentials in every command); in that case, they are stored encrypted. By default, keys are not stored and are requested for any CLI operation.
• Content manager credentials: docXtend stores content at the content manager with specific user credentials (that can be customized in a per table basis). This way, any content moved to the content manager can be secured and access policies defined at the ECM platform level for ensuring the correct visibility.

Data integrity

Our solution design is ensuring we don’t break DB transactional consistency in common application operations. We ensure transactional consistency at database level both in normal CRUD operations (insert, read, update, delete) and through move/rollback processes (“move” is the operation of transferring content from the database to the content manager; “rollback”, in this specific context is the reverse operation, it has nothing to do with the database transactions).

SQL inserts or updates issued by your application will leverage the same transactional boundaries as before and committed by the database. Only after that, the operation is logged for content transfer and a recurring job will be activated (every minute) for moving that content to the document manager. Again, opening an isolated transaction; so if any problem arises with that operation, it is rolled back and retried later on. In fact, when moving the content to the content manager the operation is only confirmed after trying to retrieve it through the database successfully and checking that the content retrieved is the same. Updated content, depending on your license, configuration and ECM platform capabilities will be versioned (however, your application will allways retrieve the latest version).

SQL delete sentences issued by your application on tables with archived BLOBs will be logged. In the case of a transaction rollback, the content is unaltered and the application can keep reading it as ever. If the transaction is committed the object is inaccessible by the application (as it would do if docXtend were not installed) and the operation is reproduced at the content manager with a configurable delay (depends on your license; free version will use only a “no delay” configuration). If your ECM platform uses a ‘trash can’ the deleted content will be moved to it.

Integration with a content manager has a much greater value if it enables content enrichment with metadata. If we have a payroll app, we can integrate with a content manager to store the payroll pdf of each employee just as a plain document, but it is much more interesting from a documental perspective to store it as a ‘payroll’ document type (instead of a plain ‘generic’ document) with custom properties as employee Id, department id, month/year of the payroll, …. This would enable much more powerful capabilities an automations in the ECM platform side (we can launch custom workflows with much more information on the content it is handling).

docXtend has a large range of capabilities and sophisticated mapping rules for decorating the transferred content with meaningful, dynamic metadata, based on the application database content. The setup tool provides a metadata mapping screen where we can define basic and advanced mappings. The mappings are configured for each table/attribute holding content that we will move to the content manager (in the case we select several attributes in the same or different tables, we can define independent mapping rules for each of them). Let’s see in detail.

Common concepts

A mapping rule is a valid SQL expression. This is done by design and opens a powerful way to define dynamic mapping rules for your content. So, any configured rule in the metadata mapping configuration screen must be syntactically a correct SQL expression and semantically acceptable in your application data model. For example, if we want to place on the content in a single subfolder called “myapp content” we have to configure this mapping rule with a SQL constant expression (that is, surrounded with single quotes). So, in our example, we have to configure ‘myapp content’ . However, if the folder name should be the value stored in the attribute “description” in the table “app_content” of our app data model, we have to configure app_content.description (without quotes). If we are using Oracle and want to make sure that all the folders are created uppercase, we would use the expression UPPER(app_content.description) .

The mappings must conform with the document model defined at your ECM platform. This must be designed and configured in advance in your ECM platform (the procedure varies depending on the platform; check your documentation). That is, if we decide to assign to our content a document type of “mycompany:payroll”, this document type must exist in your ECM platform and you have to create mappings for all the mandatory properties defined in such document type. Otherwise, the validation tests will fail and a error message will be generated in the docXtend setup tool.

Basic mappings

We consider basic mappings as those that define the core behavior for the transferred content:

• MIME type: Is the content type for the transferred content (e.g. application/pdf, image/png, …). Enterprise grade platforms as Alfresco are able to detect it automatically so leaving it blank should be a safe option.
• Document type: Is the document type (conforming our document model in the content manager, as described above) to be assigned. If we leave it blank the default, generic document type in your content manager will be used.
• Folder: It is the subfolder to be created for placing the content from the root folder defined in the content manager credentials configuration screen. Notice that this is a dynamic expression so we can create a variable list of folders, not necessarily all the content will be placed in the same subfolder. Following our payroll example, if we have an attribute in our database defining the year and month of the payroll we can define an expression year||’/’||month that would create a hierarchy of subfolders with the year – month hierarchy of our payrolls.
• File name: The name of the document in the content manager. Any content stored in a BLOB attribute in a database has no identifiable ‘name’, so we should provide a mapping for naming this content with a reasonable meaningful value.

It is not mandatory to define any mapping rule. In the case we leave the full mapping configuration screen blank, the behavior is:

• MIME type automatically guessed.
• Document type as the default document type in your content manager.
• No subfolders; all the content will be placed in the root folder configured in the content manager connection screen.
• Random generated file names.

Once our mappings are configured, the setup tool will execute a series of validations through your database and your content manager to ensure that your rules are:

• Syntactically correct from a SQL perspective.
• Conforms the document model in your content manager.

If everything is OK, the tool will simulate the mappings for a few rows in your data model and generate a screen where you can check that the folder structure and document name are the expected, before moving on.

Advanced mappings

In addition to the basic mappings we can configure custom properties that conforms with our document model. If our payroll document type in the content manager has an attribute emp_id we can define a custom mapping for that attribute. This is valid also for subtypes (in Alfresco terminology, aspects). The way to assign a aspect to a content is assigning a custom property of that aspect through a custom mapping. The advanced mappings should conform to the same rules and syntactical/semmantical requirements described for basic mappings.

Join expression

Depending on the complexity of our mapping, we may need to define the JOIN expression that will link our data model tables to generate the metadata mappings query that docXtend uses when moving content. As stated above, we are defining the mapping rules for an specific table/attribute in our data model (this is shown at the top of the screen). If our mapping expressions uses attributes from other tables, we need to define a join expression to precisely guide how to link them together. So if we want to add to our payroll document properties the emp_name attribute value from the table employees and the table payroll and employees are ‘linked’ by the attribute emp_id, we need to add the join expression employees ON employees.emp_id = payroll.emp_id (notice that you must NOT include the beginning JOIN word). This way we can use the SQL expression employees.name in the mapping rules for our table payroll.

For complex data models and mapping rules it is recommendable to test a query and join clause directly through our SQL query tool and validate it generates the expected results before configuring it in the docXtend setup tool.

Updating mappgins

We should carefully plan and configure our mapping rules. We can update them anytime it is needed but those changes will not be automatically applied to the content already moved to the content manager (it will require an update on the content at the database level). Based on that, we recommend:

• Using a non-production environment for testing our mappings.
• Install docXtend, configure your mappings, insert some content with your application, check that it generates the expected structure and metadata.
• If it requires adjustments, rollback the content, update the mappings and move it again, using the command line interface (commands “docxtend rollback” and “docxtend move” respectively)
• Once finished, apply the same settings in your production environment.

For updating mappings, just open the same setup tool and select the option Upgrade/update software and DB configuration (it is the same option for upgrading the software with a new release).

When requested, select the check “enter schema credentials and update metadata mappings” as shown below.

ç

After that, you can select your specific table / attribute and will use the same mappings configuration screen shown above.