ECMS - ECM/Imaging Environments

This document explains the ECM/Imaging Environments.

8386 29059

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.

Server/Client version

Refresh Interval

Purpose

Provide an early testing environment for Imaging Team and customers with the latest builds/patch releases

Provide an environment that is segragated from environments in which Imaging customers do development and testing of real processes.

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.

Refresh Interval

Purpose

Create docs, etc. which go into its OSM. These objects cannot be copied/migrated to TEST or PROD

iScript development

If there is a need for elevated security in SCHEMA we will provide it to you.

Connection Profile Settings

Name: what ever you want, like "7Schema"

Server: schema.imaging.services.wisc.edu

Port: 6000

Type: production

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 Managementis in affect 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 (NOTDEV) 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.