Overview

User Acceptance Testing (UAT) is a type of testing performed by end-users or clients to verify that a software system or its changes are working as expected, before applying any new changes to Production environments. This is performed on purpose-built UAT Instances, which are a copy of Production instances, in terms of data and documents.

The illustration below shows the typical flow of features/changes from Development to Production.

A Data Refresh involves copying data and documents from Production Instances to UAT instances. These are point-in-time copies and are intended to give the UAT Instances a snapshot of the latest data. So, testing can be performed on a data set that is a reflection of production data.

Jive supports refreshing data from a Production Hosted instance to a UAT Hosted instance or a Production Cloud instance to a UAT Cloud instance. It does not support refreshing between Hosted and Cloud instances. 

Data Refresh is executed by L2 Support Agents, using the Jive Cloud Admin (JCA) Console. During the refresh process, the target UAT instance will remain unavailable for user login. 

The following categories of data and settings are copied across:

• Application Database (with some exceptions).
• Plugins
• Analytics Database
• EAE Database
• Binary Storage Data.

Remember, this is a point-in-time copy of data and documents. Any changes made to Production data after the Refresh will not reflect in UAT. You may see a difference in things like View Count Analytics, Document Comments, Etc.

<supportagent>

See the Data Refresh Process and the Data Refresh Troubleshooting Article.

</supportagent>

Topics

Progress Update on a Data Refresh

Customers cannot perform the refresh themselves and raise tickets to have the refresh done by L2 agents. A common follow-up question is, “How much longer will the refresh take?” Support Agents can estimate the time based on the number of directories that need to be synced. There is no exactly accurate way to estimate the time remaining. 

The process can take a long time to complete. Please expect anything from a few hours to a few days, depending on the size of your Production instance and when the last refresh was performed. We have seen cases where the process has taken 6 days to complete because the binstore to copy was more than 1TB in size.

<supportagent>

See the article: Estimating Completion Time For The Hosted Data Refresh Process

</supportagent>

SSO Related Errors after a Refresh

When doing a data refresh there is an option to leave the SSO settings of the target UAT instance unchanged. Customers can request this when they request a refresh. Sometimes during the refresh process, a SAML keystore may get copied from Production to UAT as part of the binstore sync process. This can result in errors during UAT instance start-up.

If users are not seeing the SSO login page, then customer support can help troubleshoot this.

<supportagent>

Please see the article: Rolling Restart failing after a Data Refresh due to SSO Errors.

</supportagent>

Errors due to Corrupt Image Data in Database

After a Data Refresh, users may find that some images are not showing or that the HTML tile is no longer available. During large data refreshes, database entries for static objects like images can get corrupted. HTML tiles often link to static images and can fail to load if those images are not accessible.

<supportagent>

See the below articles:

• Fixing Database Corruption Due to Inflated objectIDs
• HTML Tile not available after Data Refresh - Hosted

</supportagent>