1 / 35

System Admin Stuff

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

cian
Download Presentation

System Admin Stuff

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related