Ben Jenkins – bljenkins1@waketech.edu
A huge shout out to Cinda Goff for her notes
and assistance, particularly with MECU settings
related to FTP parameters.
• Primary Non-Cinda Sources:
– NC Community Colleges “R18 Cloning Process”
– Colleague R18 Installation Procedures
– Managing Colleague Software Environments
Terminology
Directories
Cloning Steps (Data Refresh)
Mecu/Becu
Cloning
•The creation of an application
environment with the same
software and data as an existing
application environment.
Source Application Environment
• The application environment that is being
cloned
• (Production)
Target Application Environment
• The application environment that results from
cloning
• (Test)
Local Product Repository (LPR)
•A storage area for software updates
from Ellucian, customer licensing
information, and your own release
packages.
SA Valet
• The application tool that supports Datatel
system administration. Datatel SA Valet
administers the DMI servers on the Datatel
system and runs on a Microsoft Windows
machine. In Release 18, SA Valet is also the
interface for the release system.
DMI
•Datatel Messaging Interface. A
highly efficient message structure
for communication between DMI
Listeners and other Datatel
software components.
DMI Listeners
•Java based programs that interpret commands
between two software components that do not
have a common command set.
•Functionality: security, data transformation
services using XML/XSLT, thread management, Java
Runtime Environment (JRE)
DMI application server (APPS)
•Software that provides access to the Datatel
application. Most external software that interfaces with
Colleague uses this Listener to exchange
communications. A DMI application server has the
following additional specialized functionality:
• Application server for WebAdvisor, between the Web
server and Colleague, and other web software.
• The UniData runtime environment.
• Communications hub for EDX/partner interfaces.
DMI data access server (DBAS)
•Software that controls access to the data in the database
environment. This is the primary method for the
application environment to communicate with the
database environment. A Colleague installation includes a
DMI data access server for the product repository
database, as well as a DMI data access server in each
application environment for the Colleague database.
• JDBC-based extensible database interface is the DMI
data access server’s additional specialized functionality.
Datatel Application Server
•Colleague executables, running on a UniData
virtual machine (VM), and the DMI Listener,
that work together to make the Colleague
application run. In Release 18 architecture,
the database does not reside on this server.
Clients will likely have “production”, “test,”
and “development” application servers.
Datatel daemon
•Communications software used to access
DMI Listeners and to transfer files during
installation. It performs functions typically
performed by Telnet and FTP. The daemon is
designed to work with all operating systems
supported by Datatel. (Telnet and FTP are
not consistent across the operating systems).
Application Environment Directories
•Production, dev, test, etc
apphome
•Where Colleague executables are installed- In a Unidata
environment it also contains Colleague data
repository_das
•Where the DMI data access server (das) for the local product
repository is installed
datatel/coll18/coll18
•Where the local product repository (lpr) is installed in a Unidata
environment
das
•Directory where the DMI data access server for the Colleague
database is installed
svr01
•Directory where the DMI app server will be installed
1.
2.
3.
4.
5.
6.
7.
8.
Record Necessary Information
Prevent User Access
Delete Target Environment
Remove Existing Application Directories/Files
Recreate the File System
Copy Directories and Files
Clone Production
Cleanup
SA Valet > Target Environment
Screenshots, screenshots, and
more screenshots
• Listeners
• Authentication providers
• Webadvisor servlets
• Directory server info
Copy input intensive text into a
notepad document for future
pasting activities.
From the “R18 Cloning Process” document:
“After production directories are copied, but before the SA
Valet Clone Environment Wizard is run, users will be able to
login to the test environment, but will actually be
redirected to the production environment due to the
SQLENVINIT command in the copied LOGIN paragraph”.
We don’t want that…
To disable access to test:
• Log in to your webserver.
• With the Server Manager
open, Roles> Web Server>
Internet Information Services
• Under connections, expand
WEBUI-01, expand sites,
single click test.
• Under the Actions column
click the Stop button.
• Access SA Valet and expand the coll18 environment using
datatel as the username.
• Right click “test” and select Delete Application
Environment from the drop-down menu.
• Answer yes to the dialogue box, if you’ve got the correct
environment selected.
• Supply the datatel username and password.
• You should see:
• Wake Tech uses an IBM AIX operating system which allows
us to take advantage of umount and rmfs commands.
• See the “R18 Cloning Process” document for information
that may apply to your school’s OS.
• AIX also allows the use of “smitty”, the System
Management Interface Tool, for file system management.
• See the “R18 Cloning Process” document for information
that may apply to your school’s OS.
It’s recommended that you clone using a quiet source
(Production in this case) with no active users, listeners should
be shut down, and patch levels should be equal in the source
and target environments.
Move to your newly created “test” directory and copy apphome
over from “production” to the current directory.
• cp –rp /datatel/coll18/production/apphome . ***see note
below
• Note: After apphome there is a space and a dot.
• The copy takes 4+ hours to complete.
• Verify the copy is accurate
• cd apphome
• ls –l | wc –l
– note the record count
• cd /datatel/coll18/production/apphome
• ls –l | wc –l
– compare the record count to the one noted above
What if the totals don’t match???
• diff /datatel/coll18/production/apphome
/datatel/coll18/test/apphome | grep Only
• Look for any missing files and copy them from
production/apphome to test/apphome.
• Although the files above didn’t contain much, it felt better to end
with an even count.
Where are your WWW
files?
Some have chosen to
mount these files on a
RAM disk. For test you’ll
probably want to copy
them back to apphome.
Then…
• change ownership and group to “datatel” and “users”
• chown datatel:users WWW*
• change permissions to allow for read and write
• chmod 770 WWW*
Last part of the WWW files horror, I promise!!
• Log in to the Test environment in terminal mode and
remove the “webfiles/” portion from line 2 of the voc
entries for the WWW files listed above. The end result
for each should look similar to:
• Log in to SA Valet with the datatel user and credentials
– Assume from this point forward that, when dealing with SA Valet,
unless otherwise specified the log in user will be datatel.
• Log in to the SA Valet production environment
• With the production environment selected, click the Wizards
tab and Clone Application Environment.
• Use the documentation
you gathered at the
beginning of all this to
populate the information
fields in the wizard.
• When you get to step 6/7,
only clone listeners that
existed in both test and
production prior to cloning.
Uncheck any you don’t
need.
• You’ll have an opportunity to review your info at the
end
• If everything looks good click “Install”
• Hopefully you’ll see:
• Note: if the following message box appears at any
point, choose “No”.
Listeners in test that weren’t in production?
Right click test > Add New Listener
• Select a role for the listener:
• Provide listener info
• When the “DMI components to install”
message box pops up click OK.
– The installation of these components can take 15+
minutes
• Click OK.
• Right-click the test
environment in SA Valet.
• Select Manage DMI
Updates.
• Click the Installed tab.
• Ensure the Post-Install steps
are marked “Completed”.
Double click each listener in the environment,
to open the Listener Properties, and toggle on
Automatic Startup.
• Even if we don’t want the listeners to automatically start, they still need to
be toggled on and saved at least once, which writes the listener name into
the dmi.ini file.
• If you don’t want the datatel password to show up in plain text when a
Unix ps command is run (ps –ef | grep datatel) I would suggest keeping
automatic startup checked. If you check it, start it, then remove the
automatic startup the password will be hidden until the next time the
listener is started.
– Starting the listener with this box unchecked leaves the password visible.
• Set the Registry Server setting on the DB_LISTENER, APP_LISTENER, and
each Webadvisor listener (svr02, svr03, and svr04) to “localhost”.
• R18 Cloning Process step 2.5.1.12 has info on Restore UI4.x Windows
Registry Parameters
• Set up LDAP
– Start the app listener
– Right-click the Directory Servers folder, choose
Create LDAP Server
– Input settings and priveleged user password
– Test authentication
• Create LDAP and REGISTRY authentication
providers
• Manage LDAP Mappings
• Set up Web Server connections for WebAdvisor
• Stop/Start all listeners
• Re-enable “test” on your web server for access
to UI.
– Get to the cleanup portion of things immediately. After UI is
enabled you have the potential for big problems until BECU is
run. **SQLENVINIT command in your login paragraph***
– Or you could edit your “test” login paragraph with a text
editor before re-enabling your web server, which might not be
a horrible idea.
• Enable BECU access in TEST
– Log in to the test UI as Datatel
– SOD > datatel > add UT-ADMIN.PRIVILEGED
• Run BECU with Environment Cleanup and
Update Mode set to “Y”.
• Remove UT-ADMIN.PRIVILEGED security class
from the datatel user
• UWPR > provide server names
– If it won’t recognize the name use “…” and select
from the list.
• At the colon prompt (if using LDAP):
• SELECT ORG.ENTITY.ENV WITH OEE.DMIDIRSERV EQ
‘<<production directory server name>>’
• MODIFY ORG.ENTITY.ENV OEE.DMIDIRSERV EQ ‘<<test
directory server name’
• In UI, update the following if necessary:
•
•
•
•
•
•
•
•
UT-EDIL
EDSD
EDQM > stop the queue/start the queue
XNCI
AS DATATEL > PRSC and clear the schedule
RSPH and reset all queues
CF-ECPR
ECPG > Payment Gateway Definition > update with test
server info
• UI updates continued:
•
•
•
•
ECPA
MTXT > NEWID > add html indicating test account
XWMN
UT-HLKM > XWMN
– Change link description
– Change target server path list
The clone is complete!!!!
• Environ Cleanup Specs (MECU)
– Able to define element values to be changed
when BECU is run.
– LESS CLEANUP!!!
How it works:
• Identify a mnemonic that you would typically need to
use to modify parameters after a clone.
– In this example, ECPR, e-Commerce Providers
• Make note of:
– The target application(CORE)
– The name of the data element whose value we want to
modify (ECOMM.HOST.ADDRESS)
– The key to the record we’ll be modifying
(VERISIGN)
How it works (continued):
• (PRODUCTION) MECU > drill down on an empty line
• When prompted, provide the application we noted
How it works (continued):
• When prompted for a data element, provide it
How it works (continued):
• After reaching MECD, supply a key to the record you
wish to modify and a value for the data element.
How it works (continued):
• When you clone the definitions you’ve created will
be copied over to the target environment.
• Run BECU (IN THE TARGET ENVIRONMENT – TEST)
• The values are automagically updated!!!
• It’s just that easy!!