Post on 30-Dec-2015
System Admin Stuff
The Local Product Repository
Managing Custom Code
LDAP Setup
The Local Product Repository
Managing Custom Code – Local Product Repo.
• Local Product Repository is a database• Contains all Datatel delivered software• Includes things you have and have not licensed
• Installing new software/modules much easier• Sign license agreement• Pay your bill• Install
• SA Valet checks/updates your license with each software download.
Managing Custom Code – Local Product Repo.
SA Valet updating your license as part of update process:
Managing Custom Code – Local Product Repo.
• Local Product Repository contains ALL software• Components:
• DMI (jar file) updates
• Envision source/specs
• Other types
• LPR Populated three ways:• Datatel delivered from start (via DVD)
• New software updates (download via SA Valet)
• Your custom code
Managing Custom Code – Local Product Repo.
Connect to LPR and update with latest software updates:
Managing Custom Code – Local Product Repo.
New software updates ready for retrieval:
Managing Custom Code – Local Product Repo.
• Local Product Repository requires little/no maintenance• Entirely managed from SA Valet• Communicates with each appenv as updates installed.• Think of as much improved Express Load repository
• LPR can be anywhere:• On own, separate server from Database and APP
• On same server as Database or APP
• All on one server (LPR, Database, APP)
Toolkit Development / Management
Managing Custom Code – Best Practices
• Custom code mostly similar to R17• A few subtle (but important) differences:
• Oracle, SQL, Unidata distributed code MUST1. Be in toolkit
2. Not perform direct Unibasic file I/O (READ/WRITE)
3. Not perform direct MIO calls
• Unidata combined does not have these limitations• But STRONGLY RECOMMENDED• Non-compliant code may not work in future releases• If time to implement is short, focus on computed columns first
Managing Custom Code – File/Element Diffs
• Custom Development in toolkit mostly same.• Some new fields on forms (mostly DE menu), such as
• DEL – Unenforced Secondary Pointer, Join File Key Routine
• FS – File as BLOB, File on App Server
• FS behaves a little differently• FS used to create new file immediately
• Now new file not created until first element is added
• Some other subtle changes• Mostly for Oracle, SQL or distributed Unidata
Managing Custom Code – File/Element Diffs
FS changes – File as BLOB, File on App Server
Managing Custom Code – Computed Columns
• New language Java/J# “like” language.• All computed columns must be in new language
XSTC.ALIEN.FLAG:
string xResult1;key xKeyForeignPerson for file ForeignPerson;xKeyForeignPerson = vStcPersonId;xResult1 = vFperAlienStatus;return xResult1;
Managing Custom Code – Computed Columns
• MGCC will migrate and convert your existing CC
• Run your scanners NOW – early and often!
• Now written and maintained in toolkit ONLY on DCC• DVF and RDVF are inq-only – do NOT use for CC• (Take DVF/RDVF away from ALL end users!)
• All subroutines called by CC must be IS typed
Managing Custom Code – Computed Columns
• DCC will generate two versions of each computed column:1. Database version2. Runtime version
• Database version in language native to your database• Uniquery - PL/SQL - Stored procedure
• Runtime version is Unidata subroutine which can be called by any code/process.
• GENing IS Subroutines produces two versions1. Toolkit version (runtime use)2. CC version (database use)
Managing Custom Code – Computed Columns
DCC will generate two versions of each computed column
Managing Custom Code – Computed Columns
GENing IS Subroutines produces two versions
• Envision/runtime version produced like before• Database version produced after runtime:
Warning message is OK – Database doesn’t know COMMON
Managing Custom Code – Computed Columns
• appl.CDD contains DCC source• See new COMPUTED.COLUMN.CODE field
• RTGEN.SOURCE contains runtime subroutines• Both source and compilied (object) code
• CC.SRC.DIR contains IS subroutine source code• DATATEL.OBJ contains IS subroutine object code
• Don’t edit these files directly – use DCC!
• Examine them to learn how/what gets placed where.
Managing Custom Code – Computed Columns
• SQL Server CC deployed as DLLs• Must place CC into ‘Bundles’• Must go thru Bundle Generation
• JEFF O - perhaps reference SQL session for Herdy/Tina• Add anything you know that I don’t here…
Managing Custom Code – Moving Code
• Development lifecycle not changed.• Best practice:
1. Start in development application environment
2. Move to test appenv for test/QA
3. Fix bugs and make changes back in development
4. Move back to test appenv for test/QA
5. (Repeat 3/4 as often as needed)
6. Move to production appenv once satisfied
Managing Custom Code – Moving Code
• MDEF replaced by CDEC (Custom Declaration)• Works in precisely same manner as MDEF• No more Install account specified• File Specifications includes
• Data elements (fields)
• Computed Columns (all components)
• Use SAVEDLISTS to narrow to specific ones
• CDEC saves data in MOVEINFO local to that appenv
Managing Custom Code – Moving Code
MDEF replaced by CDEC (Custom Declaration)
Managing Custom Code – Moving Code
• CPKG –Build Release Package - your new best friend• Replaces MTST• Can include one or more MOVEINFO (CDEC) records• Builds RELEASE_PKG (and other) records in LPR
• Your package installed just like Datatel software updates• You can add pre/post install comments• You can specify prerequisites• You can rebuild a package (with changes) anytime• LPR will only install latest version of package
Managing Custom Code – Moving Code
CPKG –Build Release Package• Package one or more CDEC records together
Managing Custom Code – Installing Code
• CSUG – Create Software Grouping (UT)• Groups one or more Release Packages from LPR• Can install any software update anytime!
• Software updates “know” prerequisites
• You must accept all prereqs to install an update
• No more date-driven software updates!• No more playing with dates to ‘fool’ Express Load
Managing Custom Code – Installing Code
CSUG – Create Software Grouping (UT)
Managing Custom Code – Installing Code
• SUGS – Software Update Group Selection• Displays all software groups and status for that appenv• Can select one at a time to view/install/post install• Can also drill down to view
• Documentation
• Pre/Post Install
• Items (files/records)
• Can record your own comments for all or specific appenv
Managing Custom Code – Installing Code
SUGS – Software Update Group Selection• Detail to ISUG to install update(s)
LDAP Setup
LDAP Configuration
• R17 LDAP was separate for each DMI listener• Could have one DMI with LDAP authentication
• Could have another DMI with registry authentication
• R18 LDAP configured for entire appenv• LDAP setting stored in DMIDEFAULTS
• Used for all DMI listeners in appenv
LDAP Configuration
• WebAdvisor guest login must exist in LDAP• R17 did not require this• Some sysadmins do not want a ‘guest’ user in LDAP• Can change the ‘guest’ username to something else• Not sure where/if this is documented• Datatel walked us through steps:
• Create new PERSON record• Create new ORG.ENTITY.ENV with different username• Change WebAdvisor to use new username• Add new guest username and password (*) to LDAP• Leave old guest login in ORG.ENTITY.ENV!
LDAP Configuration
Add server in SA Valet with Create LDAP Server:
Stored in DMIDIRSERV ‘LDAP’ record
LDAP Configuration
• Turn on/off LDAP with DMI Defaults tab• Can set Synchronization
• Can set Authentication
• Can allow/disable password changes
• Stored in DMIDEFAULTS ‘DMIDEFAULTRECORD’
LDAP Configuration
Turn on/off LDAP with DMI Defaults tab
LDAP Configuration
• All admin usernames must exist in LDAP• dmiadmin
• prodadmin
• devadmin
• testadmin
• lpradmin
• etc