Staging, Import, Export

Overview

It is common to have a staging server where everything is tested before being installed on a production system. ViewsFlash Staging allows survey creation and testing on a staging system and controlled promotion of proven surveys to the production system. The staging system can also be used to promote surveys from a development system to a staging system.

When staging is enabled, the Publish page allows an administrator to lock and unlock a survey (preventing any change to the survey while locked), and to stage the survey and the styles and invite lists it uses which have changed at the same time. If using User Security, these capabilities are available to users who have Staging access right in that place. See Publish. Administrators also have a Staging page that allows them to manually stage all components.

How it works

When a survey, style or invite list is staged, one or more files are written to the export directory in the staging server's file system (data/export by default). From this directory, a system administrator or a content management system moves them to the destination server's import directory (data/import by default). Moving is preferable to copying, to avoid the possibility of staging something twice. The entire contents of the /export directory should be moved all at once. When the destination ViewsFlash detects these files, it uses them to update its configuration. The ViewsFlash administrator and the place e-mail recipient are notified by email whenever components are written to the export directory.

If a survey, place, style or invite list is removed in the staging server, an entry appears in the Staging page with Status set to "Removed", which allows the Administrator to remove those components on the destination system.

Staging requires that the staging and production servers use a database.

Staging from one server to a clustered server

The destination servers can either share a single import directory, or each server can have its own. If each server has its own, the staging procedure should move the files to be staged from the export directory to every server's import directory; however, everything works if only one of the clustered server's import directories receives the staging files (it is best to put it on all of them for redundancy).

Staging from clustered staging servers to clustered production servers

The staging procedure must move the files from each staging server's export directory to a corresponding import directory on the production server. When something is staged, the staged files will appear in only one of the server's export directories, so the staging procedure must be alert to both. The staging procedure can also move the files to every production server's import directory for redundancy.

Synchronization

In all the above configurations, the software synchronizes among different servers in the cluster using a database table named VWFSTAGING. In the staging server, this ensures that a component is only staged once, and components already staged are not staged again unnecessarily. On the destination server, this table ensures that components are not imported more than once. When a component is imported into one of the servers in a cluster, it notifies the other servers that the component has been modified, and the other servers upgrade to the latest version automatically.

Import and Export

Staging and Importing can be used to transfer surveys, styles and invite lists between different servers. Just export the survey, transfer the files from the export directory to the destination server's import directory, and import them. The two installations can even use different databases.

Configuration

Staging is configured using servlet parameters. If these parameters are omitted, only ViewsFlash administrators can export and import.

Servlet Parameters to use in the staging (originating) server.

• exportby controls who can export. Its value is either none, admin, or user, as follows:
  exportby=admin (the default) allows staging only by ViewsFlash administrators
  exportby=none disables exporting
  exportby=user allows staging by ViewsFlash administrators and users with appropriate rights. If using User Security, only users who have the Staging access right can stage surveys.
• exportusersecurity=yes allows staging User Access Rights to the destination server. Without this parameter, User Access Rights are administered separately on the staging and the destination server.
• exportdir=full path to an existing directory. If omitted defaults to data/export.

Servlet Parameters to use in the production (destination) server:

• importby controls who can import. Its value is either none,admin, background, or a number, as follows:
  importby=admin (the default) allows the ViewsFlash Administrator to manually import from the Staging menu
  importby=none disables importing
  importby=background imports automatically every 5 minutes and allows manual import by the Administrator
  importby=NNNN imports automatically every NNNN seconds and allows manual import by the Administrator
• importdir=full path to an existing directory. If omitted defaults to data/import.

Staging without using the file system

There are situations where it is preferable to write and read the staging files from a database. To us this method, add the servlet parameter to both the source and the destination ViewsFlash instances:
stagingextension=DatabaseStaging

With this parameter, staging will read and write records to the database instead of the file system. But, of course, since the two databases are different, this is not sufficient.
An additional parameter is needed to tell the two instances to look for the records in the database of the other instance, not its own. Use the following parameters:

datasource.export=JNDIDataSourceName
or
datasource.import=JNDIDataSourceName

The first of these tells ViewsFlash to write staging records on a different database, specified in a different JNDI data source.
The second, conversetly, tells ViewsFlash to read staging records from a different database, specified in a different JNDI data source.

Note that all references to staging tables, on all data sources, are always prefixed by the dbtablenameprefix servlet parameter, if used.

Note that the exact syntax of the datasource parameter depends on the application server being used.
For most application servers, it is just the name of the JNDI data source:
datasource=NameOfTheJNDIDataSource
Tomcat, however, requires:
datasource=java:comp/env/NameOfTheJNDIDataSource

Next: Recent Users