System Admin Stuff The Local Product Repository Managing Custom Code LDAP Setup.

Post on 30-Dec-2015

221 views 1 download

Transcript of System Admin Stuff The Local Product Repository Managing Custom Code LDAP Setup.

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