[Doc 8386 content is unavailable at this time.]

ECM/Imaging Environments

The following outlines the environments of our ECM/Imaging service. It details what is available in software and configuration in the environments. It also explains expectations for use of these environments.

1. PROD - other system's PROD; production
2. TEST - other system's QA; non-production
3. DEV - other system's TEST; non-production
4. SCHEMA - latest version sandbox; non-production

Environments

PROD

Description

• • Primary ECM/Imaging shared system
  • Basis for TEST, DEV, and SCHEMA environments

Server/Client Version:  24.1, 7.11.0.226 / 24.1 7.11.0.226

Client Installer and Instructions

Connection Profile Settings

• • Profile name: Anything you like, e.g. Production
  • Server name: imaging.services.wisc.edu
  • Port number: 6000
  • Type: production

TEST

Description

• • COPY of current production environment DB and OSM
  • Includes folders workflow, queues, groups, users, views, and documents
  • Has some ancillary services (sFTP, etc.)
  • No agents enabled in TEST by default; enabled manually as needed (contact Imaging team)

Server/Client Version:  24.1 7.11.0.226

Client Installer and Instructions

Refresh Interval

Monthly from PROD

Purpose

1. 1. Pre-production staging of new work
   2. Available for development projects shorter than 4 weeks
   3. Essentially full PROD environment so mapping to system objects should be accurate for pre-production testing

Connection Profile Settings**

• • Name: what ever you want, like "7Test"
  • Server: imagingtest.services.wisc.edu
  • See https://kb.wisc.edu/ecms/133013

** Imaging team retains the ability to "monitor" TEST

DEV

Description

• • COPY of current production environment DB
  • Includes folders, workflow, queues, groups, users as in PROD
  • NO real, sensitive data should ever be used; dummy data/documents only
  • NO documents or document data from PROD
  • Independent OSM (into which end-users can put new documents)
  • Some ancillary services as needed for end-user projects/testing

Server/Client Version:  24.1 7.11.0.226

Client Installer and Instructions

Refresh Interval

• • Refreshed for functional changes (patches, etc.)
  • 6-month refresh barring other exigencies

Purpose

1. 1. Provide an early testing environment for Imaging Team and customers with the latest builds/patch releases
   2. Provide an environment that is segregated from environments in which Imaging customers do development and testing of real processes
   3. NOTE: Almost always, the server/client builds will require a client different from that used in PROD, TEST, and SCHEMA; you will need a dedicated system (or a VM) to use the newer clients for connections so that the client for the other environments is not removed

Connection Profile Settings

• • Name: what ever you want, like "7Dev"
  • Server: imagingdev.services.wisc.edu
  • See https://kb.wisc.edu/ecms/133013

SCHEMA/DEV2

Description

• • COPY of current production environment DB
  • Includes folders, workflow, queues, groups, users as in PROD
  • NO real, sensitive data should ever be used; dummy data/documents only
  • NO documents or document data from PROD
  • Independent OSM (into which end-users can put new documents)
  • Some ancillary services as needed for end-user projects/testing

Server/Client Version:  24.1 7.11.0.226

Refresh Interval

• • Refreshed for functional changes (patches, etc.)
  • 6-month refresh barring other exigencies

Purpose

1. 1. Initial/Early end-user DEVELOPMENT work
   2. Create docs, etc. which go into its OSM. These objects cannot be copied/migrated to TEST or PROD
   3. iScript development
   4. If there is a need for elevated security in SCHEMA, the Imaging Team will provision it for you

Connection Profile Settings

• • Name: what ever you want, like "7Schema"
  • Server: schema.imaging.services.wisc.edu
  • See https://kb.wisc.edu/ecms/133013

Notes

• Perceptive Content's architecture, the inability to move or copy from one environment to another, places a burden on end-users, developers, or their agents who have to manually create users, groups, folders, workflows, queues, etc. as they work in the differing environments.
• There is NO way to copy or migrate work from one environment to the other. Document steps, configurations, attributes so objects can be recreated in other environments.
• Business Units are responsible for documenting their Imaging system use. This includes drawers, doctypes, custom properties, workflows, queues, routing rules, iScripts, views, groups, and users. This document is a Microsoft Excel workbook to help in doing so. The ECM/Imaging Team cannot create or maintain this documentation.
• Change Management is in effect for changes made to PROD. Change Management is required for systems that are routinely audited as is the Imaging system. When business units are ready to create/modify objects in PROD they will work with the ECM/Imaging team to schedule PROD work and change record submission.
• If work is estimated to take longer than 4 weeks use SCHEMA (NOT DEV) since TEST is running on a 4-week update cycle.
• Because iScript development requires developer access to the primary server installation host, *iScript development can only be done in SCHEMA. We are working towards a more automated way of script management using a code repository that will make working in this way less onerous.
• We can spin up separate environments for projects longer than 6 months; this will require funds from the business unit who require the special environment to cover labor, backup, storage, and VM costs.
• Using TEST for any development work that will take less that four weeks violates the QA model. TEST would not be a true QA environment as a QA environment is never used for any type of development work. Using TEST in this way was approved by Department Leads.