System Admin Stuff

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

2. The Local Product Repository

3. 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.

4. Managing Custom Code – Local Product Repo. SA Valet updating your license as part of update process:

5. 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

6. Managing Custom Code – Local Product Repo. Connect to LPR and update with latest software updates:

7. Managing Custom Code – Local Product Repo. New software updates ready for retrieval:

8. 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)

9. Toolkit Development / Management

10. Managing Custom Code – Best Practices • Custom code mostly similar to R17 • A few subtle (but important) differences: • Oracle, SQL, Unidata distributed code MUST • Be in toolkit • Not perform direct Unibasic file I/O (READ/WRITE) • 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

11. 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

12. Managing Custom Code – File/Element Diffs FS changes – File as BLOB, File on App Server

13. Managing Custom Code – Computed Columns • New language Java/J# “like” language. • All computed columns mustbe in new language XSTC.ALIEN.FLAG: string xResult1; key xKeyForeignPerson for file ForeignPerson; xKeyForeignPerson = vStcPersonId; xResult1 = vFperAlienStatus; return xResult1;

14. 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

15. Managing Custom Code – Computed Columns • DCC will generate two versions of each computed column: • Database version • 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 versions • Toolkit version (runtime use) • CC version (database use)

16. Managing Custom Code – Computed Columns DCC will generate two versions of each computed column

17. 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

18. 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.

19. 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…

20. Managing Custom Code – Moving Code • Development lifecycle not changed. • Best practice: • Start in development application environment • Move to test appenv for test/QA • Fix bugs and make changes back in development • Move back to test appenv for test/QA • (Repeat 3/4 as often as needed) • Move to production appenv once satisfied

21. 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

22. Managing Custom Code – Moving Code MDEF replaced by CDEC (Custom Declaration)

23. 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

24. Managing Custom Code – Moving Code CPKG –Build Release Package • Package one or more CDEC records together

25. 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

26. Managing Custom Code – Installing Code CSUG – Create Software Grouping (UT)

27. 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

28. Managing Custom Code – Installing Code SUGS – Software Update Group Selection • Detail to ISUG to install update(s)

29. LDAP Setup

30. 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

31. 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!

32. LDAP Configuration Add server in SA Valet with Create LDAP Server: Stored in DMIDIRSERV ‘LDAP’ record

33. 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’

34. LDAP Configuration Turn on/off LDAP with DMI Defaults tab

35. LDAP Configuration • All admin usernames must exist in LDAP • dmiadmin • prodadmin • devadmin • testadmin • lpradmin • etc