Staging, Import, Export
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.
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.
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.
Servlet Parameters to use in the production (destination) server:
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:
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:
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:
Tomcat, however, requires:
Next: Recent Users