Overview
This guide outlines the steps to update your Sandbox environment which is done typically after a production upgrade. The following sections describe how to prepare, backup, and synchronize the Sandbox with the Production environment.
Backup And Prepare For Upgrade
Before making changes to your Sandbox environment, it is important to save a copy of the current configuration of the integration and database. Performing these backups ensures that the integration and database can be restored if unexpected issues arise during the upgrade process. To capture these backups, follow the steps below:
- Stop the current version of the web service for Sandbox. If there are any other services or background processes tied to the Sandbox service, stop them as well.
- Backup the integration files and database of the current Sandbox environment before making changes:
- Take a full backup of the database by running the ELEOS – Backup Database.sql scripting in the database connected to your Sandbox environment. See the subsection “Backing Up The Database” for the full SQL scripting and more information on this step.
- Backup the current integration files so they can be restored if needed. To back up all the source and setup files of the integration, you can create a zipped copy of the entire “EleosIntegration” folder for Sandbox. See the subsection “Backing Up The Integration” for more information on this step.
Note this “EleosIntegration” folder containing Sandbox may be named differently on your server.
3. Make a copy of the appsettings.json file, located in the root “EleosIntegration” folder for the Sandbox integration. This file contains application keys, database connection information, credentials, and other information specific to Sandbox. Copy this file to another location as it will be edited later.
Backing Up The Database
The following SQL scripting pasted below is the full definition of the ELEOS – Backup Database.sql file and the @BackupName parameter on the second line should be configured to a backup name of your choosing:
-- Set a Backup Name for this Iteration.
;DECLARE @BackupName VARCHAR(30)
;SELECT @BackupName = ''
/******************************************************************************************************************
TABLE: ELEOS.DatabaseHistory
******************************************************************************************************************/
;IF NOT EXISTS( SELECT NULL
FROM sys.schemas S
LEFT JOIN sys.tables T
ON S.[schema_id] = T.[schema_id]
WHERE S.[name] = 'ELEOS'
AND T.[name] = 'DatabaseHistory' )
BEGIN
;CREATE TABLE ELEOS.DatabaseHistory (
[EventDate] DATETIMEOFFSET NOT NULL DEFAULT(SYSDATETIMEOFFSET())
,[BackupName] VARCHAR(30) NULL DEFAULT('')
,[EventType] NVARCHAR(64) NULL
,[SchemaName] NVARCHAR(255) NULL
,[ObjectName] NVARCHAR(255) NULL
,[Definition] NVARCHAR(MAX) NULL
,[EventData] XML NULL
)
END
-- Add Columns Created in Subsequent Updates.
;IF ( COL_LENGTH('ELEOS.DatabaseHistory', 'BackupName' ) IS NULL )
ALTER TABLE ELEOS.DatabaseHistory ADD [BackupName] VARCHAR(30) NULL DEFAULT('')
/******************************************************************************************************************
SCRIPT: Audit Current Values.
******************************************************************************************************************/
;INSERT ELEOS.DatabaseHistory (
[EventType]
,[BackupName]
,[SchemaName]
,[ObjectName]
,[Definition]
,[EventData] )
SELECT [EventType] = O.[type]
,[BackupName] = @BackupName
,[SchemaName] = S.[name]
,[ObjectName] = O.[name]
,[Definition] = OBJECT_DEFINITION(O.[OBJECT_ID])
,[EventData] = NULL
FROM sys.schemas S
LEFT JOIN sys.objects O
ON S.[schema_id] = O.[schema_id]
WHERE S.[name] = 'ELEOS'
AND O.[type] IN ('P','TF','TR','FN')
Note, the scripting above will create backups for all ELEOS related SQL objects however if preferred to do your own entire SQL database backup and migrate the files of your Production database into Sandbox instead this can be done too and if done so step 5 of the “UPDATING SANDBOX” section should be skipped.
Backing Up The Integration
When looking for the Sandbox integration files to perform a backup the folder containing the Sandbox integration files may look something like the following:
It is this root folder that you will want to create a backup of by creating a zipped copy as shown in the example below:
Note your server may even have a folder dedicated to integration backups where this can be moved.
Updating Sandbox
Once the Sandbox environment has been backed up and prepared, the next step is to update Sandbox with the newer version of the application and SQL scripting. This process will update the Sandbox environment to match what is currently in the Production environment. Note if there are any SQL changes custom or specific to the Sandbox database, these next steps will overwrite those changes with the SQL scripting from Production. To proceed with updating Sandbox, follow the steps below:
- Delete everything in the root folder of the Sandbox directory before copying the new files into it. This ensures no old files remain that may not have been replaced.
- Copy all files from the root folder of Production and paste them within the empty root folder of Sandbox.
- Replace the appsettings.json file in the Sandbox root folder with the copy you saved earlier.
- Using a compare tool, compare the appsettings.json file in Production with the appsettings.json file in Sandbox. Confirm that settings that need to be specific to Sandbox, such as connection strings, keys, tokens, and division codes, are still configured correctly for Sandbox and check for any new settings introduced in Production that need to be added to the Sandbox appsettings.json file to support newer features. Add any missing settings that are found while preserving environment-specific values.
In the example comparison shown below, the Production appsettings.json file is represented on the left and the Sandbox appsettings.json file is represented on the right. The first group of settings highlighted in red on the left (and blank on the right) represents new settings from Production that need to be added to Sandbox. The setting highlighted in red below that on the left (and green on the right) represents a setting that should be different between Production and Sandbox since each would have their own division code.
- Apply the TMS specific install scripting provided from ASR upon request to update the ELEOS schema database objects with any newer scripting versions found.
- Restart the Sandbox service and any other associated services that were turned off with Sandbox and verify the application is running by logging into Sandbox as a test user and pushing data through for confirmation that things like messaging, workflow, and document scanning are all working as expected.
After following, completing, and verifying these above steps the Sandbox environment will be up to date with Production so that the latest features and functionality can be tested from your Sandbox integration.
Note, any updates from Production to Sandbox that rely on specific forms, actions, custom screens, or other Drive Axle specific items will require creating those in the Sandbox Drive Axle environment as well. If numerous Drive Axle changes need to be copied from Production to Sandbox, ASR can also assist in copying these Drive Axle specific items programmatically upon request.