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

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 must be 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: 1.Database version 2.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 1.Toolkit version (runtime use) 2.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: 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

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